From tcpm-bounces@ietf.org Fri Nov 02 03:02:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InqWP-0001qs-Tu; Fri, 02 Nov 2007 03:00:49 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1InqWO-0001oZ-67 for tcpm-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 03:00:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InqWJ-0001kl-CE for tcpm@ietf.org; Fri, 02 Nov 2007 03:00:43 -0400 Received: from web31711.mail.mud.yahoo.com ([68.142.201.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InqWD-0002n4-2k for tcpm@ietf.org; Fri, 02 Nov 2007 03:00:43 -0400 Received: (qmail 59364 invoked by uid 60001); 2 Nov 2007 07:00:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=abYEyR69nq22hv+HdAe4IULuV5y1Rl++3t9kAD+7cU/sUKcuXPlYpp0yb9TVKMCg0Cs/WQ5uJnmhbrxsTti411whkzOX9W7yau+TawwD5fsDm7jLbpQpaC/lyO6viN/sMeOD7nTLxY9TfhtLRKlZBuey/+Fha3ZMeWfpIFsjv8w=; X-YMail-OSG: DYrXJAUVM1l3WC0bMS9L1Xz4OM2_sO0tq2O4Wn7cyrWnAnZDDqm9hwIS.Ih6tmqu8BHlbA05ojytp6Q5EjmV6MfebtmTBO3xW5gM7lCbb62Sn6k- Received: from [67.161.9.166] by web31711.mail.mud.yahoo.com via HTTP; Fri, 02 Nov 2007 00:00:22 PDT X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152 Date: Fri, 2 Nov 2007 00:00:22 -0700 (PDT) From: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? To: John Heffner , Mahesh Jethanandani MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <359024.58790.qm@web31711.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) 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 Clearly there seems to be no consensus on where the problem lies. I've heard that it's not a transport problem, and that the responsibility for mitigating the problem lies with a) sockets API, b) OS, and c) the application. That's as varied a response as one can get... It seems to me that all of these approaches have a key flaw in that they leave the solution to be handled by a proprietary method of defending against the attack. Solving the problem in the transport layer would make the solution a standard one and applicable to environments a) where the standard BSD socket API is not the transport layer interface of choice, b) would work for user space or kernel-less TCP implementations such as TCP proxies and hence would not have to depend on the OS, and c) certainly would not have to be at the mercy of the plethora of TCP based applications out there which have not done anything abt it so far and are making the entire server vulnerable in the process. ----- Original Message ---- From: John Heffner To: Mahesh Jethanandani Cc: tcpm@ietf.org Sent: Tuesday, October 30, 2007 11:58:58 AM Subject: Re: [tcpm] Is this a problem? Mahesh Jethanandani wrote: > Folks, > > We have documented a case of HTTP servers that are prone to resource starvation with the use of a small user level program. The program does not require any special privileges or changes in the kernel. The user level program on the client opens a connection to a HTTP server, sends a GET request for a large file (larger than the advertised window of the client) but never reads the response. This problem has been well documented for at least seven years. http://shlang.com/netkill/ http://shlang.com/netkill/20000421-netkill-bugtraq-announcement.txt > Three well-known, public sites were tested for this vulnerability. The two most common HTTP servers, Apache and IIS were the target. While one site had put mitigation technique in place, the others had none. With the latter two we were able to hold connections in ESTABLISHED state for days. The former site had a mitigation in place with a fixed timeout of 11 min., which was easy to guess and work around. > > We (the authors) believe that this is a huge problem. What do you folks feel? I personally believe it is a problem, but the absence of wide-spread attacks using this technique leads me to believe that other attacks are still more effective. All the same, I would like to see more widespread defense against it. > Previous responses to this documentation has been that it is a application problem. It is clear from our experimentation that most HTTP servers (and FTP too) have not implemented any mitigation techniques. We believe that this problem exists across the whole range of TCP based applications prevalent on the internet, although our experiments were limited to the web application. Where applications have tried to put mitigation techniques in place, workaround has been easy. This is mainly because applications do not have the same amount of visibility as TCP does on the state of the connection. I think nearly all responses (including mine) have been of the opinion that this is not a transport problem. However, I think this is not necessarily an application problem, either. Since the contended resource is system memory, the best place to implement a fairness policy is in the operating system -- possibly but not necessarily in the kernel (for OS's where such a distinction applies). -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 02 03:21:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InqpR-0007Eh-Ac; Fri, 02 Nov 2007 03:20:29 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1InqpP-0007DN-K0 for tcpm-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 03:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InqpP-0007Cl-AH for tcpm@ietf.org; Fri, 02 Nov 2007 03:20:27 -0400 Received: from mail4.sea5.speakeasy.net ([69.17.117.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InqpJ-0003NL-2s for tcpm@ietf.org; Fri, 02 Nov 2007 03:20:27 -0400 Received: (qmail 18750 invoked from network); 2 Nov 2007 07:20:05 -0000 Received: from imac.asomi.com (cait@asomi.com@[66.92.48.27]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 2 Nov 2007 07:20:05 -0000 From: cait@asomi.com(speakeasy) To: MURALI BASHYAM In-Reply-To: <359024.58790.qm@web31711.mail.mud.yahoo.com> Subject: Re: [tcpm] Is this a problem? References: <359024.58790.qm@web31711.mail.mud.yahoo.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Fri, 2 Nov 2007 00:20:04 -0700 X-Mailer: Apple Mail (2.912) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 2, 2007, at 12:00 AM, MURALI BASHYAM wrote: > > Clearly there seems to be no consensus on where the problem lies. > I've heard that it's not a transport problem, and that the > responsibility for mitigating the problem lies with a) sockets API, > b) OS, and > c) the application. That's as varied a response as one can get... > There is no need for TCPM to decide which of the three is the best solution, since all three solutions can interoperate on the wire. The fact that this behavior is not specified by TCP is actually a strength. It allows different hosts to use very different stack strategies. Even for web servers one size does not fit all. What makes sense for a high volume site supporting a large number of virtual sites does not make sense for an embedded web server in a home router that supports configuration. And once you vary the ULP the variations get even greater. You need to find a more narrowly focused forum that can judge whether the proposed solutions are proper for Web servers (or whatever). But these are all issues that the transport layer needs to avoid. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 02 09:32:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InwbX-0002yH-Ct; Fri, 02 Nov 2007 09:30:31 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImYVW-0004nu-LH for tcpm-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 13:34:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImYVW-0003zd-9P for tcpm@ietf.org; Mon, 29 Oct 2007 13:34:34 -0400 Received: from dsl.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImYV8-0002v1-8Q for tcpm@ietf.org; Mon, 29 Oct 2007 13:34:11 -0400 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA100459207; Mon, 29 Oct 2007 18:33:27 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id SAA13049; Mon, 29 Oct 2007 18:33:24 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200710291733.SAA13049@TR-Sys.de> To: fernando@gont.com.ar, lars.eggert@nokia.com Date: Mon, 29 Oct 2007 18:33:24 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Fri, 02 Nov 2007 09:30:29 -0400 Cc: tcpm@ietf.org Subject: [tcpm] draft-ietf-tcpm-tcp-uto-06 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 Hello, I've also studied the latest rev. of your TCP UTO draft, draft-ietf-tcpm-tcp-uto-06, and would once again like to point out a few nits I found there. (I do not want to engage in the requirements language discussion as well :-)) (1) Terminology -- Section 3, 3.1 et al. Section 3 newly has introduced the variable 'USER_TIMEOUT': USER_TIMEOUT TCP's USER TIMEOUT parameter, as specified in [RFC0793]. The subsequent text uses 'user timeout', 'USER TIMEOUT', and 'USER_TIMEOUT' in a way that seems to be a bit confusing; the distinction between these terms, and the rationale for selecting one of these terms remains unclear in some places. In particular, according to the quoted definition, I do not see a significant difference between 'USER TIMEOUT' and 'USER_TIMEOUT' that might justify wording like: ... the local TCP USER TIMEOUT (USER_TIMEOUT) ... (Section 3.1, 2nd paragraph). Also, the title of Section 3.1 contains 'User Timeout' whereas most occurrences of 'user timeout' have been changed to 'USER TIMEOUT' in the body of Section 3.1. I propose to reconsider the distinction, and to use 'USER TIMEOUT' only in the immediate context of RFC 793 as opposed to this draft; most of the occurrences of 'USER TIMEOUT' should better be replaced by 'USER_TIMEOUT' (the TCP state variable) or 'user timeout' (the abstract concept as seen from the application / user). Also, the names of the two variables, USER_TIMEOUT and LOCAL_UTO, are not good mnemonics for the intended purpose of these variables; IMHO, the naming should be reconsidered again (I already had argued in this matter). In particular, 'LOCAL_UTO' now has much diminuished *local* significance, it it just the value advertised to the peer (=3D> my new proposal: ADV_UTO ); USER_TIMEOUT ist the important local state variable, and there's now only a loose coupling between both. (2) Section 3 In the second-to-last paragraph of Section 3, there's an unnecessary word replication: vvvvvvvvv vvvvvvvvv [...]. Section 3.1 discusses user timeout limits and discusses potentially problematic effects of some user timeout settings. Perhaps, the second instance should be removed from the text: [...]. Section 3.1 discusses user timeout limits and | potentially problematic effects of some user timeout settings. (3) Section 3.3 In the last paragraph, remove the duplicate full-stop in "connection.." Kind regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 02 09:32:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InwbZ-00031B-HF; Fri, 02 Nov 2007 09:30:33 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1InJyh-0006DX-9q for tcpm-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 16:15:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InJyg-0005yV-VJ for tcpm@ietf.org; Wed, 31 Oct 2007 16:15:51 -0400 Received: from dsl.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InJyT-0006Gl-FA for tcpm@ietf.org; Wed, 31 Oct 2007 16:15:38 -0400 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA111791694; Wed, 31 Oct 2007 21:14:54 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA18697; Wed, 31 Oct 2007 21:14:54 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200710312014.VAA18697@TR-Sys.de> To: tcpm@ietf.org Date: Wed, 31 Oct 2007 21:14:53 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-Mailman-Approved-At: Fri, 02 Nov 2007 09:30:29 -0400 Subject: [tcpm] draft-sridharan-tcpm-ctcp-00 -- mail delivery problem 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 wanted to submit a big bunch of editorial comments on the I-D, draft-sridharan-tcpm-ctcp-00, in private communications to the authors of this draft, because this kind of comments is deemed clutter to the mailing list (I'm not on regularly). Unfortunately, some responsible persons within the affiliation of the authors of this draft apparently have arranged to filter DNS traffic to their public DNS servers by *source* port, effectively disabling the possibility to perform MX record lookups from any recursive DNS cache server behind a NAT/NAPT access router, where the source port used on the public interface cannot be controlled. This also makes clients of the well-known public mail service hosted by that company unreachable, and it makes the web and ftp servers of that company invisible for this site and topologically similarly structured sites. This problem persists since a couple of months, and has not existed before. The analysis performed shows that DNS requests sent to any one of the five public DNS servers of that company always time out. Support personal of our ISP has verified that these DNS servers do respond to DNS requests with source port 53, but don't respond to DNS requests with other source ports that result from the port mapping of the NAPT router. It should be noted that within the last year or two, we already had suffered from similar (mis)behavior of other sites, e.g.: maintainers of significant Internet infrastructure and registries for very large gTLDs, important players in network security, and some large academic campus networks. In all these cases, the same symptoms had been observed, and after an explanation of the problem, showing that sending DNS requests with *any* UDP source port is perfectly legal (as per all relevant RFCs), the problem has been resolved quickly. (This problem also already has been submitted to the DNSOP WG in 2006.) In this case however, any attempts so far to make the responsible persons aware of the problem (using third-party-forwarded messages) unfortunately have not even been responded to, within the last two months. This note is another attempt to raise awareness of the problem and restore full communications possibilities between IETF participants. Thus, I kindly ask the authors of the draft to try to investigate (or perhaps delegate) the problem appropriately. Thankyou in advance. Best regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 02 09:32:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InwbZ-0002zW-A6; Fri, 02 Nov 2007 09:30:33 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1InGjC-0006WV-Gq for tcpm-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 12:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InGjC-0006Qt-7K for tcpm@ietf.org; Wed, 31 Oct 2007 12:47:38 -0400 Received: from dsl.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InGj0-0007Mu-B4 for tcpm@ietf.org; Wed, 31 Oct 2007 12:47:34 -0400 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA110579167; Wed, 31 Oct 2007 17:46:07 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA18397; Wed, 31 Oct 2007 17:46:06 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200710311646.RAA18397@TR-Sys.de> To: toby.moncaster@bt.com, bob.briscoe@bt.com, arnaud.jacquet@bt.com Date: Wed, 31 Oct 2007 17:46:06 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 X-Mailman-Approved-At: Fri, 02 Nov 2007 09:30:29 -0400 Cc: tcpm@ietf.org Subject: [tcpm] draft-moncaster-tcpm-rcv-cheat-01 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 Hello, after studying the Internet-Draft authored by you, draft-moncaster-tcpm-rcv-cheat-01, I'd like to submit a few comments, mostly addressing textual flaws I found in that memo. The items below are presented in (almost) textual order. To give more context, sometimes I quote larger blocks of text literally and show the replacement proposed using the shorthand notation: --- I use change bars ('|' in column 1) and occasionally up/down pointing marker lines ('^^^'/'vvv') to emphasize the location of textual issues and/or proposed corrections. Modified text has been re-adjusted to match RFC formatting rules, where appropriate. I also try to accomodate published RFC-Ed policy on style and punctuation etc. in my proposals. (1) General The prologue of the draft says: Changes from previous drafts (to be removed by the RFC Editor) From -00 to -01: Draft rewritten to emphasise testing for non-compliance. Some changes to protocol to remove possible unwanted interactions with other TCP variants. Sections added on comparison of solutions and alternative uses of test. Unfortunately, this change apparently has not been performed perfectly. I still find numerous instances of old-style wording in the text, like "cheating", "honest", "dishonest", "misbehaving", etc. ... I recommend that this should be reconsidered systematically. Among the terms listed, only "misbehaving" might be appropriate in certain places, in the new spirit of the draft. For brevity, below I omit quoting most occurrences of this issue unless there are other reasons to do so as well, or they appear particularly significant. I hope that the above list of terms is exhaustive, such that these places can be located easily. (2) Section 1 (2a) Typo: In the 3rd paragraph, change "optimisitic" --> "optimistic". (2b) In the 8th paragraph, In order for a sender ... I recommend to apply the following clarification and improvement of language: [...] Instead, the sender | emulates network re-ordering then network loss to test that the | receiver reacts as it should as defined within the basic TCP protocol. It is important that the level of emulated re-ordering that such a test introduces should not adversely impact compliant receivers. --- [...] Instead, the sender | emulates network re-ordering, and then network loss, to test that the ^^^^^ ^ | receiver reacts as it should according to the basic TCP protocol. It ^^^^^^^^^^^^ is important that the level of emulated re-ordering that such a test introduces should not adversely impact compliant receivers. (3) Section 5.1 The first paragraph twice says "re-transmitted" when in fact it refers to the *first* transmission of a packet that has been artificially delayed as requested by the test procedure. I propose to replace "re-transmitted" by "transmitted". However, in an implementation these transmissions might be handled using code otherwise used for re-transmissions; thus alternatively it might arguably make sense to just (single-/double-)quote this word to indicate the reuse/abuse of code. As this background might not be immediately clear to a reader (without further elaboration), I recommend the former change. (4) Section 5.2 In the first paragraph of Section 5.2, the draft says: [...]. The nonce works by randomly setting the ECN field to ECN(0) or ECN(1). It then maintains the least significant bit of the sum of this value and stores the expected sum for each segment boundary. [...] The "It then maintains ..." is potentially misleading. I recommend to substitute inequivocally "The sender maintains ...". Furthermore, I suggest to add the definite article: "in experimental [RFC3540]" --> "in the experimental [RFC3540]" Altogether, the initial part of the modified first paragraph will be: The authors of the ECN scheme [RFC3168] identified the failure to echo ECN marks as a potential attack on ECN. The ECN nonce was | proposed as a possible solution to this in the experimental [RFC3540]. It uses a 1 bit nonce in every IP header. The nonce | works by randomly setting the ECN field to ECN(0) or ECN(1). The | sender then maintains the least significant bit of the sum of this value and stores the expected sum for each segment boundary. At the receiver end, the same 1-bit sum is calculated and is echoed back in the NS (nonce sum) flag added to the TCP header. [...] (5) Section 6 According to (1), change the title: 6. The Test for Receiver Cheating --- 6. The Test for a Non-conforming Receiver (6) Section 6.2.1 In the first paragraph od Section 6.2.1, the draft says: [...]. If K is less than 5, the sender can proceed straight to the deterministic test. [...] I'm in doubt whether that is a good idea, and the test be reasonably performed in this case. When the current [send] window size K is less than 5, arguably the receiver does not obtain an inappropriate share of the sender's (and the network's) resources, and it is quite unlikely that the receiver is misbehaving / non-conformant. In the absence of a strong indication to this end, it seems to be not justified and invasive to incur the performance penalty of the deterministic test. Thus, it seems to me that in the case of K < 5, execution of the test should be strongly discouraged in general. There might be an exception to this: working in a dedicated test scenario; but that should only be done under explicit administrative control, not routinely by a deployed (e.g. web / media distribution) server. Should I err in my diagnosis and you have strong arguments for indeed immediately turning to the deterministic test in the case K < 5, that should perhaps be elaborated upon in the text. (7) Section 6.2.5 (7a) In the first bullet, there is an unpleasant use of `optional plural`, "a non-compliant receiver(s)". IMHO, it would not harm to simplify the language using plural anyway: o Any TCP sender MAY check the compliance of its receivers using the probabilistic test periodically and randomly. In particular, it would be advantageous for any sender that is heavily loaded to | identify if it is being taken advantage of by a non-compliant | receiver(s). --- ^^^ ^^ o Any TCP sender MAY check the compliance of its receivers using the probabilistic test periodically and randomly. In particular, it would be advantageous for any sender that is heavily loaded to | identify if it is being taken advantage of by non-compliant | receivers. (7b) The 3rd bullet of Section 6.2.5 says: OLD: o To perform the test, the sender MUST select a segment N. The transmission of this segment MUST be delayed by D places. D MUST lie between 2 and K-2 exclusively where K is the current size of the transmit window. D SHOULD lie between 2 and 6 exclusively except in those circumstances when a receiver has failed to respond as expected to an earlier test but the sender chooses not to proceed to the deterministic test. D MUST be generated pseudo- randomly and unpredictably. The actual delay SHOULD be such that the receiver can't distinguish the test segment from the background traffic. If there are less than D segments worth of data in the send buffer then the test should be aborted. I diagnose abuse of RFC 2119 language here. (I remember the allegory, "the IETF has a salt shaker for RFC 2119 language", attributed to such usage patterns, once applied by one of the authors of that RFC.) 'MUST' should be avoided whenever a protocol entity has no reasonable alternative behavior to achieve the intended goal. Thus, I recommend to get rid of the first two instances of 'MUST' there. I also strongly recommend to list the preliminary steps required in one place, at the start of the paragraph. The phrase, "D SHOULD lie in between 2 and 6 exclusively ..." IMHO hides the fact that this range for D is rather small, namely "between 3 and 5 inclusively, i.e. {3,4,5}. (NB: This small range makes the stated requirement of unpredictability questionable for low values of K.) Since only the upper limit, D < 6, is introduced here as a new requirement, it might be worth to emphasize that. (BTW: Since the text deals with natural numbers, it might generally be preferable to specify in prose text the much more intuitive *inclusive* limits of intervals instead of *exclusive* limits; admittedly, in formulae, using '<' is attractive over '<=3D'.) Finally, the phrase, "the test should be aborted" at the end of the paragraph seems to be inappropriate. At this stage, no externally visible traces of the attempt to perform the test have been created; all that has been done was to select (within close boundary conditions) two random integers. Perhaps, "abolished" or "omitted" would be better terms than "aborted" here. As explained later in the draft, not omitting the test when there are less than D segments in the send buffer incurs a significant performance penalty and security risk; therefore, in this case I opt for a stronger requirements language. Taking altogether, a possible revised version of that bullet is: NEW: | o To perform the test, the sender selects a segment N and a delay D, | in order to delay the transmission of this segment by D places. D MUST lie between 2 and K-2 exclusively where K is the current size | of the transmit window. D SHOULD be less than 6, i.e. be one of | 3, 4, or 5, except in those circumstances when a receiver has failed to respond as expected to an earlier test but the sender chooses not to proceed to the deterministic test. D MUST be generated pseudo-randomly and unpredictably. The actual delay SHOULD be such that the receiver can't distinguish the test segment from the background traffic. If there are less than D | segments worth of data in the send buffer then the test SHOULD be | omitted. (7c) For concerns regarding the 4th bullet, see (6) above! (7d) The 7th bullet uses sluggish language, not distinguishing properly between segment numbers (used in the text for explanatory purposes) and TCP (ACK) sequence numbers (counting octets). `N` has been introduced as a segment number; hence the following text gives a wrong indication of a sequence number: "N-1". o If the sender receives any duplicate acknowledgements during a testing phase it MUST check to see if they were generated by | segment N (i.e. the acknowledged sequence number will be N-1). If they are caused by segment N the sender SHOULD NOT react as if they are an indication of congestion. This text should be revised to use precise language. (7e) Various `phases` are always named with a definite article, e.g. "in the slow start phase", with the exception of the "test phase" newly introduced by this draft. I strongly recommend to uniformly change "in a test phase" --> "in the test phase" as well, in subsequent bullets of Section 6.2.5 (4 instances), and in Section 6.3.3 (one instance). (7f) In the newly introduced second-to-last bullet, apparently an "over-shooting" has happened, induced by Section 6.5.1: OLD: o If a sender is in a test phase and the next segment to be | transmitted has either the SYN or RST bits set, then it must immediately stop the test, and transmit segment N before | transmitting the SYN or RST segment. The TCP SYN flag is only carried only in the very first TCP segment sent by either party (not counting possible retransmissions). It makes absolutely no sense to perform the test for the first segment since the 3-way-handshake requires the SYN / SYN-ACK segment at the very beginning of any TCP connection. Setting SYN on an outgoing segment later is non-conformant at best -- isn't it? Note: AFAICS, SYN segments can only be *received* on a synchronized TCP connection in case of a sender restart (and for the sender, this would have been the first segment of a new connection!); protecting against connection abort due to the reception of spoofed such segments is what tcpsecure deals with. The pre-existing text already only allows the test to be performed for a *data* segment N, thus already excluding its applicability to the initial (SYN / SYN-ACK) segment of a connection. To enter the test phase, the sender must already have an existing connection, and no SYN segment should have to be transmitted then. Hence, "SYN or" should be removed from the quoted bullet. Contrary to that, it might be worth considering the FIN flag. I leave the reasoning as an exercise and just propose to add, as a catch-all for completeness, the FIN flag to the text, replacing the two occurrences of FIN: NEW: vvv(7d) | o If a sender is in the test phase and the next segment to be | transmitted has either the FIN or RST bits set, then it must immediately stop the test, and transmit segment N before | transmitting the FIN or RST segment. The text in Section 6.5.1 should be reconsidered in the light of these arguments. (8) Section 6.3.2 The last sentence in the first paragraph of that section says: [...] A sender would be expected to close a connection with any receiver that had failed the deterministic test, but this draft was not written to specify what a sender should or must do if a receiver fails the test, only how to establish such non-compliance. IMHO, this phrase partly contradicts the statements made in Section 6.4, which is the proper place to discuss that topis. Thus, this sentence should be dropped entirely. (9) Section 6.3 Apply (7f) to the second-to-last bullet here as well. (10) Section 6.5.1 As explained in item (7f) above, TCP Secure deals with receiver processing, whereas this draft deals with sender processing only. It might be true that considering TCP Secure has drawn the attention to (SYN and) RST, but I do not understand the rationale given in 6.5.1, under the (accepted) hypothesis that the TCP sender performing these tests is assumed to follow conformant behavior and not perform one of the attacks considered in the tcpsecure draft, against its receiving peer. Somehow, sending and receiving behavior seem to have been messed up in the text. Should I be wrong in this diagnosis, that might be an indication of that the text needs more elaboration on the topic. Otherwise, I question whether this section is appropriate. (11) Section 6.5.2 -- improper text The description of the Nagle algorithm is wrong; Nagle deals with sending only, not with waiting for acknowledgements to send. The Wikipedia entry for "Nagle Algorithm" contains all you want. I found it immediately as the number one top entry in YAHOO for this key-phrase. Please revise the initial part of Section 6.5.2 accordingly. And, a ref. to RFC 896 should perhaps be added for this matter. (12) Section 6.5 -- important additional consideration There are important interactions with another TCP extension. AFAICS, testing should generally not be performed when BETS has been negotiated in the 3-way-handshake, using TCP Option #20. BETS (Best Effort Transport Service) is intended for the semi- reliable transport of bulk data to loss-tolerant receivers, which are explicitely allowed to send ACKs for non-received / damaged TCP segments, after exceeding some configurable margins. For details, please refer to the SCPS-TP specification: "Space Communications Protocol Specification -- Transport Protocol"; Blue Book, Issue 2; October 2006. (This is CCSDS 714.0-B-2, available for download on the CCSDS web site: (BTW: Thanks to Keith L. Scott, kscott (at) mitre (dot) org, for pointing me to the Space Data Specifications for the first time!) Best regards, Alfred H=CEnes. -- = +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 02 18:31:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io4ye-0005sx-2E; Fri, 02 Nov 2007 18:26:56 -0400 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Io4yc-0005rb-Ht for tcpm-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 18:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io4yc-0005rT-8G for tcpm@ietf.org; Fri, 02 Nov 2007 18:26:54 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io4yU-0003pg-T4 for tcpm@ietf.org; Fri, 02 Nov 2007 18:26:54 -0400 Received: from [128.9.160.144] (nib.isi.edu [128.9.160.144]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA2MQS9o023131; Fri, 2 Nov 2007 15:26:28 -0700 (PDT) Message-ID: <472BA410.5070509@isi.edu> Date: Fri, 02 Nov 2007 15:26:24 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: speakeasy Subject: Re: [tcpm] Is this a problem? References: <359024.58790.qm@web31711.mail.mud.yahoo.com> In-Reply-To: X-Enigmail-Version: 0.95.3 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 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="===============1915959761==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1915959761== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5B124C2DCB64B22B8650D35B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5B124C2DCB64B22B8650D35B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable speakeasy wrote: >=20 > On Nov 2, 2007, at 12:00 AM, MURALI BASHYAM wrote: >=20 >> >> Clearly there seems to be no consensus on where the problem lies.=20 >> I've heard that it's not a transport problem, and that the >> responsibility for mitigating the problem lies with a) sockets API, b)= >> OS, and >> c) the application. That's as varied a response as one can get... >> >=20 > There is no need for TCPM to decide which of the three is the best > solution, since all > three solutions can interoperate on the wire. I agree - the fact that these all vary is less important to TCPM than the fact that none have anything to do with TCP. Yes, this is a problem for which a variety of solutions exist, and for which a coordinated solution would be useful. No, that itself is not justification for assuming TCP is the place to do this. Joe --------------enig5B124C2DCB64B22B8650D35B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHK6QQE5f5cImnZrsRArD/AKDUpgmPIu+wbPiECgfzwtmJoEMLqwCg289b vsLorJiezrC9/e+VeW7oI6A= =3dTd -----END PGP SIGNATURE----- --------------enig5B124C2DCB64B22B8650D35B-- --===============1915959761== 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 --===============1915959761==-- From tcpm-bounces@ietf.org Mon Nov 05 08:42:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2Dk-0008If-AB; Mon, 05 Nov 2007 08:42:28 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ip2An-0004Hv-5t for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 08:39:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2Am-0004Gz-Qa for tcpm@ietf.org; Mon, 05 Nov 2007 08:39:24 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip2Ad-00070Z-AZ for tcpm@ietf.org; Mon, 05 Nov 2007 08:39:24 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA5DcVuH000856; Mon, 5 Nov 2007 15:39:12 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 15:39:07 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 15:39:07 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 15:39:05 +0200 Received: from [172.21.34.243] (esdhcp034243.research.nokia.com [172.21.34.243]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA5DctAm012300; Mon, 5 Nov 2007 15:38:55 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <6B3D5E1D-F2DA-428C-AAEF-6F548F48F4F5@nokia.com> References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> <4728A553.2020300@isi.edu> <6B3D5E1D-F2DA-428C-AAEF-6F548F48F4F5@nokia.com> Message-Id: <3DF7B46C-5246-470E-9C98-08A5AEADDAF3@nokia.com> From: Lars Eggert Subject: Re: [tcpm] WGLC for UTO Date: Mon, 5 Nov 2007 15:38:52 +0200 To: ext Joe Touch , tcpm@ietf.org, =?ISO-8859-1?Q?ext_Alfred_H=CEnes?= X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Nov 2007 13:39:05.0423 (UTC) FILETIME=[3BDF6DF0:01C81FB1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ec9c506f029e38d2a6e7b00bc7714181 X-Mailman-Approved-At: Mon, 05 Nov 2007 08:42:27 -0500 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: , Content-Type: multipart/mixed; boundary="===============2005242575==" Errors-To: tcpm-bounces@ietf.org --===============2005242575== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--933115601; protocol="application/pkcs7-signature" --Apple-Mail-7--933115601 Content-Type: multipart/mixed; boundary=Apple-Mail-6--933115752 --Apple-Mail-6--933115752 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, attached is a diff between -06 and my current working copy, to let the WG know about the changes I've made so far to address WG last call comments. There were some suggestions discussed in response to Joe's and Alfred's comments that I haven't made, because the rest of the WG was silent, which I interpreted as lack of consensus for the change. Speak up if you disagree with this resolution. Lars --Apple-Mail-6--933115752 Content-Transfer-Encoding: 7bit Content-Type: text/html; x-unix-mode=0644; name=draft-ietf-tcpm-tcp-uto-07-from-6.diff.html Content-Disposition: attachment; filename=draft-ietf-tcpm-tcp-uto-07-from-6.diff.html Diff: draft-ietf-tcpm-tcp-uto-06.txt - draft-ietf-tcpm-tcp-uto-07.txt
 draft-ietf-tcpm-tcp-uto-06.txt   draft-ietf-tcpm-tcp-uto-07.txt 
TCP Maintenance and Minor L. Eggert TCP Maintenance and Minor L. Eggert
Extensions (tcpm) Nokia Extensions (tcpm) Nokia
Internet-Draft F. Gont Internet-Draft F. Gont
Intended status: Standards Track UTN/FRH Intended status: Standards Track UTN/FRH
Expires: December 13, 2007 June 11, 2007 Expires: May 8, 2008 November 5, 2007
TCP User Timeout Option TCP User Timeout Option
draft-ietf-tcpm-tcp-uto-06 draft-ietf-tcpm-tcp-uto-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 13, 2007. This Internet-Draft will expire on May 8, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The TCP user timeout controls how long transmitted data may remain The TCP user timeout controls how long transmitted data may remain
unacknowledged before a connection is forcefully closed. It is a unacknowledged before a connection is forcefully closed. It is a
local, per-connection parameter. This document specifies a new TCP local, per-connection parameter. This document specifies a new TCP
option - the TCP User Timeout Option - that allows one end of a TCP option - the TCP User Timeout Option - that allows one end of a TCP
connection to advertise its current user timeout value. This connection to advertise its current user timeout value. This
information provides advice to the other end to adapt its user information provides advice to the other end of the TCP connection to
timeout accordingly. Increasing the user timeouts on both ends of a adapt its user timeout accordingly. Increasing the user timeouts on
TCP connection allows it to survive extended periods without end-to- both ends of a TCP connection allows it to survive extended periods
end connectivity. Decreasing the user timeouts allows busy servers without end-to-end connectivity. Decreasing the user timeouts allows
to explicitly notify their clients that they will maintain the busy servers to explicitly notify their clients that they will
connection state only for a short time without connectivity. maintain the connection state only for a short time without
connectivity.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6
3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8 3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8
3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 9 3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 10
4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10
4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Document Revision History . . . . . . . . . . . . . . 13 Appendix A. Document Revision History . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The Transmission Control Protocol (TCP) specification [RFC0793] The Transmission Control Protocol (TCP) specification [RFC0793]
defines a local, per-connection "user timeout" parameter that defines a local, per-connection "user timeout" parameter that
specifies the maximum amount of time that transmitted data may remain specifies the maximum amount of time that transmitted data may remain
unacknowledged before TCP will forcefully close the corresponding unacknowledged before TCP will forcefully close the corresponding
connection. Applications can set and change this parameter with OPEN connection. Applications can set and change this parameter with OPEN
and SEND calls. If an end-to-end connectivity disruption lasts and SEND calls. If an end-to-end connectivity disruption lasts
longer than the user timeout, no acknowledgments will be received for longer than the user timeout, no acknowledgments will be received for
any transmission attempt, including keep-alives, and the TCP any transmission attempt, including keep-alives, and the TCP
connection will close when the user timeout occurs. connection will close when the user timeout occurs.
This document specifies a new TCP option - the TCP User Timeout
Option - that allows one end of a TCP connection to advertise its
current user timeout value. This information provides advice to the
other end of the connection to adapt its user timeout accordingly.
That is, TCP remains free to disregard the advice provided by the UTO
option if local policies suggest it to be appropriate.
Increasing the user timeouts on both ends of a TCP connection allows
it to survive extended periods without end-to-end connectivity.
Decreasing the user timeouts allows busy servers to explicitly notify
their clients that they will maintain the connection state only for a
short time without connectivity.
In the absence of an application-specified user timeout, the TCP In the absence of an application-specified user timeout, the TCP
specification [RFC0793] defines a default user timeout of 5 minutes. specification [RFC0793] defines a default user timeout of 5 minutes.
The Host Requirements RFC [RFC1122] refines this definition by The Host Requirements RFC [RFC1122] refines this definition by
introducing two thresholds, R1 and R2 (R2 > R1), that control the introducing two thresholds, R1 and R2 (R2 > R1), that control the
number of retransmission attempts for a single segment. It suggests number of retransmission attempts for a single segment. It suggests
that TCP should notify applications when R1 is reached for a segment, that TCP should notify applications when R1 is reached for a segment,
and close the connection when R2 is reached. [RFC1122] also defines and close the connection when R2 is reached. [RFC1122] also defines
the recommended values for R1 (three retransmissions) and R2 (100 the recommended values for R1 (three retransmissions) and R2 (100
seconds), noting that R2 for SYN segments should be at least 3 seconds), noting that R2 for SYN segments should be at least 3
minutes. Instead of a single user timeout, some TCP implementations minutes. Instead of a single user timeout, some TCP implementations
offer finer-grained policies. For example, Solaris supports offer finer-grained policies. For example, Solaris supports
different timeouts depending on whether a TCP connection is in the different timeouts depending on whether a TCP connection is in the
SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL]. SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL].
Although some TCP implementations allow applications to set their Although some TCP implementations allow applications to set their
local user timeout, TCP has no in-protocol mechanism to signal local user timeout, TCP has no in-protocol mechanism to signal
changes to the local user timeout to the other end. This causes changes to the local user timeout to the other end of a connection.
local changes to be ineffective in allowing a connection to survive This causes local changes to be ineffective in allowing a connection
extended periods without connectivity, because the other end will to survive extended periods without connectivity, because the other
still close the connection after its user timeout expires. end will still close the connection after its user timeout expires.
The ability to inform the other end about the local user timeout for The ability to inform the other end of a connection about the local
the connection can improve TCP operation in scenarios that are user timeout can improve TCP operation in scenarios that are
currently not well supported. One example of such scenarios are currently not well supported. One example of such scenarios are
mobile hosts that change network attachment points based on current mobile hosts that change network attachment points based on current
location. Such hosts, maybe using Mobile IP [RFC3344], HIP [RFC4423] location. Such hosts, maybe using Mobile IP [RFC3344], HIP [RFC4423]
or transport-layer mobility mechanisms [I-D.eddy-tcp-mobility], are or transport-layer mobility mechanisms [I-D.eddy-tcp-mobility], are
only intermittently connected to the Internet. In between connected only intermittently connected to the Internet. In between connected
periods, mobile hosts may experience periods without end-to-end periods, mobile hosts may experience periods without end-to-end
connectivity. Other factors that can cause transient connectivity connectivity. Other factors that can cause transient connectivity
disruptions are high levels of congestion or link or routing failures disruptions are high levels of congestion or link or routing failures
inside the network. In these scenarios, a host may not know exactly inside the network. In these scenarios, a host may not know exactly
when or for how long connectivity disruptions will occur, but it when or for how long connectivity disruptions will occur, but it
might be able to determine an increased likelihood for such events might be able to determine an increased likelihood for such events
based on past mobility patterns and thus benefit from using longer based on past mobility patterns and thus benefit from using longer
user timeouts. In other scenarios, the time and duration of a user timeouts. In other scenarios, the time and duration of a
connectivity disruption may even be predictable. For example, an connectivity disruption may even be predictable. For example, an
orbiting node on a non-geostationary satellite might experience orbiting node on a non-geostationary satellite might experience
connectivity disruptions due to line-of-sight blocking by other connectivity disruptions due to line-of-sight blocking by other
planetary bodies. The timing of these events may be computable from planetary bodies. The timing of these events may be computable from
orbital mechanics. orbital mechanics.
This document specifies a new TCP option - the TCP User Timeout
Option - that allows one end of a TCP connection to advertise its
current user timeout value. This information provides advice to the
other end of the connection to adapt its user timeout accordingly.
That is, TCP remains free to disregard the advice provided by the UTO
option if local policies suggest it to be appropriate.
Increasing the user timeouts on both ends of a TCP connection allows
it to survive extended periods without end-to-end connectivity.
Decreasing the user timeouts allows busy servers to explicitly notify
their clients that they will maintain the connection state only for a
short time without connectivity.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Operation 3. Operation
Use of the TCP User Timeout Option can be enabled either on a per- Use of the TCP User Timeout Option can be enabled either on a per-
application basis, e.g., through a socket option, or controlled by a connection basis, e.g., through a socket option, or controlled by a
system-wide setting. TCP maintains four per-connection state system-wide setting. TCP maintains four per-connection state
variables to control the operation of the UTO option, three of which variables to control the operation of the UTO option, three of which
(LOCAL_UTO, ENABLED and CHANGEABLE) are new: (ADV_UTO, ENABLED and CHANGEABLE) are new:
USER_TIMEOUT USER_TIMEOUT
TCP's USER TIMEOUT parameter, as specified in [RFC0793]. TCP's USER TIMEOUT parameter, as specified in [RFC0793].
LOCAL_UTO ADV_UTO
UTO option advertised to the remote TCP peer. This is an UTO option advertised to the remote TCP peer. This is an
application-specified value, and may be specified on a system-wide application-specified value, and may be specified on a system-wide
basis. If unspecified, it default to the default system-wide USER basis. If unspecified, it defaults to the default system-wide
TIMEOUT. USER TIMEOUT.
ENABLED (Boolean) ENABLED (Boolean)
Flag that controls whether the UTO option is enabled for a Flag that controls whether the UTO option is enabled for a
connection. Defaults to false. connection. Defaults to false.
CHANGEABLE (Boolean) CHANGEABLE (Boolean)
Flag that controls whether USER_TIMEOUT (TCP's USER_TIMEOUT Flag that controls whether USER_TIMEOUT (TCP's USER_TIMEOUT
parameter) may be changed based on an UTO option received from the parameter) may be changed based on an UTO option received from the
other end. Defaults to true and becomes false when an application other end of the connection. Defaults to true and becomes false
explicitly sets USER_TIMEOUT. when an application explicitly sets USER_TIMEOUT.
Note that an exchange of UTO options between both ends of a Note that an exchange of UTO options between both ends of a
connection is not a binding negotiation. Transmission of a UTO connection is not a binding negotiation. Transmission of a UTO
option is a suggestion that the other end consider adapting its user option is a suggestion that the other end consider adapting its user
timeout. This adaptation only happens if the the other end has timeout. This adaptation only happens if the the other end of the
explicitly allowed it (both ENABLED and CHANGEABLE are true). connection has explicitly allowed it (both ENABLED and CHANGEABLE are
true).
Before opening a connection, an application that wishes to use the Before opening a connection, an application that wishes to use the
UTO option SHOULD enable its use by setting ENABLED to true. It MAY UTO option enables its use by setting ENABLED to true. It may choose
pick an appropriate local UTO by setting LOCAL_UTO, which is an appropriate local UTO by explicitly setting ADV_UTO; otherwise,
otherwise set to the default USER TIMEOUT value. Finally, the UTO is set to the default USER TIMEOUT value. Finally, the
application should determine whether it will allow the local USER application should determine whether it will allow the local USER
TIMEOUT to change based on received UTO options from the other end. TIMEOUT to change based on received UTO options from the other end of
The default is to allow this for connections that do not have a a connection. The default is to allow this for connections that do
specific user timeout concerns. If an application explicitly sets not have specific user timeout concerns. If an application
the USER TIMEOUT, CHANGEABLE MUST become false, to prevent UTO explicitly sets the USER TIMEOUT, CHANGEABLE MUST become false, to
options from the other end to override local application requests. prevent UTO options from the other end to override local application
Alternatively, applications MAY set or clear CHANGEABLE directly. requests. Alternatively, applications can set or clear CHANGEABLE
directly through socket API calls.
Performing these steps before an active or passive open causes UTO Performing these steps before an active or passive open causes UTO
options to be exchanged in the SYN and SYN-ACK packets and is a options to be exchanged in the SYN and SYN-ACK packets and is a
reliable way to initially exchange and potentially adapt to UTO reliable way to initially exchange, and potentially adapt to, UTO
values. Systems MAY provide system-wide default settings for the values. TCP implementations MAY provide system-wide default settings
ENABLED, LOCAL_UTO and CHANGEABLE connection parameters. for the ENABLED, ADV_UTO and CHANGEABLE connection parameters.
In addition to exchanging UTO options in the SYN segments, a In addition to exchanging UTO options in the SYN segments, a
connection that has enabled UTO options SHOULD include a UTO option connection that has enabled UTO options SHOULD include a UTO option
in the first packet that does not have the SYN flag set. This helps in the first packet that does not have the SYN flag set. This helps
to minimize the amount of state information TCP must keep for to minimize the amount of state information TCP must keep for
connections in non-synchronized states, and is particularly useful connections in non-synchronized states, and is particularly useful
when mechanisms such as "SYN cookies" [I-D.ietf-tcpm-syn-flood] are when mechanisms such as "SYN cookies" [I-D.ietf-tcpm-syn-flood] are
implemented, allowing a newly-established TCP connection to benefit implemented, allowing a newly-established TCP connection to benefit
from the information advertised by the UTO option, even if the UTO from the information advertised by the UTO option, even if the UTO
contained in the initial SYN segment was not recorded. contained in the initial SYN segment was not recorded.
A host that supports the UTO option SHOULD include one in the next A host that supports the UTO option SHOULD include one in the next
possible outgoing segment whenever it starts using a new user timeout possible outgoing segment whenever it starts using a new user timeout
for the connection. This allows the other end to adapt its local for the connection. This allows the other end of the connection to
user timeout for the connection accordingly. A TCP implementation adapt its local user timeout accordingly. A TCP implementation that
that does not support the UTO option MUST silently ignore it does not support the UTO option MUST silently ignore it [RFC1122],
[RFC1122], thus ensuring interoperability. thus ensuring interoperability.
Hosts MUST impose upper and lower limits on the user timeouts they Hosts MUST impose upper and lower limits on the user timeouts they
use for a connection. Section 3.1 discusses user timeout limits and use for a connection. Section 3.1 discusses user timeout limits and
discusses potentially problematic effects of some user timeout potentially problematic effects of some user timeout settings.
settings.
Finally, it is worth noting that TCP's option space is limited to 40 Finally, it is worth noting that TCP's option space is limited to 40
bytes. As a result, if other TCP options are in use, they may bytes. As a result, if other TCP options are in use, they may
already consume all the available TCP option space, thus preventing already consume all the available TCP option space, thus preventing
the use of the UTO option specified in this document. Therefore, TCP the use of the UTO option specified in this document. Therefore, TCP
option space issues should be considered before enabling the UTO option space issues should be considered before enabling the UTO
option. option.
3.1. Changing the Local User Timeout 3.1. Changing the Local User Timeout
When a host receives a TCP User Timeout Option, it must decide When a host receives a TCP User Timeout Option, it must decide
whether to change the local user timeout of the corresponding whether to change the local user timeout of the corresponding
connection. If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT connection. If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT
be changed, regardless of the received UTO option. Without this be changed, regardless of the received UTO option. Without this
restriction, the UTO option would modify TCP semantics, because an restriction, the UTO option would modify TCP semantics, because an
application-requested USER TIMEOUT could be overridden by peer application-requested USER TIMEOUT could be overridden by peer
requests. In this case, they SHOULD, however, notify the application requests. In this case TCP SHOULD, however, notify the application
about the user timeout value received from the other end. about the user timeout value received from the other end system.
In general, unless the application on the local host has requested a In general, unless the application on the local host has requested a
specific USER TIMEOUT for the connection, CHANGEABLE will be true and specific USER TIMEOUT for the connection, CHANGEABLE will be true and
hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in
response to receiving a UTO option, as described in the remainder of response to receiving a UTO option, as described in the remainder of
this section. this section.
The UTO option specifies the user timeout in seconds or minutes, The UTO option specifies the user timeout in seconds or minutes,
rather than in number of retransmissions or round-trip times (RTTs). rather than in number of retransmissions or round-trip times (RTTs).
Thus, the UTO option allows hosts to exchange user timeout values Thus, the UTO option allows hosts to exchange user timeout values
skipping to change at page 7, line 14 skipping to change at page 7, line 14
To protect against these effects, implementations MUST impose limits To protect against these effects, implementations MUST impose limits
on the user timeout values they accept and use. The remainder of on the user timeout values they accept and use. The remainder of
this section describes a RECOMMENDED scheme to limit TCP's USER this section describes a RECOMMENDED scheme to limit TCP's USER
TIMEOUT based on upper and lower limits. TIMEOUT based on upper and lower limits.
Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end
SHOULD compute the local USER TIMEOUT for a connection according to SHOULD compute the local USER TIMEOUT for a connection according to
this formula: this formula:
USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT))
Each field is to be interpreted as follows: Each field is to be interpreted as follows:
USER_TIMEOUT USER_TIMEOUT
USER TIMEOUT value to be adopted by the local TCP for this USER TIMEOUT value to be adopted by the local TCP for this
connection. connection.
U_LIMIT U_LIMIT
Current upper limit imposed on the user timeout of a connection by Current upper limit imposed on the user timeout of a connection by
the local host. the local host.
LOCAL_UTO ADV_UTO
User timeout advertised to the remote TCP peer in a TCP User User timeout advertised to the remote TCP peer in a TCP User
Timeout Option. Timeout Option.
REMOTE_UTO REMOTE_UTO
Last "user timeout" value received from the other end in a TCP Last user timeout value received from the other end in a TCP User
User Timeout Option. Timeout Option.
L_LIMIT L_LIMIT
Current lower limit imposed on the user timeout of a connection by Current lower limit imposed on the user timeout of a connection by
the local host. the local host.
This means that, provided they are within the upper and lower limits, The RECOMMENDED formula results in the maximum of the two advertised
the maximum of the two advertised values will be adopted for the user values to be adopted for the user timeout of the connection on both
timeout of the connection. The rationale is that choosing the ends, provided they are within the upper and lower limits. The
maximum of the two values will let the connection survive longer rationale is that choosing the maximum of the two values will let the
periods without end-to-end connectivity. If the end that announced connection survive longer periods without end-to-end connectivity.
the lower of the two user timeout values did so in order to reduce If the end that announced the lower of the two user timeout values
the amount of TCP state information that must be kept on the host, it did so in order to reduce the amount of TCP state information that
can, nevertheless, close or abort the connection whenever it wants. must be kept on the host, it can close or abort the connection
whenever it wants.
It must be noted that the two endpoints of the connection will not It must be noted that the two endpoints of the connection will not
necessarily adopt the same user timeout. necessarily adopt the same user timeout.
Enforcing a lower limit (L_LIMIT) prevents connections from closing Enforcing a lower limit (L_LIMIT) prevents connections from closing
due to transient network conditions, including temporary congestion, due to transient network conditions, including temporary congestion,
mobility hand-offs and routing instabilities. mobility hand-offs and routing instabilities.
An upper limit (U_LIMIT) can reduce the effect of resource exhaustion An upper limit (U_LIMIT) can reduce the effect of resource exhaustion
attacks. Section 5 discusses the details of these attacks. attacks. Section 5 discusses the details of these attacks.
Note that these limits MAY be specified as system-wide constants or Note that these limits MAY be specified as system-wide constants or
at other granularities, such as on per-host, per-user, per-outgoing- at other granularities, such as on per-host, per-user, per-outgoing-
interface or even per-connection basis. Furthermore, these limits interface or even per-connection basis. Furthermore, these limits
need not be static. For example, they MAY be a function of system need not be static. For example, they MAY be a function of system
resource utilization or attack status and could be dynamically resource utilization or attack status and could be dynamically
adapted. adapted.
The Host Requirements RFC [RFC1122] does not impose any limits on the The Host Requirements RFC [RFC1122] does not impose any limits on the
length of the user timeout. However, a time interval of at least 100 length of the user timeout. However, it recommends a time interval
seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT) of at least 100 seconds. Consequently, the lower limit (L_LIMIT)
SHOULD be set to at least 100 seconds when following the RECOMMENDED SHOULD be set to at least 100 seconds when following the RECOMMENDED
scheme described in this section. Adopting a user timeout smaller scheme described in this section. Adopting a user timeout smaller
than the current retransmission timeout (RTO) for the connection than the current retransmission timeout (RTO) for the connection
would likely cause the connection to be aborted unnecessarily. would likely cause the connection to be aborted unnecessarily.
Therefore, the lower limit (L_LIMIT) MUST be larger than the current Therefore, the lower limit (L_LIMIT) MUST be larger than the current
retransmission timeout (RTO) for the connection. It is worth noting retransmission timeout (RTO) for the connection. It is worth noting
that an upper limit may be imposed on the RTO, provided it is at that an upper limit may be imposed on the RTO, provided it is at
least 60 seconds [RFC2988]. least 60 seconds [RFC2988].
3.2. UTO Option Reliability 3.2. UTO Option Reliability
skipping to change at page 8, line 51 skipping to change at page 9, line 8
It is important to note that although these mechanisms can improve It is important to note that although these mechanisms can improve
transmission reliability for the UTO option, they do not guarantee transmission reliability for the UTO option, they do not guarantee
delivery (a three-way handshake would be required for this). delivery (a three-way handshake would be required for this).
Consequently, implementations MUST NOT assume that UTO options are Consequently, implementations MUST NOT assume that UTO options are
transmitted reliably. transmitted reliably.
3.3. Option Format 3.3. Option Format
Sending a TCP User Timeout Option informs the other end of the Sending a TCP User Timeout Option informs the other end of the
current local user timeout for the connection and suggests that the connection of the current local user timeout and suggests that the
other end adapt its user timeout accordingly. The user timeout value other end adapt its user timeout accordingly. The user timeout value
included in a UTO option contains the LOCAL_UTO value, that is included in a UTO option contains the ADV_UTO value, that is expected
expected to be adopted for the TCP's USER TIMEOUT parameter during to be adopted for the TCP's USER TIMEOUT parameter during the
the synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-
FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other
states MUST use the default timeout values defined in [RFC0793] and states MUST use the default timeout values defined in [RFC0793] and
[RFC1122]. [RFC1122].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind = X | Length = 4 |G| User Timeout | | Kind = TBD | Length = 4 |G| User Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(One tick mark represents one bit.) (One tick mark represents one bit.)
Figure 1: Format of the TCP User Timeout Option Figure 1: Format of the TCP User Timeout Option
Figure 1 shows the format of the TCP User Timeout Option. It Figure 1 shows the format of the TCP User Timeout Option. It
contains these fields: contains these fields:
Kind (8 bits) Kind (8 bits)
A TCP option number [RFC0793] to be assigned by IANA upon This MUST be TBD, i.e., the TCP option number [RFC0793] assigned
publication of this document (see Section 6). by IANA upon publication of this document (see Section 6). [[Note
to RFC Editor: Replace "TBD" with the TCP option number that IANA
has allocated throughout this document, and remove this note.]]
Length (8 bits) Length (8 bits)
Length of the TCP option in octets [RFC0793]; its value MUST be 4. Length of the TCP option in octets [RFC0793]; its value MUST be 4.
Granularity (1 bit) Granularity (1 bit)
Granularity bit, indicating the granularity of the "User Timeout" Granularity bit, indicating the granularity of the "User Timeout"
field. When set (G = 1), the time interval in the "User Timeout" field. When set (G = 1), the time interval in the "User Timeout"
field MUST be interpreted as minutes. Otherwise (G = 0), the time field MUST be interpreted as minutes. Otherwise (G = 0), the time
interval in the "User Timeout" field MUST be interpreted as interval in the "User Timeout" field MUST be interpreted as
seconds. seconds.
User Timeout (15 bits) User Timeout (15 bits)
Specifies the user timeout suggestion for this connection.. It Specifies the user timeout suggestion for this connection. It
MUST be interpreted as a 15-bit unsigned integer. The granularity MUST be interpreted as a 15-bit unsigned integer. The granularity
of the timeout (minutes or seconds) depends on the "G" field. of the timeout (minutes or seconds) depends on the "G" field.
3.4. Reserved Option Values 3.4. Reserved Option Values
An TCP User Timeout Option with a "User Timeout" field of zero and a An TCP User Timeout Option with a "User Timeout" field of zero and a
"Granularity" bit of either minutes (1) or seconds (0) is reserved "Granularity" bit of either minutes (1) or seconds (0) is reserved
for future use. TCP implementations MUST NOT send it and MUST ignore for future use. Current TCP implementations MUST NOT send it and
it upon reception. MUST ignore it upon reception.
4. Interoperability Issues 4. Interoperability Issues
This section discusses interoperability issues related to introducing This section discusses interoperability issues related to introducing
the TCP User Timeout Option. the TCP User Timeout Option.
4.1. Middleboxes 4.1. Middleboxes
A TCP implementation that does not support the TCP User Timeout A TCP implementation that does not support the TCP User Timeout
Option MUST silently ignore it [RFC1122], thus ensuring Option MUST silently ignore it [RFC1122], thus ensuring
skipping to change at page 10, line 29 skipping to change at page 10, line 36
failures caused by unknown options is small and they are a result of failures caused by unknown options is small and they are a result of
incorrectly implemented TCP stacks that violate existing requirements incorrectly implemented TCP stacks that violate existing requirements
to ignore unknown options, they do not warrant special measures. to ignore unknown options, they do not warrant special measures.
Thus, this document does not define a mechanism to negotiate support Thus, this document does not define a mechanism to negotiate support
of the TCP User Timeout Option during the three-way handshake. of the TCP User Timeout Option during the three-way handshake.
Stateful firewalls usually time out connection state after a period Stateful firewalls usually time out connection state after a period
of inactivity. If such a firewall exists along the path, it may of inactivity. If such a firewall exists along the path, it may
close or abort connections regardless of the use of the TCP User close or abort connections regardless of the use of the TCP User
Timeout Option. In the future, such firewalls may learn to parse the Timeout Option. In the future, such firewalls may learn to parse the
TCP User Timeout Option and adapt connection state management TCP User Timeout Option in unencrypted TCP segments and adapt
accordingly. connection state management accordingly.
4.2. TCP Keep-Alives 4.2. TCP Keep-Alives
Some TCP implementations, such as those in BSD systems, use a Some TCP implementations, such as those in BSD systems, use a
different abort policy for TCP keep-alives than for user data. Thus, different abort policy for TCP keep-alives than for user data. Thus,
the TCP keep-alive mechanism might abort a connection that would the TCP keep-alive mechanism might abort a connection that would
otherwise have survived the transient period without connectivity. otherwise have survived the transient period without connectivity.
Therefore, if a connection enables keep-alives that is also using the Therefore, if a connection that enables keep-alives is also using the
TCP User Timeout Option, then the keep-alive timer MUST be set to a TCP User Timeout Option, then the keep-alive timer MUST be set to a
value larger than that of the adopted USER TIMEOUT. value larger than that of the adopted USER TIMEOUT.
5. Security Considerations 5. Security Considerations
Lengthening user timeouts has obvious security implications. Lengthening user timeouts has obvious security implications.
Flooding attacks cause denial of service by forcing servers to commit Flooding attacks cause denial of service by forcing servers to commit
resources for maintaining the state of throw-away connections. resources for maintaining the state of throw-away connections.
However, TCP implementations do not become more vulnerable to simple However, TCP implementations do not become more vulnerable to simple
SYN flooding by implementing the TCP User Timeout Option, because SYN flooding by implementing the TCP User Timeout Option, because
skipping to change at page 11, line 15 skipping to change at page 11, line 26
However, when an attacker completes the three-way handshakes of its However, when an attacker completes the three-way handshakes of its
throw-away connections it can amplify the effects of resource throw-away connections it can amplify the effects of resource
exhaustion attacks, because the attacked server must maintain the exhaustion attacks, because the attacked server must maintain the
connection state associated with the throw-away connections for connection state associated with the throw-away connections for
longer durations. Because connection state is kept longer, lower- longer durations. Because connection state is kept longer, lower-
frequency attack traffic, which may be more difficult to detect, can frequency attack traffic, which may be more difficult to detect, can
already exacerbate resource exhaustion. already exacerbate resource exhaustion.
Several approaches can help mitigate this issue. First, Several approaches can help mitigate this issue. First,
implementations can require prior peer authentication, e.g., using implementations can require prior peer authentication, e.g., using
IPsec [RFC4301], before accepting long user timeouts for the peer's IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user
connections. Similarly, a host can start to accept long user timeouts for the peer's connections. Similarly, a host can start to
timeouts for an established connection only after in-band accept long user timeouts for an established connection only after
authentication has occurred, for example, after a TLS handshake in-band authentication has occurred, for example, after a TLS
across the connection has succeeded [RFC4346]. Although these are handshake across the connection has succeeded [RFC4346]. Although
arguably the most complete solutions, they depend on external these are arguably the most complete solutions, they depend on
mechanisms to establish a trust relationship. external mechanisms to establish a trust relationship.
A second alternative that does not depend on external mechanisms A second alternative that does not depend on external mechanisms
would introduce a per-peer limit on the number of connections that would introduce a per-peer limit on the number of connections that
may use increased user timeouts. Several variants of this approach may use increased user timeouts. Several variants of this approach
are possible, such as fixed limits or shortening accepted user are possible, such as fixed limits or shortening accepted user
timeouts with a rising number of connections. Although this timeouts with a rising number of connections. Although this
alternative does not eliminate resource exhaustion attacks from a alternative does not eliminate resource exhaustion attacks from a
single peer, it can limit their effects. Reducing the number of single peer, it can limit their effects. Reducing the number of
high-UTO connections a server supports in the face of an attack turns high-UTO connections a server supports in the face of an attack turns
that attack into a denial-of-service attack against the service of that attack into a denial-of-service attack against the service of
skipping to change at page 12, line 9 skipping to change at page 12, line 20
Note that if TCP needs to close or abort connections with a long TCP Note that if TCP needs to close or abort connections with a long TCP
User Timeout Option to shed load, these connections are still no User Timeout Option to shed load, these connections are still no
worse off than without the option. worse off than without the option.
Finally, upper and lower limits on user timeouts, discussed in Finally, upper and lower limits on user timeouts, discussed in
Section 3.1, can be an effective tool to limit the impact of these Section 3.1, can be an effective tool to limit the impact of these
sorts of attacks. sorts of attacks.
6. IANA Considerations 6. IANA Considerations
This section is to be interpreted according to [RFC2434]. This section is to be interpreted according to
[I-D.narten-iana-considerations-rfc2434bis].
This document does not define any new namespaces. It uses an 8-bit This document does not define any new namespaces. It requests that
TCP option number maintained by IANA at IANA allocate a new 8-bit TCP option number for the UTO option from
the registry maintained at
http://www.iana.org/assignments/tcp-parameters. http://www.iana.org/assignments/tcp-parameters.
7. Acknowledgments 7. Acknowledgments
The following people have improved this document through thoughtful The following people have improved this document through thoughtful
suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden, suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden,
Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted
Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris,
Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid
Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe
skipping to change at page 12, line 34 skipping to change at page 12, line 47
Stiemerling. Stiemerling.
Lars Eggert has been partly funded by Ambient Networks, a research Lars Eggert has been partly funded by Ambient Networks, a research
project supported by the European Commission under its Sixth project supported by the European Commission under its Sixth
Framework Program. Framework Program.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-08 (work in
progress), October 2007.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
8.2. Informative References 8.2. Informative References
[I-D.eddy-tcp-mobility] [I-D.eddy-tcp-mobility]
Eddy, W., "Mobility Support For TCP", Eddy, W., "Mobility Support For TCP",
draft-eddy-tcp-mobility-00 (work in progress), April 2004. draft-eddy-tcp-mobility-00 (work in progress), April 2004.
[I-D.ietf-tcpm-syn-flood] [I-D.ietf-tcpm-syn-flood]
Eddy, W., "TCP SYN Flooding Attacks and Common Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", draft-ietf-tcpm-syn-flood-05 (work in Mitigations", draft-ietf-tcpm-syn-flood-05 (work in
progress), May 2007. progress), May 2007.
[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring
Interactions Between Transport Protocols and Middleboxes", Interactions Between Transport Protocols and Middleboxes",
Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Proc. 4th ACM SIGCOMM/USENIX Conference on Internet
Measurement , October 2004. Measurement , October 2004.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
 End of changes. 42 change blocks. 
103 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Apple-Mail-6--933115752 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed --Apple-Mail-6--933115752-- --Apple-Mail-7--933115601 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzExMDUxMzM4NTNaMCMGCSqGSIb3DQEJBDEWBBRhzVq5F4G3cL0l zKHrcwTOq59w8TCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAHtTRNwZTlKr3t7Ys8zgDNf2alD0PJx3U+XgnpXnopdA0vgCaQsw3 fdjqRSFbGVUErUs12Yr8H5jPcAZY974uqYoBt+OK7yAMobAn1QRhhc2lATmStw1nk+4SY3HKxLNR LUbcKmfZ1nGe3KRLIVS03AUdAqSa/fdikMoshkWg4mfLY3pLnRX7ULDUaPOzqi+hBFDcuc9hy4// AY8zb+dGm3IRGRDFVZTk/MOzU5+DKdqxZjByV6hEAkABvFYP0TAFlUa4daG5k+2HjCg3FNw4ssAB g+W6aZmM1kVXiP4jmF+utbVbzUxq3ND7NpQ+4Gqg5XXFZB1olQtbGJOmdTaGvQAAAAAAAA== --Apple-Mail-7--933115601-- --===============2005242575== 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 --===============2005242575==-- From tcpm-bounces@ietf.org Mon Nov 05 10:32:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3wH-0005wb-34; Mon, 05 Nov 2007 10:32:33 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ip3wF-0005v1-Js for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 10:32:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3wF-0005tB-83 for tcpm@ietf.org; Mon, 05 Nov 2007 10:32:31 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip3wE-0001Ef-SA for tcpm@ietf.org; Mon, 05 Nov 2007 10:32:31 -0500 Received: from [192.168.1.46] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA5FVS5d018629; Mon, 5 Nov 2007 07:31:28 -0800 (PST) Message-ID: <472F3742.3010009@isi.edu> Date: Mon, 05 Nov 2007 07:31:14 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [tcpm] Is this a problem? References: <359024.58790.qm@web31711.mail.mud.yahoo.com> <472BA410.5070509@isi.edu> <046A93B9-CB27-4B36-8B18-8D205E066069@nokia.com> In-Reply-To: <046A93B9-CB27-4B36-8B18-8D205E066069@nokia.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1573252555==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1573252555== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3D0B3100FE379E2395A9DEDE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3D0B3100FE379E2395A9DEDE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > Hi, >=20 > attached is a diff between -06 and my current working copy, to let the > WG know about the changes I've made so far to address WG last call > comments. >=20 > There were some suggestions discussed in response to Joe's and Alfred's= > comments that I haven't made, because the rest of the WG was silent, > which I interpreted as lack of consensus for the change. Speak up if yo= u > disagree with this resolution. PS - could you provide a brief list of those suggestions? Joe --------------enig3D0B3100FE379E2395A9DEDE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHLzdDE5f5cImnZrsRAtU8AJ9CaNibCpGZ4wF5FpRZJ1GvxtCeBACglsZZ Dbqhn+HdaMBJsIJ8Bba9NIE= =Lx8b -----END PGP SIGNATURE----- --------------enig3D0B3100FE379E2395A9DEDE-- --===============1573252555== 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 --===============1573252555==-- From tcpm-bounces@ietf.org Mon Nov 05 10:32:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3wH-0005wb-34; Mon, 05 Nov 2007 10:32:33 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ip3wF-0005v1-Js for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 10:32:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3wF-0005tB-83 for tcpm@ietf.org; Mon, 05 Nov 2007 10:32:31 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip3wE-0001Ef-SA for tcpm@ietf.org; Mon, 05 Nov 2007 10:32:31 -0500 Received: from [192.168.1.46] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA5FVS5d018629; Mon, 5 Nov 2007 07:31:28 -0800 (PST) Message-ID: <472F3742.3010009@isi.edu> Date: Mon, 05 Nov 2007 07:31:14 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [tcpm] Is this a problem? References: <359024.58790.qm@web31711.mail.mud.yahoo.com> <472BA410.5070509@isi.edu> <046A93B9-CB27-4B36-8B18-8D205E066069@nokia.com> In-Reply-To: <046A93B9-CB27-4B36-8B18-8D205E066069@nokia.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1573252555==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1573252555== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3D0B3100FE379E2395A9DEDE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3D0B3100FE379E2395A9DEDE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > Hi, >=20 > attached is a diff between -06 and my current working copy, to let the > WG know about the changes I've made so far to address WG last call > comments. >=20 > There were some suggestions discussed in response to Joe's and Alfred's= > comments that I haven't made, because the rest of the WG was silent, > which I interpreted as lack of consensus for the change. Speak up if yo= u > disagree with this resolution. PS - could you provide a brief list of those suggestions? Joe --------------enig3D0B3100FE379E2395A9DEDE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHLzdDE5f5cImnZrsRAtU8AJ9CaNibCpGZ4wF5FpRZJ1GvxtCeBACglsZZ Dbqhn+HdaMBJsIJ8Bba9NIE= =Lx8b -----END PGP SIGNATURE----- --------------enig3D0B3100FE379E2395A9DEDE-- --===============1573252555== 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 --===============1573252555==-- From tcpm-bounces@ietf.org Mon Nov 05 10:32:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3wM-00069w-AB; Mon, 05 Nov 2007 10:32:38 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ip3wK-000658-St for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 10:32:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3wK-00064A-II for tcpm@ietf.org; Mon, 05 Nov 2007 10:32:36 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip3wJ-0001IJ-8X for tcpm@ietf.org; Mon, 05 Nov 2007 10:32:36 -0500 Received: from [192.168.1.46] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA5FUH7V018378; Mon, 5 Nov 2007 07:30:17 -0800 (PST) Message-ID: <472F36FC.1030301@isi.edu> Date: Mon, 05 Nov 2007 07:30:04 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [tcpm] WGLC for UTO References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> <4728A553.2020300@isi.edu> <6B3D5E1D-F2DA-428C-AAEF-6F548F48F4F5@nokia.com> <3DF7B46C-5246-470E-9C98-08A5AEADDAF3@nokia.com> In-Reply-To: <3DF7B46C-5246-470E-9C98-08A5AEADDAF3@nokia.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: =?ISO-8859-1?Q?ext_Alfred_H=CEnes?= , 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="===============0824813132==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0824813132== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig019DE5A8BED146CAC6AD1574" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig019DE5A8BED146CAC6AD1574 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lars Eggert wrote: > Hi, >=20 > attached is a diff between -06 and my current working copy, to let the > WG know about the changes I've made so far to address WG last call > comments. >=20 > There were some suggestions discussed in response to Joe's and Alfred's= > comments that I haven't made, because the rest of the WG was silent, > which I interpreted as lack of consensus for the change. Speak up if yo= u > disagree with this resolution. I have spoken before on this point in general. Apathy is not consensus. Apathy can be a reason to not include a change, but that's the reason. Not consensus. Joe --------------enig019DE5A8BED146CAC6AD1574 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHLzb8E5f5cImnZrsRAqbJAJ9Bc3S388d/Q27sjsTOpN+W1VWGoACgywPU 1kjlap4PnbnkK4f9xsABMqc= =I93B -----END PGP SIGNATURE----- --------------enig019DE5A8BED146CAC6AD1574-- --===============0824813132== 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 --===============0824813132==-- From tcpm-bounces@ietf.org Mon Nov 05 12:20:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip5dC-0008WQ-Ih; Mon, 05 Nov 2007 12:20:58 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ip5dB-0008WK-L7 for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 12:20:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip5dB-0008WB-9f for tcpm@ietf.org; Mon, 05 Nov 2007 12:20:57 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip5dA-0004EN-Or for tcpm@ietf.org; Mon, 05 Nov 2007 12:20:57 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA5HKsFc026113; Mon, 5 Nov 2007 19:20:54 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 19:20:40 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 19:20:40 +0200 Received: from [192.168.255.2] (essapo-nirac25326.europe.nokia.com [10.162.253.26]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA5HKd4V009582; Mon, 5 Nov 2007 19:20:39 +0200 In-Reply-To: <472F36FC.1030301@isi.edu> References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> <4728A553.2020300@isi.edu> <6B3D5E1D-F2DA-428C-AAEF-6F548F48F4F5@nokia.com> <3DF7B46C-5246-470E-9C98-08A5AEADDAF3@nokia.com> <472F36FC.1030301@isi.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <001BF967-9D6E-4583-8C08-6B4AC29A567C@nokia.com> From: Lars Eggert Subject: Re: [tcpm] WGLC for UTO Date: Mon, 5 Nov 2007 19:20:34 +0200 To: ext Joe Touch X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Nov 2007 17:20:40.0999 (UTC) FILETIME=[30A75370:01C81FD0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: =?ISO-8859-1?Q?ext_Alfred_H=CEnes?= , 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="===============0478666480==" Errors-To: tcpm-bounces@ietf.org --===============0478666480== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14--919813904; protocol="application/pkcs7-signature" --Apple-Mail-14--919813904 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-11-5, at 17:30, ext Joe Touch wrote: > Lars Eggert wrote: >> There were some suggestions discussed in response to Joe's and >> Alfred's >> comments that I haven't made, because the rest of the WG was silent, >> which I interpreted as lack of consensus for the change. Speak up >> if you >> disagree with this resolution. > > I have spoken before on this point in general. Apathy is not > consensus. > > Apathy can be a reason to not include a change, but that's the reason. > Not consensus. My understanding is that we have *had* consensus on what the document currently says about the two points in question (whether to include the UTO in both the SYN and the first non-SYN, and whether UTO is supposed to be transmitted reliably) since these points were discussed a few revisions back. I'm not opposed to making changes if the consensus has changed. But I have difficulties determining whether this is the case. I'd appreciate some additional WG comments on this. Lars --Apple-Mail-14--919813904 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzExMDUxNzIwMzRaMCMGCSqGSIb3DQEJBDEWBBS2DPqM0bwm2Hpa JsPNwefjT031ETCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEARCos2SZvA2w2Tn1xhvBRJZOQeAdMwz08Tn/0ZLPeyCta04Au09lA GHk3x2xcU27qRUzmqI1Td2MVNrlxG6ycT/KjPbcCnEorVHs4+RR7qKc1e2KZ8w5rj/6mfHrjhLpG DxE8fBXkUJNni+kkjL9aStk16RnpU3JfnP+wa7kA8Zn0FI0YemxkeL0bZV6RS6ePG59ggT4Mn39h LbMDT+3VwfoT7s7MJwQ6yQ75foeP+4URojDSz2i8GD2B/cB45FbCxa6W1omNwEX+hMnTPMGk0mdG 5mW1n5bpeM1JdzL9/rEymonp/YFiXEyeGzSSuvBk3gTqhFkkRb8wDiJ9sqeQWQAAAAAAAA== --Apple-Mail-14--919813904-- --===============0478666480== 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 --===============0478666480==-- From tcpm-bounces@ietf.org Mon Nov 05 13:52:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip73f-0004dG-Gf; Mon, 05 Nov 2007 13:52:23 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ip73e-0004bE-4o for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 13:52:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip73d-0004b6-RX for tcpm@ietf.org; Mon, 05 Nov 2007 13:52:21 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip73c-0007Na-Ec for tcpm@ietf.org; Mon, 05 Nov 2007 13:52:21 -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 lA5IntmC004819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Nov 2007 10:49:55 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id lA5InnUA086058; Mon, 5 Nov 2007 10:49:49 -0800 (PST) (envelope-from faber) Date: Mon, 5 Nov 2007 10:49:49 -0800 From: Ted Faber To: Joe Touch Subject: Re: [tcpm] WGLC for UTO Message-ID: <20071105184949.GA31862@hut.isi.edu> References: <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> <4728A553.2020300@isi.edu> <6B3D5E1D-F2DA-428C-AAEF-6F548F48F4F5@nokia.com> <3DF7B46C-5246-470E-9C98-08A5AEADDAF3@nokia.com> <472F36FC.1030301@isi.edu> Mime-Version: 1.0 In-Reply-To: <472F36FC.1030301@isi.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ext Alfred =?iso-8859-1?Q?H=CEnes?= , 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="===============0788885988==" Errors-To: tcpm-bounces@ietf.org --===============0788885988== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 05, 2007 at 07:30:04AM -0800, Joe Touch wrote: >=20 >=20 > Lars Eggert wrote: > > Hi, > >=20 > > attached is a diff between -06 and my current working copy, to let the > > WG know about the changes I've made so far to address WG last call > > comments. > >=20 > > There were some suggestions discussed in response to Joe's and Alfred's > > comments that I haven't made, because the rest of the WG was silent, > > which I interpreted as lack of consensus for the change. Speak up if you > > disagree with this resolution. >=20 > I have spoken before on this point in general. Apathy is not consensus. >=20 > Apathy can be a reason to not include a change, but that's the reason. > Not consensus. Apathy and consensus are not point states. This document has a lengthy (perhaps too lengthy) history of largely supportive comment. The IETF doesn't require people to re-defend consensus on each iteration. I haven't gone back to re-read the exchanges on this particular aspect of the doc and I will. --=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 --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHL2XNaUz3f+Zf+XsRAt0xAKDceYiZVgAmLXU71GjU+lsG/BJMKACdEu6p mfH1GmcLDpxE+WG62FDx9AI= =QVma -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- --===============0788885988== 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 --===============0788885988==-- From tcpm-bounces@ietf.org Mon Nov 05 14:30:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7en-00065g-7U; Mon, 05 Nov 2007 14:30:45 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ip7el-00065P-VZ for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 14:30:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7el-00065C-KY for tcpm@ietf.org; Mon, 05 Nov 2007 14:30:43 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip7el-0000SX-2H for tcpm@ietf.org; Mon, 05 Nov 2007 14:30:43 -0500 Received: from [75.214.23.2] (2.sub-75-214-23.myvzw.com [75.214.23.2]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA5JUDcG011430; Mon, 5 Nov 2007 11:30:14 -0800 (PST) Message-ID: <472F6F38.5050803@isi.edu> Date: Mon, 05 Nov 2007 11:30:00 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Faber Subject: Re: [tcpm] WGLC for UTO References: <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> <4728A553.2020300@isi.edu> <6B3D5E1D-F2DA-428C-AAEF-6F548F48F4F5@nokia.com> <3DF7B46C-5246-470E-9C98-08A5AEADDAF3@nokia.com> <472F36FC.1030301@isi.edu> <20071105184949.GA31862@hut.isi.edu> In-Reply-To: <20071105184949.GA31862@hut.isi.edu> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tcpm@ietf.org, =?ISO-8859-1?Q?nes?= , =?ISO-8859-1?Q?ext_Alfred_H=CE?= 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="===============0680282583==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0680282583== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0225AE2B9718F918A7A55E08" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0225AE2B9718F918A7A55E08 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ted Faber wrote: > On Mon, Nov 05, 2007 at 07:30:04AM -0800, Joe Touch wrote: >> >> Lars Eggert wrote: >>> Hi, >>> >>> attached is a diff between -06 and my current working copy, to let th= e >>> WG know about the changes I've made so far to address WG last call >>> comments. >>> >>> There were some suggestions discussed in response to Joe's and Alfred= 's >>> comments that I haven't made, because the rest of the WG was silent, >>> which I interpreted as lack of consensus for the change. Speak up if = you >>> disagree with this resolution. >> I have spoken before on this point in general. Apathy is not consensus= =2E >> >> Apathy can be a reason to not include a change, but that's the reason.= >> Not consensus. >=20 > Apathy and consensus are not point states. >=20 > This document has a lengthy (perhaps too lengthy) history of largely > supportive comment. The IETF doesn't require people to re-defend > consensus on each iteration. >=20 > I haven't gone back to re-read the exchanges on this particular aspect > of the doc and I will. I don't know if the points Lars is discussing above have been raised before; he indicated only that there was no discussion by the WG. If they have been raised before, I agree with your statement about not re-defending consensus. If these are new, however, I would hope we would have some discusion to determine how to proceed. I'll wait for the summary of points though - which could include that context (i.e., consensus'd before or not)... Joe --------------enig0225AE2B9718F918A7A55E08 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHL284E5f5cImnZrsRAibEAJ46xInSKMiO0F//sYVU8/9DR3uFrACfTpdh DYMUrXn0ZyYl2lxxkXY1LXk= =udWp -----END PGP SIGNATURE----- --------------enig0225AE2B9718F918A7A55E08-- --===============0680282583== 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 --===============0680282583==-- From tcpm-bounces@ietf.org Mon Nov 05 14:52:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7zM-0001vs-5i; Mon, 05 Nov 2007 14:52:00 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ip7zJ-0001uI-GO for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 14:51:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7zJ-0001u9-6u for tcpm@ietf.org; Mon, 05 Nov 2007 14:51:57 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip7zH-0000Mj-Tx for tcpm@ietf.org; Mon, 05 Nov 2007 14:51:57 -0500 Received: from [128.9.176.244] (c3-vpn6.isi.edu [128.9.176.244]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA5JpZ4T005780; Mon, 5 Nov 2007 11:51:39 -0800 (PST) Message-ID: <472F7437.7010207@isi.edu> Date: Mon, 05 Nov 2007 11:51:19 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [tcpm] WGLC for UTO References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> <4728A553.2020300@isi.edu> <6B3D5E1D-F2DA-428C-AAEF-6F548F48F4F5@nokia.com> <3DF7B46C-5246-470E-9C98-08A5AEADDAF3@nokia.com> In-Reply-To: <3DF7B46C-5246-470E-9C98-08A5AEADDAF3@nokia.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: =?ISO-8859-1?Q?ext_Alfred_H=CEnes?= , 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="===============0267006637==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0267006637== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig73C1089011AF29AE729B71E8" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig73C1089011AF29AE729B71E8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable PS - overall, the updates below look good (thanks). Joe Lars Eggert wrote: > Hi, >=20 > attached is a diff between -06 and my current working copy, to let the > WG know about the changes I've made so far to address WG last call > comments. >=20 > There were some suggestions discussed in response to Joe's and Alfred's= > comments that I haven't made, because the rest of the WG was silent, > which I interpreted as lack of consensus for the change. Speak up if yo= u > disagree with this resolution. >=20 > Lars --------------enig73C1089011AF29AE729B71E8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHL3Q3E5f5cImnZrsRAsyEAKCrgDt795FHl2bdVauUw9sSiC5q7wCfYVUx SXDGmLVtC9yfHKiKEnaCBas= =SLAZ -----END PGP SIGNATURE----- --------------enig73C1089011AF29AE729B71E8-- --===============0267006637== 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 --===============0267006637==-- From tcpm-bounces@ietf.org Mon Nov 05 16:16:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip9J6-0000qj-L6; Mon, 05 Nov 2007 16:16:28 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ip9J5-0000q6-LJ for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 16:16:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip9J5-0000pm-9w for tcpm@ietf.org; Mon, 05 Nov 2007 16:16:27 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip9J4-0003cd-SS for tcpm@ietf.org; Mon, 05 Nov 2007 16:16:27 -0500 X-IronPort-AV: E=Sophos;i="4.21,374,1188770400"; d="scan'208";a="156965724" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2007 22:16:24 +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 lA5LGN0Z007929; Mon, 5 Nov 2007 22:16:23 +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 lA5LGIqT008694; Mon, 5 Nov 2007 21:16:18 GMT Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4400.cisco.com [10.61.81.47]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA25938; Mon, 5 Nov 2007 21:16:17 GMT Message-Id: <200711052116.VAA25938@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 05 Nov 2007 21:16:13 +0000 To: Joe Touch , speakeasy From: Lloyd Wood Subject: Re: [tcpm] Is this a problem? In-Reply-To: <472BA410.5070509@isi.edu> References: <359024.58790.qm@web31711.mail.mud.yahoo.com> <472BA410.5070509@isi.edu> 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: 52e1467c2184c31006318542db5614d5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org At Friday 02/11/2007 15:26 -0700, Joe Touch wrote: >speakeasy wrote: >> >> On Nov 2, 2007, at 12:00 AM, MURALI BASHYAM wrote: >> >>> >>> Clearly there seems to be no consensus on where the problem lies. >>> I've heard that it's not a transport problem, and that the >>> responsibility for mitigating the problem lies with a) sockets API, b) >>> OS, and >>> c) the application. That's as varied a response as one can get... >>> >> >> There is no need for TCPM to decide which of the three is the best >> solution, since all >> three solutions can interoperate on the wire. > >I agree - the fact that these all vary is less important to TCPM than >the fact that none have anything to do with TCP. > >Yes, this is a problem for which a variety of solutions exist, and for >which a coordinated solution would be useful. No, that itself is not >justification for assuming TCP is the place to do this. try this thought on for size: "The need for congestion control is a problem for which a variety of solutions exist, and for which a coordinated solution would be useful. No, that itself is not justification for assuming TCP is the place to do this." ...but congestion control was put in TCP _anyway_. I still don't see what output behaviour algorithms have to do with on-the-wire header layout specifications, but that is all that is being discussed here. L. Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 05 16:28:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip9Ug-00053i-Gh; Mon, 05 Nov 2007 16:28:26 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ip9Ue-000511-4u for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 16:28:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip9Ud-00050W-Q3 for tcpm@ietf.org; Mon, 05 Nov 2007 16:28:23 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip9Ud-0003tc-Du for tcpm@ietf.org; Mon, 05 Nov 2007 16:28:23 -0500 Received: from [128.9.176.244] (c3-vpn6.isi.edu [128.9.176.244]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA5LS5lf017998; Mon, 5 Nov 2007 13:28:06 -0800 (PST) Message-ID: <472F8AD8.8080602@isi.edu> Date: Mon, 05 Nov 2007 13:27:52 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lloyd Wood Subject: Re: [tcpm] Is this a problem? References: <359024.58790.qm@web31711.mail.mud.yahoo.com> <472BA410.5070509@isi.edu> <200711052116.VAA25938@cisco.com> In-Reply-To: <200711052116.VAA25938@cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0455168447==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0455168447== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC879BDD9F6BCC48EBB075AA7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC879BDD9F6BCC48EBB075AA7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lloyd Wood wrote: =2E.. >> Yes, this is a problem for which a variety of solutions exist, and for= >> which a coordinated solution would be useful. No, that itself is not >> justification for assuming TCP is the place to do this. >=20 > try this thought on for size: >=20 > "The need for congestion control is a problem for which a variety of > solutions exist, and for which a coordinated solution would be useful. I should have said "for which a variety of solutions in a variety of places - OS, application, API, protocol - exist..." The primary point is that this isn't owned by communications layers. Joe --------------enigC879BDD9F6BCC48EBB075AA7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHL4rYE5f5cImnZrsRAs61AJ9mw8Hlna+neGAiCs4Omv7TX2OCYQCgwlOJ Rj/TlJES77mtg8BqQG90oKc= =+RuT -----END PGP SIGNATURE----- --------------enigC879BDD9F6BCC48EBB075AA7-- --===============0455168447== 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 --===============0455168447==-- From tcpm-bounces@ietf.org Mon Nov 05 18:14:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpB9M-0003dN-Pv; Mon, 05 Nov 2007 18:14:32 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpB9L-0003bz-Fo for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 18:14:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpB9L-0003bD-4p for tcpm@ietf.org; Mon, 05 Nov 2007 18:14:31 -0500 Received: from web31703.mail.mud.yahoo.com ([68.142.201.183]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpB9K-0000We-OU for tcpm@ietf.org; Mon, 05 Nov 2007 18:14:31 -0500 Received: (qmail 85898 invoked by uid 60001); 5 Nov 2007 23:14:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=ATEvre+LnRpvF9kYAhzCqIT/zvzV+WAKBUkTIl19M58BLnYw7XuVwYRgfjHbfO+9qk0wp6uDeUU+KyI6BSwS48p6lrZgdoa8iesX6yR1r+7z0VIgGLqD5qEyuvK6wmRUd9peJfTfjAmDlN2GzTjNxrFRavMyvU93EdDNJZfUv34=; X-YMail-OSG: qkSN85MVM1loix3qhLXoJcoNDelc1hRAloYMrxPwTMo0H0.AVMRjzxlyacMCgqt8uq4fcuRbHNwPppjbyVzmUMsOZHCGLnBu5wGL5NWwGmmkSQub92raLLiDULbRFQ-- Received: from [69.3.29.18] by web31703.mail.mud.yahoo.com via HTTP; Mon, 05 Nov 2007 15:14:29 PST X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152 Date: Mon, 5 Nov 2007 15:14:29 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? To: Joe Touch , Lloyd Wood MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <71199.85889.qm@web31703.mail.mud.yahoo.com> 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: , Errors-To: tcpm-bounces@ietf.org ----- Original Message ---- From: Joe Touch To: Lloyd Wood Cc: tcpm@ietf.org Sent: Monday, November 5, 2007 1:27:52 PM Subject: Re: [tcpm] Is this a problem? Lloyd Wood wrote: ... >> Yes, this is a problem for which a variety of solutions exist, and for >> which a coordinated solution would be useful. No, that itself is not >> justification for assuming TCP is the place to do this. > > try this thought on for size: > > "The need for congestion control is a problem for which a variety of > solutions exist, and for which a coordinated solution would be useful. I should have said "for which a variety of solutions in a variety of places - OS, application, API, protocol - exist..." The primary point is that this isn't owned by communications layers. The point is that it can be solved in TCP or at the transport layer ALSO. It's as good a place if not better (from the co-ordination point of view and from the sender state visibility points of view). Let me ask the question: Can you elaborate the reasons why doing it in TCP is not a good idea? "A variety of solutions in a variety of places" is not a good position to be in, we want the right solution in the one, correct place, with the least possible disruption to the server community. Joe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 05 19:04:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpBvq-00089n-K2; Mon, 05 Nov 2007 19:04:38 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpBvq-00089b-2w for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 19:04:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpBvp-00089S-O7 for tcpm@ietf.org; Mon, 05 Nov 2007 19:04:37 -0500 Received: from web31710.mail.mud.yahoo.com ([68.142.201.190]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpBvp-0001kR-97 for tcpm@ietf.org; Mon, 05 Nov 2007 19:04:37 -0500 Received: (qmail 34125 invoked by uid 60001); 6 Nov 2007 00:04:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=U6T19lkzPo4kZr4X5ubw01RqWuAQL+7/a1rcts0kIMjh9lkeyAIy0vijGevprpUS/PI9vAktAQWJfvu+fwPSZskzkR7vIaFOVy7zpn388ERt6Z2BumeoFYjWaEcUWnDboFUrp9SbGVlyHpoQPgUJQiZXYFIFJP1q54PHF8+lojs=; X-YMail-OSG: kzqMkagVM1kEy03.a_X0q8erKYLdbn_ISizFyPDg4IUjnWHOapcZs5yRRHcooUAt0faU6dzmm_g_v6I40F7YnA5sTNJi1t9hOaw.uPCY3GSPz9xjl.E- Received: from [69.3.29.18] by web31710.mail.mud.yahoo.com via HTTP; Mon, 05 Nov 2007 16:04:36 PST X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152 Date: Mon, 5 Nov 2007 16:04:36 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? To: MURALI BASHYAM , Joe Touch , Lloyd Wood MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <477019.33504.qm@web31710.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Re-posting my response. Joe, apologies for mangling your response. The point is that it can be solved in TCP or at the transport layer ALSO. It's as good a place if not better (from the co-ordination point of view and from the sender state visibility points of view). Let me ask the question: Can you elaborate the reasons why doing it in TCP is not a good idea? "A variety of solutions in a variety of places" is not a good position to be in, we want the right solution in the one, correct place, with the least possible disruption to the server community. Murali ----- Original Message ---- From: MURALI BASHYAM To: Joe Touch ; Lloyd Wood Cc: tcpm@ietf.org Sent: Monday, November 5, 2007 3:14:29 PM Subject: Re: [tcpm] Is this a problem? ----- Original Message ---- From: Joe Touch To: Lloyd Wood Cc: tcpm@ietf.org Sent: Monday, November 5, 2007 1:27:52 PM Subject: Re: [tcpm] Is this a problem? Lloyd Wood wrote: ... >> Yes, this is a problem for which a variety of solutions exist, and for >> which a coordinated solution would be useful. No, that itself is not >> justification for assuming TCP is the place to do this. > > try this thought on for size: > > "The need for congestion control is a problem for which a variety of > solutions exist, and for which a coordinated solution would be useful. I should have said "for which a variety of solutions in a variety of places - OS, application, API, protocol - exist..." The primary point is that this isn't owned by communications layers. Joe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 05 19:42:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpCWH-00075n-Ar; Mon, 05 Nov 2007 19:42:17 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpCWF-00073R-Mx for tcpm-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 19:42:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpCWF-00072V-D8 for tcpm@ietf.org; Mon, 05 Nov 2007 19:42:15 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpCWC-0000yA-Qz for tcpm@ietf.org; Mon, 05 Nov 2007 19:42:15 -0500 Received: from [75.213.137.22] (22.sub-75-213-137.myvzw.com [75.213.137.22]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA60g3hZ009097; Mon, 5 Nov 2007 16:42:03 -0800 (PST) Message-ID: <472FB84B.9010003@isi.edu> Date: Mon, 05 Nov 2007 16:41:47 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? References: <477019.33504.qm@web31710.mail.mud.yahoo.com> In-Reply-To: <477019.33504.qm@web31710.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: tcpm@ietf.org, Lloyd Wood 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="===============1079951940==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1079951940== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEBCE06A7164ADA9553B958F2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEBCE06A7164ADA9553B958F2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: > Re-posting my response.=20 >=20 > Joe, apologies for mangling your response. >=20 >=20 > The point is that it can be solved in TCP or at the transport layer > ALSO.=20 It CAN. The question is whether it SHOULD be. > It's as good a place > if not better (from the co-ordination point of view and from the sender= > state visibility points of view). > Let me ask the question: Can you elaborate the reasons why doing it in > TCP is not a good idea?=20 Basically because it CAN easily be done somewhere else. The recommendation (Clark?) is "think twice before modifying TCP, then don't" comes into play. IMO, that means "don't modify TCP unless you absolutely have to". TCP isn't supposed to be a convenient place to do things. It ought to be lean, so you KNOW it'll work correctly. > "A variety of solutions in a variety of places" is not a good position > to be in, we want the right > solution in the one, correct place, with the least possible disruption > to the server community. The right solution in the right place is a good rule too. I don't think TCP is the right - i.e., best or most appropriate place - to do this. I've noted in other emails that you're making a huge assumption about using TCP for this - that all TCP connections are implemented in a single, shared codebase (i.e., the kernel). They are not; that's not a requirement of TCP. I.e., every reason you have for wanting to do this in TCP is a good reason to do this in the kernel, not TCP. Joe > ----- Original Message ---- > From: MURALI BASHYAM > To: Joe Touch ; Lloyd Wood > Cc: tcpm@ietf.org > Sent: Monday, November 5, 2007 3:14:29 PM > Subject: Re: [tcpm] Is this a problem? >=20 >=20 >=20 >=20 > ----- Original Message ---- > From: Joe Touch > To: Lloyd Wood > Cc: tcpm@ietf.org > Sent: Monday, November 5, 2007 1:27:52 PM > Subject: Re: [tcpm] Is this a problem? >=20 >=20 >=20 >=20 > Lloyd Wood wrote: > ... >>> Yes, this is a problem for which a variety of solutions exist, and > for >>> which a coordinated solution would be useful. No, that itself is not >>> justification for assuming TCP is the place to do this. >> try this thought on for size: >> >> "The need for congestion control is a problem for which a variety of >> solutions exist, and for which a coordinated solution would be > useful. >=20 > I should have said "for which a variety of solutions in a variety of > places - OS, application, API, protocol - exist..." >=20 > The primary point is that this isn't owned by communications layers. >=20 >=20 > Joe >=20 >=20 >=20 >=20 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm >=20 >=20 >=20 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com=20 --------------enigEBCE06A7164ADA9553B958F2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHL7hLE5f5cImnZrsRAu79AKC+yz7OHW1peUf9mjZCed4cHJczcQCgkFdr +biu5FjwznS59ss9/cVgwVA= =nJQ2 -----END PGP SIGNATURE----- --------------enigEBCE06A7164ADA9553B958F2-- --===============1079951940== 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 --===============1079951940==-- From tcpm-bounces@ietf.org Tue Nov 06 13:17:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSzT-0008AB-Fx; Tue, 06 Nov 2007 13:17:31 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpSzS-00086w-Da for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 13:17:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSzS-00086o-2a for tcpm@ietf.org; Tue, 06 Nov 2007 13:17:30 -0500 Received: from web31707.mail.mud.yahoo.com ([68.142.201.187]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpSzR-0006xR-Ea for tcpm@ietf.org; Tue, 06 Nov 2007 13:17:29 -0500 Received: (qmail 1069 invoked by uid 60001); 6 Nov 2007 18:17:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=ZfOQyfSlH3XfNWuC8oEzHE8i5RecxFA/2HaGNpEThTbhf2E1mHcJXqR4Fkn1RZ5sW37UNlQT/FtCMcmQOZUEcKz8f2xxZCByfkWrHcKgch3yqQuQlV9Mm4Z3Btit9aRQxpwWFTM4m8TNypDG2PxKKVch9MhtAHSYHj27EbA0jC0=; X-YMail-OSG: X8GvwbsVM1mVC_8e992INh3w_zWi_XomRYC1mf3CmW4nMeHCwr9rzhu43UvXYZd.W_Q3ePRgSJwLgu19X5MUBteIVDUqEBOMUDgzcdI651wpLIkaTTG7FJoqaAbHQw-- Received: from [69.3.29.18] by web31707.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 10:17:28 PST X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152 Date: Tue, 6 Nov 2007 10:17:28 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? To: Joe Touch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <702821.475.qm@web31707.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: tcpm@ietf.org, Lloyd Wood X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org In the spirit of keeping changes to TCP protocol minimal, how about having the application specify a time limit via the socket API when TCP gets into this state and TCP cuts its indefinite wait down to this timeout? All states in the TCP protocol have some sort of a bound in terms of how long they will continue in that state (even EST. has a keepalive timeout tunable by app). Default behaviour continues to be current. ----- Original Message ---- From: Joe Touch To: MURALI BASHYAM Cc: Lloyd Wood ; tcpm@ietf.org Sent: Monday, November 5, 2007 4:41:47 PM Subject: Re: [tcpm] Is this a problem? MURALI BASHYAM wrote: > Re-posting my response. > > Joe, apologies for mangling your response. > > > The point is that it can be solved in TCP or at the transport layer > ALSO. It CAN. The question is whether it SHOULD be. > It's as good a place > if not better (from the co-ordination point of view and from the sender > state visibility points of view). > Let me ask the question: Can you elaborate the reasons why doing it in > TCP is not a good idea? Basically because it CAN easily be done somewhere else. The recommendation (Clark?) is "think twice before modifying TCP, then don't" comes into play. IMO, that means "don't modify TCP unless you absolutely have to". TCP isn't supposed to be a convenient place to do things. It ought to be lean, so you KNOW it'll work correctly. > "A variety of solutions in a variety of places" is not a good position > to be in, we want the right > solution in the one, correct place, with the least possible disruption > to the server community. The right solution in the right place is a good rule too. I don't think TCP is the right - i.e., best or most appropriate place - to do this. I've noted in other emails that you're making a huge assumption about using TCP for this - that all TCP connections are implemented in a single, shared codebase (i.e., the kernel). They are not; that's not a requirement of TCP. I.e., every reason you have for wanting to do this in TCP is a good reason to do this in the kernel, not TCP. Joe > ----- Original Message ---- > From: MURALI BASHYAM > To: Joe Touch ; Lloyd Wood > Cc: tcpm@ietf.org > Sent: Monday, November 5, 2007 3:14:29 PM > Subject: Re: [tcpm] Is this a problem? > > > > > ----- Original Message ---- > From: Joe Touch > To: Lloyd Wood > Cc: tcpm@ietf.org > Sent: Monday, November 5, 2007 1:27:52 PM > Subject: Re: [tcpm] Is this a problem? > > > > > Lloyd Wood wrote: > ... >>> Yes, this is a problem for which a variety of solutions exist, and > for >>> which a coordinated solution would be useful. No, that itself is not >>> justification for assuming TCP is the place to do this. >> try this thought on for size: >> >> "The need for congestion control is a problem for which a variety of >> solutions exist, and for which a coordinated solution would be > useful. > > I should have said "for which a variety of solutions in a variety of > places - OS, application, API, protocol - exist..." > > The primary point is that this isn't owned by communications layers. > > > Joe > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 06 13:25:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpT76-0008WB-AS; Tue, 06 Nov 2007 13:25:24 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpT75-0008Uk-NC for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 13:25:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpT75-0008Uc-DY for tcpm@ietf.org; Tue, 06 Nov 2007 13:25:23 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpT70-0003Uc-6w for tcpm@ietf.org; Tue, 06 Nov 2007 13:25:23 -0500 Received: from [75.212.119.228] (228.sub-75-212-119.myvzw.com [75.212.119.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA6IP6sW017703; Tue, 6 Nov 2007 10:25:06 -0800 (PST) Message-ID: <4730B171.5020009@isi.edu> Date: Tue, 06 Nov 2007 10:24:49 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? References: <702821.475.qm@web31707.mail.mud.yahoo.com> In-Reply-To: <702821.475.qm@web31707.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tcpm@ietf.org, Lloyd Wood 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="===============1203466546==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1203466546== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig24A6E11A2881D9DA2CE2AFAC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig24A6E11A2881D9DA2CE2AFAC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: > In the spirit of keeping changes to TCP protocol minimal, how about > having the application specify a time limit via the socket API when TCP= gets into this > state and TCP cuts its indefinite wait down to this timeout?=20 Why not set the timer in the application and ABORT or CLOSE the connection when the timer goes off? Joe --------------enig24A6E11A2881D9DA2CE2AFAC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMLFyE5f5cImnZrsRAuUiAJ9dlmoe/0y9I5TMn7y0iBB8ikw93QCdE7RW Wta6Fc/24TqvVjbp9bWR4pg= =JLgC -----END PGP SIGNATURE----- --------------enig24A6E11A2881D9DA2CE2AFAC-- --===============1203466546== 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 --===============1203466546==-- From tcpm-bounces@ietf.org Tue Nov 06 13:37:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTIo-0004CX-Qz; Tue, 06 Nov 2007 13:37:30 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpTIo-0004CS-0D for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 13:37:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTIn-0004CK-Mu for tcpm@ietf.org; Tue, 06 Nov 2007 13:37:29 -0500 Received: from web31702.mail.mud.yahoo.com ([68.142.201.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IpTIk-0003od-0S for tcpm@ietf.org; Tue, 06 Nov 2007 13:37:29 -0500 Received: (qmail 10538 invoked by uid 60001); 6 Nov 2007 18:37:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=G+CU4nHIfeWGSbMomO6VV2Ljt69FyNOPp/PE8hkPIidndZvs+8pT9dhbGW8IJOyJdHv5Dvpw1rCoqIY33QavUCi7Dr/iQQbLEvS9SILsRr7OVGudolT5al2RUfZJvz+5EjkRfxg3LZw6pORA6FQAN2KCQQt2DynZvoEReox95ic=; X-YMail-OSG: On0oakwVM1kGzDoFGzAoClqi0s2wgq9c7MEA4EzDB2cyVdZnLvwPKnM10Vlq2s81_MdQwwHnTZx9qEXC0RZgjXbbuPS3p2cL6BrRbz5IGqA5Vqd5_o0- Received: from [69.3.29.18] by web31702.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 10:37:24 PST X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152 Date: Tue, 6 Nov 2007 10:37:24 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? To: Joe Touch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <121882.10140.qm@web31702.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tcpm@ietf.org, Lloyd Wood 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 We want to limit the timer to the sender's persist state only, any other timeout overloads the semantics of the application, and may also cause unnecessary timeouts for the application. In fact there are instances where the application may not even have the connection state around to implement the timout correctly, like the tail of a long HTTP response. After sending the tail of the response, the application can close the connection and release its connection memory, during this window only TCP has the connection state. We've done a lot of testing and design for handling all these cases, and to implement this correctly, we need TCP's involvement. Murali ----- Original Message ---- From: Joe Touch To: MURALI BASHYAM Cc: Lloyd Wood ; tcpm@ietf.org Sent: Tuesday, November 6, 2007 10:24:49 AM Subject: Re: [tcpm] Is this a problem? MURALI BASHYAM wrote: > In the spirit of keeping changes to TCP protocol minimal, how about > having the application specify a time limit via the socket API when TCP gets into this > state and TCP cuts its indefinite wait down to this timeout? Why not set the timer in the application and ABORT or CLOSE the connection when the timer goes off? Joe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 06 13:41:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTMD-00081L-Vn; Tue, 06 Nov 2007 13:41:01 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpTMC-0007zM-PR for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 13:41:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTMC-0007zD-Ev for tcpm@ietf.org; Tue, 06 Nov 2007 13:41:00 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpTMC-0007Yf-0O for tcpm@ietf.org; Tue, 06 Nov 2007 13:41:00 -0500 Received: from [75.212.119.228] (228.sub-75-212-119.myvzw.com [75.212.119.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA6IePr1021729; Tue, 6 Nov 2007 10:40:30 -0800 (PST) Message-ID: <4730B50A.1030102@isi.edu> Date: Tue, 06 Nov 2007 10:40:10 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? References: <121882.10140.qm@web31702.mail.mud.yahoo.com> In-Reply-To: <121882.10140.qm@web31702.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tcpm@ietf.org, Lloyd Wood 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="===============1285824496==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1285824496== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig02FA7786B738EAE5B33C3540" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig02FA7786B738EAE5B33C3540 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: > We want to limit the timer to the sender's persist state only, any othe= r timeout overloads the semantics of the application, > and may also cause unnecessary timeouts for the application. In fact th= ere are instances where the application may not > even have the connection state around to implement the timout correctly= , like the tail of a long HTTP response. After sending the tail of the=20 > response, the application can close the connection and release its conn= ection memory, during this window only TCP has the=20 > connection state. We've done a lot of testing and design for handling = all these cases, and to implement this correctly,=20 > we need TCP's involvement. It still sounds like you have a poorly written application to me; anyone else? Joe --------------enig02FA7786B738EAE5B33C3540 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMLUKE5f5cImnZrsRAlquAKCRHnzXU2+nh+Veb43vH9bL6R2ZFACg4Bpj +61ebLAlCwIIycvVTfarb60= =5UJ7 -----END PGP SIGNATURE----- --------------enig02FA7786B738EAE5B33C3540-- --===============1285824496== 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 --===============1285824496==-- From tcpm-bounces@ietf.org Tue Nov 06 13:51:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTVs-0007Hn-C2; Tue, 06 Nov 2007 13:51:00 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpTVr-0007Hh-1X for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 13:50:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTVq-0007Gr-Mh for tcpm@ietf.org; Tue, 06 Nov 2007 13:50:58 -0500 Received: from web31710.mail.mud.yahoo.com ([68.142.201.190]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpTVq-0007m6-9D for tcpm@ietf.org; Tue, 06 Nov 2007 13:50:58 -0500 Received: (qmail 66101 invoked by uid 60001); 6 Nov 2007 18:50:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=XjXyrGcJ3i64p1jDacy4D6Hcj8S52PrmoqvoHGCCCZ90egDY4Dj1A7OWpbp4oczniJ2MtvaqTkwWcc9b+P9CTp+7qpVAntB9FoEVzEe+4DFp7T4NxOR9ZsSZEVWGDCXPhy/Jdow7Ii5guQodv79wNxwiADY+kSPTJGMuxiExuqs=; X-YMail-OSG: IRB.CfkVM1nKO7vlR7ms5YL2tyVTDjLgpTrVsjl8ikm2heV76vAeGGLOR8jzPiXuZHkfCetPGsAdJ1y_ItIKSUiXzAaCJhcg.IltW7sFuIG.acDq6Ik- Received: from [69.3.29.18] by web31710.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 10:50:50 PST X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152 Date: Tue, 6 Nov 2007 10:50:50 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? To: Joe Touch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <599223.66019.qm@web31710.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org, Lloyd Wood X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org This behaviour can and does get exhibited by standard web servers also, it's not only our application. The solution must work in scenarios where the application can cleanup its connection state, expecting TCP to deliver the data reliably to the peer after that. It's not a broken application, this is a perfectly legal scenario. As far as the app is concerned, it's done with that connection, it can devote that connection memory and resources to another user or client, thus increasing goodput. ----- Original Message ---- From: Joe Touch To: MURALI BASHYAM Cc: Lloyd Wood ; tcpm@ietf.org Sent: Tuesday, November 6, 2007 10:40:10 AM Subject: Re: [tcpm] Is this a problem? MURALI BASHYAM wrote: > We want to limit the timer to the sender's persist state only, any other timeout overloads the semantics of the application, > and may also cause unnecessary timeouts for the application. In fact there are instances where the application may not > even have the connection state around to implement the timout correctly, like the tail of a long HTTP response. After sending the tail of the > response, the application can close the connection and release its connection memory, during this window only TCP has the > connection state. We've done a lot of testing and design for handling all these cases, and to implement this correctly, > we need TCP's involvement. It still sounds like you have a poorly written application to me; anyone else? Joe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 06 14:04:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTic-0007TJ-LW; Tue, 06 Nov 2007 14:04:10 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpTib-0007M2-Fd for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 14:04:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTib-0007Lt-4G for tcpm@ietf.org; Tue, 06 Nov 2007 14:04:09 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpTia-0008SQ-LP for tcpm@ietf.org; Tue, 06 Nov 2007 14:04:09 -0500 Received: from [75.212.119.228] (228.sub-75-212-119.myvzw.com [75.212.119.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA6J3f7T027706; Tue, 6 Nov 2007 11:03:42 -0800 (PST) Message-ID: <4730BA7E.4090209@isi.edu> Date: Tue, 06 Nov 2007 11:03:26 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? References: <599223.66019.qm@web31710.mail.mud.yahoo.com> In-Reply-To: <599223.66019.qm@web31710.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org, Lloyd Wood 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="===============0198109138==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0198109138== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6177B720588AD01CD0198037" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6177B720588AD01CD0198037 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: > This behaviour can and does get exhibited by standard web servers also,= it's not only our application. So multiple apps are broken - this has happened before. > The solution must > work in scenarios where the application can cleanup its connection stat= e, expecting TCP to deliver the data reliably to the peer after that. There is a disconnect in believing that TCP ever needs to clean up its connection state. TCP tends to leave state around and clean it up when a new connection overtakes it; it does not tend to clean things up. > It's not a broken application, this is a perfectly legal scenario. As f= ar as the app is concerned, it's done with that connection, it can devote= > that connection memory and resources to another user or client, thus i= ncreasing goodput. As you note the resources don't get released until the data is transferred or the connection is aborted, so it's a misconception that the application should close a connection to release memory and resources= =2E Finally, it sounds like you didn't want a nonblocking CLOSE; you want to use a blocking CLOSE with an application timeout timer. Joe --------------enig6177B720588AD01CD0198037 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMLp/E5f5cImnZrsRAotkAKDE6w4mBoT2aZQPkbPXKx/57Jv2pQCeI7/H mcJbRFk6M94qekO02bjXQy0= =T6SV -----END PGP SIGNATURE----- --------------enig6177B720588AD01CD0198037-- --===============0198109138== 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 --===============0198109138==-- From tcpm-bounces@ietf.org Tue Nov 06 14:09:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTnH-0007Yl-M9; Tue, 06 Nov 2007 14:08:59 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpTnH-0007Xk-1S for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 14:08:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTnG-0007XN-Ni for tcpm@ietf.org; Tue, 06 Nov 2007 14:08:58 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpTnD-0004mA-CJ for tcpm@ietf.org; Tue, 06 Nov 2007 14:08:58 -0500 Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpTn6-0003g0-7k; Tue, 06 Nov 2007 19:08:53 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 040E52BE21; Tue, 6 Nov 2007 14:08:45 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 43A7A283F2; Tue, 6 Nov 2007 14:08:45 -0500 (EST) Date: Tue, 6 Nov 2007 14:08:45 -0500 From: Ethan Blanton To: Joe Touch Subject: Re: [tcpm] Is this a problem? Message-ID: <20071106190845.GC5881@elb.elitists.net> Mail-Followup-To: Joe Touch , MURALI BASHYAM , tcpm@ietf.org, Lloyd Wood References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> MIME-Version: 1.0 In-Reply-To: <4730B50A.1030102@isi.edu> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -102.8 (---------------------------------------------------) X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tcpm@ietf.org, Lloyd Wood 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="===============1431810457==" Errors-To: tcpm-bounces@ietf.org --===============1431810457== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CblX+4bnyfN0pR09" Content-Disposition: inline --CblX+4bnyfN0pR09 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Joe Touch spake unto us the following wisdom: > MURALI BASHYAM wrote: > > We want to limit the timer to the sender's persist state only, any > > other timeout overloads the semantics of the application, and may also > > cause unnecessary timeouts for the application. In fact there are > > instances where the application may not even have the connection state > > around to implement the timout correctly, like the tail of a long HTTP > > response. After sending the tail of the response, the application can > > close the connection and release its connection memory, during this > > window only TCP has the connection state. We've done a lot of testing > > and design for handling all these cases, and to implement this > > correctly, we need TCP's involvement. >=20 > It still sounds like you have a poorly written application to me; anyone > else? This comment of Murali's, specifically, is a case that the application *cannot* (portably or cleanly) handle, at least under the Berkeley sockets API. He is correct that once an application writes the end of its data and calls close() or shutdown(), the TCP socket may persist indefinitely in the kernel, and the application would never know (if there are no application-level acknowledgments, as there are not in simple HTTP responses). It does not seem unreasonable to add a zero-window timeout tunable to any given TCP implementation; I don't necessarily think it is a TCP standardization issue, however, as there is no wire impact. 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 --CblX+4bnyfN0pR09 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHMLu9r9kA9Ig8HBQRAkglAKCxyV5T6hMhf1NyMbO8l9CGSeNv+ACfRnqS afflKGYp4m19dfewxR4E4fM= =0zCk -----END PGP SIGNATURE----- --CblX+4bnyfN0pR09-- --===============1431810457== 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 --===============1431810457==-- From tcpm-bounces@ietf.org Tue Nov 06 14:13:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTrm-0005tp-DX; Tue, 06 Nov 2007 14:13:38 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpTrk-0005py-Ol for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 14:13:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTrk-0005pb-Dd for tcpm@ietf.org; Tue, 06 Nov 2007 14:13:36 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpTrj-0000Ec-Tq for tcpm@ietf.org; Tue, 06 Nov 2007 14:13:36 -0500 Received: from [75.212.119.228] (228.sub-75-212-119.myvzw.com [75.212.119.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA6JCPxc029806; Tue, 6 Nov 2007 11:12:26 -0800 (PST) Message-ID: <4730BC89.5000909@isi.edu> Date: Tue, 06 Nov 2007 11:12:09 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch , MURALI BASHYAM , tcpm@ietf.org, Lloyd Wood Subject: Re: [tcpm] Is this a problem? References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> In-Reply-To: <20071106190845.GC5881@elb.elitists.net> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: , Content-Type: multipart/mixed; boundary="===============0076362326==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0076362326== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBD767C88FB0A17F1538D3006" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBD767C88FB0A17F1538D3006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ethan Blanton wrote: > Joe Touch spake unto us the following wisdom: >> MURALI BASHYAM wrote: >>> We want to limit the timer to the sender's persist state only, any >>> other timeout overloads the semantics of the application, and may als= o >>> cause unnecessary timeouts for the application. In fact there are >>> instances where the application may not even have the connection stat= e >>> around to implement the timout correctly, like the tail of a long HTT= P >>> response. After sending the tail of the response, the application can= >>> close the connection and release its connection memory, during this >>> window only TCP has the connection state. We've done a lot of testing= >>> and design for handling all these cases, and to implement this >>> correctly, we need TCP's involvement. >> It still sounds like you have a poorly written application to me; anyo= ne >> else? >=20 > This comment of Murali's, specifically, is a case that the application > *cannot* (portably or cleanly) handle, at least under the Berkeley > sockets API. He is correct that once an application writes the end of > its data and calls close() or shutdown(), the TCP socket may persist > indefinitely in the kernel, and the application would never know (if > there are no application-level acknowledgments, as there are not in > simple HTTP responses). Why would a blocking CLOSE not solve that? > It does not seem unreasonable to add a zero-window timeout tunable to > any given TCP implementation; I don't necessarily think it is a TCP > standardization issue, however, as there is no wire impact. Protocols are more than just what is on the wire. They include state at the endpoints, and APIs. Joe --------------enigBD767C88FB0A17F1538D3006 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMLyJE5f5cImnZrsRArDzAKDpUqaoC9ItytXA2BzLmSJicRpEbwCg9Gn7 RfYok1vySNtG6CHKAdxfTF4= =gGlI -----END PGP SIGNATURE----- --------------enigBD767C88FB0A17F1538D3006-- --===============0076362326== 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 --===============0076362326==-- From tcpm-bounces@ietf.org Tue Nov 06 14:27:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpU5e-00070T-IO; Tue, 06 Nov 2007 14:27:58 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpU5d-0006yw-Jg for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 14:27:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpU5d-0006yo-A4 for tcpm@ietf.org; Tue, 06 Nov 2007 14:27:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpU5a-00059p-SV for tcpm@ietf.org; Tue, 06 Nov 2007 14:27:57 -0500 Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpU5V-0004y1-2f; Tue, 06 Nov 2007 19:27:54 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id D1B1F2BE21; Tue, 6 Nov 2007 14:27:46 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 1DC44283F2; Tue, 6 Nov 2007 14:27:46 -0500 (EST) Date: Tue, 6 Nov 2007 14:27:46 -0500 From: Ethan Blanton To: Joe Touch Subject: Re: [tcpm] Is this a problem? Message-ID: <20071106192746.GE5881@elb.elitists.net> Mail-Followup-To: Joe Touch , tcpm@ietf.org References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu> MIME-Version: 1.0 In-Reply-To: <4730BC89.5000909@isi.edu> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -104.1 (---------------------------------------------------) X-Spam-Score: -4.0 (----) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0777269282==" Errors-To: tcpm-bounces@ietf.org --===============0777269282== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RpqchZ26BWispMcB" Content-Disposition: inline --RpqchZ26BWispMcB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (Apologies for the duplicate, Joe, I didn't reply-to-list.) Joe Touch spake unto us the following wisdom: > > This comment of Murali's, specifically, is a case that the application > > *cannot* (portably or cleanly) handle, at least under the Berkeley > > sockets API. He is correct that once an application writes the end of > > its data and calls close() or shutdown(), the TCP socket may persist > > indefinitely in the kernel, and the application would never know (if > > there are no application-level acknowledgments, as there are not in > > simple HTTP responses). >=20 > Why would a blocking CLOSE not solve that? It is my understanding (correct me if I am wrong) that close() returns immediately, regardless of queued data in the send buffer. In addition, I am not aware of any way to force a reset on a TCP socket without pending data in the read buffer. > > It does not seem unreasonable to add a zero-window timeout tunable to > > any given TCP implementation; I don't necessarily think it is a TCP > > standardization issue, however, as there is no wire impact. >=20 > Protocols are more than just what is on the wire. They include state at > the endpoints, and APIs. Agreed, to some extent. 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 --RpqchZ26BWispMcB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHMMAyr9kA9Ig8HBQRAt8oAJ9cQTQxR6qcg+7ZiRw71IWC0W+h1ACdH8FI LKFTInilVn8USxG9JMjkvKc= =mO+S -----END PGP SIGNATURE----- --RpqchZ26BWispMcB-- --===============0777269282== 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 --===============0777269282==-- From tcpm-bounces@ietf.org Tue Nov 06 14:39:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUGk-0003WT-1F; Tue, 06 Nov 2007 14:39:26 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpUGi-0003WN-R4 for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 14:39:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUGi-0003WF-Ha for tcpm@ietf.org; Tue, 06 Nov 2007 14:39:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpUGf-0005Qy-7U for tcpm@ietf.org; Tue, 06 Nov 2007 14:39:24 -0500 Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpUGZ-0005ls-58; Tue, 06 Nov 2007 19:39:20 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id DD0F22BE21; Tue, 6 Nov 2007 14:39:12 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 259CE283F2; Tue, 6 Nov 2007 14:39:12 -0500 (EST) Date: Tue, 6 Nov 2007 14:39:12 -0500 From: Ethan Blanton To: Joe Touch , tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? Message-ID: <20071106193912.GF5881@elb.elitists.net> Mail-Followup-To: Joe Touch , tcpm@ietf.org References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu> <20071106192746.GE5881@elb.elitists.net> MIME-Version: 1.0 In-Reply-To: <20071106192746.GE5881@elb.elitists.net> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -104.1 (---------------------------------------------------) X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: , Content-Type: multipart/mixed; boundary="===============1452877758==" Errors-To: tcpm-bounces@ietf.org --===============1452877758== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UBnjLfzoMQYIXCvq" Content-Disposition: inline --UBnjLfzoMQYIXCvq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ethan Blanton spake unto us the following wisdom: > It is my understanding (correct me if I am wrong) that close() returns > immediately, regardless of queued data in the send buffer. In > addition, I am not aware of any way to force a reset on a TCP socket > without pending data in the read buffer. SO_LINGER is indeed more flexible than I have used it for -- it can be used to solve both of these problems. For the benefit of those listening: 1) Set SO_LINGER with l_onoff !=3D 0 and l_linger =3D timeout in seconds. 2) If a nonblocking close returns EWOULDBLOCK, the linger timeout expired, so: 2a) set SO_LINGER with l_onoff !=3D 0 and l_linger =3D 0 2b) call close, which will emit a RST I recant my previous claims -- this can be handled cleanly with standard sockets. > > > It does not seem unreasonable to add a zero-window timeout tunable to > > > any given TCP implementation; I don't necessarily think it is a TCP > > > standardization issue, however, as there is no wire impact. I do stand by this, however. 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 --UBnjLfzoMQYIXCvq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQFHMMLgr9kA9Ig8HBQRAnU2AJdqu7TvC6QmVWb+PSmL89BH5giHAKDBp2qf uVfXXlSLo+uu7RPzAgQ3GA== =5MjG -----END PGP SIGNATURE----- --UBnjLfzoMQYIXCvq-- --===============1452877758== 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 --===============1452877758==-- From tcpm-bounces@ietf.org Tue Nov 06 15:09:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUkC-0000kw-Nh; Tue, 06 Nov 2007 15:09:52 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpUkB-0000kr-V8 for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 15:09:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUkB-0000kc-LT for tcpm@ietf.org; Tue, 06 Nov 2007 15:09:51 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpUk7-0006ER-NU for tcpm@ietf.org; Tue, 06 Nov 2007 15:09:51 -0500 X-IronPort-AV: E=Sophos;i="4.21,380,1188802800"; d="gif'147?scan'147,208,217,147";a="413875928" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2007 12:08:57 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA6K8uME022416; Tue, 6 Nov 2007 12:08:56 -0800 Received: from [171.69.75.40] (dhcp-171-69-75-40.cisco.com [171.69.75.40]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lA6K8ueF018505; Tue, 6 Nov 2007 20:08:56 GMT Message-ID: <4730C9D6.1020700@cisco.com> Date: Tue, 06 Nov 2007 12:08:54 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: eblanton@cs.ohiou.edu, tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu> <20071106192746.GE5881@elb.elitists.net> <20071106193912.GF5881@elb.elitists.net> In-Reply-To: <20071106193912.GF5881@elb.elitists.net> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9596; t=1194379736; x=1195243736; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=P8bRns+nW244QZF60HhtYFGn5iZuPOmVXYSDredbJb4=; b=gCFRgaMHaMZbyHDCj8noN5v8o28DAzREDNOVJGuQ0secvkBF+XNTcUk9FSpzd/qThDRo5FKD bQjt9fpQ2usPk5jJgGytWAHCiu52hwEA3Vmw1KfTGk2BuAwdqi9/svWMk1eHTRecpU6Ym/Yamp oO8vglnEDZHZ2qfxnm7Xpqxug=; Authentication-Results: sj-dkim-1; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -1.4 (-) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 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: , Content-Type: multipart/mixed; boundary="===============0559495710==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0559495710== Content-Type: multipart/alternative; boundary="------------020505050509010608040100" This is a multi-part message in MIME format. --------------020505050509010608040100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ethan, Would we not receive a EWOULDBLOCK if the connection was throttled because of congestion in the network? Under the scenario you describe we would have timed out a connection that was either slow or congested. Is that true? Ethan Blanton wrote: > Ethan Blanton spake unto us the following wisdom: > >> It is my understanding (correct me if I am wrong) that close() returns >> immediately, regardless of queued data in the send buffer. In >> addition, I am not aware of any way to force a reset on a TCP socket >> without pending data in the read buffer. >> > > SO_LINGER is indeed more flexible than I have used it for -- it can be > used to solve both of these problems. For the benefit of those > listening: > > 1) Set SO_LINGER with l_onoff != 0 and l_linger = timeout in seconds. > 2) If a nonblocking close returns EWOULDBLOCK, the linger timeout > expired, so: > 2a) set SO_LINGER with l_onoff != 0 and l_linger = 0 > 2b) call close, which will emit a RST > > I recant my previous claims -- this can be handled cleanly with > standard sockets. > > >>>> It does not seem unreasonable to add a zero-window timeout tunable to >>>> any given TCP implementation; I don't necessarily think it is a TCP >>>> standardization issue, however, as there is no wire impact. >>>> > > I do stand by this, however. > > Ethan > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > -- *Mahesh Jethanandani* *Technical Leader* **Corporate Development* * mahesh@cisco.com Phone :*+1 408 527-8230* Fax :*+1 408 527-6351* ** 170 West Tasman Drive San Jose, CA 95070 United States www.cisco.com This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. --------------020505050509010608040100 Content-Type: multipart/related; boundary="------------090405080607070205060000" --------------090405080607070205060000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ethan,

Would we not receive a EWOULDBLOCK if the connection was throttled because of congestion in the network? Under the scenario you describe we would have timed out a connection that was either slow or congested. Is that true?

Ethan Blanton wrote: 
Ethan Blanton spake unto us the following wisdom:
  
It is my understanding (correct me if I am wrong) that close() returns
immediately, regardless of queued data in the send buffer.  In
addition, I am not aware of any way to force a reset on a TCP socket
without pending data in the read buffer.
    

SO_LINGER is indeed more flexible than I have used it for -- it can be
used to solve both of these problems.  For the benefit of those
listening:

1) Set SO_LINGER with l_onoff != 0 and l_linger = timeout in seconds.
2) If a nonblocking close returns EWOULDBLOCK, the linger timeout
   expired, so:
   2a) set SO_LINGER with l_onoff != 0 and l_linger = 0
   2b) call close, which will emit a RST

I recant my previous claims -- this can be handled cleanly with
standard sockets.

  
It does not seem unreasonable to add a zero-window timeout tunable to
any given TCP implementation; I don't necessarily think it is a TCP
standardization issue, however, as there is no wire impact.
        

I do stand by this, however.

Ethan

  

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm

--

Mahesh Jethanandani
Technical Leader
Corporate Development

mahesh@cisco.com
Phone :+1 408 527-8230
Fax :+1 408 527-6351


170 West Tasman Drive
San Jose, CA 95070
United States
www.cisco.com

  
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.


--------------090405080607070205060000 Content-Type: image/gif; name="spacer.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="spacer.gif" R0lGODlhCgAKAJEAAAAAAP///////wAAACH5BAEAAAIALAAAAAAKAAoAAAIIlI+py+0PYysA Ow== --------------090405080607070205060000 Content-Type: image/gif; name="footerHead.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="footerHead.gif" R0lGODlhHwIBAJEAAAAAAP///9bY2v///yH5BAEAAAMALAAAAAAfAgEAAAIVlI+py+0Po5y0 2ouz3rz7D4biSE4FADs= --------------090405080607070205060000 Content-Type: image/gif; name="footer.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="footer.gif" R0lGODlhHwIRAMQAAAAAAP////f3+PX19vHx8u7u7+jp6+Tl59/g4tze4Nvd39ja3NfZ29bY 2vHy8+3u7+vs7eTl5ufp6uTm597g4dze3/j5+fHy8v7+/v39/fv7+/n5+f///wAAAAAAAAAA ACH5BAEAABwALAAAAAAfAhEAAAXY4JIFZGmeaKqubOu+cCzPdG3feK7vfO//wKCwlVkkNsOk cslsOp/QqHRKFW4SE0J1y+16v+CweJwkZCfktHrNbrvf7yymMoDb7/i8fp8fKDABFweAfIWG h4iJijIYBxclBhIai5SVlpeYXhoSBicQDA+ZoqOkpaYuBQwQKRsIERcCp7KztLV2Ag4RCBYs DgcUDcHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3twUEQ625OXm5+jp6uvs7e7v8PHy 8/T19vf4+fr7/P3+/wADChxIUEYIADs= --------------090405080607070205060000-- --------------020505050509010608040100-- --===============0559495710== 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 --===============0559495710==-- From tcpm-bounces@ietf.org Tue Nov 06 15:32:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpV63-0008T6-7X; Tue, 06 Nov 2007 15:32:27 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpV61-0008Qm-ID for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 15:32:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpV61-0008Q2-62 for tcpm@ietf.org; Tue, 06 Nov 2007 15:32:25 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpV60-0002OV-PP for tcpm@ietf.org; Tue, 06 Nov 2007 15:32:25 -0500 Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpV5r-0009j8-46 for tcpm@ietf.org; Tue, 06 Nov 2007 20:32:23 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id DD3A62BE21 for ; Tue, 6 Nov 2007 15:32:12 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 2A383283F2; Tue, 6 Nov 2007 15:32:12 -0500 (EST) Date: Tue, 6 Nov 2007 15:32:12 -0500 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? Message-ID: <20071106203212.GG5881@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu> <20071106192746.GE5881@elb.elitists.net> <20071106193912.GF5881@elb.elitists.net> <4730C9D6.1020700@cisco.com> MIME-Version: 1.0 In-Reply-To: <4730C9D6.1020700@cisco.com> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -104.0 (---------------------------------------------------) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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="===============1413031374==" Errors-To: tcpm-bounces@ietf.org --===============1413031374== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UKNXkkdQCYZ6W5l3" Content-Disposition: inline --UKNXkkdQCYZ6W5l3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani spake unto us the following wisdom: > Would we not receive a EWOULDBLOCK if the connection was throttled=20 > because of congestion in the network? Under the scenario you describe we= =20 > would have timed out a connection that was either slow or congested. Is= =20 > that true? Yes; however, I agree with Joe (and others) that in the situation you are *actually* trying to solve, this is not particularly relevant. If you are short on resources, the distinction between "not making progress due to zero window" and "not making progress for some other reason" does not seem important. As previously mentioned, zero window does _not_ indicate a malicious host in any way. [Snip *24 lines* of signature] 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 --UKNXkkdQCYZ6W5l3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHMM9Mr9kA9Ig8HBQRAgrgAJ47tPOhToDm77NTaa7rtTq9sLReSQCeO0G/ zQCeaN2HlzAVa/HTyI/ZFiU= =XAqY -----END PGP SIGNATURE----- --UKNXkkdQCYZ6W5l3-- --===============1413031374== 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 --===============1413031374==-- From tcpm-bounces@ietf.org Tue Nov 06 16:36:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpW5w-0005Br-Nv; Tue, 06 Nov 2007 16:36:24 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpW5v-0005BW-8P for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 16:36:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpW5u-0005Af-Uj for tcpm@ietf.org; Tue, 06 Nov 2007 16:36:22 -0500 Received: from web31711.mail.mud.yahoo.com ([68.142.201.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IpW5r-0000Qn-El for tcpm@ietf.org; Tue, 06 Nov 2007 16:36:22 -0500 Received: (qmail 38852 invoked by uid 60001); 6 Nov 2007 21:36:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=5j7AHkvCMgRJDkKxLRvZptGjHNgYwZ0mpaPnbhWYQrsrDgeuho4SDbHcDm70SADhgmt0FQghNdaPLzKTmGa2+izKhXTt6kjkeTzrMzRXBQTL01i6AUoAVFDJxMFPJCMh7z68HtIzBOU2pnCvG7YVZZwZbJfDQgkmbiwm8miyXmk=; X-YMail-OSG: eDgQT7sVM1nhmJKYIvdFaa9mNFg0NDfjapCkrKnnjcLnWnDG4RBc9SMX0GaTtULkOWuysq5_JDr8uVaqK1SSkZELHbKbK9ITdR16WZmUo1ld0XM6Zqk- Received: from [69.3.29.18] by web31711.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 13:36:18 PST X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152 Date: Tue, 6 Nov 2007 13:36:18 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? To: Ethan Blanton , Joe Touch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <895257.37528.qm@web31711.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tcpm@ietf.org, Lloyd Wood X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org The problem is also harder to solve in the HTTP context, for persistent connections, where the server can write the tail of the HTTP response to the connection send buffer, and then it keeps the connection around (i.e no app close) waiting for a new HTTP request from any clients out there. It has no way of detecting whether forward progress has been made for that particular response, because it is now completely in TCP's send buffer to deliver it. These are scenarios where it seems acceptable for TCP to accomodate what the application wants (don't hang indefinitely to deliver that response). Murali ----- Original Message ---- From: Ethan Blanton To: Joe Touch Cc: MURALI BASHYAM ; tcpm@ietf.org; Lloyd Wood Sent: Tuesday, November 6, 2007 11:08:45 AM Subject: Re: [tcpm] Is this a problem? Joe Touch spake unto us the following wisdom: > MURALI BASHYAM wrote: > > We want to limit the timer to the sender's persist state only, any > > other timeout overloads the semantics of the application, and may also > > cause unnecessary timeouts for the application. In fact there are > > instances where the application may not even have the connection state > > around to implement the timout correctly, like the tail of a long HTTP > > response. After sending the tail of the response, the application can > > close the connection and release its connection memory, during this > > window only TCP has the connection state. We've done a lot of testing > > and design for handling all these cases, and to implement this > > correctly, we need TCP's involvement. > > It still sounds like you have a poorly written application to me; anyone > else? This comment of Murali's, specifically, is a case that the application *cannot* (portably or cleanly) handle, at least under the Berkeley sockets API. He is correct that once an application writes the end of its data and calls close() or shutdown(), the TCP socket may persist indefinitely in the kernel, and the application would never know (if there are no application-level acknowledgments, as there are not in simple HTTP responses). It does not seem unreasonable to add a zero-window timeout tunable to any given TCP implementation; I don't necessarily think it is a TCP standardization issue, however, as there is no wire impact. Ethan -- 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 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 06 16:36:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpW6P-0005d7-62; Tue, 06 Nov 2007 16:36:53 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpW6O-0005d0-Bq for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 16:36:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpW6O-0005bq-0e for tcpm@ietf.org; Tue, 06 Nov 2007 16:36:52 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpW6N-0004Zj-Gb for tcpm@ietf.org; Tue, 06 Nov 2007 16:36:51 -0500 Received: from [75.212.24.145] (145.sub-75-212-24.myvzw.com [75.212.24.145]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA6LaGuf011169; Tue, 6 Nov 2007 13:36:17 -0800 (PST) Message-ID: <4730DE3B.9030706@isi.edu> Date: Tue, 06 Nov 2007 13:35:55 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch , tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu> <20071106192746.GE5881@elb.elitists.net> In-Reply-To: <20071106192746.GE5881@elb.elitists.net> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Content-Type: multipart/mixed; boundary="===============1963250352==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1963250352== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig08B093C6495F6FBD0875702B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig08B093C6495F6FBD0875702B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ethan Blanton wrote: > (Apologies for the duplicate, Joe, I didn't reply-to-list.) >=20 > Joe Touch spake unto us the following wisdom: >>> This comment of Murali's, specifically, is a case that the applicatio= n >>> *cannot* (portably or cleanly) handle, at least under the Berkeley >>> sockets API. He is correct that once an application writes the end o= f >>> its data and calls close() or shutdown(), the TCP socket may persist >>> indefinitely in the kernel, and the application would never know (if >>> there are no application-level acknowledgments, as there are not in >>> simple HTTP responses). >> Why would a blocking CLOSE not solve that? >=20 > It is my understanding (correct me if I am wrong) that close() returns > immediately, regardless of queued data in the send buffer. ... See, e.g.: http://www.developerweb.net/forum/archive/index.php/t-2982.html > In > addition, I am not aware of any way to force a reset on a TCP socket > without pending data in the read buffer. ABORT is defined to do this, and does not require pending data in the buffer AFAICT. Joe --------------enig08B093C6495F6FBD0875702B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMN5AE5f5cImnZrsRAqqlAKD6kmx14uFBlHDDNT4qtqgjdn2u8wCgneMI qM++RrIsSPTHr9FmzY0NTBk= =ZwhM -----END PGP SIGNATURE----- --------------enig08B093C6495F6FBD0875702B-- --===============1963250352== 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 --===============1963250352==-- From tcpm-bounces@ietf.org Tue Nov 06 17:28:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWtv-00015n-ET; Tue, 06 Nov 2007 17:28:03 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpWtu-00014w-5L for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 17:28:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWtt-00014o-Ck for tcpm@ietf.org; Tue, 06 Nov 2007 17:28:01 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpWtq-0002XV-GA for tcpm@ietf.org; Tue, 06 Nov 2007 17:28:01 -0500 Received: from [75.212.24.145] (145.sub-75-212-24.myvzw.com [75.212.24.145]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA6MRYrL024256; Tue, 6 Nov 2007 14:27:35 -0800 (PST) Message-ID: <4730EA46.1000605@isi.edu> Date: Tue, 06 Nov 2007 14:27:18 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? References: <895257.37528.qm@web31711.mail.mud.yahoo.com> In-Reply-To: <895257.37528.qm@web31711.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Ethan Blanton , tcpm@ietf.org, Lloyd Wood 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="===============1681994954==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1681994954== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig666C9CB03B3B872B548EF102" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig666C9CB03B3B872B548EF102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, HTTP has head of line blocking on persistent connections. If HTTP doesn't want to hang that connection forever on a pending transfer, use blocking writes and terminate the connection on a timeout. If HTTP doesn't want HOL blocking, don't use persistent connections. Joe MURALI BASHYAM wrote: > The problem is also harder to solve in the HTTP context, for persistent= connections, where the server > can write the tail of the HTTP response to the connection send buffer, = and then it keeps the connection around > (i.e no app close) waiting for a new HTTP request from any clients out = there. It has > no way of detecting whether forward progress has been made for that par= ticular response, because it is now > completely in TCP's send buffer to deliver it. These are scenarios wher= e it seems acceptable for TCP to accomodate > what the application wants (don't hang indefinitely to deliver that res= ponse). >=20 > Murali >=20 > ----- Original Message ---- > From: Ethan Blanton > To: Joe Touch > Cc: MURALI BASHYAM ; tcpm@ietf.org; Lloyd Woo= d > Sent: Tuesday, November 6, 2007 11:08:45 AM > Subject: Re: [tcpm] Is this a problem? >=20 >=20 > Joe Touch spake unto us the following wisdom: >> MURALI BASHYAM wrote: >>> We want to limit the timer to the sender's persist state only, any >>> other timeout overloads the semantics of the application, and may > also >>> cause unnecessary timeouts for the application. In fact there are >>> instances where the application may not even have the connection > state >>> around to implement the timout correctly, like the tail of a long > HTTP >>> response. After sending the tail of the response, the application > can >>> close the connection and release its connection memory, during this >>> window only TCP has the connection state. We've done a lot of > testing >>> and design for handling all these cases, and to implement this >>> correctly, we need TCP's involvement. >> It still sounds like you have a poorly written application to me; > anyone >> else? >=20 > This comment of Murali's, specifically, is a case that the application > *cannot* (portably or cleanly) handle, at least under the Berkeley > sockets API. He is correct that once an application writes the end of > its data and calls close() or shutdown(), the TCP socket may persist > indefinitely in the kernel, and the application would never know (if > there are no application-level acknowledgments, as there are not in > simple HTTP responses). >=20 > It does not seem unreasonable to add a zero-window timeout tunable to > any given TCP implementation; I don't necessarily think it is a TCP > standardization issue, however, as there is no wire impact. >=20 > Ethan >=20 --------------enig666C9CB03B3B872B548EF102 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMOpGE5f5cImnZrsRAvihAKDd7407hzN07s0aBkttisxhec1QswCg4aGN kZpkvYP2wqgdacQlva+z0j4= =8N1M -----END PGP SIGNATURE----- --------------enig666C9CB03B3B872B548EF102-- --===============1681994954== 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 --===============1681994954==-- From tcpm-bounces@ietf.org Tue Nov 06 18:19:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpXhS-0004uR-DB; Tue, 06 Nov 2007 18:19:14 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpXhQ-0004tp-Te for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 18:19:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpXhQ-0004th-IQ for tcpm@ietf.org; Tue, 06 Nov 2007 18:19:12 -0500 Received: from web31705.mail.mud.yahoo.com ([68.142.201.185]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpXhP-0008VN-TU for tcpm@ietf.org; Tue, 06 Nov 2007 18:19:12 -0500 Received: (qmail 85125 invoked by uid 60001); 6 Nov 2007 23:19:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=r45jFQrDqJhW7XLZMUdhBM+Aa9z6i2mu5I8cCJlbDUKXtg8L+VyPCbUqhvlxHAkKz8AKCPyHozJkKo0Mql1ucw64zmDF0pSZSJFUAC9j/7OYkETMJ7a0zYRXCsQ0kiuRoN/h0eiK2zL0COhZOIjDrEhscnL5OZKtub1ELrmzWXg=; X-YMail-OSG: K6bE3SEVM1kIAHs51n.olDjbRxhUoxLcQ5mv98307egRbPcaWJ_YqMLtG8Wwmp0LgA-- Received: from [69.3.29.18] by web31705.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 15:19:11 PST X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.152 Date: Tue, 6 Nov 2007 15:19:11 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? To: Joe Touch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <266520.84910.qm@web31705.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Ethan Blanton , tcpm@ietf.org, Lloyd Wood 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 Writes may not block here, since there is space in the socket send buffer to accomodate the response tail. We can't assume blocking writes to solve this issue. If writes do not block, and the (tail of) response fits in the send buffer queue, now the responsibility for managing that data is completely TCP's. TCP now needs an indication from the application to decide whether to try to send that data indefinitely when the receiver continually advertises zero window or it has to implement a time bound as requested by the app. It's that simple, isn't it? Murali ----- Original Message ---- From: Joe Touch To: MURALI BASHYAM Cc: Ethan Blanton ; tcpm@ietf.org; Lloyd Wood Sent: Tuesday, November 6, 2007 2:27:18 PM Subject: Re: [tcpm] Is this a problem? Yes, HTTP has head of line blocking on persistent connections. If HTTP doesn't want to hang that connection forever on a pending transfer, use blocking writes and terminate the connection on a timeout. If HTTP doesn't want HOL blocking, don't use persistent connections. Joe MURALI BASHYAM wrote: > The problem is also harder to solve in the HTTP context, for persistent connections, where the server > can write the tail of the HTTP response to the connection send buffer, and then it keeps the connection around > (i.e no app close) waiting for a new HTTP request from any clients out there. It has > no way of detecting whether forward progress has been made for that particular response, because it is now > completely in TCP's send buffer to deliver it. These are scenarios where it seems acceptable for TCP to accomodate > what the application wants (don't hang indefinitely to deliver that response). > > Murali > > ----- Original Message ---- > From: Ethan Blanton > To: Joe Touch > Cc: MURALI BASHYAM ; tcpm@ietf.org; Lloyd Wood > Sent: Tuesday, November 6, 2007 11:08:45 AM > Subject: Re: [tcpm] Is this a problem? > > > Joe Touch spake unto us the following wisdom: >> MURALI BASHYAM wrote: >>> We want to limit the timer to the sender's persist state only, any >>> other timeout overloads the semantics of the application, and may > also >>> cause unnecessary timeouts for the application. In fact there are >>> instances where the application may not even have the connection > state >>> around to implement the timout correctly, like the tail of a long > HTTP >>> response. After sending the tail of the response, the application > can >>> close the connection and release its connection memory, during this >>> window only TCP has the connection state. We've done a lot of > testing >>> and design for handling all these cases, and to implement this >>> correctly, we need TCP's involvement. >> It still sounds like you have a poorly written application to me; > anyone >> else? > > This comment of Murali's, specifically, is a case that the application > *cannot* (portably or cleanly) handle, at least under the Berkeley > sockets API. He is correct that once an application writes the end of > its data and calls close() or shutdown(), the TCP socket may persist > indefinitely in the kernel, and the application would never know (if > there are no application-level acknowledgments, as there are not in > simple HTTP responses). > > It does not seem unreasonable to add a zero-window timeout tunable to > any given TCP implementation; I don't necessarily think it is a TCP > standardization issue, however, as there is no wire impact. > > Ethan > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 06 18:41:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpY3G-0003Ik-1M; Tue, 06 Nov 2007 18:41:46 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IpY3E-0003Ia-IJ for tcpm-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 18:41:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpY3E-0003Hn-7R for tcpm@ietf.org; Tue, 06 Nov 2007 18:41:44 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpY3D-0000sK-GR for tcpm@ietf.org; Tue, 06 Nov 2007 18:41:44 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lA6Nf8cE011950; Tue, 6 Nov 2007 15:41:09 -0800 (PST) Message-ID: <4730FB86.5050704@isi.edu> Date: Tue, 06 Nov 2007 15:40:54 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? References: <266520.84910.qm@web31705.mail.mud.yahoo.com> In-Reply-To: <266520.84910.qm@web31705.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Ethan Blanton , tcpm@ietf.org, Lloyd Wood 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="===============1439607123==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1439607123== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB5E22DC7B3358DD639C9A366" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB5E22DC7B3358DD639C9A366 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable MURALI BASHYAM wrote: > Writes may not block here, since there is space in the socket send buff= er to accomodate the response tail. Sure. In which case you have a background timer. Either way, your problem is solved. You seem to want to interpret this as a unique DOS attack based on TCP-specific info that differentiates it from a connection that's just slow. I agree with Ethan - if you have limited resources, you terminate either way. If not, you hang around until you need to recover state. Either way you don't need to differentiate the two, and an app timer suffices. Joe > ----- Original Message ---- > From: Joe Touch > To: MURALI BASHYAM > Cc: Ethan Blanton ; tcpm@ietf.org; Lloyd Wood > Sent: Tuesday, November 6, 2007 2:27:18 PM > Subject: Re: [tcpm] Is this a problem? >=20 >=20 > Yes, HTTP has head of line blocking on persistent connections. >=20 > If HTTP doesn't want to hang that connection forever on a pending > transfer, use blocking writes and terminate the connection on a > timeout. >=20 > If HTTP doesn't want HOL blocking, don't use persistent connections. >=20 > Joe >=20 > MURALI BASHYAM wrote: >> The problem is also harder to solve in the HTTP context, for > persistent connections, where the server >> can write the tail of the HTTP response to the connection send > buffer, and then it keeps the connection around >> (i.e no app close) waiting for a new HTTP request from any clients > out there. It has >> no way of detecting whether forward progress has been made for that > particular response, because it is now >> completely in TCP's send buffer to deliver it. These are scenarios > where it seems acceptable for TCP to accomodate >> what the application wants (don't hang indefinitely to deliver that > response). >> Murali >> >> ----- Original Message ---- >> From: Ethan Blanton >> To: Joe Touch >> Cc: MURALI BASHYAM ; tcpm@ietf.org; Lloyd > Wood >> Sent: Tuesday, November 6, 2007 11:08:45 AM >> Subject: Re: [tcpm] Is this a problem? >> >> >> Joe Touch spake unto us the following wisdom: >>> MURALI BASHYAM wrote: >>>> We want to limit the timer to the sender's persist state only, any >>>> other timeout overloads the semantics of the application, and may >> also >>>> cause unnecessary timeouts for the application. In fact there are >>>> instances where the application may not even have the connection >> state >>>> around to implement the timout correctly, like the tail of a long >> HTTP >>>> response. After sending the tail of the response, the application >> can >>>> close the connection and release its connection memory, during this >>>> window only TCP has the connection state. We've done a lot of >> testing >>>> and design for handling all these cases, and to implement this >>>> correctly, we need TCP's involvement. >>> It still sounds like you have a poorly written application to me; >> anyone >>> else? >> This comment of Murali's, specifically, is a case that the > application >> *cannot* (portably or cleanly) handle, at least under the Berkeley >> sockets API. He is correct that once an application writes the end > of >> its data and calls close() or shutdown(), the TCP socket may persist >> indefinitely in the kernel, and the application would never know (if >> there are no application-level acknowledgments, as there are not in >> simple HTTP responses). >> >> It does not seem unreasonable to add a zero-window timeout tunable to >> any given TCP implementation; I don't necessarily think it is a TCP >> standardization issue, however, as there is no wire impact. >> >> Ethan >> >=20 >=20 >=20 >=20 >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com=20 --------------enigB5E22DC7B3358DD639C9A366 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMPuGE5f5cImnZrsRAoqIAKCrRPCKqzRoN47utAuxY/ii/H8LkwCeIXc2 CJ3KjF9DtvrBlMfm0Q/uGgQ= =/xCQ -----END PGP SIGNATURE----- --------------enigB5E22DC7B3358DD639C9A366-- --===============1439607123== 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 --===============1439607123==-- From tcpm-bounces@ietf.org Wed Nov 07 04:15:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iph0c-0003tf-Lq; Wed, 07 Nov 2007 04:15:38 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iph0a-0003p8-23 for tcpm-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 04:15:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iph0U-0003m7-Vt for tcpm@ietf.org; Wed, 07 Nov 2007 04:15:30 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iph0Q-0008NL-Ux for tcpm@ietf.org; Wed, 07 Nov 2007 04:15:30 -0500 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 09:15:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] WGLC for UTO Date: Wed, 7 Nov 2007 09:14:12 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC for UTO Thread-Index: Acgf0ENtKjJfCoRARJehxuqLOKYy8gBTkxNu References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> <4728A553.2020300@isi.edu> <6B3D5E1D-F2DA-428C-AAEF-6F548F48F4F5@nokia.com> <3DF7B46C-5246-470E-9C98-08A5AEADDAF3@nokia.com> <472F36FC.1030301@isi.edu> <001BF967-9D6E-4583-8C08-6B4AC29A567C@nokia.com> From: To: , X-OriginalArrivalTime: 07 Nov 2007 09:15:25.0997 (UTC) FILETIME=[BB9615D0:01C8211E] X-Spam-Score: -1.0 (-) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ah@tr-sys.de, tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I think the document as stands (in your latest diffed version) seems = fine. (I'm not an expert on SYN cookies though...) =20 Toby ________________________________ From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Mon 05/11/2007 17:20 To: ext Joe Touch Cc: ext Alfred H=CEnes; tcpm@ietf.org Subject: Re: [tcpm] WGLC for UTO On 2007-11-5, at 17:30, ext Joe Touch wrote: > Lars Eggert wrote: >> There were some suggestions discussed in response to Joe's and=20 >> Alfred's >> comments that I haven't made, because the rest of the WG was silent, >> which I interpreted as lack of consensus for the change. Speak up=20 >> if you >> disagree with this resolution. > > I have spoken before on this point in general. Apathy is not=20 > consensus. > > Apathy can be a reason to not include a change, but that's the reason. > Not consensus. My understanding is that we have *had* consensus on what the document=20 currently says about the two points in question (whether to include=20 the UTO in both the SYN and the first non-SYN, and whether UTO is=20 supposed to be transmitted reliably) since these points were=20 discussed a few revisions back. I'm not opposed to making changes if the consensus has changed. But I=20 have difficulties determining whether this is the case. I'd=20 appreciate some additional WG comments on this. Lars=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 08 10:28:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9IQ-0003xl-In; Thu, 08 Nov 2007 10:27:54 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iq9IO-0003wZ-LX for tcpm-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 10:27:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9IO-0003vr-7M for tcpm@ietf.org; Thu, 08 Nov 2007 10:27:52 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq9IN-00020p-F4 for tcpm@ietf.org; Thu, 08 Nov 2007 10:27:51 -0500 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 15:27:50 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Nov 2007 15:28:15 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version of draft-moncaster-tcpm-rcv-cheat-02 Thread-Index: AcgiG/tR19cANsxBSBO2p9HrA3UWPA== From: To: X-OriginalArrivalTime: 08 Nov 2007 15:27:50.0285 (UTC) FILETIME=[EC3B9BD0:01C8221B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: faber@ISI.EDU, mallman@icir.org Subject: [tcpm] New Version of draft-moncaster-tcpm-rcv-cheat-02 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 All,=20 We have just posted a new version of the TCP testing draft = (draft-moncaster-tcpm-rcv-cheat-02). There is no significant new material in this version. The majority of = the changes are in line with the comments received from Alfred H=F6nes = last week. Our intention is not to request a presentation slot for = Vancouver unless the WG wants us to present. We have now reached the stage when we would like input from the WG as to = what our next step should be. Does the WG want to adopt this work as a = draft or not? As we see it this draft has three possible ways to go = next: 1) Adopted as WG draft (to become informational) 2) If WG isn't interested it could become an individual contribution=20 3) It could be taken elsewhere.=20 In terms of its possible track at the IETF it is clearly not a standards = document (nor an experiment) and, whilst it seemingly fits the RFC2026 = definition of BCP it doesn't fit the de facto definition. That leaves = informational as the obvious track. Toby=20 _________________________________________________________________________= ___ Toby Moncaster, Networks Research Centre, BT = Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. = +44 1473 648734=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 08 11:57:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAgg-0008QM-OJ; Thu, 08 Nov 2007 11:57:02 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IqAgf-0008P4-ML for tcpm-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 11:57:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAgf-0008Ov-Bd for tcpm@ietf.org; Thu, 08 Nov 2007 11:57:01 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqAgb-0003ad-W3 for tcpm@ietf.org; Thu, 08 Nov 2007 11:57:01 -0500 X-IronPort-AV: E=Sophos;i="4.21,390,1188802800"; d="scan'208";a="248585294" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Nov 2007 08:56:57 -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 lA8GuvSr006138 for ; Thu, 8 Nov 2007 08:56:57 -0800 Received: from [10.21.107.22] (sjc-vpnasa-791.cisco.com [10.21.107.22]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lA8GuvQ6025674 for ; Thu, 8 Nov 2007 16:56:57 GMT Message-ID: <47333FD9.8010508@cisco.com> Date: Thu, 08 Nov 2007 08:56:57 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu> <20071106192746.GE5881@elb.elitists.net> <20071106193912.GF5881@elb.elitists.net> <4730C9D6.1020700@cisco.com> <20071106203212.GG5881@elb.elitists.net> In-Reply-To: <20071106203212.GG5881@elb.elitists.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=976; t=1194541017; x=1195405017; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=/8pV3J2ddhXrypzZkKqVoINlR/+7Hm7McapIk9i2Plw=; b=B31ALp1BhpzAeJm9drjkKUohHwPbS+gMnY58wIwF/ZE0JfUiwTNVE1+9mCk1nm3ejQYxdPxz qM7oPZVsdgaAKBQIEbWQ6mHjx2DNqcdgBP4ul0XTHPQ8zLlpzDpOtsD5; Authentication-Results: sj-dkim-4; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Ethan Blanton wrote: > Yes; however, I agree with Joe (and others) that in the situation you > are *actually* trying to solve, this is not particularly relevant. If > you are short on resources, the distinction between "not making > progress due to zero window" and "not making progress for some other > reason" does not seem important. As previously mentioned, zero window > does _not_ indicate a malicious host in any way. > Where is the fairness argument in knocking connections off without making distinctions? A connection that is not making progress because of congestion in the network is a transient behavior and is very different from a connection that continues to advertise a zero window. The former is much harder to do and requires TCP stack changes. Zero window connection can be made to happen on a whim (as we successfully did) on a large number of connections from a user level program with little or no privileges. /mahesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 08 12:50:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBVg-0004le-Ev; Thu, 08 Nov 2007 12:49:44 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IqBVf-0004l7-8g for tcpm-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 12:49:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBVe-0004kO-If for tcpm@ietf.org; Thu, 08 Nov 2007 12:49:42 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqBVc-0005Ww-7j for tcpm@ietf.org; Thu, 08 Nov 2007 12:49:42 -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 lA8HnUwS028869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Nov 2007 09:49:30 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id lA8HnUsN022814 for tcpm@ietf.org; Thu, 8 Nov 2007 09:49:30 -0800 (PST) (envelope-from faber) Date: Thu, 8 Nov 2007 09:49:30 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? Message-ID: <20071108174930.GB1552@hut.isi.edu> References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu> <20071106192746.GE5881@elb.elitists.net> <20071106193912.GF5881@elb.elitists.net> Mime-Version: 1.0 In-Reply-To: <20071106193912.GF5881@elb.elitists.net> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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="===============2099180669==" Errors-To: tcpm-bounces@ietf.org --===============2099180669== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+pHx0qQiF2pBVqBT" Content-Disposition: inline --+pHx0qQiF2pBVqBT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 06, 2007 at 02:39:12PM -0500, Ethan Blanton wrote: > Ethan Blanton spake unto us the following wisdom: > > > > It does not seem unreasonable to add a zero-window timeout tunable = to > > > > any given TCP implementation; I don't necessarily think it is a TCP > > > > standardization issue, however, as there is no wire impact. >=20 > I do stand by this, however. Let's not lose sight of this point. Do we need a new standard interface to the TCP stack, or is this an implementation issue? --=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 --+pHx0qQiF2pBVqBT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHM0wqaUz3f+Zf+XsRAvI2AKCM58Vqv5gLPKEyIcgH7AOnvAKWsQCgofo+ oujUteQX0BKjw1YjapyiQ6Y= =JaA6 -----END PGP SIGNATURE----- --+pHx0qQiF2pBVqBT-- --===============2099180669== 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 --===============2099180669==-- From tcpm-bounces@ietf.org Thu Nov 08 12:55:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBbH-0002EU-BN; Thu, 08 Nov 2007 12:55:31 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IqBbH-0002Du-3j for tcpm-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 12:55:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBbG-0002Cq-Pj for tcpm@ietf.org; Thu, 08 Nov 2007 12:55:30 -0500 Received: from mx.neterion.com ([72.1.205.142] helo=owa.neterion.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqBbD-0005hW-B2 for tcpm@ietf.org; Thu, 08 Nov 2007 12:55:30 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [tcpm] Is this a problem? Date: Thu, 8 Nov 2007 12:55:25 -0500 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77027EA415@nekter> In-Reply-To: <47333FD9.8010508@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Is this a problem? Thread-Index: AcgiKIit4wNAyzsyRACalWYxB1vUKQABbW1g References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu><20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu><20071106192746.GE5881@elb.elitists.net> <20071106193912.GF5881@elb.elitists.net> <4730C9D6.1020700@cisco.com><20071106203212.GG5881@elb.elitists.net> <47333FD9.8010508@cisco.com> From: "Caitlin Bestler" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org *If* you were going to solve this problem as a *transport* problem then you would have to define it in transport terms. I'll attempt to offer such a description, and show that it is still in conflict with the application layer problem. The apparent transport layer issue is that the application does not know whether the lack of credits are due to lack of receive buffers or network congestion. The presumption here is that the server is willing to suffer a bit if the problem is in the network rather than the client. The problem is that as long as the client is using TCP over a conventional stack the receive buffers actually belong to the OS and not to the client. So the absence or presence of receive buffers does not really tell us anything about the client's state. For example the reason the available receive buffering for the connection is so small might be that the OS or Hypervisor has swapped the client out. So the lack of adequate receive windows can have *three* causes: network congestion, lack of OS buffering resources or failure of the client to drain the connection. And the latter case can be a failure of the client to drain the connection that is based on malice and/or sufficiently sloppy coding that terminating the connection is justified, or it could just be that the client is not getting scheduled for OS reasons. There is no way for the transport layer to distinguish between any of the latter three cases. There are many reasons for a lack of receive buffering, and they all look the same on the wire. Now you could use a transport that guaranteed availability of specific buffers that are fully guaranteed. You might even call it something like Remote Direct Memory Access. But before you could deploy this solution you would have to convince the clients to use it. If you are trying to do this as a DoS protection then you must convince *All* clients to make the shift so that you can turn off support for legacy modes. If you were to actually attempt such a project you should not do it with TCP. HTTP would be far better implemented over SCTP and/or RDMA than over TCP (if you are willing to ignore the billion or so installed clients). More generally, while there is some merit in separating feedback about end-to-end buffer credits from congestion tracking, such a change would not be a "minor" tweak to TCP. If the market was willing to make major changes to TCP it would already be using SCTP instead. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 12 06:38:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrXcv-0001uZ-GG; Mon, 12 Nov 2007 06:38:49 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IrXcu-0001uF-DA for tcpm-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 06:38:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrXct-0001tr-TY for tcpm@ietf.org; Mon, 12 Nov 2007 06:38:48 -0500 Received: from dsl.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrXcp-00073X-BF for tcpm@ietf.org; Mon, 12 Nov 2007 06:38:47 -0500 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA186217481; Mon, 12 Nov 2007 12:38:01 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA06290; Mon, 12 Nov 2007 12:37:59 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200711121137.MAA06290@TR-Sys.de> To: toby.moncaster@bt.com, bob.briscoe@bt.com, arnaud.jacquet@bt.com Date: Mon, 12 Nov 2007 12:37:59 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 Cc: tcpm@ietf.org Subject: [tcpm] draft-moncaster-tcpm-rcv-cheat-02 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 Hello, thanks for updating your Internet-Draft to draft-moncaster-tcpm-rcv-cheat-02, incorporating many of the suggestions I had supplied in my review of rev. -01. Studying the new version, I unfortunately found some of the issues raised addressed incompletely, or even missed, and some typos newly intruduced; and I also got aware of a small number other nits not mentioned previously. Note to readers of the list (added on proofreading): Item (5) below is the single non-editiorial topic discussed, and it might deserve further comments! This topic has caused me to copy this entire message to the list. (1) Re: "cheating", "[dis]honest[ly]" , etc. Whereas you have modified many of the occurrences of these words not complying to the stated aims of the draft, a few have been left in the text -- some apparently intentionally (e.g., Sections 6.2.3 amd 6.3.2), some perhaps missed. Please reconsider these parts of the text; I'll give pointers below. (1a) Section 5.1 IMHO, it would be consistent with the rest of the memo to replace "dishonest behaviour" by "non-conforming behavior" in the second line of the second paragraph of Section 5.1. (1b) Section 6.2 Similarly, it seems that using "conformant" in place of "honest" would be more consistent with the rest of the text, at the very end of the last paragraph of Section 6.2. (1c) Section 6.2.1 The text in the box in Figure 3 has been modified to adopt the term "compliant". Hence it would be reasonable to change the figure cation as well. For brevity and clearness, I suggest to change it as follows: Figure 3: A receiver reacting honestly to a probabilistic test --- Figure 3: Compliant receiver reaction to a probabilistic test The instances of "dishonest" and "honestly" in the paragraph below Figure 3 arguably still make sense in the stated setup. (1d) Sections 6.2.2, 6.2.3, and 6.2.5 This IMHO also is true for "honestly" in the first paragraph of Section 6.2.2 and the instances "dishonest" in the first paragraph (2x) and the second paragraph (1x) of Section 6.2.3. The "cheat" at the latter place also seems acceptable. Yet, this arguably does not apply to the "honest" in the last text box in Figure 4, where I'd prefer "conformant". The "dishonest" in the 8th bullet in Section 6.2.5 arguably is acceptable, but might be replaced by "non-conformant" as well, whereas the "dishonest" in the last bullet looks good to me. (1e) Section 6.3.2 The two instances of "dishonest" and the subsequent "honest" in Section also make sense in that re-worded context. (1f) Section 6.4 I recommend changing "dishonest" to "non-conformant" in the first line of Section 6.4, as the sender can only deduce from the test that the receiver behaves in a non-conformant way, not the possible rationale behind this behavior, which the reader might well feel as being categorized by the semantics of "dishonest". Similar arguments also apply to the subsequent word "dishonestly" in the same paragraph. (1g) Section 10 Please also reconsider the "dishonest" and "honest" (one instance each) in Section 10. (I'm in doubt whether I should argue against these words in favor of "non-conformant" / "conformant" or not.) (2) Outdated reference The SCTP specification has been updated recently. RFC 2960 has been obsoleted by RFC 4960. Please update the ref. tag "[RFC2960]" used in the second-to-last paragraph of Section 1 and the matching entry in Section 14.2 accordingly, and re-adjust the placement of that entry according to the collation order (by increasing RFC number). (3) Section 6.2.1 -- new nits In the first paragraph of Section 6.2.1, the text has been revised, and three new flaws introduced thereby: - please correct the spelling: "trhreshold" --> "threshold" - please correct the spelling: "significnat" --> "significant" - In the sentence, To conduct the probabilistic test, instead of transmitting segment N, it transmits N+1, N+2, etc. as shown in the figure below. the "it" has been orphaned by the changed amended text directly preceding this sentence, and I suggest to clarify the text by substituting "the sender" for "it". (4) Section 6.2.3 -- Figure 4 I already had mentioned that, IMHO, in the third text box within Figure 4, "sender" should be replaced by "receiver". Apparently this has been missed in the update to -02. (5) Segment numbers vs. TCP sequence numbers -- and possible extensions of the tests I already had mentioned the confusion between TCP segment numbers (e.g., "N") in the text, and TCP sequence numbers counting the cumulative bytes in these segments (and certain specific protocol events as well), and you have corrected that issue in the single instance I had pointed to explicitly. Unfortunately, when reading the text again, and with that change in mind, it now became apparent to me that the same issue permeates the text. Clarification/correction is needed by also changing the wording in the places of the draft listed below. I also have included further ramifications of this issue, and an ensuing potential enhancement for the tests. (5a) Section 6.2.1 At the end of the first paragraph, the draft says: Once it has transmitted N+D it can transmit segment N. The sender needs to record the sequence number, N as well as the displacement, D. It would perhaps be better to say: Once it has transmitted N+D it can transmit segment N. The sender needs to record the sequence number corresponding to N as well as the displacement, D. or: Once it has transmitted N+D it can transmit segment N. The sender needs to record the sequence number of the first octet in segment N as well as the displacement, D. But apparently, that will not suffice. Note: Due to lack of time to investigate all the details (and possible opportunities for optimizations in implementations), I only present my concerns and ideas very roughly. I strongly suspect that it does not suffice to record the displacement in segments (D); perhaps the sequence number of the first octet in segment N+D needs to be recorded (or, equivalently, the sequence number of the last octet in segment N+D-1). Also, the 'width' of the artificial gap in the octet stream sent, i.e. the octet size of segment N, should perhaps be recorded as well -- assuming it might not always equal the full MSS of the connection, as this would allow to discriminate the unusual and suspicion-raising receiver behavior of sending 'optimistic' ACKs for some octets in the middle of the (not yet sent) segment N. Reconsidering this observation, I found that there might be an opportunity to refine and amend the tests, by tightly controlling the segment sizes sent and recording this information until receipt of a covering ACK. Unless the TCP_NODELAY socket option is applied by the sending application (cf. Section 6.5.2), and if the TCP send buffers are filled to the extent necessary to perform the test, the TCP sender will regulargly send segments of maximum size (MSS). Under these circumstances, reducing the segment size randomly below MSS by a small amount and performing suitable bookkeeping thereof, the sender would be able to identify ACKs not matching segment boundaries. (Such sender behavior seems to be fully compliant with the TCP specification, as shorter segments might also be sent at any time, based on application requests like the TCP_NODELY socket option.) A misbehaving receiver would then have trouble to always guess the proper expected ACK sequence numbers matching segment boundaries if it wants to send optimistic ACKs, thus necessarily providing further hints to the sender of its non-conforming behavior. (5b) Section 6.2.5 The 5th bullet says: o The sequence number N of the delayed segment MUST be recorded by the sender as must the amount of delay D. It should better say: o The sequence number of the delayed segment N MUST be recorded by the sender as must the amount of delay D. Yet this still leaves open the question which figures should be recorded for "the amount of delay D" -- is it D, or some sequence number corresponding to segment N+D, or both? See the indications above. Note: The 9th bullet already has been clarified. The 10th bullet says: o If the sender receives an acknowledgement for a segment with a sequence number between N and N+D inclusively it MUST treat this as an indication of congestion and react appropriately. The phrase, "sequence number between N and N+D" also is imprecise and confusing, and should be clarified. (5c) Section 6.3.* In Section 6.3.*, 'M' is the segment number for the suspended segment. Yet, the first paragraph of Section 6.3.2 says: The sender can therefore state that if it receives an acknowledgement for a segment with a sequence number greater than M before it has actually sent segment M then the receiver must either be cheating or is very non-compliant. Again, "sequence number greater than M" is imprecise and confusing, and hence should be clarified. The second bullet in Section 6.3.3 already vaguely specifies: o To perform the deterministic test the sender MUST select a segment M at random. The sender MUST store this segment in the buffer of unacknowledged data without sending it and MUST record the sequence number. It remains open exactly which sequence number to record. But note that, arguably, this saved buffer content indirectly already comprises the *size* of segment M, the additional information needed for the refined tests! (6) Section 6.5.4 The sentence there, vv [...]. SCPS-TP (SCPS - Tranpsort Protocol) is based on TCP and is an official TCP option (number 20). [...] ^^^^^ ^^^^^^ is a bit misleading, and it contains a typo. SCPS-TP makes use of four TCP options, with option kinds 20,...,23. I suggest to say instead: [...]. SCPS-TP (SCPS - Transport Protocol) is a modular extension of TCP making use of the IANA registered TCP options with Option Kind 20 through 23. Feature negotiation for SCPS-TP is performed via the 'SCPS Capabilities' TCP option (number 20). [...] (7) Section 12 -- typo Please correct the case: "Rob sherwood" --> "Rob Sherwood" (8) Section 14.2 (8a) Update: see item (2) above. (8b) I already had asked for the addition of some more detailed bibliographic information (and/or URL) for the terse references [Piratla], [Savage], [Sherwood], and [VU102014]. Apparently, this has been missed. IMHO, it would put undue load on the RFC editor to have them figure out what you presumably already have at hands. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 12 07:37:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYXD-00013o-TJ; Mon, 12 Nov 2007 07:36:59 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IrYXC-000117-LM for tcpm-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 07:36:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYXC-00010x-B7 for tcpm@ietf.org; Mon, 12 Nov 2007 07:36:58 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrYXC-0004Sr-1Q for tcpm@ietf.org; Mon, 12 Nov 2007 07:36:58 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id A7D9C1758F; Mon, 12 Nov 2007 12:36:57 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IrYXB-00047L-71; Mon, 12 Nov 2007 07:36:57 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: touch@isi.edu From: IETF I-D Submission Tool Message-Id: Date: Mon, 12 Nov 2007 07:36:57 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org, mankin@psg.com Subject: [tcpm] New Version Notification for draft-ietf-tcpm-tcp-auth-opt-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org A new version of I-D, draft-ietf-tcpm-tcp-auth-opt-00.txt has been successfuly submitted by Joseph Touch and posted to the IETF repository. Filename: draft-ietf-tcpm-tcp-auth-opt Revision: 00 Title: The TCP Authentication Option Creation_date: 2007-11-11 WG ID: tcpm Number_of_pages: 31 Abstract: This document specifies a TCP Authentication Option (TCP-AO) which is intended to replace the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs) and provides more details on the association of security associations with TCP connections. TCP-AO assumes an external, out- of-band mechanism (manual or via a separate protocol) for session key establishment, parameter negotiation, and rekeying, replicating the separation of key management and key use as in the IPsec suite. The result is intended to be a simple modification to support current infrastructure uses of TCP MD5, such as to protect BGP and LDP, and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a new option identifier, even though it is intended to be mutually exclusive with TCP MD5 on a given TCP connection. It supports IPv6, and is fully compatible with requirements under development for an update to TCP MD5. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. The IETF Secretariat. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 12 07:40:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYah-0004Wk-50; Mon, 12 Nov 2007 07:40:35 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IrYaf-0004WN-83 for tcpm-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 07:40:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYae-0004WF-TL; Mon, 12 Nov 2007 07:40:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrYae-0004Xx-Ec; Mon, 12 Nov 2007 07:40:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 488382AC5F; Mon, 12 Nov 2007 12:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IrYaA-0001ZY-23; Mon, 12 Nov 2007 07:40: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: Mon, 12 Nov 2007 07:40:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --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 : The TCP Authentication Option Author(s) : J. Touch, et al. Filename : draft-ietf-tcpm-tcp-auth-opt-00.txt Pages : 31 Date : 2007-11-12 This document specifies a TCP Authentication Option (TCP-AO) which is intended to replace the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs) and provides more details on the association of security associations with TCP connections. TCP-AO assumes an external, out- of-band mechanism (manual or via a separate protocol) for session key establishment, parameter negotiation, and rekeying, replicating the separation of key management and key use as in the IPsec suite. The result is intended to be a simple modification to support current infrastructure uses of TCP MD5, such as to protect BGP and LDP, and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a new option identifier, even though it is intended to be mutually exclusive with TCP MD5 on a given TCP connection. It supports IPv6, and is fully compatible with requirements under development for an update to TCP MD5. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-auth-opt-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-auth-opt-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-12073654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-auth-opt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-auth-opt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-12073654.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Tue Nov 13 03:23:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irr3M-0006Ft-4j; Tue, 13 Nov 2007 03:23:24 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Irr3L-0006Fg-Go for tcpm-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 03:23:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irr3E-0005xZ-W5 for tcpm@ietf.org; Tue, 13 Nov 2007 03:23:17 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irr3E-00008y-GL for tcpm@ietf.org; Tue, 13 Nov 2007 03:23:16 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAD8MfCN031447; Tue, 13 Nov 2007 10:23:08 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 10:22:44 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 10:22:44 +0200 Received: from [172.21.34.254] (esdhcp034254.research.nokia.com [172.21.34.254]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAD8MgMc021799; Tue, 13 Nov 2007 10:22:43 +0200 In-Reply-To: References: <20071015161355.CDC992CA32C@lawyers.icir.org> <44C4AF94-CC5D-4702-914E-764583E2AADA@nokia.com> <78C9135A3D2ECE4B8162EBDCE82CAD77026345DE@nekter> <4717E7D6.7000407@isi.edu> <14C200C0-73DE-4550-A1E2-5B43BEE29BAF@nokia.com> <472756CC.8070809@isi.edu> <582A6F13-12CC-4B5C-8415-CBDAD73116AA@nokia.com> <4728A553.2020300@isi.edu> <6B3D5E1D-F2DA-428C-AAEF-6F548F48F4F5@nokia.com> <3DF7B46C-5246-470E-9C98-08A5AEADDAF3@nokia.com> <472F36FC.1030301@isi.edu> <001BF967-9D6E-4583-8C08-6B4AC29A567C@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <08183AA6-9C86-4060-BE9C-2F8590A43D00@nokia.com> Content-Transfer-Encoding: 7bit From: Lars Eggert Subject: Re: [tcpm] WGLC for UTO Date: Tue, 13 Nov 2007 10:22:40 +0200 To: "ext toby.moncaster@bt.com" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Nov 2007 08:22:44.0947 (UTC) FILETIME=[5DEEA230:01C825CE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ah@tr-sys.de, tcpm@ietf.org, touch@ISI.EDU 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, FYI, I'll shortly submit my working copy as -07. Thanks to the new submission system, it will be a simple thing to push out an -08 revision before the cutoff, if the WG would like to see further changes. Lars _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 13 03:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrrAH-00060b-PX; Tue, 13 Nov 2007 03:30:33 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IrrAG-0005zR-R1 for tcpm-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 03:30:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrrAG-0005zJ-HY for tcpm@ietf.org; Tue, 13 Nov 2007 03:30:32 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrrAD-0000Jo-Nf for tcpm@ietf.org; Tue, 13 Nov 2007 03:30:32 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id 8DC9426E77; Tue, 13 Nov 2007 08:30:29 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IrrAD-0002Sa-F7; Tue, 13 Nov 2007 03:30:29 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: lars.eggert@nokia.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 13 Nov 2007 03:30:29 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tcpm@ietf.org, fernando@gont.com.ar Subject: [tcpm] New Version Notification for draft-ietf-tcpm-tcp-uto-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org A new version of I-D, draft-ietf-tcpm-tcp-uto-07.txt has been successfuly submitted by Lars Eggert and posted to the IETF repository. Filename: draft-ietf-tcpm-tcp-uto Revision: 07 Title: TCP User Timeout Option Creation_date: 2007-11-13 WG ID: tcpm Number_of_pages: 16 Abstract: The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option - the TCP User Timeout Option - that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. The IETF Secretariat. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 13 03:40:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrrK2-0001vS-SW; Tue, 13 Nov 2007 03:40:38 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IrrK0-0001r7-Mx for tcpm-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 03:40:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrrK0-0001qz-93; Tue, 13 Nov 2007 03:40:36 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrrJw-0000eN-22; Tue, 13 Nov 2007 03:40:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 0965B3290B; Tue, 13 Nov 2007 08:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IrrJR-00063e-UR; Tue, 13 Nov 2007 03:40: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, 13 Nov 2007 03:40:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-uto-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP User Timeout Option Author(s) : L. Eggert, F. Gont Filename : draft-ietf-tcpm-tcp-uto-07.txt Pages : 16 Date : 2007-11-13 The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option - the TCP User Timeout Option - that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-uto-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-13033027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-uto-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-13033027.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Tue Nov 13 05:16:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irsoc-0000D9-PP; Tue, 13 Nov 2007 05:16:18 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Irsob-0000Bx-IS for tcpm-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 05:16:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irsob-0000Ar-7k for tcpm@ietf.org; Tue, 13 Nov 2007 05:16:17 -0500 Received: from dsl.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrsoZ-0004dc-JD for tcpm@ietf.org; Tue, 13 Nov 2007 05:16:16 -0500 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA192538933; Tue, 13 Nov 2007 11:15:33 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA10052 for tcpm@ietf.org; Tue, 13 Nov 2007 11:15:32 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200711131015.LAA10052@TR-Sys.de> Subject: Re: [tcpm] WGLC for UTO (fwd) To: tcpm@ietf.org Date: Tue, 13 Nov 2007 11:15:32 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 ----- Forwarded message from Alfred H=CEnes ----- > From: Alfred H=CEnes > To: lars.eggert@nokia.com > Cc: fernando@gont.com.ar > In-Reply-To: <08183AA6-9C86-4060-BE9C-2F8590A43D00@nokia.com> from Lars= Eggert at Nov "13, 2007 10:22:40" am > Message-Id: <200711130956.KAA09990@TR-Sys.de> > Date: Tue, 13 Nov 2007 10:56:36 +0100 (MEZ) > Subject: Re: [tcpm] WGLC for UTO > On Tue, 13 Nov 2007 10:22:40 +0200, Lars Eggert wrote: >> Hi, >> = >> FYI, I'll shortly submit my working copy as -07. >> = >> Thanks to the new submission system, it will be a simple thing to >> push out an -08 revision before the cutoff, if the WG would like to >> see further changes. > = > Indeed, both: it was nearly instantaneous, and I have a few more nits. > = > = > (1) Section 3 > = > I'm still not content with the delineation between "USER TIMEOUT" > and "USER_TIMEOUT" -- the latter being the per-connection > instantiation (TCB variable) of the former, according to the first > hanging list entry in Section 3. > = > Accordingly, in the last list entry, the second instance of > "USER_TIMEOUT" should be changed to "USER TIMEOUT". > v > CHANGEABLE (Boolean) > | Flag that controls whether USER_TIMEOUT (TCP's USER_TIMEOUT > parameter) may be changed based on an UTO option received from th= e > other end of the connection. Defaults to true and becomes false > when an application explicitly sets USER_TIMEOUT. > --- v > CHANGEABLE (Boolean) > | Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT > parameter) may be changed based on an UTO option received from th= e > other end of the connection. Defaults to true and becomes false > when an application explicitly sets USER_TIMEOUT. > = > The second-to-next paragraph, starting > = > Before opening a connection, ... > = > explicitely deals with setting the per-connection variables (in > the TCB, presumably by a suitable extension to the socket API). > Hence, it should refer to setting the "USER_TIMEOUT". > So please change: > vvvvvvvvvvvvvvvv > [...]. If an application > | explicitly sets the USER TIMEOUT, CHANGEABLE MUST become false, to > prevent UTO options from the other end to override local application= > requests. [...] > --- vvvvvvvvvvvv > [...]. If an application > | explicitly sets USER_TIMEOUT, CHANGEABLE MUST become false, to > prevent UTO options from the other end to override local application= > requests. [...] > = > = > (2) Section 3.1 > = > Below the recommended formula and the explanation of its terms, > the draft now says: > = > The RECOMMENDED formula results in the maximum of the two advertised= > values to be adopted for the user timeout of the connection on both > | ends, provided they are within the upper and lower limits. [...] > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > = > This might be misunderstood as referring to a *conditional* assignment,= > only to be performed when this precondition is met; but the formula > describes an *unconditional* assignment, and a two-sided clipping > operation on the right-hand side. > That might be better reflected by saying: > = > The RECOMMENDED formula results in the maximum of the two advertised= > values to be adopted for the user timeout of the connection on both > | ends, after clipping to the preset upper and lower limits. [...] > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > = > Please also consider replacing the newly introduced "preset" by "local"= > if you want to emphasize the fact that these limits are indeed a local > matter, which means that the values adopted on the two ends of the TCP > connection might well be different: > = > The RECOMMENDED formula results in the maximum of the two advertised= > values to be adopted for the user timeout of the connection on both > | ends, after clipping to the local upper and lower limits. [...] > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > = > I have tried to find a short phrase not expanding the text further; > I you prefer, chose more verbose wording. > = > = > Kind regards, > Alfred. > = > -- = > = > +------------------------+--------------------------------------------+= > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |= > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |= > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de |= > +------------------------+--------------------------------------------+= ----- End of forwarded message from Alfred H=CEnes ----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 14 10:46:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKRj-0001bu-UE; Wed, 14 Nov 2007 10:46:31 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IsKRi-0001WY-Ah for tcpm-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:46:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKRh-0001WE-VU for tcpm@ietf.org; Wed, 14 Nov 2007 10:46:29 -0500 Received: from mailer1.psc.edu ([2001:5e8:1:3a::64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKRh-0007Uj-Ft for tcpm@ietf.org; Wed, 14 Nov 2007 10:46:29 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer1.psc.edu (8.14.1/8.13.3) with ESMTP id lAEFkPMx029311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2007 10:46:26 -0500 (EST) Message-ID: <473B1851.2020502@psc.edu> Date: Wed, 14 Nov 2007 10:46:25 -0500 From: John Heffner User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Mahesh Jethanandani Subject: Re: [tcpm] Is this a problem? References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu> <20071106192746.GE5881@elb.elitists.net> <20071106193912.GF5881@elb.elitists.net> <4730C9D6.1020700@cisco.com> <20071106203212.GG5881@elb.elitists.net> <47333FD9.8010508@cisco.com> In-Reply-To: <47333FD9.8010508@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Mahesh Jethanandani wrote: > > > Ethan Blanton wrote: >> Yes; however, I agree with Joe (and others) that in the situation you >> are *actually* trying to solve, this is not particularly relevant. If >> you are short on resources, the distinction between "not making >> progress due to zero window" and "not making progress for some other >> reason" does not seem important. As previously mentioned, zero window >> does _not_ indicate a malicious host in any way. >> > Where is the fairness argument in knocking connections off without > making distinctions? A connection that is not making progress because of > congestion in the network is a transient behavior and is very different > from a connection that continues to advertise a zero window. The former > is much harder to do and requires TCP stack changes. Zero window > connection can be made to happen on a whim (as we successfully did) on a > large number of connections from a user level program with little or no > privileges. It's actually an easy and generally more effective attack to just drop all the packets on the floor rather than continue ACKing with zero window. The connection will eventually time out, but it takes so long, it's easy to initiate another one in this time to take its place. Once again, please look carefully at Stas's netkill: . It's a simple short perl script. The defense you are proposing does nothing for this attack. I don't think it's critical to determine whether a connection is stalled while limited by cwnd or rwin. This *may* be useful information, but it's not the most important. In my view, the more important thing to know is (1) whether the connection is making progress, and (2) how much memory (the contended resource) it is using. Using this information, you can implement a policy that resets connections that are consuming resources with no benefit (progress). This solves the more general problem -- both the netkill attack and a persist attack. Also, I have a quibble with some of the language in the draft that I think reflects a view of where the solution must go: In most implementations, TCP runs in kernel mode as part of the operating system. In this mode the operating system may share the same address space as TCP. For the purposes of discussion, this draft considers TCP protocol implementation to be a separate module responsible for all resources such as buffers and connection control blocks that it borrows from the operating system. The operating system can enforce the maximum number of buffers it is willing to give to TCP but beyond that it lets TCP decide how to manage them. Even if you view TCP as running with an inaccessible address space, it can still export all sorts of information, in both standard (see RFC 4022 and RFC 4898) and non-standard ways. From a standards point of view, I think RFC 4898 exports all the necessary information. And even if the solution must be implemented in an independent TCP module, this does not mean the solution should be defined and standardized as a transport layer mechanism. A TCP module could implement a memory-based fairness policy if it's controlling its own memory pool as you describe. This does not mean you need to change the definition of how the TCP protocol behaves in the persist state. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 14 11:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLY5-0000d4-LK; Wed, 14 Nov 2007 11:57:09 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IsLY3-0000aj-Kz for tcpm-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 11:57:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLY3-0000ab-BQ for tcpm@ietf.org; Wed, 14 Nov 2007 11:57:07 -0500 Received: from mailer1.psc.edu ([2001:5e8:1:3a::64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsLY2-0007nW-ND for tcpm@ietf.org; Wed, 14 Nov 2007 11:57:07 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer1.psc.edu (8.14.1/8.13.3) with ESMTP id lAEGv4iI013585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2007 11:57:05 -0500 (EST) Message-ID: <473B28E0.6040602@psc.edu> Date: Wed, 14 Nov 2007 11:57:04 -0500 From: John Heffner User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: toby.moncaster@bt.com, tcpm Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [tcpm] draft-moncaster-tcpm-rcv-cheat-02 probabilistic test 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 Toby, I'm not sure I completely understand some of the claims in Section 6.2.2, particularly: "That is to say, a receiver can either honestly report the missing packets or it can suffer a reduced throughput by delaying segments and increasing the RTT," and "Equally, a receiver that delays transmission of the duplicate acknowledgements until it is sure it is being tested will leave an obvious pattern of acknowledgements that the sender can identify." If I were designing a receiver to try to defeat this test, I would delay response by six segments, or a short timeout, whichever is less. If I observe reordered segments, I would send the ACK/SACK that the sender would expect. Additionally, I would ACK any lost segments, and any received segments as normal, only delayed by the time to receive the following six segments. You seem to have thought about this strategy, but I'm not sure I see how the claims in section 6.2.2 apply. I don't think this strategy will increase the RTT so much that it will cause significant performance reduction. And I'm not sure how delaying the ACKs will leave an obvious pattern that the sender can identify. Am I missing something? -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 14 17:58:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRBq-000085-J5; Wed, 14 Nov 2007 17:58:34 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IsRBp-000079-1r for tcpm-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 17:58:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsRBo-000061-No for tcpm@ietf.org; Wed, 14 Nov 2007 17:58:32 -0500 Received: from dsl.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsRBj-0003sz-H3 for tcpm@ietf.org; Wed, 14 Nov 2007 17:58:32 -0500 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA202281064; Wed, 14 Nov 2007 23:57:44 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA13402; Wed, 14 Nov 2007 23:57:43 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200711142257.XAA13402@TR-Sys.de> To: tcpm@ietf.org Date: Wed, 14 Nov 2007 23:57:42 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM1195081062-13327-0_ Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 Subject: [tcpm] TCP options - tcp-parameters IANA registry 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 --ELM1195081062-13327-0_ Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Hello all, there are currently several proposals for new TCP options. It has turned out onerous to get an overview of the TCP options defined in the past, because the IANA 'tcp-parameters' registry had not seen any additions until recently, for more than a decade, and has not been maintained as carefully as might be desirable, and because there are some apparently very obscure entries. I have perceived the desire to build a more sound foundation for my understanding of the issues related with those old and proposed TCP options. To this end, I have tried to perform a survey of the non-RFC IANA-registered TCP options, by sending out a questionnary to personal registrants last January, and I have tried to collect and condense information contained in RFCs, and from the distributed wisdom of the net. I'd like to acknowledge the efforts of those individuals who have assisted my attempts to get in contact with the owners of legacy registrations, and who have taken the time to fill in the questionnary and to supply additional information. Due to lack of spare time and a rather small rate of feedback I eventually arrived at for the survey, it took me until now to prepare an updated, corrected, amended, and annotated version of the latest IANA 'tcp-parameters' file. I hope that sharing this information with the list will help to o complete the information, and o serve as a solid base of additional information for ongoing and starting discussions on various issues related to (existing and) newly proposed TCP options. Furthermore, I'm interested to hear whether it might make sense to start an 'authorized' effort to improve and update the 'tcp-parameters' IANA registry, incorporating some of the changes I have performed on my local copy. Currently, an update to the IANA Considerations for the 'protocols' registry is submitted (from within and) to the IESG for publication as an RFC, and a similar effort is being discussed for the 'port-numbers' registry as well. This therefore might be a good opportunity for a cleanup of the 'tcp-parameters' registry as well, closing the gaps and facelifting the file. I have enclosed as an attachment my current working copy of that registry file, including `==>` tagged lines pointing to specific solicitations for additional information. For informational purposes, I have also left therein a few traces of the history of the file, as recovered from local backup media. Please send comments to the list or in private communication, as deemed useful. I will honor requests for non-disclosure of information sources and/or details received in personal communication, and will try to update the working copy based on feedback received, in a neutral and abstract way -- following the style you'll already find there currently. ( see attached file: annotated_tcp-parameters.20070216 ) Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ --ELM1195081062-13327-0_ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename=annotated_tcp-parameters.20070216 Content-Description: draft annotated IANA file Content-Transfer-Encoding: quoted-printable Transmission Control Protocol (TCP) Parameters -- per [RFC793] and [RFC27= 80] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -- draft amended and annotated edition, based on 2007-02-15 IANA version= -- Contents: =B7 TCP Option Kind Numbers =B7 TCP Alternate Checksum Numbers Related registries: =B7 - for TCP (server) port numbers, per section 9.1 of [RFC2780] =B7 - for flag bits (in the 4th word of the TCP head= er), per section 9.2 of [RFC2780] TCP Option Kind Numbers -- per section 9.3 of [RFC2780] =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF The Transmission Control Protocol (TCP) [RFC793] has provision for option= al header fields identified by a one-octet Option Kind field. Options 0 and 1 are exactly one octet which is their Kind field. All other options have their one-octet Kind field, followed by a one-octet Length field, followed by -2 octets of option data. There are no alignment requirements for TCP options. Optionally, alignment may be achieved by inserting instances of Option 1.= The maximum cumulative size of all options in one TCP header is 40 octets= =2E If the cumulative size of all options supplied is not an integer multiple= of 4, Option 0 has to be appended, followed by zero or more zero-valued padd= ing octets, up to the TCP header size implied by the Data Offset TCP header f= ield. Assignment policy: Standards Action or IESG Approval. Registry: Kind Length Meaning References (r) Notes ---- ------ ---------------------------------- --------------- ---------= ------ 0 - End of Option List [RFC793] FS ANY fi= x 1 - No-Operation [RFC793] FS ANY fi= x 2 4 Maximum Segment Size [RFC793] FS SYY fi= x 3 3 WSOPT - Window Scale [RFC1072,RFC1323] PS SYZ fi= x 4 2 SACK Permitted [RFC1072,RFC2018] PS SYY fi= x 5 2+8*n SACK [RFC1072,RFC2018] PS EST fi= x (n) 6 6 Echo (obsoleted by option 8) [RFC1072] H SY+ fi= x (e) 7 6 Echo Reply (obsoleted by option 8) [RFC1072] H SY+ fi= x (e) 8 10 TSOPT - Time Stamp Option [RFC1323] PS SY+ fi= x (s) 9 2 Partial Order Connection Permitted [RFC1693] EX SYY fi= x (x) 10 3 Partial Order Service Profile [RFC1693] EX EST fi= x (x) 11 6 CC [RFC1644] EX H ANY f= ix (t) 12 6 CC.NEW [RFC1644] EX H SYN f= ix (t) 13 6 CC.ECHO [RFC1644] EX H SYA f= ix (t) 14 3 TCP Alternate Checksum Request [RFC1146] EX H SYY f= ix (x) 15 2+c TCP Alternate Checksum Data [RFC1146] EX H EST f= ix (cx) 16 ? Skeeter [Knowles] EX H = (y) 17 ? Bubba [Knowles] EX H = (y) 18 3 Trailer Checksum Option [Subbu+Bridges] EX H = (y) 19 18 MD5 Signature Option [RFC2385] PS ANY fi= x 20 4 SCPS-TP Capabilities [Scott+SCPSTP] XS SYY fi= x 20 5+ SCPS-TP Extended Capabilities [Scott+SCPSTP] XS SYY fi= x 21 6+ Selective Negative Acknowledgements [Scott+SCPSTP] XS EST fi= x 22 2 Record Boundaries [Scott+SCPSTP] XS DTA fi= x 23 2 Corruption experienced [Scott+SCPSTP] XS EST fi= x 24 ? SNAP [Sukonnik] EX H = (y) 25 - unassigned - (released 12/18/00) - 26 ? TCP Compression Filter [Bellovin] EX H fi= x (y) 27 8 Quick-Start Response [RFC4782] EX SYA/ES= T fix 28 - unassigned - - :: :: 252 - unassigned - - 253 N RFC3692-style Experiment 1 (*) [RFC4727] PS = (p) 254 N RFC3692-style Experiment 2 (*) [RFC4727] PS = (p) 255 - unassigned - / - reserved - ? [???] = (z) (*) It is only appropriate to use these values in explicitly-configured experiments; they MUST NOT be shipped as defaults in implementations.= See [RFC3692] for details. Legend and additional notes: XS ... eXternal (non-IETF) Standard PS ... IETF Proposed Internet Standard \ classification DS ... IETF Draft Internet Standard > based on rfcxx00.txt FS ... IETF Full Internet Standard / EX ... Experimental Protocol ... " " (in case of RF= Cs) H ... now Historic SYN ... Option only used in the initial SYN segment. SYA ... Option only used in the initial SYN-ACK segment. SYY ... Option only used in the initial SYN and SYN-ACK segments; sending on SYN-ACK admitted only if received on SYN. SYZ ... Option only effective in the initial (SYN and SYN-ACK) segmen= ts; it may be sent thereafter, but then must be ignored on receip= t. SY+ ... Option used in the initial SYN segment, and in any subsequent= segment, provided it has been received in the initial SYN or SYN-ACK segment of the connection. EST ... Option only used after connection establishment (non-SYN segments -- data or pure ACK). There may be additional restrictions on use. DTA ... Option only used in data segments. ANY ... Option usable in any segment. fix ... Option is invariate (MUST NOT be changed in transit), i.e. this is an end-to-end option. Note that ALGs in NAT/Firewall boxes might want/need to chang= e some of such options "in transit", but this scenario is better des= cribed as the termination of two 'half-connections' on the ALG, anyw= ay. (c) One usage with c =3D 2, i.e. Length =3D 4, has been defined and regis= tered. (e) Publication predates Standards Track. Considered EXPERIMENTAL. RFC index says current status is UNKNOWN, but also document obsoleted= by RFC 1323 + RFC 2018; in particular, RFC 1323 has updated option #3= and replaced options #6 and #7 by option #8; RFC 2018 has update opti= on #4 and #5. (n) 1 <=3D n <=3D 4 , i.e. Length is in {10,18,26,34}. (p) Properties and requirements vary (specific to the particular experime= nt). (r) Obsoleted references are included leftmost, separated with a comma; multiple, equally applicable references are separated by plus signs. (s) RFC 1323 is ambiguous on the preconditions for sending TSopt; the explanation above for SY+ is offered as a reasonable interpretati= on. (t) Declared Historic by RFC 4614, but included by reference in SCPS-TP ;= also known to be implemented in some major OS's TCP/IP stack. =3D=3D> Feedback regarding implementation and deployment is solicited. (x) It is believed that the experiment has been concluded, and that the o= ption is neither implemented nor deployed currently; hence it is considered= as Historic -- see RFC 4614 for the detailed rationale of the demotion. =3D=3D> Feedback regarding implementation and deployment is solicited, an= yway. (y) No public documentation available. (Thus, for most of these options, the additional information given he= re is necessarily based on vague secondary or tertiary sources.) Option used in a (concluded) experiment, never deployed in the Intern= et; considered as Historic, allocation retained for archival purpose only= =2E =3D=3D> Feedback on all kind of additional information is solicited. (z) Option Kind 255 does not appear in the original IANA registry file; apparently, Option Kind 255 should be considered as -reserved-, But neither of RFC 793, RFC 1122, RFC 2780, RFC 4614, RFC 4727 contains any explicit statement to this end. =3D=3D> Are there other specifications stating IANA policy for Option Kin= d 255 ? TCP Alternate Checksum Numbers -- per [RFC1146] =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF RFC 1146 defines the TCP Alternate Checksum Option (Kind=3D14, see above)= =2E This option carries the one-octet field. Assignment policy: none so far -- RFC 1146 predates the formalization of IANA assignment p= olicy, and RFC 2780 does not contain directions for this field.= Registry: Number Description Reference ------ ------------------------------- --------- 0 TCP Checksum [RFC1146] 1 8-bit Fletchers's algorithm [RFC1146] 2 16-bit Fletchers's algorithm [RFC1146] 3 Redundant Checksum Avoidance [KAY] REFERENCES ---------- [RFC793] J. Postel, "Transmission Control Protocol - DARPA Internet Prog= ram Protocol Specification", STD 7, RFC 793, September 1981. [RFC1323] V. Jacobson, R. Braden, and D. Borman, "TCP Extensions for High= Performance", RFC 1323, May 1992. [RFC1072] V. Jacobson and R. Braden, "TCP Extensions for Long-Delay Paths= ", RFC 1072, October 1988. [RFC1644] R. Braden, "T/TCP -- TCP Extensions for Transactions - Function= al Specification", RFC 1644, July 1994. [RFC1693] T. Connolly et al., "An Extension to TCP : Partial Order Servic= e", RFC 1693, November 1994. [RFC1146] J. Zweig and C. Partridge, "TCP Alternate Checksum Options", RFC 1146, March 1990. [RFC2018] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP Selective= Acknowledgement Options", RFC 2018, April 1996. [RFC2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signa= ture Option", RFC 2385, August 1998. [RFC2780] S. Bradner and V. Paxson, "IANA Allocation Guidelines for Value= s in the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC3692] T. Narten, "Assigning Experimental and Testing Numbers Consider= ed Useful", BCP 82, RFC 3692, January 2004. [RFC4413] M. West and S. McCann, "TCP/IP Field Behavior", RFC 4413, March= 2006. [RFC4614] M. Duke, R. Braden, W. Eddy, and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006. [RFC4727] B. Fenner, "Experimental values In IPv4, IPv6, ICMPv4, ICMPv6, = UDP and TCP Headers", RFC 4727, November 2006. [RFC4782] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, "Quick-Start fo= r TCP and IP", RFC 4782, January 2007. [KAY] J. Kay, and J. Pasquale, "Measurement, Analysis, and Improvemen= t of UDP/IP Throughput for the DECstation 5000", Proceedings of the = Winter 1993 Usenix Conference, January 1993 (available for anonymous F= TP in ucsd.edu:/pub/csl/fastnet/fastnet.tar.Z). [SCPSTP] "Space Communications Protocol Specification (SCPS) -- Transpor= t Protocol". Blue Book. Issue 2. October 2006. PEOPLE ------ [Bellovin] Steve Bellovin, , March 2000. = (+) [Braden] Bob Braden, , March 1995. = (-) [Bridges] Monroe Bridges, , September 1994. = (*) [Knowles] Stev Knowles, , March 1995. = (*) [Kay] J. Kay, , Septermber 1994. = (*) [Scott] Keith Scott, , February 1999. [Subbu] Subbu Subramaniam, , September 1994. = (*) [Sukonnik] Vladimir Sukonnik, , February 199= 9. (*) Notes: (*) - email address outdated / unreachable (Jan. 2007) (+) - email address updated (-) - redundant entry (not used) (.... updated 2001-05-01) (.... updated 2006-12-14) (last updated 2007-02-15) (updated and annotated ... 2007-11-14 ah (at) TR-Sys.de) [] --ELM1195081062-13327-0_ 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 --ELM1195081062-13327-0_-- From tcpm-bounces@ietf.org Fri Nov 16 04:38:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxeH-0007IW-6K; Fri, 16 Nov 2007 04:38:05 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IsxeF-0007EP-Si for tcpm-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 04:38:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxeF-0007EH-J3 for tcpm@ietf.org; Fri, 16 Nov 2007 04:38:03 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsxeB-00067w-2J for tcpm@ietf.org; Fri, 16 Nov 2007 04:38:03 -0500 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 09:37:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Nov 2007 09:37:45 -0000 Message-ID: In-Reply-To: <200711121137.MAA06290@TR-Sys.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-moncaster-tcpm-rcv-cheat-02 Thread-Index: AcglIJiuKa7J8A1xRO6oQCueAXWn5QDEizTQ From: To: , , X-OriginalArrivalTime: 16 Nov 2007 09:37:58.0202 (UTC) FILETIME=[5F47F1A0:01C82834] X-Spam-Score: -1.0 (-) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Cc: tcpm@ietf.org Subject: [tcpm] RE: draft-moncaster-tcpm-rcv-cheat-02 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 Alfred, Many thanks for sending these comments. We are currently going through = them adding them to the draft for the next version. In particular we = will be sure to clarify the confusion between segment and sequence = numbers. We originally did give some thought to altering the segment sizes as = part of the test. This was identified by Rob Sherwood in the extended = version of "Misbehaving TCP Receivers Can Cause Internet-Wide Congestion = Collapse" . We originally rejected this solution because the TCP protocol allows the = receiver to cumulatively acknowledge large chunks of data (though = usually this is limited to 2xMSS per ACK). We felt this meant that = altering the segment sizes didn't give a sure enough test. However your = suggestion of combining this behaviour with segment reordering does at = first glance seem to be quite powerful. The presence of an out-of-order = segment should trigger an immediate ACK even if delayed ACKs are being = used. We will look into this in detail for the next version of the = draft. Yours, Toby _________________________________________________________________________= ___ Toby Moncaster, Networks Research Centre, BT = Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 = 648734=20 -----Original Message----- From: Alfred H=CEnes [mailto:ah@tr-sys.de]=20 Sent: 12 November 2007 11:38 To: Moncaster,T,Toby,CXR9 R; Briscoe,RJ,Bob,CXR9 R; = Jacquet,A,Arnaud,CXR9 R Cc: tcpm@ietf.org Subject: draft-moncaster-tcpm-rcv-cheat-02 Hello, thanks for updating your Internet-Draft to = draft-moncaster-tcpm-rcv-cheat-02, incorporating many of the suggestions = I had supplied in my review of rev. -01. Studying the new version, I unfortunately found some of the issues = raised addressed incompletely, or even missed, and some typos newly = intruduced; and I also got aware of a small number other nits not = mentioned previously. Note to readers of the list (added on proofreading): Item (5) below is the single non-editiorial topic discussed, and it might deserve further comments! This topic has caused me to copy this entire message to the list. (1) Re: "cheating", "[dis]honest[ly]" , etc. Whereas you have modified many of the occurrences of these words not = complying to the stated aims of the draft, a few have been left in the = text -- some apparently intentionally (e.g., Sections 6.2.3 amd 6.3.2), = some perhaps missed. Please reconsider these parts of the text; I'll give pointers below. (1a) Section 5.1 IMHO, it would be consistent with the rest of the memo to replace = "dishonest behaviour" by "non-conforming behavior" in the second line of the second paragraph of Section 5.1. (1b) Section 6.2 Similarly, it seems that using "conformant" in place of "honest" would be more consistent with the rest of the text, at the very end of = the last paragraph of Section 6.2. (1c) Section 6.2.1 The text in the box in Figure 3 has been modified to adopt the term = "compliant". Hence it would be reasonable to change the figure cation as well. For brevity and clearness, I suggest to change it as follows: Figure 3: A receiver reacting honestly to a probabilistic test --- Figure 3: Compliant receiver reaction to a probabilistic test The instances of "dishonest" and "honestly" in the paragraph below = Figure 3 arguably still make sense in the stated setup. (1d) Sections 6.2.2, 6.2.3, and 6.2.5 This IMHO also is true for "honestly" in the first paragraph of Section = 6.2.2 and the instances "dishonest" in the first paragraph (2x) and the second paragraph (1x) of Section 6.2.3. The "cheat" at the latter place also seems acceptable. Yet, this arguably does not apply to the "honest" in the last text box = in Figure 4, where I'd prefer "conformant". The "dishonest" in the 8th bullet in Section 6.2.5 arguably is = acceptable, but might be replaced by "non-conformant" as well, whereas = the "dishonest" in the last bullet looks good to me. (1e) Section 6.3.2 The two instances of "dishonest" and the subsequent "honest" in Section also make sense in that re-worded context. (1f) Section 6.4 I recommend changing "dishonest" to "non-conformant" in the first line = of Section 6.4, as the sender can only deduce from the test that the = receiver behaves in a non-conformant way, not the possible rationale = behind this behavior, which the reader might well feel as being = categorized by the semantics of "dishonest". Similar arguments also apply to the subsequent word "dishonestly" in the same paragraph. (1g) Section 10 Please also reconsider the "dishonest" and "honest" (one instance each) in Section 10. (I'm in doubt whether I should argue against these = words in favor of "non-conformant" / "conformant" or not.) (2) Outdated reference The SCTP specification has been updated recently. RFC 2960 has been obsoleted by RFC 4960. Please update the ref. tag "[RFC2960]" used in the second-to-last = paragraph of Section 1 and the matching entry in Section 14.2 = accordingly, and re-adjust the placement of that entry according to the = collation order (by increasing RFC number). (3) Section 6.2.1 -- new nits In the first paragraph of Section 6.2.1, the text has been revised, and = three new flaws introduced thereby: - please correct the spelling: "trhreshold" --> "threshold" - please correct the spelling: "significnat" --> "significant" - In the sentence, To conduct the probabilistic test, instead of transmitting segment N, it transmits N+1, N+2, etc. as shown in the figure below. the "it" has been orphaned by the changed amended text directly preceding this sentence, and I suggest to clarify the text by substituting "the sender" for "it". (4) Section 6.2.3 -- Figure 4 I already had mentioned that, IMHO, in the third text box within Figure = 4, "sender" should be replaced by "receiver". Apparently this has been missed in the update to -02. (5) Segment numbers vs. TCP sequence numbers -- and possible extensions of the tests I already had mentioned the confusion between TCP segment numbers (e.g., = "N") in the text, and TCP sequence numbers counting the cumulative bytes = in these segments (and certain specific protocol events as well), and = you have corrected that issue in the single instance I had pointed to = explicitly. Unfortunately, when reading the text again, and with that change in = mind, it now became apparent to me that the same issue permeates the = text. Clarification/correction is needed by also changing the wording = in the places of the draft listed below. I also have included further ramifications of this issue, and an ensuing = potential enhancement for the tests. (5a) Section 6.2.1 At the end of the first paragraph, the draft says: Once it has transmitted N+D it can transmit segment N. The sender needs to record the sequence number, N as well as the displacement, D. It would perhaps be better to say: Once it has transmitted N+D it can transmit segment N. The sender needs to record the sequence number corresponding to N as well as the displacement, D. or: Once it has transmitted N+D it can transmit segment N. The sender needs to record the sequence number of the first octet in segment N as well as the displacement, D. But apparently, that will not suffice. Note: Due to lack of time to investigate all the details (and possible opportunities for optimizations in implementations), I only present my concerns and ideas very roughly. I strongly suspect that it does not suffice to record the displacement = in segments (D); perhaps the sequence number of the first octet in = segment N+D needs to be recorded (or, equivalently, the sequence number = of the last octet in segment N+D-1). Also, the 'width' of the artificial gap in the octet stream sent, i.e. = the octet size of segment N, should perhaps be recorded as well -- assuming it might not always equal the full MSS of the connection, as = this would allow to discriminate the unusual and suspicion-raising = receiver behavior of sending 'optimistic' ACKs for some octets in the = middle of the (not yet sent) segment N. Reconsidering this observation, I found that there might be an = opportunity to refine and amend the tests, by tightly controlling the = segment sizes sent and recording this information until receipt of a = covering ACK. Unless the TCP_NODELAY socket option is applied by the = sending application (cf. Section 6.5.2), and if the TCP send buffers are = filled to the extent necessary to perform the test, the TCP sender will = regulargly send segments of maximum size (MSS). Under these circumstances, reducing the segment size randomly below MSS = by a small amount and performing suitable bookkeeping thereof, the = sender would be able to identify ACKs not matching segment boundaries. (Such sender behavior seems to be fully compliant with the TCP = specification, as shorter segments might also be sent at any time, based = on application requests like the TCP_NODELY socket option.) A = misbehaving receiver would then have trouble to always guess the proper = expected ACK sequence numbers matching segment boundaries if it wants to = send optimistic ACKs, thus necessarily providing further hints to the = sender of its non-conforming behavior. (5b) Section 6.2.5 The 5th bullet says: o The sequence number N of the delayed segment MUST be recorded by the sender as must the amount of delay D. It should better say: o The sequence number of the delayed segment N MUST be recorded by the sender as must the amount of delay D. Yet this still leaves open the question which figures should be recorded = for "the amount of delay D" -- is it D, or some sequence number = corresponding to segment N+D, or both? See the indications above. Note: The 9th bullet already has been clarified. The 10th bullet says: o If the sender receives an acknowledgement for a segment with a sequence number between N and N+D inclusively it MUST treat this as an indication of congestion and react appropriately. The phrase, "sequence number between N and N+D" also is imprecise and = confusing, and should be clarified. (5c) Section 6.3.* In Section 6.3.*, 'M' is the segment number for the suspended segment. Yet, the first paragraph of Section 6.3.2 says: The sender can therefore state that if it receives an acknowledgement for a segment with a sequence number greater than M before it has actually sent segment M then the receiver must either be cheating or is very non-compliant. Again, "sequence number greater than M" is imprecise and confusing, and = hence should be clarified. The second bullet in Section 6.3.3 already vaguely specifies: o To perform the deterministic test the sender MUST select a segment M at random. The sender MUST store this segment in the buffer of unacknowledged data without sending it and MUST record the sequence number. It remains open exactly which sequence number to record. But note that, arguably, this saved buffer content indirectly already = comprises the *size* of segment M, the additional information needed for = the refined tests! (6) Section 6.5.4 The sentence there, vv [...]. SCPS-TP (SCPS - Tranpsort Protocol) is based on TCP and is an official TCP option (number 20). [...] ^^^^^ ^^^^^^ is a bit misleading, and it contains a typo. SCPS-TP makes use of four TCP options, with option kinds 20,...,23. I suggest to say instead: [...]. SCPS-TP (SCPS - Transport Protocol) is a modular extension of TCP making use of the IANA registered TCP options with Option Kind 20 through 23. Feature negotiation for SCPS-TP is performed via the 'SCPS Capabilities' TCP option (number 20). [...] (7) Section 12 -- typo Please correct the case: "Rob sherwood" --> "Rob Sherwood" (8) Section 14.2 (8a) Update: see item (2) above. (8b) I already had asked for the addition of some more detailed bibliographic = information (and/or URL) for the terse references [Piratla], [Savage], = [Sherwood], and [VU102014]. Apparently, this has been missed. IMHO, it would put undue load on the RFC editor to have them figure out = what you presumably already have at hands. Kind regards, Alfred. --=20 +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 16 05:51:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isyn9-0002Dp-HY; Fri, 16 Nov 2007 05:51:19 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Isyn8-00029m-6g for tcpm-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 05:51:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isyn7-00028g-RL for tcpm@ietf.org; Fri, 16 Nov 2007 05:51:17 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isyn7-0006bw-76 for tcpm@ietf.org; Fri, 16 Nov 2007 05:51:17 -0500 Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 10:51:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Nov 2007 10:51:27 -0000 Message-ID: In-Reply-To: <473B28E0.6040602@psc.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-moncaster-tcpm-rcv-cheat-02 probabilistic test Thread-Index: Acgm32OvxSNQW4BgSjCRjs0WhfCv8ABXI84w From: To: , X-OriginalArrivalTime: 16 Nov 2007 10:51:16.0108 (UTC) FILETIME=[9CA324C0:01C8283E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: bob.briscoe@bt.com Subject: [tcpm] RE: draft-moncaster-tcpm-rcv-cheat-02 probabilistic test 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 Hi John, When we originally wrote the test we did think that the increase in RTT estimate might act as a strong enough disincentive to those receivers that were actively seeking to misbehave. However we realised this probably wasn't the case, especially given the relatively coarse granularity of most TCP timers. We obviously need to update the draft to reflect this. Our current view is that the main protection afforded by this test is as follows: * Those receivers seeking to use optimistic acknowledgement are forced to not use it as they may unwittingly optimistically acknowledge a segment that was delayed. In turn they can't try and defeat the test in the manner you suggest as this relies on them waiting for the data to arrive before acknowledging (rather than acknowledging before it arrives). * Those receivers that are seeking to conceal congestion losses must have decided they don't need the missing data. This suggests either they are streaming media off the sender or they are collaborating with the sender. In the first instance I am not convinced it would be appropriate for the sender to be performing the test as that may disrupt the streaming (though more thought is needed here). In the second case the sender and receiver are cooperating and so the sender would be unlikely to want to challenge the conformance of the receiver. (Aside: There is a subsidiary possibility which is that the receiver may be able to get the missing data from some other source such as a parity file set on a different server. This test can't overcome that possibility. The only feasible defence then is to use cumulative nonces as described by Savage et al in "TCP Congestion Control with a Misbehaving Receiver" ) Further to this the test also allows for occasional delays larger than 6. If a receiver is actively seeking to defeat the test as above then it will never be able to tell when a test is happening or when it is natural re-ordering. In this case the receiver will get trapped into sending a stream of duplicate acknowledgements to defeat the test when in fact there was a genuine reordered segment. Thus it is not the actual test that catches the receiver out but the natural behaviour that underlies the test. The very existence of the test means a misbehaving receiver is forced to assume any reordering is in fact a result of the test (in order to defeat the test) and thus it is forced to respond to all reordering as if it were a test thus making it compliant.=20 Hope this answers your questions? Toby ________________________________________________________________________ ____ Toby Moncaster, Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734=20 -----Original Message----- From: John Heffner [mailto:jheffner@psc.edu]=20 Sent: 14 November 2007 16:57 To: Moncaster,T,Toby,CXR9 R; tcpm Subject: draft-moncaster-tcpm-rcv-cheat-02 probabilistic test Toby, I'm not sure I completely understand some of the claims in Section 6.2.2, particularly: "That is to say, a receiver can either honestly report the missing packets or it can suffer a reduced throughput by delaying segments and increasing the RTT," and "Equally, a receiver that delays transmission of the duplicate acknowledgements until it is sure it is being tested will leave an obvious pattern of acknowledgements that the sender can identify." If I were designing a receiver to try to defeat this test, I would delay response by six segments, or a short timeout, whichever is less. If I observe reordered segments, I would send the ACK/SACK that the sender would expect. Additionally, I would ACK any lost segments, and any received segments as normal, only delayed by the time to receive the following six segments. You seem to have thought about this strategy, but I'm not sure I see how the claims in section 6.2.2 apply. I don't think this strategy will increase the RTT so much that it will cause significant performance reduction. And I'm not sure how delaying the ACKs will leave an obvious pattern that the sender can identify. Am I missing something? -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 16 10:00:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2gG-0007DE-Qw; Fri, 16 Nov 2007 10:00:28 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1It2gF-0007BK-Gr for tcpm-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 10:00:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2gF-0007B5-4v for tcpm@ietf.org; Fri, 16 Nov 2007 10:00:27 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It2gE-0006Vm-Pb for tcpm@ietf.org; Fri, 16 Nov 2007 10:00:27 -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 lAGF0Pfs029530; Fri, 16 Nov 2007 07:00:25 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 752D212003F6; Fri, 16 Nov 2007 10:00:20 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6337D2F3B46; Fri, 16 Nov 2007 10:00:05 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Who Made Who MIME-Version: 1.0 Date: Fri, 16 Nov 2007 10:00:05 -0500 Message-Id: <20071116150005.6337D2F3B46@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Ted Faber Subject: [tcpm] agenda requests 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="===============1219681067==" Errors-To: tcpm-bounces@ietf.org --===============1219681067== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please send agenda requests for the IETF-70 TCPM meeting to Ted and I ASAP. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHPbB1WyrrWs4yIs4RArguAJ0b0b9N9RUZrUgh1j7hOhzoktPzSwCfSaSf KD2H+vFBFp/GEaD5itpSUYA= =xpnh -----END PGP SIGNATURE----- --=_bOundary-- --===============1219681067== 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 --===============1219681067==-- From tcpm-bounces@ietf.org Fri Nov 16 13:59:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6P6-0005Hd-E0; Fri, 16 Nov 2007 13:59:00 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1It6P5-0005HP-8J for tcpm-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 13:58:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6P4-0005H6-UB for tcpm@ietf.org; Fri, 16 Nov 2007 13:58:58 -0500 Received: from dsl.tr-sys.de ([213.178.172.147] helo=WOTAN.TR-Sys.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It6P3-0000rW-04 for tcpm@ietf.org; Fri, 16 Nov 2007 13:58:58 -0500 Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA211569492; Fri, 16 Nov 2007 19:58:12 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA15560; Fri, 16 Nov 2007 19:58:10 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200711161858.TAA15560@TR-Sys.de> Subject: [tcpm] RE: draft-moncaster-tcpm-rcv-cheat-02 probabilistic test To: jheffner@psc.edu, toby.moncaster@bt.com Date: Fri, 16 Nov 2007 19:58:10 +0100 (MEZ) References: <473B28E0.6040602@psc.edu> X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Fri, 16 Nov 2007 10:51:27 -0000 , wrote: > * Those receivers that are seeking to conceal congestion losses must > have decided they don't need the missing data. This suggests either > they are streaming media off the sender or they are collaborating > with the sender. ... That is exactly the scenario supported by the Space Communication Transport Protocol (SCPS-TP) "BETS" extension to TCP, now shortly discussed in Section 6.5.4 of draft-moncaster-tcpm-rcv-cheat-02: The reciever does not need outdated data, and it announces this (and supporting protocol behavior) by negotiating BETS via TCP option #20; and thus, the sender is aware or the possibility of receiving ACKs for data not arrived at the receiver, and can suppress the test. I suggest that particular applications interested in this "Real-Time Streaming over TCP" should consider implementing enough parts of SCPS-TP to support BETS to coordinate sender and receiver behavior in a manner tailored to these specific requirements. Partial implementation of SCPS-TP is facilitated by the fact that most TCP extensions of SCPS-TP have to be negotiated per connection; if you do not have implemented a feature, just don't negotiate it! Alfred. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Nov 18 11:20:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itmsu-0007vK-EO; Sun, 18 Nov 2007 11:20:36 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Itmss-0007vC-Gg for tcpm-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 11:20:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itmss-0007v0-75; Sun, 18 Nov 2007 11:20:34 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itmsq-0007xj-00; Sun, 18 Nov 2007 11:20:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id EDD0D328E7; Sun, 18 Nov 2007 16:20:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItmsL-000104-Se; Sun, 18 Nov 2007 11:20: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: Sun, 18 Nov 2007 11:20:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-rfc4138bis-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP Author(s) : P. Sarolahti, et al. Filename : draft-ietf-tcpm-rfc4138bis-01.txt Pages : 20 Date : 2007-11-18 Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc4138bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-rfc4138bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-rfc4138bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-18111836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-rfc4138bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-rfc4138bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18111836.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 Sun Nov 18 20:30:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItvSh-0002nQ-AH; Sun, 18 Nov 2007 20:30:07 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ItvSc-0002n2-V8 for tcpm-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 20:30:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItvSc-0002mu-Jw; Sun, 18 Nov 2007 20:30:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItvSc-0004V9-67; Sun, 18 Nov 2007 20:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1D6922AC5D; Mon, 19 Nov 2007 01:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItvSb-0001JJ-Qa; Sun, 18 Nov 2007 20:30: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: Sun, 18 Nov 2007 20:30:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-ecnsyn-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets Author(s) : S. Floyd, I. Property Filename : draft-ietf-tcpm-ecnsyn-03.txt Pages : 23 Date : 2007-11-18 This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specifies setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document specifies the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to a report of an ECN-marked SYN/ACK packet by reducing its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-ecnsyn-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-ecnsyn-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-18202251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-ecnsyn-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-ecnsyn-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18202251.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 Sun Nov 18 20:35:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItvXZ-0001VY-UO; Sun, 18 Nov 2007 20:35:09 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ItvXZ-0001VT-GE for tcpm-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 20:35:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItvXZ-0001VK-3W for tcpm@ietf.org; Sun, 18 Nov 2007 20:35:09 -0500 Received: from smtpoutm.mac.com ([17.148.16.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItvXV-0007my-GY for tcpm@ietf.org; Sun, 18 Nov 2007 20:35:09 -0500 Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout018/MantshX 4.0) with ESMTP id lAJ1Z41p007059; Sun, 18 Nov 2007 17:35:04 -0800 (PST) Received: from [192.168.1.64] (adsl-70-231-233-75.dsl.snfc21.sbcglobal.net [70.231.233.75]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id lAJ1Z2nn019674; Sun, 18 Nov 2007 17:35:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83e299b7cab04a1025fe4c1ea8f25d79@mac.com> Content-Transfer-Encoding: 7bit From: Sally Floyd Date: Sun, 18 Nov 2007 17:35:00 -0800 To: tcpm X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "K. K. Ramakrishnan" , Amit Mondal , Aleksandar Kuzmanovic Subject: [tcpm] draft-ietf-tcpm-ecnsyn-03.txt ready for Working Group Last Call 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 Tom and Mark - I presented a report on draft-ietf-tcpm-ecnsyn-03.txt at the last IETF, and the consensus at that meeting was that after the comments raised at the meeting were addressed, this should be ready for Working Group Last Call. I apologize for the delay in finishing this up, but I have finally made the changes and submitted the revised draft, and I believe this is now ready for Working Group Last Call. The revised draft is available at: http://www.icir.org/floyd/papers/draft-ietf-tcpm-ecnsyn-03.txt http://www.icir.org/floyd/papers/draft-ietf-tcpm-ecnsyn-03.ps The changes from the last version are fairly minimal, as follows: ------------------------------------------------------------------------ ------ Changes from draft-ietf-tcpm-ecnsyn-02: * Added to the discussion in the Security section of whether ECN-Capable TCP SYN packets have problems with firewalls, over and above the known problems of TCP data packets (e.g., as in the Microsoft report). From a question raised at the TCPM meeting at the July 2007 IETF. * Added a sentence to the discussion of routers or middleboxes that *might* drop TCP SYN packets on the basis of IP header fields. Feedback from Remi Denis-Courmont. * General editing. Feedback from Alfred Henes. ------------------------------------------------------------------------ ------ Many thanks, - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 19 04:01:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2VW-0003se-Ke; Mon, 19 Nov 2007 04:01:30 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iu2VV-0003rW-As for tcpm-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 04:01:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2VQ-0003qZ-6R for tcpm@ietf.org; Mon, 19 Nov 2007 04:01:24 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu2VM-0001tI-W3 for tcpm@ietf.org; Mon, 19 Nov 2007 04:01:24 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAJ91CgB016065; Mon, 19 Nov 2007 03:01:20 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 11:01:10 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 11:01:09 +0200 Received: from esdhcp03989.research.nokia.com (esdhcp03989.research.nokia.com [172.21.39.89]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAJ90xlw013216; Mon, 19 Nov 2007 11:00:59 +0200 Message-Id: <5D825585-DEC5-4B04-B07C-D2C59A7F1548@nokia.com> From: Lars Eggert To: =?ISO-8859-1?Q?ext_Alfred_H=CEnes?= In-Reply-To: <200711131015.LAA10052@TR-Sys.de> Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [tcpm] WGLC for UTO (fwd) Date: Mon, 19 Nov 2007 11:00:59 +0200 References: <200711131015.LAA10052@TR-Sys.de> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 19 Nov 2007 09:01:09.0055 (UTC) FILETIME=[B9C41CF0:01C82A8A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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="===============2038545403==" Errors-To: tcpm-bounces@ietf.org --===============2038545403== Content-Type: multipart/signed; boundary=Apple-Mail-21-259811041; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-21-259811041 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On 2007-11-13, at 12:15, ext Alfred H=CEnes wrote: >> I'm still not content with the delineation between "USER TIMEOUT" >> and "USER_TIMEOUT" -- the latter being the per-connection >> instantiation (TCB variable) of the former, according to the first >> hanging list entry in Section 3. I've made the changes you suggest. >> The RECOMMENDED formula results in the maximum of the two =20 >> advertised >> values to be adopted for the user timeout of the connection on both >> | ends, provided they are within the upper and lower limits. [...] >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> This might be misunderstood as referring to a *conditional* =20 >> assignment, >> only to be performed when this precondition is met; but the formula >> describes an *unconditional* assignment, and a two-sided clipping >> operation on the right-hand side. I've rephrased that as: "The RECOMMENDED formula results in the =20 maximum of the two advertised values, adjusted for the configured =20 upper and lower limits, to be adopted for the user timeout of the =20 connection on both ends." I'll shortly submit -08 with these fixes, so that we have an up-to-=20 date version to discuss at the IETF. Lars= --Apple-Mail-21-259811041 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTExOTA5MDA1OVowIwYJKoZI hvcNAQkEMRYEFHD5IBjx/iNWSNNoeNq7VM4vQKRVMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQa3GQsUdC7WDruGWZh/A+4jCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQa3GQsUdC7WDruGWZh/A+4jANBgkqhkiG9w0BAQEFAASCAQCyjveagSJ/I1vbDPpR/PP0hM52 UAckRJ8ocp9/k7cId1c84Ejhi1uEhTTETdrsBgCU/JmtpRhP8ybI8BWSdMyEQ18phZ19jRi6XxpL pNme7JBGSUN9AiakS0a364YNmXR1cnoqPKtzci5pJxVOEs0fqHsi3qdAabRuU7fyJ/xNLYKxQmoT rcthVlBu6Z8NPi6KCUOp9ST8gbChirtZT4e6sZjp6Srvoviw/i/Xj5GV8pRsQgpGr7oHVdOqr2l3 Kp9xr1Zzbiz7UFEdIl7E+tiZAdjLvhsxTTSTjfzhLWDFKuSjngUETWUlqk36JhEWOjes7HObrOrz yJ2n5U6tNJ7GAAAAAAAA --Apple-Mail-21-259811041-- --===============2038545403== 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 --===============2038545403==-- From tcpm-bounces@ietf.org Mon Nov 19 04:50:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3HB-0006VI-Th; Mon, 19 Nov 2007 04:50:45 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iu3H0-0006Hc-Np for tcpm-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 04:50:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Gy-0006H3-Cy; Mon, 19 Nov 2007 04:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu3Gx-0003zq-W0; Mon, 19 Nov 2007 04:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DE6232AC50; Mon, 19 Nov 2007 09:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu3GT-0001zW-Lm; Mon, 19 Nov 2007 04: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: Mon, 19 Nov 2007 04:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-uto-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP User Timeout Option Author(s) : L. Eggert, F. Gont Filename : draft-ietf-tcpm-tcp-uto-08.txt Pages : 17 Date : 2007-11-19 The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option - the TCP User Timeout Option - that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-uto-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tcpm-tcp-uto-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19044112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tcpm-tcp-uto-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-uto-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19044112.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 Mon Nov 19 08:38:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6pF-0000UW-AE; Mon, 19 Nov 2007 08:38:09 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iu6pD-0000U9-V3 for tcpm-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 08:38:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6pD-0000Ty-Ku for tcpm@ietf.org; Mon, 19 Nov 2007 08:38:07 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu6pD-0007Z6-8K for tcpm@ietf.org; Mon, 19 Nov 2007 08:38:07 -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 lAJDc5vU012094; Mon, 19 Nov 2007 05:38:06 -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 97BB212199C7; Mon, 19 Nov 2007 08:37:59 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 58ADD2F5CF2; Mon, 19 Nov 2007 08:35:38 -0500 (EST) To: MURALI BASHYAM From: Mark Allman Subject: Re: [tcpm] Is this a problem? In-Reply-To: <359024.58790.qm@web31711.mail.mud.yahoo.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Who Made Who MIME-Version: 1.0 Date: Mon, 19 Nov 2007 08:35:38 -0500 Message-Id: <20071119133538.58ADD2F5CF2@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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="===============0084789957==" Errors-To: tcpm-bounces@ietf.org --===============0084789957== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Clearly there seems to be no consensus on where the problem lies. That is my read of this thread. > It seems to me that all of these approaches have a key flaw in that > they leave the solution to be handled by a proprietary method of > defending against the attack. Solving the problem in the transport > layer would make the solution a standard one I think a key question here is whether we need a standard solution. If this were solved in a 'proprietary' manner, why would that be a big deal? I don't understand this notion that we need some sort of standard behavior here. Please explain. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHQZEqWyrrWs4yIs4RApKuAJ0cupHbmsBI4QxjpWLhLx8PP3WgvwCePo0e E2wQvHeo1O4q/6sWFcJjYok= =nQMz -----END PGP SIGNATURE----- --=_bOundary-- --===============0084789957== 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 --===============0084789957==-- From tcpm-bounces@ietf.org Mon Nov 19 08:38:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6pH-0000WF-HP; Mon, 19 Nov 2007 08:38:11 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iu6pF-0000Ua-F1 for tcpm-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 08:38:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6pF-0000UN-4a for tcpm@ietf.org; Mon, 19 Nov 2007 08:38:09 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu6pC-0000oc-Hu for tcpm@ietf.org; Mon, 19 Nov 2007 08:38:09 -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 lAJDc5Kj012096; Mon, 19 Nov 2007 05:38:05 -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 9E60212199C9; Mon, 19 Nov 2007 08:37:59 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A2CBE2F5CE0; Mon, 19 Nov 2007 08:35:29 -0500 (EST) To: Mahesh Jethanandani From: Mark Allman Subject: Re: [tcpm] Is this a problem? In-Reply-To: <472654F9.5030308@cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Who Made Who MIME-Version: 1.0 Date: Mon, 19 Nov 2007 08:35:29 -0500 Message-Id: <20071119133529.A2CBE2F5CE0@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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="===============1694300707==" Errors-To: tcpm-bounces@ietf.org --===============1694300707== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [catching up] > We have documented a case of HTTP servers that are prone to resource > starvation with the use of a small user level program. The program > does not require any special privileges or changes in the kernel. The > user level program on the client opens a connection to a HTTP server, > sends a GET request for a large file (larger than the advertised > window of the client) but never reads the response. > > Three well-known, public sites were tested for this vulnerability. The > two most common HTTP servers, Apache and IIS were the target. While > one site had put mitigation technique in place, the others had > none. With the latter two we were able to hold connections in > ESTABLISHED state for days. The former site had a mitigation in place > with a fixed timeout of 11 min., which was easy to guess and work > around. I want to try to understand these experiments. You used your program against public, well-known sites, right? I also assume you did this in a sort of "one at a time" fashion, right? That is, you didn't beat these web sites with a zillion of your test connections. Am I right here? If I read all this right then I don't understand how you can claim that two of the three sites used **no mitigation** for the problem you describe. It seems to me that they could well have a mitigation that kicks in when their resources are in high-demand (this is a resource contention problem after all) and your one "malicious" connection did not send them to that state. This, of course, may not be the case. But, I don't see how you can make the above claim. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD4DBQFHQZEhWyrrWs4yIs4RAvddAKCKv4gLtLv4MzKRN1KKiWouWdxlgQCYgl0G YFX+gvufq5NhFZa9hyuTfw== =VNXF -----END PGP SIGNATURE----- --=_bOundary-- --===============1694300707== 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 --===============1694300707==-- From tcpm-bounces@ietf.org Mon Nov 19 15:20:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuD6D-0001os-IK; Mon, 19 Nov 2007 15:20:05 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuD6B-0001oi-Hi for tcpm-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:20:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuD6B-0001oZ-1v for tcpm@ietf.org; Mon, 19 Nov 2007 15:20:03 -0500 Received: from web31701.mail.mud.yahoo.com ([68.142.201.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuD68-0001qp-Jl for tcpm@ietf.org; Mon, 19 Nov 2007 15:20:03 -0500 Received: (qmail 86902 invoked by uid 60001); 19 Nov 2007 20:20:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=As2Lh0/ecgFM0zUSdH8C/pYlxk8PY830YQPx/6XV3KX0ZRepyKbnx1IP+R4w+odltGXIRhREQmC9XO8jbbjBddyiQyIctsJ+6GxyAx6VLuJqa0HnB8CII3mUWy7e7pSu3a+W8r+jEFBKLEh4CZxVjmZvQaXlgGSqyeEvJ5HpbIc=; X-YMail-OSG: tTMZXokVM1l3gbaVu2a80EVeCBfpG9VjKTNtCypx6MAPq06fiweTKX5fKH9fjT3PvKIe_Lv.OuoCOW3K4CzkBPQVPk8K8ypcuH4zKXf1FSf1Xds- Received: from [69.3.29.18] by web31701.mail.mud.yahoo.com via HTTP; Mon, 19 Nov 2007 12:19:59 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157 Date: Mon, 19 Nov 2007 12:19:59 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? To: mallman@icir.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <25299.86272.qm@web31701.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org The problem directly stems from TCP's choice to persist indefinitely. It seems a very simple notion of allowing the application to be the master here (borrowing Joe's words :-)), and providing a ceiling on how long this behaviour will continue. This is fully in spirit with how the other TCP timers have evolved and added over the years. Now this alone does not address the requirements of a co-ordinated distributed DOS attack, but the point here is how long the connection should be allowed to (re)try sending data is purely an *application* decision i.e it MUST be under application control. It's a bad design to have an indefinite retry like this in the transport layer without providing an override to the app. This feature alone has value even in legitimate applications such as gaming where this override is desirable (non DOS scenario here). Do we believe this timeout is useful or not? If so, then this is no different than any other TCP timer, and standardizing it is a relevant discussion. To consider and extend this timeout for DoS scenarios, one must get into aspects of why 1. that timeout must be adaptive. 2. the scheme must be fair i.e an algorithm that penalizes persist state connections before penalizing connections that are experiencing transient or permanent network congestion is clearly superior to one that just does it purely based on the connection backlog. Murali ----- Original Message ---- From: Mark Allman To: MURALI BASHYAM Cc: John Heffner ; Mahesh Jethanandani ; tcpm@ietf.org Sent: Monday, November 19, 2007 5:35:38 AM Subject: Re: [tcpm] Is this a problem? > Clearly there seems to be no consensus on where the problem lies. That is my read of this thread. > It seems to me that all of these approaches have a key flaw in that > they leave the solution to be handled by a proprietary method of > defending against the attack. Solving the problem in the transport > layer would make the solution a standard one I think a key question here is whether we need a standard solution. If this were solved in a 'proprietary' manner, why would that be a big deal? I don't understand this notion that we need some sort of standard behavior here. Please explain. allman ____________________________________________________________________________________ Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 19 15:49:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDZ8-0007OF-V9; Mon, 19 Nov 2007 15:49:58 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuDZ7-0007O7-14 for tcpm-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:49:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDZ6-0007Nz-MM for tcpm@ietf.org; Mon, 19 Nov 2007 15:49:56 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuDZ6-00029U-5e for tcpm@ietf.org; Mon, 19 Nov 2007 15:49:56 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id lAJKniZe021990; Mon, 19 Nov 2007 12:49:45 -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 F0DF2121C9E6; Mon, 19 Nov 2007 15:49:39 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id CF8602F64A4; Mon, 19 Nov 2007 15:49:19 -0500 (EST) To: MURALI BASHYAM From: Mark Allman Subject: Re: [tcpm] Is this a problem? In-Reply-To: <25299.86272.qm@web31701.mail.mud.yahoo.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Who Made Who MIME-Version: 1.0 Date: Mon, 19 Nov 2007 15:49:19 -0500 Message-Id: <20071119204919.CF8602F64A4@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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="===============0894758832==" Errors-To: tcpm-bounces@ietf.org --===============0894758832== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > The problem directly stems from TCP's choice to persist > indefinitely. It seems a very simple notion of allowing the > application to be the master here (borrowing Joe's words :-)), and > providing a ceiling on how long this behaviour will continue. This is > fully in spirit with how the other TCP timers have evolved and added > over the years. Now this alone does not address the requirements of a > co-ordinated distributed DOS attack, but the point here is how long > the connection should be allowed to (re)try sending data is purely an > *application* decision i.e it MUST be under application control. It's > a bad design to have an indefinite retry like this in the transport > layer without providing an override to the app. I don't follow this line of thinking. Let's see ... + I don't know where we have added standard timers to TCP except where we have to (e.g., for time-wait or something). We basically add timers when the only things we can count on is the passage of time. + It doesn't seem to me a problem that a connection does this persist business indefinitely because both ends are consenting. It isn't like one end is silent or going away. + The application *is* in control. The application can close a connection whenever it wants to close a connection. Giving it a way to tell TCP when to kill a connection is a distinction without a difference. I don't think you answered my question in any way. Why do we have to standardize this? It seems to me that if some server wants to implement a policy that says "a connection can stay in zero window persist for 60 seconds" then great. Fine. I don't care. Might work fine for the use case of that server. Might cause problems for its connections. But, if that is its policy then wonderful. Who am I to say that is right or wrong? Change the policy and all that still applies. Seems perfectly consistent with lots of other things .... E.g., who am I to say which SYNs a TCP should accept? If they are from "bad" IPs and I want to drop them on the floor who are you to tell me I am wrong? E.g., who am I to say how many retransmits you should conduct before determining the peer is somehow gone and you give up? Why does this persist stuff need to be done in a standard fashion? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHQfbPWyrrWs4yIs4RAnovAJ9JiW5NmmfJA90nOT/D9JRo1/7uIACfay8Z abbZjopxxodA2cG7hoIGObg= =27o9 -----END PGP SIGNATURE----- --=_bOundary-- --===============0894758832== 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 --===============0894758832==-- From tcpm-bounces@ietf.org Mon Nov 19 17:25:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF3i-0008Pd-Rn; Mon, 19 Nov 2007 17:25:38 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuF3h-0008MC-IM for tcpm-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 17:25:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuF3h-0008M4-8Y for tcpm@ietf.org; Mon, 19 Nov 2007 17:25:37 -0500 Received: from [2001:5e8:2:42:2e0:81ff:fe30:e898] (helo=mailer2.psc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuF3g-0006ht-Ln for tcpm@ietf.org; Mon, 19 Nov 2007 17:25:37 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer2.psc.edu (8.14.1/8.13.3) with ESMTP id lAJMPVmZ007722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Nov 2007 17:25:34 -0500 (EST) Message-ID: <47420D5B.7070900@psc.edu> Date: Mon, 19 Nov 2007 17:25:31 -0500 From: John Heffner User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: toby.moncaster@bt.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: tcpm@ietf.org, bob.briscoe@bt.com Subject: [tcpm] Re: draft-moncaster-tcpm-rcv-cheat-02 probabilistic test 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 toby.moncaster@bt.com wrote: > > Hi John, > > When we originally wrote the test we did think that the increase in RTT > estimate might act as a strong enough disincentive to those receivers > that were actively seeking to misbehave. However we realised this > probably wasn't the case, especially given the relatively coarse > granularity of most TCP timers. We obviously need to update the draft to > reflect this. Our current view is that the main protection afforded by > this test is as follows: > > * Those receivers seeking to use optimistic acknowledgement are forced > to not use it as they may unwittingly optimistically acknowledge a > segment that was delayed. In turn they can't try and defeat the test in > the manner you suggest as this relies on them waiting for the data to > arrive before acknowledging (rather than acknowledging before it > arrives). Right. This works for detecting receivers doing optimistic acking. I'm concerned here only with receivers acking sequence numbers <= than the highest received. > * Those receivers that are seeking to conceal congestion losses must > have decided they don't need the missing data. This suggests either they > are streaming media off the sender or they are collaborating with the > sender. In the first instance I am not convinced it would be appropriate > for the sender to be performing the test as that may disrupt the > streaming (though more thought is needed here). In the second case the > sender and receiver are cooperating and so the sender would be unlikely > to want to challenge the conformance of the receiver. (Aside: There is a > subsidiary possibility which is that the receiver may be able to get the > missing data from some other source such as a parity file set on a > different server. This test can't overcome that possibility. The only > feasible defence then is to use cumulative nonces as described by Savage > et al in "TCP Congestion Control with a Misbehaving Receiver" > ) I think this is a pretty good explanation of why the opt-acking has not been a major practical problem. :) > Further to this the test also allows for occasional delays larger than > 6. If a receiver is actively seeking to defeat the test as above then it > will never be able to tell when a test is happening or when it is > natural re-ordering. In this case the receiver will get trapped into > sending a stream of duplicate acknowledgements to defeat the test when > in fact there was a genuine reordered segment. Thus it is not the actual > test that catches the receiver out but the natural behaviour that > underlies the test. The very existence of the test means a misbehaving > receiver is forced to assume any reordering is in fact a result of the > test (in order to defeat the test) and thus it is forced to respond to > all reordering as if it were a test thus making it compliant. I'm not sure I follow this. Assuming the sender ignores the SHOULD in the draft and delays more than 6, the misbehaving receiver can adjust its strategy accordingly. The worst case bound is doubling RTT at the receiver. For anything but an interactive flow, this is not likely a strong disincentive. I do not believe a receiver behaving in the manner I described -- delaying acknowledgements by some fixed amount (up to 1 RTT), sending appropriate dup-acks for reordered segments but acking lost segments as if they arrived -- is compliant, even though it responds to all reordering as if it were a test. Does this make sense, or am I missing something? An additional comment about the probabilistic test: It assumes that a compliant receiver sends dup-acks on every out-of-order segment. This behavior is unspecified in RFC793, a MAY in RFC1122, and changed to a SHOULD in RFC2581. Labeling receivers that don't obey the SHOULD in RFC2581 as "misbehaving" seems severe, and if such a test were widely deployed, is likely to lead to further ossification of TCP. I can imagine some scenarios where it may be useful to delay acknowledgement of out-of-order segments, particularly if you see persistent reordering. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 20 03:07:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuO8q-00086J-Cr; Tue, 20 Nov 2007 03:07:32 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuO8o-000868-Vh for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 03:07:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuO8j-0007z8-GM for tcpm@ietf.org; Tue, 20 Nov 2007 03:07:25 -0500 Received: from web31703.mail.mud.yahoo.com ([68.142.201.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuO8f-0002Mp-Sq for tcpm@ietf.org; Tue, 20 Nov 2007 03:07:25 -0500 Received: (qmail 89245 invoked by uid 60001); 20 Nov 2007 08:07:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=yJgm62mH/i97xheCGGG5z+QNj3MjcsMnnk7daKhj9wUzXYGjp2bSOJhH8mNzU3gz5ruHRG2pdryLH2VioyQGBlJujBKj2VOGH/x0j3LVlkTkNtPFeJNYV5Y0qxo+MMvF1jBczaGjzyrKpr3vv/FrQyJrHuyGDPFLXZB/V+xLDq4=; X-YMail-OSG: M59EG1cVM1nh45oYEIRfg4H.fROtvGDOd9konAflBbKpRXQM76oDr2rR9ZNSzwBx1MlnFBf_0rLNS4dnLtm3tIx.pO_mjGcNgd3W3ETBGvbZUgU- Received: from [67.161.9.166] by web31703.mail.mud.yahoo.com via HTTP; Tue, 20 Nov 2007 00:07:21 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157 Date: Tue, 20 Nov 2007 00:07:21 -0800 (PST) From: MURALI BASHYAM Subject: Re: [tcpm] Is this a problem? To: mallman@icir.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <299249.88905.qm@web31703.mail.mud.yahoo.com> 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 ----- Original Message ---- From: Mark Allman To: MURALI BASHYAM Cc: John Heffner ; Mahesh Jethanandani ; tcpm@ietf.org Sent: Monday, November 19, 2007 12:49:19 PM Subject: Re: [tcpm] Is this a problem? > The problem directly stems from TCP's choice to persist > indefinitely. It seems a very simple notion of allowing the > application to be the master here (borrowing Joe's words :-)), and > providing a ceiling on how long this behaviour will continue. This is > fully in spirit with how the other TCP timers have evolved and added > over the years. Now this alone does not address the requirements of a > co-ordinated distributed DOS attack, but the point here is how long > the connection should be allowed to (re)try sending data is purely an > *application* decision i.e it MUST be under application control. It's > a bad design to have an indefinite retry like this in the transport > layer without providing an override to the app. I don't follow this line of thinking. Let's see ... + I don't know where we have added standard timers to TCP except where we have to (e.g., for time-wait or something). We basically add timers when the only things we can count on is the passage of time. + It doesn't seem to me a problem that a connection does this persist business indefinitely because both ends are consenting. It isn't like one end is silent or going away. + The application *is* in control. The application can close a connection whenever it wants to close a connection. Giving it a way to tell TCP when to kill a connection is a distinction without a difference. Merely closing a connection does not accomplish things, the FIN will simply get queued behind existing data. What's required is an abort here for termination. But abort is a drastic action for the application which it cannot issue w/o some sort of explicit feedback from TCP... I don't think you answered my question in any way. Why do we have to standardize this? It seems to me that if some server wants to implement a policy that says "a connection can stay in zero window persist for 60 seconds" then great. Fine. I don't care. Might work fine for the use case of that server. Might cause problems for its connections. But, if that is its policy then wonderful. Who am I to say that is right or wrong? Change the policy and all that still applies. Seems perfectly consistent with lots of other things .... When and how does the application know that the connection entered and exited the persist condition? Where is the required feedback here? I am not aware of any... It seems like we are exporting a TCP specific state and knowledge all the way into the application to accomplish what seems a simple matter of starting a timer on entry into persist condition, stop on exit, abort on timeout (if specified by application). E.g., who am I to say which SYNs a TCP should accept? If they are from "bad" IPs and I want to drop them on the floor who are you to tell me I am wrong? E.g., who am I to say how many retransmits you should conduct before determining the peer is somehow gone and you give up? Why does this persist stuff need to be done in a standard fashion? Because zero window is a transport layer notion, and it is the responsibility of the transport layer to provide a robust and fair solution to this issue which benefits ALL applications instantaneously, at least that's the way i view it. Why does congestion control require standardization, when every client/server application out there is perfectly capable of doing it? To achieve consistent behaviour across the widest range of applications... allman ____________________________________________________________________________________ Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 20 07:13:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRyY-0003z5-8d; Tue, 20 Nov 2007 07:13:10 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuRyW-0003z0-JB for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 07:13:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRyW-0003ys-8E for tcpm@ietf.org; Tue, 20 Nov 2007 07:13:08 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuRyV-0000Ba-EI for tcpm@ietf.org; Tue, 20 Nov 2007 07:13:08 -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 lAKCD5tp013826; Tue, 20 Nov 2007 04:13:06 -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 1F4321223B62; Tue, 20 Nov 2007 07:13:00 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 740442F6E0C; Tue, 20 Nov 2007 07:12:38 -0500 (EST) To: MURALI BASHYAM From: Mark Allman Subject: Re: [tcpm] Is this a problem? In-Reply-To: <299249.88905.qm@web31703.mail.mud.yahoo.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Who Made Who MIME-Version: 1.0 Date: Tue, 20 Nov 2007 07:12:38 -0500 Message-Id: <20071120121238.740442F6E0C@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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="===============0454679474==" Errors-To: tcpm-bounces@ietf.org --===============0454679474== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline (hat off, clearly) > I don't follow this line of thinking. Let's see ... > > + I don't know where we have added standard timers to TCP except > where > we have to (e.g., for time-wait or something). We basically add > timers when the only things we can count on is the passage of time. > > + It doesn't seem to me a problem that a connection does this persist > business indefinitely because both ends are consenting. It isn't > like one end is silent or going away. > > + The application *is* in control. The application can close a > connection whenever it wants to close a connection. Giving it a > way > to tell TCP when to kill a connection is a distinction without a > difference. > > Merely closing a connection does not accomplish things, the FIN will > simply get queued behind existing data. What's required is an abort > here for termination. Yes- sorry for being overly glib in my language in the last bullet. You are right ... abort, not close. > But abort is a drastic action for the application which it cannot > issue w/o some sort of explicit feedback from TCP... I don't think so. I think applications care about getting data through the network. If they can't do it then they abort regardless. This has been said better by others, however. I recognize that we disagree here. > > I don't think you answered my question in any way. Why do we have to > > standardize this? It seems to me that if some server wants to > > implement a policy that says "a connection can stay in zero window > > persist for 60 seconds" then great. Fine. I don't care. Might work > > fine for the use case of that server. Might cause problems for its > > connections. But, if that is its policy then wonderful. Who am I to > > say that is right or wrong? Change the policy and all that still > > applies. Seems perfectly consistent with lots of other things .... > > When and how does the application know that the connection entered and > exited the persist condition? Where is the required feedback here? I > am not aware of any... It seems like we are exporting a TCP specific > state and knowledge all the way into the application to accomplish > what seems a simple matter of starting a timer on entry into persist > condition, stop on exit, abort on timeout (if specified by > application). I should have been more careful. I was thinking of this policy as a TCP or OS-level policy. Certainly it could be in the app, too---regardless of whether the app knows exactly why it has not made progress over some timescale that it cares about. Again, this is about *where* to standardize something and this has been argued better by others. I am more interested in the question of whether we even need to have the "where?" argument because I don't think we need to standardize it anywhere. (See below.) > > E.g., who am I to say which SYNs a TCP should accept? If they are > > from "bad" IPs and I want to drop them on the floor who are you to > > tell me I am wrong? > > > > E.g., who am I to say how many retransmits you should conduct > > before determining the peer is somehow gone and you give up? > > > > Why does this persist stuff need to be done in a standard fashion? > > Because zero window is a transport layer notion, and it is the > responsibility of the transport layer to provide a robust and fair > solution to this issue which benefits ALL applications > instantaneously, at least that's the way i view it. My view is that there need not be one true notion of "robust and fair". Why should their be? > Why does congestion control require standardization, when every > client/server application out there is perfectly capable of doing it? > To achieve consistent behaviour across the widest range of > applications... I think this is a complete mis-characterization. The answer is that congestion control is standardized because congestion control is about dealing with a *shared resource*. We can do that control from a number of places in the stack and people have advocated for each of them at different points. But, *where* that functionality exists is a second question after we establish that the functionality needs to exist and we need to standardize on it. This persist business is not about controlling a shared resource, but about controlling a *local resource*. Why should the community standardize local resource control? That seems absurd to me. So, to me, arguing about where to mitigate the persist stuff is putting the cart before the horse. First, we'd need to establish some reason to standardize local resource control. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHQs82WyrrWs4yIs4RArslAJ96s9hcZnQlUav2064WLN3UPjeGrgCfeKD5 2pOy6Ha807pA7xGMJzKFtEg= =Hrs7 -----END PGP SIGNATURE----- --=_bOundary-- --===============0454679474== 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 --===============0454679474==-- From tcpm-bounces@ietf.org Tue Nov 20 17:01:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iub9i-0000mj-Io; Tue, 20 Nov 2007 17:01:18 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iub9h-0000mb-ER for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 17:01:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iub9g-0000mT-O0 for tcpm@ietf.org; Tue, 20 Nov 2007 17:01:16 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iub9c-0004R6-J8 for tcpm@ietf.org; Tue, 20 Nov 2007 17:01:16 -0500 X-IronPort-AV: E=Sophos;i="4.21,443,1188770400"; d="scan'208";a="158306998" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2007 23:01:11 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAKM1B7X001735; Tue, 20 Nov 2007 23:01:11 +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 lAKM1BUm004796; Tue, 20 Nov 2007 22:01:11 GMT Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4559.cisco.com [10.61.81.206]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA05926; Tue, 20 Nov 2007 22:01:10 GMT Message-Id: <200711202201.WAA05926@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2007 22:01:07 +0000 To: mallman@icir.org, MURALI BASHYAM From: Lloyd Wood Subject: Re: [tcpm] Is this a problem? In-Reply-To: <20071120121238.740442F6E0C@lawyers.icir.org> References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-1; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 20/11/2007 07:12 -0500, Mark Allman wrote: >> Why does congestion control require standardization, when every >> client/server application out there is perfectly capable of doing it? >> To achieve consistent behaviour across the widest range of >> applications... > >I think this is a complete mis-characterization. The answer is that >congestion control is standardized because congestion control is about >dealing with a *shared resource*. We can do that control from a number >of places in the stack and people have advocated for each of them at >different points. But, *where* that functionality exists is a second >question after we establish that the functionality needs to exist and we >need to standardize on it. This persist business is not about >controlling a shared resource, but about controlling a *local >resource*. Why should the community standardize local resource control? The community standardised TCP window size advertisements. That's a local resource control issue, surely? >That seems absurd to me. So, to me, arguing about where to mitigate the >persist stuff is putting the cart before the horse. First, we'd need to >establish some reason to standardize local resource control. because it's useful? L. Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 20 19:02:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iud2Y-0000yg-P4; Tue, 20 Nov 2007 19:02:02 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iud2X-0000yY-Rf for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:02:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iud2X-0000yQ-8R for tcpm@ietf.org; Tue, 20 Nov 2007 19:02:01 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iud2T-0000gj-Re for tcpm@ietf.org; Tue, 20 Nov 2007 19:02:01 -0500 Received: from [75.215.105.196] (196.sub-75-215-105.myvzw.com [75.215.105.196]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAL01Snj004393; Tue, 20 Nov 2007 16:01:29 -0800 (PST) Message-ID: <47437551.7020205@isi.edu> Date: Tue, 20 Nov 2007 16:01:21 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lloyd Wood Subject: Re: [tcpm] Is this a problem? References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> In-Reply-To: <200711202201.WAA05926@cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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="===============1686055676==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1686055676== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA966E4B709A162F857C315D2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA966E4B709A162F857C315D2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lloyd Wood wrote: > At Tuesday 20/11/2007 07:12 -0500, Mark Allman wrote: >=20 >>> Why does congestion control require standardization, when every >>> client/server application out there is perfectly capable of doing it?= >>> To achieve consistent behaviour across the widest range of >>> applications... >> I think this is a complete mis-characterization. The answer is that >> congestion control is standardized because congestion control is about= >> dealing with a *shared resource*. We can do that control from a numbe= r >> of places in the stack and people have advocated for each of them at >> different points. But, *where* that functionality exists is a second >> question after we establish that the functionality needs to exist and = we >> need to standardize on it. This persist business is not about >> controlling a shared resource, but about controlling a *local >> resource*. Why should the community standardize local resource contro= l? >=20 > The community standardised TCP window size advertisements. That's a loc= al resource control issue, surely? That's something you have to tell the other end, i.e., it requires a change to the protocol on the wire. This one can be implemented without any change to the protocol at all - entirely at the app layer. >> That seems absurd to me. So, to me, arguing about where to mitigate t= he >> persist stuff is putting the cart before the horse. First, we'd need = to >> establish some reason to standardize local resource control. >=20 > because it's useful? Useful is a fine metric for a new protocol, not for mucking with such a ubiquitous and established one unnecessarily, IMO. Joe --------------enigA966E4B709A162F857C315D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQ3VRE5f5cImnZrsRAstzAKDbBTHuKXY9VeJJ3u/arGfbff674wCgg+AS D9ky04jF/ZNkMz/kLYiO3fo= =F1L/ -----END PGP SIGNATURE----- --------------enigA966E4B709A162F857C315D2-- --===============1686055676== 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 --===============1686055676==-- From tcpm-bounces@ietf.org Tue Nov 20 19:25:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudP3-0000Z5-NT; Tue, 20 Nov 2007 19:25:17 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IudP2-0000WA-KM for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:25:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudP2-0000W2-9W for tcpm@ietf.org; Tue, 20 Nov 2007 19:25:16 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IudP1-0003az-RB for tcpm@ietf.org; Tue, 20 Nov 2007 19:25: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 lAL0PE63029796; Tue, 20 Nov 2007 16:25:15 -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 A7F291229CB6; Tue, 20 Nov 2007 19:25:04 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5A95C2F8228; Tue, 20 Nov 2007 18:10:00 -0500 (EST) To: Lloyd Wood From: Mark Allman Subject: Re: [tcpm] Is this a problem? In-Reply-To: <200711202201.WAA05926@cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Walk on the Wild Side MIME-Version: 1.0 Date: Tue, 20 Nov 2007 18:10:00 -0500 Message-Id: <20071120231000.5A95C2F8228@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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="===============2071769356==" Errors-To: tcpm-bounces@ietf.org --===============2071769356== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Lloyd- > >I think this is a complete mis-characterization. The answer is that > >congestion control is standardized because congestion control is > >about dealing with a *shared resource*. We can do that control from > >a number of places in the stack and people have advocated for each of > >them at different points. But, *where* that functionality exists is > >a second question after we establish that the functionality needs to > >exist and we need to standardize on it. This persist business is not > >about controlling a shared resource, but about controlling a *local > >resource*. Why should the community standardize local resource > >control? > > The community standardised TCP window size advertisements. That's a > local resource control issue, surely? The community has not standardized TCP window size advertisements. And, you know it. The community has standardized an encoding to allow the end points of a TCP connection to exchange information. What is your point? > >That seems absurd to me. So, to me, arguing about where to mitigate > >the persist stuff is putting the cart before the horse. First, we'd > >need to establish some reason to standardize local resource control. > > because it's useful? We disagree on that point. I certainly can understand that connections consume local resources and this is something that a system (OS, TCP, app, whatever) will want to control. But, I don't agree that we can determine one global definition of "useful" local resource control that will hold for everyone. Should we tell Cisco how to allocate socket buffers while we're at it? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHQ2lIWyrrWs4yIs4RAgfbAJ438tSHI/nsbwsV6uQYvIU9sCIOegCdHl5J 6iJsDnG9FSlIEaZf/ifgvqM= =cPn3 -----END PGP SIGNATURE----- --=_bOundary-- --===============2071769356== 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 --===============2071769356==-- From tcpm-bounces@ietf.org Tue Nov 20 19:46:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudjJ-0002hz-7H; Tue, 20 Nov 2007 19:46:13 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IudjH-0002g3-R5 for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:46:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudjH-0002fv-Ha for tcpm@ietf.org; Tue, 20 Nov 2007 19:46:11 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IudjE-0001p6-1H for tcpm@ietf.org; Tue, 20 Nov 2007 19:46:11 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 20 Nov 2007 16:46:07 -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 lAL0k7qo020071; Tue, 20 Nov 2007 16:46:07 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAL0k7Gc017998; Wed, 21 Nov 2007 00:46:07 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA03912; Tue, 20 Nov 2007 16:44:27 -0800 (PST) Date: Tue, 20 Nov 2007 16:44:27 -0800 From: Chandrashekhar Appanna To: Joe Touch Subject: Re: [tcpm] Is this a problem? Message-ID: <20071121004427.GI26548@cisco.com> References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47437551.7020205@isi.edu> User-Agent: Mutt/1.4i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2529; t=1195605967; x=1196469967; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=3CstJxXZ/bPFkalpv+snsCz1yuNXExGbUyktT6bRn5A=; b=SErrowFrdPKkdQ4a8p/o0t+jYffWecXGUMjpkKtY4yfM9T5s4NjMf0GMvdee8KSe4sStA/WG yXcLuwpmeFEW+f/33J0jCBLD8puBCD1nUS2WqAMP/Y1zm3IcMQz3/+0h; Authentication-Results: sj-dkim-4; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: tcpm@ietf.org, Lloyd Wood , 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 Tue, Nov 20, 2007 at 04:01:21PM -0800, Joe Touch wrote: > > > Lloyd Wood wrote: > > At Tuesday 20/11/2007 07:12 -0500, Mark Allman wrote: > > > >>> Why does congestion control require standardization, when every > >>> client/server application out there is perfectly capable of doing it? > >>> To achieve consistent behaviour across the widest range of > >>> applications... > >> I think this is a complete mis-characterization. The answer is that > >> congestion control is standardized because congestion control is about > >> dealing with a *shared resource*. We can do that control from a number > >> of places in the stack and people have advocated for each of them at > >> different points. But, *where* that functionality exists is a second > >> question after we establish that the functionality needs to exist and we > >> need to standardize on it. This persist business is not about > >> controlling a shared resource, but about controlling a *local > >> resource*. Why should the community standardize local resource control? > > > > The community standardised TCP window size advertisements. That's a local resource control issue, surely? > > That's something you have to tell the other end, i.e., it requires a > change to the protocol on the wire. This one can be implemented without > any change to the protocol at all - entirely at the app layer. > And I think the authors are positioning that there is a better place in the architecture to solve this and that is in tcp. I think it is boiling down to just a matter of opinions so far.. esp when you keep repeating that it could be solved in the app layer (for as long as I recall!!) > >> That seems absurd to me. So, to me, arguing about where to mitigate the > >> persist stuff is putting the cart before the horse. First, we'd need to > >> establish some reason to standardize local resource control. > > > > because it's useful? > > Useful is a fine metric for a new protocol, not for mucking with such a > ubiquitous and established one unnecessarily, IMO. > I do not understand that line of reasoning at all.. I think the point was that it could be useful to tcp.. not to some new protocol. I think the discussion has to be around that point only.. last I checked this was the tcp m mailing list. - Chandra. > 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 Tue Nov 20 20:11:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iue7d-0004XI-O1; Tue, 20 Nov 2007 20:11:21 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iue7b-0004GY-J9 for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 20:11:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iue7a-00049M-Ru for tcpm@ietf.org; Tue, 20 Nov 2007 20:11:18 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iue7X-0002ZQ-Lx for tcpm@ietf.org; Tue, 20 Nov 2007 20:11:18 -0500 Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iue7R-000HhW-2M for tcpm@ietf.org; Wed, 21 Nov 2007 01:11:15 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 940C72BE21 for ; Tue, 20 Nov 2007 20:11:06 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id A61F82840D; Tue, 20 Nov 2007 20:11:05 -0500 (EST) Date: Tue, 20 Nov 2007 20:11:05 -0500 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? Message-ID: <20071121011105.GQ5881@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> <20071121004427.GI26548@cisco.com> MIME-Version: 1.0 In-Reply-To: <20071121004427.GI26548@cisco.com> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -102.7 (---------------------------------------------------) X-Spam-Score: -4.0 (----) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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="===============0153459591==" Errors-To: tcpm-bounces@ietf.org --===============0153459591== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="glwmnIOgU1tcuP7N" Content-Disposition: inline --glwmnIOgU1tcuP7N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Chandrashekhar Appanna spake unto us the following wisdom: > On Tue, Nov 20, 2007 at 04:01:21PM -0800, Joe Touch wrote: > > Lloyd Wood wrote: > > > The community standardised TCP window size advertisements. That's a > > > local resource control issue, surely? > >=20 > > That's something you have to tell the other end, i.e., it requires a > > change to the protocol on the wire. This one can be implemented without > > any change to the protocol at all - entirely at the app layer. >=20 > And I think the authors are positioning that there is a better place > in the architecture to solve this and that is in tcp. I think it is > boiling down to just a matter of opinions so far.. esp when you keep > repeating that it could be solved in the app layer (for as long as I > recall!!) Joe keeps making this point because it is _very important_. Any feature which can be accomplished at Layer N can be accomplished at Layer N - 1, and vice-versa. However, the Internet protocols have enjoyed tremendous success and longevity in part because they resist the urge to push application and other high-layer semantics into the lower layers. > > Useful is a fine metric for a new protocol, not for mucking with such a > > ubiquitous and established one unnecessarily, IMO. >=20 > I do not understand that line of reasoning at all.. I think the point > was that it could be useful to tcp.. not to some new protocol. I think > the discussion has to be around that point only.. last I checked this > was the tcp m mailing list. "Unnecessarily" is an important word in that statement, which you did not address. The question has never been "can this be done in TCP", it is rather, "should this be done in TCP?" For my own part, I have not yet seen a reason why application layer timeouts are not a reasonable solution to this problem, or even the _correct_ solution to this problem, because only the application knows how much progress is "sufficient" progress, and as such I cannot see driving this feature into the TCP _standards_. I also, however, see no reason why some particular TCP stack could not provide a socket tunable for persist timeout, if sufficient userspace demand were present. 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 --glwmnIOgU1tcuP7N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHQ4Wpr9kA9Ig8HBQRAoT9AKCgqAQppyFSje1CoOhBSRSezmSQ0QCgvlXp mLMzSuD3fFbAFfJYWZJ6mGQ= =1wV/ -----END PGP SIGNATURE----- --glwmnIOgU1tcuP7N-- --===============0153459591== 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 --===============0153459591==-- From tcpm-bounces@ietf.org Tue Nov 20 20:48:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuehc-00062W-7x; Tue, 20 Nov 2007 20:48:32 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iueha-0005nj-BA for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 20:48:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iueha-0005ld-0Y for tcpm@ietf.org; Tue, 20 Nov 2007 20:48:30 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuehV-0003ad-UD for tcpm@ietf.org; Tue, 20 Nov 2007 20:48:29 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 20 Nov 2007 17:48:25 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAL1mPjx005521 for ; Tue, 20 Nov 2007 17:48:25 -0800 Received: from [171.69.75.93] (dhcp-171-69-75-93.cisco.com [171.69.75.93]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAL1mPGc000826 for ; Wed, 21 Nov 2007 01:48:25 GMT Message-ID: <47438E69.5060701@cisco.com> Date: Tue, 20 Nov 2007 17:48:25 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> <20071121004427.GI26548@cisco.com> <20071121011105.GQ5881@elb.elitists.net> In-Reply-To: <20071121011105.GQ5881@elb.elitists.net> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6315; t=1195609705; x=1196473705; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=Mit0CI6qqyC0XmCw0TDRasN5XvuxuwSi14hOy3qdJEk=; b=ongyQ9/t+RCzooY7TjgYRo8yzud0Ka1i1KwIx+0H2kFJxsFoL3ZWQ3kM7mxE8TSdjUL5TYhu qTPOzqxgWXxdPje05yqVjivHjuaSDEtwIWJlaH6E/484lUijZg/meWOs; Authentication-Results: sj-dkim-3; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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="===============1164088386==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============1164088386== Content-Type: multipart/alternative; boundary="------------080103060604080006000807" This is a multi-part message in MIME format. --------------080103060604080006000807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ethan Blanton wrote: >> And I think the authors are positioning that there is a better place >> in the architecture to solve this and that is in tcp. I think it is >> boiling down to just a matter of opinions so far.. esp when you keep >> repeating that it could be solved in the app layer (for as long as I >> recall!!) >> > > Joe keeps making this point because it is _very important_. Any > feature which can be accomplished at Layer N can be accomplished at > Layer N - 1, and vice-versa. However, the Internet protocols have > enjoyed tremendous success and longevity in part because they resist > the urge to push application and other high-layer semantics into the > lower layers. > But in case of congestion control it was felt that it would be done better in TCP. Why? After all nothing stopped applications from implementing congestion control. > >>> Useful is a fine metric for a new protocol, not for mucking with such a >>> ubiquitous and established one unnecessarily, IMO. >>> >> I do not understand that line of reasoning at all.. I think the point >> was that it could be useful to tcp.. not to some new protocol. I think >> the discussion has to be around that point only.. last I checked this >> was the tcp m mailing list. >> > > "Unnecessarily" is an important word in that statement, which you did > not address. The question has never been "can this be done in TCP", > it is rather, "should this be done in TCP?" > > For my own part, I have not yet seen a reason why application layer > timeouts are not a reasonable solution to this problem, or even the > _correct_ solution to this problem, because only the application knows > how much progress is "sufficient" progress, and as such I cannot see > driving this feature into the TCP _standards_. I also, however, see > no reason why some particular TCP stack could not provide a socket > tunable for persist timeout, if sufficient userspace demand were > present. > We give reasons as to why a timeout in application will not work. For one, a fixed timeout is easy to defeat. If you are not proposing a fixed timeout, what kind of timeout are you proposing? Is it going to be based on that applications view of how many buffers it is holding on to? What if that application is not the problem, but some other application is? What if the other application does not even bother about connections in persist condition. The problem is also that the resources in question are TCP resources and applications have a snapshot of the problem from their connection point of view. They do not see the problem that TCP is seeing. --------------080103060604080006000807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Ethan Blanton wrote: 
And I think the authors are positioning that there is a better place
in the architecture to solve this and that is in tcp. I think it is
boiling down to just a matter of opinions so far.. esp when you keep
repeating that it could be solved in the app layer (for as long as I
recall!!)
    

Joe keeps making this point because it is _very important_.  Any
feature which can be accomplished at Layer N can be accomplished at
Layer N - 1, and vice-versa.  However, the Internet protocols have
enjoyed tremendous success and longevity in part because they resist
the urge to push application and other high-layer semantics into the
lower layers.
But  in case of congestion control it was felt that it would be done better in TCP. Why? After all nothing stopped applications from implementing congestion control.
  
Useful is a fine metric for a new protocol, not for mucking with such a
ubiquitous and established one unnecessarily, IMO.
      
I do not understand that line of reasoning at all.. I think the point
was that it could be useful to tcp.. not to some new protocol. I think
the discussion has to be around that point only.. last I checked this
was the tcp m mailing list.
    

"Unnecessarily" is an important word in that statement, which you did
not address.  The question has never been "can this be done in TCP",
it is rather, "should this be done in TCP?"

For my own part, I have not yet seen a reason why application layer
timeouts are not a reasonable solution to this problem, or even the
_correct_ solution to this problem, because only the application knows
how much progress is "sufficient" progress, and as such I cannot see
driving this feature into the TCP _standards_.  I also, however, see
no reason why some particular TCP stack could not provide a socket
tunable for persist timeout, if sufficient userspace demand were
present.
We give reasons as to why a timeout in application will not work. For one, a fixed timeout is easy to defeat. If you are not proposing a fixed timeout, what kind of timeout are you proposing? Is it going to be based on that applications view of how many buffers it is holding on to? What if that application is not the problem, but some other application is? What if the other application does not even bother about connections in persist condition.

The problem is also that the resources in question are TCP resources and applications have a snapshot of the problem from their connection point of view. They do not see the problem that TCP is seeing.


--------------080103060604080006000807-- --===============1164088386== 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 --===============1164088386==-- From tcpm-bounces@ietf.org Tue Nov 20 20:57:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iueqb-0000Ip-1f; Tue, 20 Nov 2007 20:57:49 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IueqZ-0000IS-B4 for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 20:57:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IueqZ-0000IK-0I for tcpm@ietf.org; Tue, 20 Nov 2007 20:57:47 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IueqY-0006E3-Hk for tcpm@ietf.org; Tue, 20 Nov 2007 20:57:46 -0500 Received: from [75.215.105.196] (196.sub-75-215-105.myvzw.com [75.215.105.196]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAL1vTqw003427; Tue, 20 Nov 2007 17:57:31 -0800 (PST) Message-ID: <47439080.6050704@isi.edu> Date: Tue, 20 Nov 2007 17:57:20 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Chandrashekhar Appanna Subject: Re: [tcpm] Is this a problem? References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> <20071121004427.GI26548@cisco.com> In-Reply-To: <20071121004427.GI26548@cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tcpm@ietf.org, Lloyd Wood , 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="===============0800686058==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0800686058== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0BFAF9086B7DC6E25594416B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0BFAF9086B7DC6E25594416B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Chandrashekhar Appanna wrote: > On Tue, Nov 20, 2007 at 04:01:21PM -0800, Joe Touch wrote: =2E.. >>> The community standardised TCP window size advertisements. That's a l= ocal resource control issue, surely? >> That's something you have to tell the other end, i.e., it requires a >> change to the protocol on the wire. This one can be implemented withou= t >> any change to the protocol at all - entirely at the app layer. >=20 > And I think the authors are positioning that there is a better place = in > the architecture to solve this and that is in tcp. I think it is boil= ing > down to just a matter of opinions so far.. esp when you keep repeatin= g > that it could be solved in the app layer (for as long as I recall!!) First, the argument above is that this is like standardizing TCP window advertisements. Second, the original argument was that this wasn't solvable at the app layer. The rationale changes and the arguments persists. That's useful to note, = IMO >>>> That seems absurd to me. So, to me, arguing about where to mitigate= the >>>> persist stuff is putting the cart before the horse. First, we'd nee= d to >>>> establish some reason to standardize local resource control. >>> because it's useful? >> >> Useful is a fine metric for a new protocol, not for mucking with such = a >> ubiquitous and established one unnecessarily, IMO. >=20 > I do not understand that line of reasoning at all.. I think the point= > was that it could be useful to tcp.. not to some new protocol. TCP doesn't need this; users do. TCP doesn't care about hanging around - or transmitting data very slowly. Some people call both a feature. Joe --------------enig0BFAF9086B7DC6E25594416B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQ5CAE5f5cImnZrsRAmbMAKDLorG9A8ZnW4HQhQQpuNEdQVi6NgCfQ98K sAPPfZr1zc8uWq0xHx+z79U= =8RO3 -----END PGP SIGNATURE----- --------------enig0BFAF9086B7DC6E25594416B-- --===============0800686058== 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 --===============0800686058==-- From tcpm-bounces@ietf.org Tue Nov 20 21:42:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IufXz-000525-Fh; Tue, 20 Nov 2007 21:42:39 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IufXy-000520-6l for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 21:42:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IufXx-00051q-SJ for tcpm@ietf.org; Tue, 20 Nov 2007 21:42:37 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IufXx-0007YK-8d for tcpm@ietf.org; Tue, 20 Nov 2007 21:42:37 -0500 Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IufXq-000Nwh-I4 for tcpm@ietf.org; Wed, 21 Nov 2007 02:42:36 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 9C6362BE21 for ; Tue, 20 Nov 2007 21:42:27 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 965FC2840D; Tue, 20 Nov 2007 21:42:26 -0500 (EST) Date: Tue, 20 Nov 2007 21:42:26 -0500 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? Message-ID: <20071121024226.GR5881@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> <20071121004427.GI26548@cisco.com> <20071121011105.GQ5881@elb.elitists.net> <47438E69.5060701@cisco.com> MIME-Version: 1.0 In-Reply-To: <47438E69.5060701@cisco.com> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -102.6 (---------------------------------------------------) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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="===============1325593164==" Errors-To: tcpm-bounces@ietf.org --===============1325593164== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eyYj78xbwv+yMvU1" Content-Disposition: inline --eyYj78xbwv+yMvU1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani spake unto us the following wisdom: > Ethan Blanton wrote: > >Joe keeps making this point because it is _very important_. Any > >feature which can be accomplished at Layer N can be accomplished at > >Layer N - 1, and vice-versa. However, the Internet protocols have > >enjoyed tremendous success and longevity in part because they resist > >the urge to push application and other high-layer semantics into the > >lower layers. > > But in case of congestion control it was felt that it would be done=20 > better in TCP. Why? After all nothing stopped applications from=20 > implementing congestion control. This has been answered several times; it's not clear to me that you are actually reading the responses to your emails. Congestion control is important for the preservation _shared resources_. Mistakes in congestion control lead to problems on somebody else's network. The timer you are asking for is a change which affects only _local resources_, and its disposition will have little or no effect on others. Congestion control was determined, by the community, to be both important and tricky enough that it should be solveld in one place (or a very small number of places), and shared among applications. It appears that there is not consensus that a persist timer tunable has impact which is anywhere near similar. If you are trying to suggest that stale sockets in zero window probing are anywhere near the impact of congestion control, I find your argument disingenuous. > >For my own part, I have not yet seen a reason why application layer > >timeouts are not a reasonable solution to this problem, or even the > >_correct_ solution to this problem, because only the application knows > >how much progress is "sufficient" progress, and as such I cannot see > >driving this feature into the TCP _standards_. I also, however, see > >no reason why some particular TCP stack could not provide a socket > >tunable for persist timeout, if sufficient userspace demand were > >present. > > We give reasons as to why a timeout in application will not work. For=20 > one, a fixed timeout is easy to defeat. If you are not proposing a fixed= =20 > timeout, what kind of timeout are you proposing? Is it going to be based= =20 > on that applications view of how many buffers it is holding on to? What= =20 > if that application is not the problem, but some other application is?=20 > What if the other application does not even bother about connections in= =20 > persist condition. I don't follow this, for several reasons. What do you mean, a fixed timeout is easy to defeat? You're *asking* for a timeout which can be set on zero window probing, are you not? Regarding your final statement, are you suggesting that application A should be able to tell the operating system that application B's sockets should time out if they are in a persist state? None of this makes any sense to me. > The problem is also that the resources in question are TCP resources and= =20 > applications have a snapshot of the problem from their connection point= =20 > of view. They do not see the problem that TCP is seeing. We fundamentally disagree on this; Joe pointed out that you _can_ indeed know whether or not a TCP connection is open or closed, by way of blocking calls and appropriate twiddling of SO_LINGER. The application therefore knows exactly how many sockets it is using, and can be tuned appropriately. I don't see what you think kernel space can accomplish, that user space cannot. 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 --eyYj78xbwv+yMvU1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHQ5sRr9kA9Ig8HBQRAmy2AKCw5XZeWWfu57Z8Ok8D0GrsZm1xdACfQpCA uDNvLZRzyziHjOcwwuntc7c= =ASZv -----END PGP SIGNATURE----- --eyYj78xbwv+yMvU1-- --===============1325593164== 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 --===============1325593164==-- From tcpm-bounces@ietf.org Tue Nov 20 22:16:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iug4F-0008A5-Mq; Tue, 20 Nov 2007 22:15:59 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iug4E-00089x-GE for tcpm-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 22:15:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iug4E-00089p-6S for tcpm@ietf.org; Tue, 20 Nov 2007 22:15:58 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iug47-0005jH-39 for tcpm@ietf.org; Tue, 20 Nov 2007 22:15:58 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Nov 2007 19:15:50 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAL3FoVL007643 for ; Tue, 20 Nov 2007 19:15:50 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAL3FnUV011470 for ; Wed, 21 Nov 2007 03:15:49 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA27672 for tcpm@ietf.org; Tue, 20 Nov 2007 19:14:10 -0800 (PST) Date: Tue, 20 Nov 2007 19:14:10 -0800 From: Chandrashekhar Appanna To: tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? Message-ID: <20071121031410.GJ26548@cisco.com> References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> <20071121004427.GI26548@cisco.com> <20071121011105.GQ5881@elb.elitists.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071121011105.GQ5881@elb.elitists.net> User-Agent: Mutt/1.4i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3272; t=1195614950; x=1196478950; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=u4jA0Xe3QL41pgcEz+LeZzFbYhoGNhbDnS3dKJaJndw=; b=ucvhNQGk4z5+hT4KgJBu/LjncKMpBm2MUX+okey9CkcD2DUVnJAT3p4e8gimMRsScRAqqWmF 2cjxChfH7xb4IWVRLkZVmnEnPwXL4BCr5u7BLmJSiCE6wJYRcGXOAX4V; Authentication-Results: sj-dkim-2; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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, Nov 20, 2007 at 08:11:05PM -0500, Ethan Blanton wrote: > Chandrashekhar Appanna spake unto us the following wisdom: > > On Tue, Nov 20, 2007 at 04:01:21PM -0800, Joe Touch wrote: > > > Lloyd Wood wrote: > > > > The community standardised TCP window size advertisements. That's a > > > > local resource control issue, surely? > > > > > > That's something you have to tell the other end, i.e., it requires a > > > change to the protocol on the wire. This one can be implemented without > > > any change to the protocol at all - entirely at the app layer. > > > > And I think the authors are positioning that there is a better place > > in the architecture to solve this and that is in tcp. I think it is > > boiling down to just a matter of opinions so far.. esp when you keep > > repeating that it could be solved in the app layer (for as long as I > > recall!!) > > Joe keeps making this point because it is _very important_. Any > feature which can be accomplished at Layer N can be accomplished at > Layer N - 1, and vice-versa. However, the Internet protocols have > enjoyed tremendous success and longevity in part because they resist > the urge to push application and other high-layer semantics into the > lower layers. > And still it is a matter of opinion as to which layer should have what beyond a point of debate. Lot of the current model has also historical significance that we try to justify now with good language and architecture. But I do not disagree with your point but the repetition, to me, means that we are stuck at a stalemate and that is not interesting.. > > > Useful is a fine metric for a new protocol, not for mucking with such a > > > ubiquitous and established one unnecessarily, IMO. > > > > I do not understand that line of reasoning at all.. I think the point > > was that it could be useful to tcp.. not to some new protocol. I think > > the discussion has to be around that point only.. last I checked this > > was the tcp m mailing list. > > "Unnecessarily" is an important word in that statement, which you did > not address. The question has never been "can this be done in TCP", I think useful to me is still a fine metric even for tcp and therefore I stopped there. 0.02, Chandra. > it is rather, "should this be done in TCP?" > > For my own part, I have not yet seen a reason why application layer > timeouts are not a reasonable solution to this problem, or even the > _correct_ solution to this problem, because only the application knows > how much progress is "sufficient" progress, and as such I cannot see > driving this feature into the TCP _standards_. I also, however, see > no reason why some particular TCP stack could not provide a socket > tunable for persist timeout, if sufficient userspace demand were > present. > > Ethan > > -- > 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 > _______________________________________________ > 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 21 00:00:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuhh1-0007hX-Tb; Wed, 21 Nov 2007 00:00:07 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iuhh0-0007gS-Nl for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 00:00:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuhgz-0007aM-7k for tcpm@ietf.org; Wed, 21 Nov 2007 00:00:05 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuhgy-0002zA-Mp for tcpm@ietf.org; Wed, 21 Nov 2007 00:00:05 -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 lAL5038m001193; Tue, 20 Nov 2007 21:00:03 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 60CB6122B35B; Tue, 20 Nov 2007 23:59:58 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7F8592F8AFA; Tue, 20 Nov 2007 23:59:35 -0500 (EST) To: Chandrashekhar Appanna From: Mark Allman Subject: Re: [tcpm] Is this a problem? In-Reply-To: <20071121031410.GJ26548@cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Walk on the Wild Side MIME-Version: 1.0 Date: Tue, 20 Nov 2007 23:59:35 -0500 Message-Id: <20071121045935.7F8592F8AFA@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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="===============1455866856==" Errors-To: tcpm-bounces@ietf.org --===============1455866856== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > Joe keeps making this point because it is _very important_. Any > > feature which can be accomplished at Layer N can be accomplished at > > Layer N - 1, and vice-versa. However, the Internet protocols have > > enjoyed tremendous success and longevity in part because they resist > > the urge to push application and other high-layer semantics into the > > lower layers. > > And still it is a matter of opinion as to which layer should have > what beyond a point of debate. Lot of the current model has also > historical significance that we try to justify now with good > language and architecture. But I do not disagree with your point > but the repetition, to me, means that we are stuck at a stalemate > and that is not interesting.. I agree with both Ethan's notes about the principles behind the decisions. But, I think you are right that there is also an element of design style to these decisions. What I really want to do here is to agree with your last bit. We are spinning here. It is not the first time we have gone in circles on this draft. As far as I can tell this document has nearly no support in this WG. I don't want to cut-off discussion if folks have something new to add. But, most of the stuff (mine included) posted is just re-hash. So, I would like to ask folks to quit saying what they have said before. New points are welcome. OK? allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHQ7s3WyrrWs4yIs4RAokBAKCK7B6twnx6JEtOuQC82HFqYKMDTwCeIE04 35CV0gznaj0qUEhWz/yEP4c= =cAux -----END PGP SIGNATURE----- --=_bOundary-- --===============1455866856== 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 --===============1455866856==-- From tcpm-bounces@ietf.org Wed Nov 21 00:20:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iui0s-0001Ca-NX; Wed, 21 Nov 2007 00:20:38 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iui0r-00013Q-5A for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 00:20:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iui0q-00012l-RH for tcpm@ietf.org; Wed, 21 Nov 2007 00:20:36 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iui0m-0000YF-F9 for tcpm@ietf.org; Wed, 21 Nov 2007 00:20:36 -0500 X-IronPort-AV: E=Sophos;i="4.21,444,1188770400"; d="scan'208";a="158323733" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2007 06:20:32 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAL5KVRt005852; Wed, 21 Nov 2007 06:20:31 +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 lAL5KVUm018549; Wed, 21 Nov 2007 05:20:31 GMT Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4559.cisco.com [10.61.81.206]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id FAA29441; Wed, 21 Nov 2007 05:20:29 GMT Message-Id: <200711210520.FAA29441@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Nov 2007 05:17:54 +0000 To: Joe Touch , Chandrashekhar Appanna From: Lloyd Wood Subject: Re: [tcpm] Is this a problem? In-Reply-To: <47439080.6050704@isi.edu> References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> <20071121004427.GI26548@cisco.com> <47439080.6050704@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-1; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 At Tuesday 20/11/2007 17:57 -0800, Joe Touch wrote: >Chandrashekhar Appanna wrote: >> On Tue, Nov 20, 2007 at 04:01:21PM -0800, Joe Touch wrote: >... >>>> The community standardised TCP window size advertisements. That's a local resource control issue, surely? >>> That's something you have to tell the other end, i.e., it requires a >>> change to the protocol on the wire. This one can be implemented without >>> any change to the protocol at all - entirely at the app layer. >> >> And I think the authors are positioning that there is a better place in >> the architecture to solve this and that is in tcp. I think it is boiling >> down to just a matter of opinions so far.. esp when you keep repeating >> that it could be solved in the app layer (for as long as I recall!!) > >First, the argument above is that this is like standardizing TCP window >advertisements. > >Second, the original argument was that this wasn't solvable at the app >layer. > >The rationale changes and the arguments persists. That's useful to note, IMO Joe, you appear to be confusing me with an author of the draft in question - and confusing my question about window advertisements (which indicate to the other end how it can usefully make use of what is essentially a local resource) for some change in rationale on behalf of the draft authors. You owe the draft authors and me apologies. L. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 00:47:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuiQM-0005SW-0n; Wed, 21 Nov 2007 00:46:58 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuiQK-0005QC-7h for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 00:46:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuiQJ-0005Q4-US for tcpm@ietf.org; Wed, 21 Nov 2007 00:46:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuiQF-0001AW-EI for tcpm@ietf.org; Wed, 21 Nov 2007 00:46:55 -0500 X-IronPort-AV: E=Sophos;i="4.21,444,1188770400"; d="scan'208";a="158324567" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2007 06:46:18 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAL5kIGK009753; Wed, 21 Nov 2007 06:46:18 +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 lAL5kHUm024121; Wed, 21 Nov 2007 05:46:17 GMT Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4559.cisco.com [10.61.81.206]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id FAA00566; Wed, 21 Nov 2007 05:46:17 GMT Message-Id: <200711210546.FAA00566@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Nov 2007 05:46:12 +0000 To: mallman@icir.org From: Lloyd Wood Subject: Re: [tcpm] Is this a problem? In-Reply-To: <20071120231000.5A95C2F8228@lawyers.icir.org> References: <200711202201.WAA05926@cisco.com> <20071120231000.5A95C2F8228@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-1; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: -4.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 At Tuesday 20/11/2007 18:10 -0500, Mark Allman wrote: >Lloyd- > >> >I think this is a complete mis-characterization. The answer is that >> >congestion control is standardized because congestion control is >> >about dealing with a *shared resource*. We can do that control from >> >a number of places in the stack and people have advocated for each of >> >them at different points. But, *where* that functionality exists is >> >a second question after we establish that the functionality needs to >> >exist and we need to standardize on it. This persist business is not >> >about controlling a shared resource, but about controlling a *local >> >resource*. Why should the community standardize local resource >> >control? >> >> The community standardised TCP window size advertisements. That's a >> local resource control issue, surely? > >The community has not standardized TCP window size advertisements. okay, e.g. RFC3390 and RFC2581 are marked standards-_track_. But those implicitly suggest how you are expected to have local resources available (congestion/loss window buffer) to meet communication conventions for shared use for a shared goal - communication. (Hmm, indicating when one side should stop communicating doesn't really fit in with the shared goal of communication.) At what point does a resource stop being shared and start being local (or vice versa)? It seems a bit fuzzy to me. L. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 01:41:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IujGx-0007GP-3P; Wed, 21 Nov 2007 01:41:19 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IujGv-0007GD-4N for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 01:41:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IujGu-0007G5-KW for tcpm@ietf.org; Wed, 21 Nov 2007 01:41:16 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IujGu-0005VX-16 for tcpm@ietf.org; Wed, 21 Nov 2007 01:41:16 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAL6eXU4008139; Tue, 20 Nov 2007 22:40:34 -0800 (PST) Message-ID: <4743D2DA.1070201@isi.edu> Date: Tue, 20 Nov 2007 22:40:26 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lloyd Wood Subject: Re: [tcpm] Is this a problem? References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> <20071121004427.GI26548@cisco.com> <47439080.6050704@isi.edu> <200711210520.FAA29441@cisco.com> In-Reply-To: <200711210520.FAA29441@cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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="===============1380347260==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1380347260== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD2E3C7410FE3DC030A6C161E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD2E3C7410FE3DC030A6C161E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lloyd Wood wrote: > At Tuesday 20/11/2007 17:57 -0800, Joe Touch wrote: >=20 >> Chandrashekhar Appanna wrote: >>> On Tue, Nov 20, 2007 at 04:01:21PM -0800, Joe Touch wrote: >> ... >>>>> The community standardised TCP window size advertisements. That's a= local resource control issue, surely? >>>> That's something you have to tell the other end, i.e., it requires a= >>>> change to the protocol on the wire. This one can be implemented with= out >>>> any change to the protocol at all - entirely at the app layer. >>> And I think the authors are positioning that there is a better plac= e in >>> the architecture to solve this and that is in tcp. I think it is bo= iling >>> down to just a matter of opinions so far.. esp when you keep repeat= ing >>> that it could be solved in the app layer (for as long as I recall!!= ) >> First, the argument above is that this is like standardizing TCP windo= w >> advertisements. >> >> Second, the original argument was that this wasn't solvable at the app= >> layer. >> >> The rationale changes and the arguments persists. That's useful to not= e, IMO >=20 > Joe, >=20 > you appear to be confusing me with an author of the draft in question Lloyd, I was not. I was explaining my response above. > - and confusing my question about window advertisements (which indicate= > to the other end how it can usefully make use of what is essentially a > local resource) for some change in rationale on behalf of the draft aut= hors. I was explaining that the authors have changed their rationale; originally, it was needed in TCP because that was the only way to solve the problem. I was not asserting that you were creating a new rationale or changing one. As to window advertisements, as I noted above, that is a property that one end communicates to the other. It isn't of purely local impact. Joe --------------enigD2E3C7410FE3DC030A6C161E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQ9LaE5f5cImnZrsRAjQwAJwLKEf9O9KS0v/bUY6MEcqGfzwRGwCgr5wT 1UiSWaBqv6heAq3bIwFoCJI= =l8gW -----END PGP SIGNATURE----- --------------enigD2E3C7410FE3DC030A6C161E-- --===============1380347260== 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 --===============1380347260==-- From tcpm-bounces@ietf.org Wed Nov 21 01:55:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IujUj-0004wM-Q2; Wed, 21 Nov 2007 01:55:33 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IujUh-0004w8-Uh for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 01:55:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IujUh-0004w0-6I for tcpm@ietf.org; Wed, 21 Nov 2007 01:55:31 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IujUc-0002Tq-Br for tcpm@ietf.org; Wed, 21 Nov 2007 01:55:30 -0500 X-IronPort-AV: E=Sophos;i="4.21,444,1188770400"; d="scan'208";a="158327188" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2007 07:55:26 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAL6tPIa020563; Wed, 21 Nov 2007 07:55:25 +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 lAL6tNUm010027; Wed, 21 Nov 2007 06:55:25 GMT Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4559.cisco.com [10.61.81.206]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA05704; Wed, 21 Nov 2007 06:55:21 GMT Message-Id: <200711210655.GAA05704@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Nov 2007 06:55:11 +0000 To: Ethan Blanton , tcpm@ietf.org From: Lloyd Wood Subject: Re: [tcpm] Is this a problem? In-Reply-To: <20071121011105.GQ5881@elb.elitists.net> References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> <20071121004427.GI26548@cisco.com> <20071121011105.GQ5881@elb.elitists.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-1; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 At Tuesday 20/11/2007 20:11 -0500, Ethan Blanton wrote: >Chandrashekhar Appanna spake unto us the following wisdom: >> On Tue, Nov 20, 2007 at 04:01:21PM -0800, Joe Touch wrote: >> > Lloyd Wood wrote: >> > > The community standardised TCP window size advertisements. That's a >> > > local resource control issue, surely? >> > >> > That's something you have to tell the other end, i.e., it requires a >> > change to the protocol on the wire. This one can be implemented without >> > any change to the protocol at all - entirely at the app layer. >> >> And I think the authors are positioning that there is a better place >> in the architecture to solve this and that is in tcp. I think it is >> boiling down to just a matter of opinions so far.. esp when you keep >> repeating that it could be solved in the app layer (for as long as I >> recall!!) > >Joe keeps making this point because it is _very important_. Any >feature which can be accomplished at Layer N can be accomplished at >Layer N - 1, and vice-versa. One obvious exception: end-to-end reliabililty. Another: error-coding for the channel. L. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 02:13:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iujlv-0008FF-QL; Wed, 21 Nov 2007 02:13:19 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iujlt-0008F9-O0 for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 02:13:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iujlt-0008F1-B3 for tcpm@ietf.org; Wed, 21 Nov 2007 02:13:17 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iujlq-0002oB-Kj for tcpm@ietf.org; Wed, 21 Nov 2007 02:13:17 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 23013CA6C4F; Tue, 20 Nov 2007 23:13:14 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11044-01; Tue, 20 Nov 2007 23:13:14 -0800 (PST) Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id D2ACECA6C4D; Tue, 20 Nov 2007 23:13:13 -0800 (PST) Message-ID: <4743DA89.6080300@redback.com> Date: Tue, 20 Nov 2007 23:13:13 -0800 From: Jakob Heitz User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lloyd Wood Subject: Re: [tcpm] Is this a problem? References: <200711202201.WAA05926@cisco.com> <20071120231000.5A95C2F8228@lawyers.icir.org> <200711210546.FAA00566@cisco.com> In-Reply-To: <200711210546.FAA00566@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tcpm@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 RFC2581 specifies behaviour of a host to protect the network. This is in the interest of all network users, thus subject to standardization. The problem of the subject line is a problem of one host, the solution to which is confined to that same host. The solution does not affect the network and requires no change in behaviour of any other host on the network. Thus it is not subject to standardization by a network standards body. The fact that a host chooses to implement TCP in something it calls a "kernel" is a private matter of that host and nothing that the rest of the network is the least bit interested in. Any host is free to fix this problem with something it might call a "socket option" or anything else without violating any IETF standards, nor requiring any blessing of the IETF. The IETF does not say that you must keep all TCP connections alive if you run out of resources, does it? Lloyd Wood wrote: > At Tuesday 20/11/2007 18:10 -0500, Mark Allman wrote: >> Lloyd- >> >>>> I think this is a complete mis-characterization. The answer is that >>>> congestion control is standardized because congestion control is >>>> about dealing with a *shared resource*. We can do that control from >>>> a number of places in the stack and people have advocated for each of >>>> them at different points. But, *where* that functionality exists is >>>> a second question after we establish that the functionality needs to >>>> exist and we need to standardize on it. This persist business is not >>>> about controlling a shared resource, but about controlling a *local >>>> resource*. Why should the community standardize local resource >>>> control? >>> The community standardised TCP window size advertisements. That's a >>> local resource control issue, surely? >> The community has not standardized TCP window size advertisements. > > okay, e.g. RFC3390 and RFC2581 are marked standards-_track_. But those implicitly suggest how you are expected to have local resources available (congestion/loss window buffer) to meet communication conventions for shared use for a shared goal - communication. (Hmm, indicating when one side should stop communicating doesn't really fit in with the shared goal of communication.) > > At what point does a resource stop being shared and start being local (or vice versa)? It seems a bit fuzzy to me. > > L. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 09:24:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqUg-0000FR-8A; Wed, 21 Nov 2007 09:23:58 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuqUf-0000D0-OT for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:23:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqUf-0000Cr-Bh for tcpm@ietf.org; Wed, 21 Nov 2007 09:23:57 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuqUe-0002Lx-VO for tcpm@ietf.org; Wed, 21 Nov 2007 09:23:57 -0500 Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuqUY-000ImD-Ff for tcpm@ietf.org; Wed, 21 Nov 2007 14:23:56 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 121CF2BE21 for ; Wed, 21 Nov 2007 09:23:47 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 487E92840D; Wed, 21 Nov 2007 09:23:47 -0500 (EST) Date: Wed, 21 Nov 2007 09:23:47 -0500 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? Message-ID: <20071121142347.GS5881@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> <20071121004427.GI26548@cisco.com> <20071121011105.GQ5881@elb.elitists.net> <200711210655.GAA05704@cisco.com> MIME-Version: 1.0 In-Reply-To: <200711210655.GAA05704@cisco.com> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -103.9 (---------------------------------------------------) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2073048442==" Errors-To: tcpm-bounces@ietf.org --===============2073048442== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mln0rGgUGuXEqmuI" Content-Disposition: inline --mln0rGgUGuXEqmuI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Lloyd Wood spake unto us the following wisdom: > At Tuesday 20/11/2007 20:11 -0500, Ethan Blanton wrote: > >Joe keeps making this point because it is _very important_. Any > >feature which can be accomplished at Layer N can be accomplished at > >Layer N - 1, and vice-versa. =20 >=20 > One obvious exception: end-to-end reliabililty. >=20 > Another: error-coding for the channel. Not to digress, but ... I think this makes the argument beautifully. Either of these *can* be handled at any layer, but we obviously agree that it's a Bad Idea to push these all the way down to the MAC layer. There is nothing magical about layering, that says "a protocol can only work if layered". Separation of concerns simply makes the model easier to grasp, and easier to Get Right. We could do end-to-end flow control, reliability, and link error-coding all in Layer 1 (or Layer 2, depending on which way you want to push), but we don't, and for a very good reason. 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 --mln0rGgUGuXEqmuI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHRD9zr9kA9Ig8HBQRAhXSAJ9rfmhnylKypKwZt/p4bjTkmmvTbQCfQZNc 04lyUyEhJ0drkEBA7DnfK5w= =zBrr -----END PGP SIGNATURE----- --mln0rGgUGuXEqmuI-- --===============2073048442== 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 --===============2073048442==-- From tcpm-bounces@ietf.org Wed Nov 21 11:48:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuskR-0001BK-Su; Wed, 21 Nov 2007 11:48:23 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuskR-0001BE-85 for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:48:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuskQ-0001B2-Bl for tcpm@ietf.org; Wed, 21 Nov 2007 11:48:22 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuskN-00037n-45 for tcpm@ietf.org; Wed, 21 Nov 2007 11:48:22 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 21 Nov 2007 08:48:21 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALGmIGV013416; Wed, 21 Nov 2007 08:48:18 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lALGmIus023244; Wed, 21 Nov 2007 16:48:18 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA05507; Wed, 21 Nov 2007 08:46:38 -0800 (PST) Date: Wed, 21 Nov 2007 08:46:38 -0800 From: Chandrashekhar Appanna To: Mark Allman Subject: Re: [tcpm] Is this a problem? Message-ID: <20071121164638.GQ26548@cisco.com> References: <20071121031410.GJ26548@cisco.com> <20071121045935.7F8592F8AFA@lawyers.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071121045935.7F8592F8AFA@lawyers.icir.org> User-Agent: Mutt/1.4i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1669; t=1195663698; x=1196527698; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=vgVuXrjv5IQkMfBpjpsN5rIsWS5x5aAnPhj5fjpuin4=; b=Md27eAgpu21q4Ktv/uc+tAZJLu8GxSc4ZYFdBw1rChASYaydTS+Bi/1N2VZRVoMHgkH9OqGh Zf109NwDLVn12kKkXg1k83QQFFwl6+oBYfkom5LmD/234tpVRXIteR/M; Authentication-Results: sj-dkim-2; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Tue, Nov 20, 2007 at 11:59:35PM -0500, Mark Allman wrote: > > > > Joe keeps making this point because it is _very important_. Any > > > feature which can be accomplished at Layer N can be accomplished at > > > Layer N - 1, and vice-versa. However, the Internet protocols have > > > enjoyed tremendous success and longevity in part because they resist > > > the urge to push application and other high-layer semantics into the > > > lower layers. > > > > And still it is a matter of opinion as to which layer should have > > what beyond a point of debate. Lot of the current model has also > > historical significance that we try to justify now with good > > language and architecture. But I do not disagree with your point > > but the repetition, to me, means that we are stuck at a stalemate > > and that is not interesting.. > > I agree with both Ethan's notes about the principles behind the > decisions. But, I think you are right that there is also an element of > design style to these decisions. > > What I really want to do here is to agree with your last bit. We are > spinning here. It is not the first time we have gone in circles on this > draft. As far as I can tell this document has nearly no support in this > WG. I don't want to cut-off discussion if folks have something new to > add. But, most of the stuff (mine included) posted is just re-hash. > So, I would like to ask folks to quit saying what they have said before. > New points are welcome. OK? > My opinion is that this draft deserves a presentation and discussion at some IETF. 0.02, Chandra. > allman > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 12:19:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IutEX-000059-LE; Wed, 21 Nov 2007 12:19:29 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IutEW-000054-RO for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 12:19:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IutEW-00004w-Fh for tcpm@ietf.org; Wed, 21 Nov 2007 12:19:28 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IutEV-0000Pm-UI for tcpm@ietf.org; Wed, 21 Nov 2007 12:19:28 -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 lALHEFph011763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Nov 2007 09:14:16 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lALHEFwD014168 for tcpm@ietf.org; Wed, 21 Nov 2007 09:14:15 -0800 (PST) (envelope-from faber) Date: Wed, 21 Nov 2007 09:14:15 -0800 From: Ted Faber To: tcpm@ietf.org Subject: Re: [tcpm] Is this a problem? Message-ID: <20071121171415.GB13024@hut.isi.edu> References: <299249.88905.qm@web31703.mail.mud.yahoo.com> <20071120121238.740442F6E0C@lawyers.icir.org> <200711202201.WAA05926@cisco.com> <47437551.7020205@isi.edu> <20071121004427.GI26548@cisco.com> <20071121011105.GQ5881@elb.elitists.net> <200711210655.GAA05704@cisco.com> <20071121142347.GS5881@elb.elitists.net> Mime-Version: 1.0 In-Reply-To: <20071121142347.GS5881@elb.elitists.net> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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="===============1634763297==" Errors-To: tcpm-bounces@ietf.org --===============1634763297== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yNb1oOkm5a9FJOVX" Content-Disposition: inline --yNb1oOkm5a9FJOVX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 21, 2007 at 09:23:47AM -0500, Ethan Blanton wrote: > Lloyd Wood spake unto us the following wisdom: > > At Tuesday 20/11/2007 20:11 -0500, Ethan Blanton wrote: > > >Joe keeps making this point because it is _very important_. Any > > >feature which can be accomplished at Layer N can be accomplished at > > >Layer N - 1, and vice-versa. =20 > >=20 > > One obvious exception: end-to-end reliabililty. > >=20 > > Another: error-coding for the channel. >=20 > Not to digress, but ... I think this makes the argument beautifully. > Either of these *can* be handled at any layer, but we obviously agree > that it's a Bad Idea to push these all the way down to the MAC layer. > There is nothing magical about layering, that says "a protocol can > only work if layered". Separation of concerns simply makes the model > easier to grasp, and easier to Get Right. >=20 > We could do end-to-end flow control, reliability, and link > error-coding all in Layer 1 (or Layer 2, depending on which way you > want to push), but we don't, and for a very good reason. [hat off] I think that any layer that can accomplish end-to-end reliability is a transport layer by definition. A link layer capable of end-to-end retransmission (say) is inherently reaching beyond the link. You could call such a layer a link layer, but the presence of an end-to-end mechanism makes it a transport layer to me. I actually think your functionality statement is a little backward - anything you can do at layer N, you can do above at layer N+1. That's because the information to implement the new feature is potentially available from the lower layers. An application can implement end-to-end reliability because the end-to-end structures/concepts are created by the transport. Implementing at layer N+1 also assumes that there's no implementation of the functionality at layer N that will interfere with your design. Implementing a retransmission strategy above TCP is fraught with peril. Perhaps that's a way to reframe this discussion. It's possible to constrain TCP to provide this timer. Are we sure that it's worth it in terms of additional complexity in TCP and constraints on other application resource management strategies? --=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 --yNb1oOkm5a9FJOVX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRGdnaUz3f+Zf+XsRAt7bAKCFF7VDWuQQmLzqwGnScEuevsmGUwCg0S+X cwTwwmaPgahz/XS//hqiqUI= =yM0x -----END PGP SIGNATURE----- --yNb1oOkm5a9FJOVX-- --===============1634763297== 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 --===============1634763297==-- From tcpm-bounces@ietf.org Wed Nov 21 12:34:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IutT1-00018T-SU; Wed, 21 Nov 2007 12:34:27 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IutT0-00018C-4Z for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 12:34:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IutSz-00016y-P7 for tcpm@ietf.org; Wed, 21 Nov 2007 12:34:25 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IutSv-0004sS-Ur for tcpm@ietf.org; Wed, 21 Nov 2007 12:34: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 lALHWrn7020439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Nov 2007 09:32:54 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lALHWnd2014435; Wed, 21 Nov 2007 09:32:49 -0800 (PST) (envelope-from faber) Date: Wed, 21 Nov 2007 09:32:49 -0800 From: Ted Faber To: Lloyd Wood Subject: Re: [tcpm] Is this a problem? Message-ID: <20071121173249.GC13024@hut.isi.edu> References: <200711202201.WAA05926@cisco.com> <20071120231000.5A95C2F8228@lawyers.icir.org> <200711210546.FAA00566@cisco.com> Mime-Version: 1.0 In-Reply-To: <200711210546.FAA00566@cisco.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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="===============0954148168==" Errors-To: tcpm-bounces@ietf.org --===============0954148168== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KN5l+BnMqAQyZLvT" Content-Disposition: inline --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Speaking as myself: On Wed, Nov 21, 2007 at 05:46:12AM +0000, Lloyd Wood wrote: > At what point does a resource stop being shared and start being local > (or vice versa)? It seems a bit fuzzy to me. So, one can make these waters pretty deep. Communication resources are shared at some level just because they're being used to swap data between hosts. I wouldn't be using a TCP buffer if I wasn't talking to anyone else, and using it to talk to you precludes me from using it to talk to Mark. They are all shared resources. However for scalability and convenience, they're all locally administered. The power to destroy a thing ... TCP standards (by and large) recognize that split and are pretty quiet on how routers and end hosts do the administration. That's a feature, IMHO. TCP standards don't tell hardware designers/application writers how to make the optimal use of their resources; the standards keep them from breaking the protocol. Mostly. Again, as myself, I prefer to let the TCP standards proscribe resource allocation systems that breaks the protocol (not applications) rather than require resource allocation systems that optimize some use of the protocol. Even extremely prevalent uses. --=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 --KN5l+BnMqAQyZLvT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRGvBaUz3f+Zf+XsRAnB8AJ4xTp9cjWv/182JLO6JZd+F1emTmQCgxPoP BuMm24KG3n8rJe+1donHQjg= =YBub -----END PGP SIGNATURE----- --KN5l+BnMqAQyZLvT-- --===============0954148168== 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 --===============0954148168==-- From tcpm-bounces@ietf.org Wed Nov 21 13:21:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuC3-0002LB-0S; Wed, 21 Nov 2007 13:20:59 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuuC1-0002L1-JQ for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 13:20:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuuC1-0002Kt-7K for tcpm@ietf.org; Wed, 21 Nov 2007 13:20:57 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuuC0-0002tm-LS for tcpm@ietf.org; Wed, 21 Nov 2007 13:20:57 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 21 Nov 2007 10:20:57 -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 lALIKj9t032216 for ; Wed, 21 Nov 2007 10:20:45 -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 lALIKfuu023194 for ; Wed, 21 Nov 2007 18:20:45 GMT 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); Wed, 21 Nov 2007 10:20:38 -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: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Date: Wed, 21 Nov 2007 10:12:44 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <200711210546.FAA00566@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Thread-Index: AcgsAhInOuk3ynh1QD6d/9hO9momLwABmDVA From: "Anantha Ramaiah (ananth)" To: X-OriginalArrivalTime: 21 Nov 2007 18:20:38.0710 (UTC) FILETIME=[37AA7560:01C82C6B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3524; t=1195669245; x=1196533245; 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:=20Summary=20of=20responses=20so=20far=20and=20proposal=20moving =20forward=20=20[Was=20Re=3A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=RWAGOvS3cVppRN42w6H3iyWWEMVnLhW/54PcpXuTH4o=; b=KOeNkOMOHylwIMjdrMx8ULlnXs1rnygc3oEXOk2uODltpbj0imJc8R675b0WJLoFkCLvOp2a n7pzSWz+SHqbW1/YhkpI1cyHUgfmK146sbNdNLoaZhjfNoAyrduf+C0R; 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: 25620135586de10c627e3628c432b04a 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 managed to read all the responses so far on this thread. At the time of writing this email, there have been 54 email exchanges (includes the authors' responses) around 9 people have responded so far not counting the private email exchanges. In order to prevent rat-holing this further I would like to step back a little and pose the following questions :- A) Do we agree that it is a problem ? [the title of the thread] Most people seem to agree on this. B) Do we think this is an issue to be dealt at the transport layer? Here there seems to be mixed reaction. Granted that there may be many people feeling that this is an application issue and not a transport issue. Now expanding on B),=20 Now the draft is talking about 2 things actually 3 things. 1) It is asking to correct/clarify the verbiage of RFC 1122. ie., RFC 1122 tells the connections MUST persist forever as long as ACK's are received. Now, clearly as demonstrated in the draft, there needs to be some ammount of robustness that can be built into the TCP layer, which can allow the connection to be aborted after some stipulated time. Is this considered a change in the standards?=20 2) The draft also outlines a solution that can be helpful to deal when a particular host is compromised with malicious intent. Agreed this may not be the only solution possible, but it is one such. This purely falls into "INFORMATIONAL" category. There is no TCP protocol change, it is upto the implementation to chose an algorithm of choice. I think the majority of the objection so far seems to be w.r.t point : "why TCP layer should be responsible for resource allocation shemes"? Again, I think this is merely a suggestion and some implementations can chose to implement it that way, there is no need to standardize this. 3) It also DOES mention about the application's role. Ie., in particular it suggests the following :-=20 "Applications can assist TCP's role in solving this problem. They can register for an event notification when the TCP connection enters or exits persist condition. They can use the notification mechanism to implement their own scheme of deciding which persist connections to clear. They can also suggest timeout or retry values to TCP." This only proves that the draft indeed does mention about application's role in assisiting the problem. Again the above purely falls into "informational" category. So, in summary : Clearly 1) above calls for some change in existing TCP behaviour. So even though it is not strictly "on the wire" change ( like someone was pointing out) it is a change to the TCP standards. Now, why can't TCP be made robust which would help to address situations like this documented in the draft? Is there a resistance to change the RFC 1122 verbiage even though it is helpful to do so? It is matter a providing a new timer in TCP ( I think Ted menioned it in one his emails) 2) and 3) doesn't need any change to the standards. They illustrate the problem and provide solutions and suggestions. Given that there seems to be an agreement that this is a problem, the way I look at is 1) above calls for a change in the standards. 2) and 3) are more informational purpose only. FWIW, the current "intended status" of the draft stands as informational.=20 Thoughts/comments? Esp. there seems to to be some scope on re-wording some sections of the draft to make the case more explicit, if that helps? -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 13:59:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuund-0007im-8C; Wed, 21 Nov 2007 13:59:49 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iuunc-0007iY-FJ for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 13:59:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuuna-0007hR-PY for tcpm@ietf.org; Wed, 21 Nov 2007 13:59:47 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuunX-0007iz-4T for tcpm@ietf.org; Wed, 21 Nov 2007 13:59:46 -0500 Received: from [70.213.183.134] (134.sub-70-213-183.myvzw.com [70.213.183.134]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lALIwpFA021377; Wed, 21 Nov 2007 10:58:58 -0800 (PST) Message-ID: <47447FE2.4040506@isi.edu> Date: Wed, 21 Nov 2007 10:58:42 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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="===============0502348485==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0502348485== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF4F42A532B9D8A659A9DDFA3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4F42A532B9D8A659A9DDFA3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it would be very useful to highlight the problem and provide information on how to solve it at the application layer in an informational RFC. I'd suggest it'd be useful to include very specific examples, e.g., with socket options, to show a potential mechanism. I also think the doc should include a discussion of making slow progress as related to this issue, and potentially a similar DOS opportunity. I don't think the doc should change 1122's text; IMO, TCP isn't the one who ought to make this decision, thus TCP ought to hang out as long as the application lets it. I don't think the doc should mention whether the timer should be embedded in TCP as an implementation decision. IMO, that crosses into a TCP mod, and since it isn't absolutely necessary, I don't see a reason to do so there. I do think it would be more useful to give the example of putting this in the kernel as a shared mechanism, with discussion to motivate it. Finally, if this is an informational RFC and the solution is soley at the app layer, it ought to be taken to TSVWG, rather than in TCPM. I don't consider this a downgrading, but rather to gain a wider audience for a very real issue. Joe Anantha Ramaiah (ananth) wrote: > I managed to read all the responses so far on this thread. At the time > of writing this email, there have been 54 email exchanges (includes the= > authors' responses) around 9 people have responded so far not counting > the private email exchanges. In order to prevent rat-holing this furthe= r > I would like to step back a little and pose the following questions :- >=20 > A) Do we agree that it is a problem ? [the title of the thread] >=20 > Most people seem to agree on this. >=20 > B) Do we think this is an issue to be dealt at the transport layer? >=20 > Here there seems to be mixed reaction. Granted that there may be man= y > people feeling that this is an application issue and not a transport > issue. >=20 > Now expanding on B),=20 >=20 > Now the draft is talking about 2 things actually 3 things. >=20 > 1) It is asking to correct/clarify the verbiage of RFC 1122. ie., RFC > 1122 tells the connections MUST persist forever as long as ACK's are > received. Now, clearly as demonstrated in the draft, there needs to be > some ammount of robustness that can be built into the TCP layer, which > can allow the connection to be aborted after some stipulated time. Is > this considered a change in the standards?=20 >=20 > 2) The draft also outlines a solution that can be helpful to deal when = a > particular host is compromised with malicious intent. Agreed this may > not be the only solution possible, but it is one such. This purely fall= s > into "INFORMATIONAL" category. There is no TCP protocol change, it is > upto the implementation to chose an algorithm of choice. I think the > majority of the objection so far seems to be w.r.t point : "why TCP > layer should be responsible for resource allocation shemes"? Again, I > think this is merely a suggestion and some implementations can chose to= > implement it that way, there is no need to standardize this. >=20 > 3) It also DOES mention about the application's role. Ie., in particula= r > it suggests the following :-=20 > "Applications can assist TCP's role in solving this problem. They > can > register for an event notification when the TCP connection enters or= > exits persist condition. They can use the notification mechanism to= > implement their own scheme of deciding which persist connections to > clear. They can also suggest timeout or retry values to TCP." >=20 > This only proves that the draft indeed does mention about application's= > role in assisiting the problem. Again the above purely falls into > "informational" category. >=20 > So, in summary : Clearly 1) above calls for some change in existing TCP= > behaviour. So even though it is not strictly "on the wire" change ( lik= e > someone was pointing out) it is a change to the TCP standards. Now, why= > can't TCP be made robust which would help to address situations like > this documented in the draft? Is there a resistance to change the RFC > 1122 verbiage even though it is helpful to do so? It is matter a > providing a new timer in TCP ( I think Ted menioned it in one his > emails) >=20 > 2) and 3) doesn't need any change to the standards. They illustrate th= e > problem and provide solutions and suggestions. >=20 > Given that there seems to be an agreement that this is a problem, the > way I look at is 1) above calls for a change in the standards. 2) and 3= ) > are more informational purpose only. >=20 > FWIW, the current "intended status" of the draft stands as > informational.=20 >=20 > Thoughts/comments? Esp. there seems to to be some scope on re-wording > some sections of the draft to make the case more explicit, if that > helps? >=20 > -Anantha >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm --------------enigF4F42A532B9D8A659A9DDFA3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRH/iE5f5cImnZrsRAvqxAJ0UPyCoyXlpmGcKm/KCymR4IdrWAgCgoVWq GrRxQ7mr3+fcdEUCYHoXxcw= =v/7P -----END PGP SIGNATURE----- --------------enigF4F42A532B9D8A659A9DDFA3-- --===============0502348485== 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 --===============0502348485==-- From tcpm-bounces@ietf.org Wed Nov 21 14:30:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuvHW-0006Da-E1; Wed, 21 Nov 2007 14:30:42 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuvHU-0006AV-MQ for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 14:30:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuvHU-00068f-Ar for tcpm@ietf.org; Wed, 21 Nov 2007 14:30:40 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuvHT-0004yU-Sa for tcpm@ietf.org; Wed, 21 Nov 2007 14:30:40 -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 lALJT1Uw007513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Nov 2007 11:29:02 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lALJT1FV016962; Wed, 21 Nov 2007 11:29:01 -0800 (PST) (envelope-from faber) Date: Wed, 21 Nov 2007 11:29:01 -0800 From: Ted Faber To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Message-ID: <20071121192901.GF13024@hut.isi.edu> References: <200711210546.FAA00566@cisco.com> <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1721624877==" Errors-To: tcpm-bounces@ietf.org --===============1721624877== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8TaQrIeukR7mmbKf" Content-Disposition: inline --8TaQrIeukR7mmbKf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I haven't spoken to Mark about this, so this is me speaking for myself. On Wed, Nov 21, 2007 at 10:12:44AM -0800, Anantha Ramaiah (ananth) wrote: > B) Do we think this is an issue to be dealt at the transport layer? >=20 > Here there seems to be mixed reaction. Granted that there may be many > people feeling that this is an application issue and not a transport > issue. That's not my assessment. It looks to me that there is considerable resistance to standardizing=20 the proposed solution, both on the grounds of placement in the stack and on the limitations of the solution. =20 [ For example, connections that advertise a large initial window and then read a byte every (proposed timer size -1) seconds will replicate the problem in the limit. Using timers alone penalizes stopped connections when there is no resource shortage. ] Despite the fairly lively discussion, I have seen little support for standardizing this mechanism in TCP, outside the authors and their collaborators, and strong resistance from the members of the WG. =20 Again, I'm not assessing consensus officially here, but that's how I see it. --=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 --8TaQrIeukR7mmbKf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRIb9aUz3f+Zf+XsRAuaeAJ49r+2whxh3MFNcfWJ8CSwsYjQIwgCgsENi zTT+TyxwiEjk/pDWRCBF1gw= =Nv1V -----END PGP SIGNATURE----- --8TaQrIeukR7mmbKf-- --===============1721624877== 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 --===============1721624877==-- From tcpm-bounces@ietf.org Wed Nov 21 14:52:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuvc7-0007sG-I6; Wed, 21 Nov 2007 14:51:59 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iuvc6-0007re-Mh for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 14:51:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuvc5-0007nM-5M for tcpm@ietf.org; Wed, 21 Nov 2007 14:51:57 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuvc4-0005rn-Of for tcpm@ietf.org; Wed, 21 Nov 2007 14:51:57 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer2.psc.edu (8.14.1/8.13.3) with ESMTP id lALJpsf4000620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Nov 2007 14:51:54 -0500 (EST) Message-ID: <47448C5A.7070007@psc.edu> Date: Wed, 21 Nov 2007 14:51:54 -0500 From: John Heffner User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Anantha Ramaiah (ananth) wrote: > I managed to read all the responses so far on this thread. At the time > of writing this email, there have been 54 email exchanges (includes the > authors' responses) around 9 people have responded so far not counting > the private email exchanges. In order to prevent rat-holing this further > I would like to step back a little and pose the following questions :- > > A) Do we agree that it is a problem ? [the title of the thread] > > Most people seem to agree on this. I would like to step back even further, and work on the definition of "it" -- the problem we want to solve. In my mail on Nov 14 (which did not elicit a response), I tried to make the case that the issues framed in the draft are in fact only a special case of a more general problem. I do not believe the indefinite nature of TCP's persist state is intrinsically something we need to fix -- in fact, it is clearly an important and useful feature of TCP. It might not be terrible for a TCP implementation to provide a switch for an implicit ABORT after a long persist timeout. However, in my opinion this is not the best solution, or even a solution at all to the more general problem. I think if consensus can be reached on what the problem actually *is*, it may be more clear how to solve it, where the solution should go, and if this is something the IETF should take on. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 15:22:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuw5h-0002pH-0S; Wed, 21 Nov 2007 15:22:33 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iuw5f-0002ot-Pv for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 15:22:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuw5f-0002oh-EX for tcpm@ietf.org; Wed, 21 Nov 2007 15:22:31 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuw5e-0007Mo-P3 for tcpm@ietf.org; Wed, 21 Nov 2007 15:22:31 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2007 12:22:31 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALKMUxU010054; Wed, 21 Nov 2007 12:22:30 -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 lALKMGvG023425; Wed, 21 Nov 2007 20:22:30 GMT 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); Wed, 21 Nov 2007 12:22:29 -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: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Date: Wed, 21 Nov 2007 12:22:27 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20071121192901.GF13024@hut.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Thread-Index: AcgsdQQG/9H1uvo3TZ6tvG9hkayUagAAEXdg From: "Anantha Ramaiah (ananth)" To: "Ted Faber" X-OriginalArrivalTime: 21 Nov 2007 20:22:29.0757 (UTC) FILETIME=[3D63B2D0:01C82C7C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4010; t=1195676550; x=1196540550; c=relaxed/simple; s=sjdkim2002; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=wcAXNZByZ8zwOaoWo72N3KbKK4qQqjujqBIMWSji0y8=; b=H4FCCer0ckEGEEXMKEbN5fCc+ReVfElJiPSPkKMdxOvpAs9nfyeJQg1Ref9zo0yDPkmbLn0p LhxdQboDeY8R9sF2EL9d7TeOLZci22LUUW4A9/wIbhYu99XyBzPz6CJ9; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 > > B) Do we think this is an issue to be dealt at the transport layer? > >=20 > > Here there seems to be mixed reaction. Granted that there may be=20 > > many people feeling that this is an application issue and not a=20 > > transport issue. >=20 > That's not my assessment. Ok. >=20 > It looks to me that there is considerable resistance to=20 > standardizing the proposed solution, both on the grounds of=20 > placement in the stack and on the limitations of the solution. =20 Ok. That is the reason I pointed that, I believe the draft is not trying to "standardize" the solution part and that is informational and illustrational purpose only. It also mentions about the role of the application, which is again needed to be treated as informational. Do you see the need for making further clarifications that would make this look better?. >=20 > [ For example, connections that advertise a large initial=20 > window and then read a byte every (proposed timer size -1)=20 > seconds will replicate the problem in the limit. Using timers=20 > alone penalizes stopped connections when there is no resource=20 > shortage. ] Good point. I would think that this is a non-standard behavior, corner case, why would an application do this in reality and how many times we have seen such behaviors? I don't want lengthy thread on this, but this is debatable, IMO. >=20 > Despite the fairly lively discussion, I have seen little=20 > support for standardizing this mechanism in TCP, outside the=20 > authors and their collaborators, and strong resistance from=20 > the members of the WG. =20 >=20 > Again, I'm not assessing consensus officially here, but=20 > that's how I see it. Poin taken. But there seems to a confusion on what is being attempted to be standardized versus what is illustrational/informational purpose only. Just to re-state : WHY WE BELIEVE THERE IS A NEED FOR STANDARD CHANGE/EXISTING STANDARD CLARIFICATION ? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Few people have echoed this question, the response below ] I think there is a need for some standards change. Reason : I'll give an example of a TCP proxy which doesn't have an application on top per se. Now I would want to track the TCP connections ( yes there are several ways to do this) and monitor the health of those, in particular those that are "hanging" in persist state forever. I can use some timeout inside TCP to kick off and kill those connections depending on some policy, is this considered a voilation of RFC since RFC says " you MUST keep these connections open as long as you receive ACKs?" Someone can point out that the TCP proxy is not RFC compliant since it was "supposed" to keep these connections but terminated them, esp since there is no application which owns these TCP connections on this box?=20 I immediately realise that there may be some responses like " TCP connection can be terminated anytime, so it should not be treated as non-compliance of RFC 1122", Is this a fair enough response?. I am confused, atleast I feel there is a need to say something like " TCP MUST keep the connection open as long as it gets ACKS, however, if the application OR a TCP implementation can abort this connection if it determines by its own means that the connection needs to be taken off".. I know.. I could have worded this better, but I hope my point is clear.=20 Ok, if you think that there is nothing to be changed in TCP, but yet an implementation trying to abort TCP connections that persist indefinitely even though it is getting ACK's is fully compliant, then there is no further debate on this point, I would think. Can you and the other work group members clarify the above point? =20 -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 15:35:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwIE-00008W-7o; Wed, 21 Nov 2007 15:35:30 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuwIC-0008WK-CO for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 15:35:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwIB-0008Tj-PX for tcpm@ietf.org; Wed, 21 Nov 2007 15:35:27 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuwI7-0003G2-AY for tcpm@ietf.org; Wed, 21 Nov 2007 15:35:27 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 21 Nov 2007 12:35:23 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALKZMHq025538; Wed, 21 Nov 2007 12:35:22 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALKZ8bG022916; Wed, 21 Nov 2007 20:35:22 GMT 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); Wed, 21 Nov 2007 12:35:08 -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: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Date: Wed, 21 Nov 2007 12:35:08 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58044CE030@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47447FE2.4040506@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Thread-Index: AcgscK2GJEtOCyXZQI+ynk/2eQJevAAC5ggw From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 21 Nov 2007 20:35:08.0914 (UTC) FILETIME=[01E1DD20:01C82C7E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2228; t=1195677322; x=1196541322; c=relaxed/simple; s=sjdkim1004; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=Hx8f7qrQuankUGH0NkBwmPHIDSfCwbsMt0uzKP4Ddv0=; b=qG6Du3Mkm6x+GnsUGt9CfgAGlmaDIQHrkLmlKQjl3UCJxUuh4HxKs8iXPRHIr5l7ZKz+vMoL h7X7/3Rg/zVUzEpTcsr31JoAA6G6CxnlF2mS8OHoXS35yBdpE3xH0vWohQHgoo/RxcOSLxhdDO jisNcyNeIO7n1T2ySV7xpBDio=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Wednesday, November 21, 2007 10:59 AM > To: Anantha Ramaiah (ananth) > Cc: tcpm@ietf.org > Subject: Re: Summary of responses so far and proposal moving=20 > forward [Was Re: [tcpm] Is this a problem?] >=20 > I think it would be very useful to highlight the problem and=20 > provide information on how to solve it at the application=20 > layer in an informational RFC. I'd suggest it'd be useful to=20 > include very specific examples, e.g., with socket options, to=20 > show a potential mechanism. I also think the doc should=20 > include a discussion of making slow progress as related to=20 > this issue, and potentially a similar DOS opportunity. Actually the mention of socket option is not explicit as it stands now in the draft and there is definetly some scope for re-wording, I think. >=20 > I don't think the doc should change 1122's text; IMO, TCP=20 > isn't the one who ought to make this decision, thus TCP ought=20 > to hang out as long as the application lets it. Pl see my response to Ted where I explicitly ask a question and provide why I think there is "some" element of standarization here, your responses are welcome. >=20 > I don't think the doc should mention whether the timer should=20 > be embedded in TCP as an implementation decision. IMO, that=20 > crosses into a TCP mod, and since it isn't absolutely=20 > necessary, I don't see a reason to do so there. I do think it=20 > would be more useful to give the example of putting this in=20 > the kernel as a shared mechanism, with discussion to motivate it. Hmm.. An informational RFC CAN recommend stuff, confused here?? >=20 > Finally, if this is an informational RFC and the solution is=20 > soley at the app layer, it ought to be taken to TSVWG, rather=20 > than in TCPM. I don't consider this a downgrading, but rather=20 > to gain a wider audience for a very real issue. Well, agree with the rationale but not the reasoning. My reasoning may be :- "since this real issue applies equally well for SCTP as well AND also to gain a wider audience, may be it is a good idea to take this to tsvwg". -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 16:32:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxB1-00069n-J9; Wed, 21 Nov 2007 16:32:07 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuxB0-00062a-Db for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:32:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxB0-00061C-2Y for tcpm@ietf.org; Wed, 21 Nov 2007 16:32:06 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuxAz-0002Sv-KZ for tcpm@ietf.org; Wed, 21 Nov 2007 16:32:05 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Nov 2007 13:32:04 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lALLW5sl014013; Wed, 21 Nov 2007 13:32:05 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lALLVlvA019401; Wed, 21 Nov 2007 21:32:05 GMT 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, 21 Nov 2007 13:31:53 -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: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Date: Wed, 21 Nov 2007 13:31:52 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58044CE07B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47448C5A.7070007@psc.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Thread-Index: Acgsd/yShbr/j/+2QuqLaDqxRk9aLwACynLA From: "Anantha Ramaiah (ananth)" To: "John Heffner" X-OriginalArrivalTime: 21 Nov 2007 21:31:53.0872 (UTC) FILETIME=[EF653900:01C82C85] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2083; t=1195680725; x=1196544725; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=us1CCYY4dl+T3Sq+Tt6TiNfP6qhh4O1xggWniPuWjL4=; b=WQSCTchX7+eSOSb7ty1zcsrSBFEkGNGG/GCAaISTSmgQSTS/fSH86AbzksYf65b01D/5DwCG dOTOeeyG/57jmiYFcd3+AEiJTCQJQ2B4sIpSwYYDrQUbwCdCefi9Uy+M; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) 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 John: =20 > >=20 > > A) Do we agree that it is a problem ? [the title of the thread] > >=20 > > Most people seem to agree on this. >=20 > I would like to step back even further, and work on the=20 > definition of "it" -- the problem we want to solve. In my=20 > mail on Nov 14 (which did not elicit a response), I tried to=20 > make the case that the issues framed in the draft are in fact=20 > only a special case of a more general problem. Sorry I haven't read that. Will do. >=20 > I do not believe the indefinite nature of TCP's persist state=20 > is intrinsically something we need to fix -- in fact, it is=20 > clearly an important and useful feature of TCP. It might not=20 > be terrible for a TCP implementation to provide a switch for=20 > an implicit ABORT after a long persist timeout. However, in=20 > my opinion this is not the best solution, or even a solution=20 > at all to the more general problem. Pl see the question I posed to in response to Ted's email. Having an implicit ABORT or having a socket option is very useful thing. It is the "basic infrastructure" needed in TCP and TCP API layer (like sockets). Now, if I follow RFC 1122 language, it seems to preclude me from doing the above. Doing such a thing is an RFC voliation? Does it need some clarification?=20 >=20 > I think if consensus can be reached on what the problem=20 > actually *is*, it may be more clear how to solve it, where=20 > the solution should go, and if this is something the IETF=20 > should take on. IMO, one problem we are trying to address ( the main issue) is the RFC language correction/clarification. Question : OTOH, I think you are asking for clear "problem statement" ? Are you saying that the the way it is stated in the document is vague, does it more clarification? I can read it again and again, but if you can ask some specfic questions, maybe that would help. Other responses have been of the nature which I summarised earlier and I don't remember anyone having issues about the problem statement.=20 -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 16:37:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxGT-0007vR-JU; Wed, 21 Nov 2007 16:37:45 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuxGR-0007vE-Ji for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:37:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxGR-0007v4-8t for tcpm@ietf.org; Wed, 21 Nov 2007 16:37:43 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuxGQ-0002jd-NO for tcpm@ietf.org; Wed, 21 Nov 2007 16:37:43 -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 lALLaAsE022200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Nov 2007 13:36:11 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lALLaAqn019212; Wed, 21 Nov 2007 13:36:10 -0800 (PST) (envelope-from faber) Date: Wed, 21 Nov 2007 13:36:10 -0800 From: Ted Faber To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Message-ID: <20071121213610.GH13024@hut.isi.edu> References: <20071121192901.GF13024@hut.isi.edu> <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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="===============0538219731==" Errors-To: tcpm-bounces@ietf.org --===============0538219731== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IR1Y5IvQhrKgS4e6" Content-Disposition: inline --IR1Y5IvQhrKgS4e6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Continuing to speak for myself. On Wed, Nov 21, 2007 at 12:22:27PM -0800, Anantha Ramaiah (ananth) wrote: > >=20 > > It looks to me that there is considerable resistance to=20 > > standardizing the proposed solution, both on the grounds of=20 > > placement in the stack and on the limitations of the solution. =20 >=20 > Ok. That is the reason I pointed that, I believe the draft is not trying > to "standardize" the solution part and that is informational and > illustrational purpose only.=20 I don't understand your snicker quotes around standardize. Changing a MUST NOT to a MAY or SHOULD NOT in 1122 is about as serious as standardizarion effort as one can undertake in TCPM. I (personally) don't see the point of publishing an RFC that describes a technique that a conformant TCP cannot implement. > It also mentions about the role of the > application, which is again needed to be treated as informational. Do > you see the need for making further clarifications that would make this > look better?. Section 3 of the draft is very hard to follow and is unclear on what's being proposed. If the work were taken up, I'd recommend rewriting it. > > [ For example, connections that advertise a large initial=20 > > window and then read a byte every (proposed timer size -1)=20 > > seconds will replicate the problem in the limit. Using timers=20 > > alone penalizes stopped connections when there is no resource=20 > > shortage. ] >=20 > Good point. I would think that this is a non-standard behavior, corner > case, why would an application do this in reality and how many times we > have seen such behaviors? I don't want lengthy thread on this, but this > is debatable, IMO. While one might dismiss a legitimate connection holding a zero window for a long time as a corner case (though doing so is projecting application semantics into the transport), the more telling criticism is the first case. An attacker who wanted to mount the DoS attack described in the draft could defeat your proposed mitigation by asking for the same large window and then draining it slowly rather than simply holding the zero window. The draft mentions that the silly window avoidance makes this difficult, but it just requires the attacker to ACK an MSS worth of data less frequently then if they read a single byte. --=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 --IR1Y5IvQhrKgS4e6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRKTKaUz3f+Zf+XsRAkBoAKD0MChD/AeGWVQGZ9BSuGE/sa4M8gCfXZSo uXV9nNgqF850rPgnnPbwJQ4= =Alc2 -----END PGP SIGNATURE----- --IR1Y5IvQhrKgS4e6-- --===============0538219731== 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 --===============0538219731==-- From tcpm-bounces@ietf.org Wed Nov 21 16:42:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxKv-0008Vg-4r; Wed, 21 Nov 2007 16:42:21 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuxKt-0008VQ-Cv for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:42:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxKt-0008VD-1x for tcpm@ietf.org; Wed, 21 Nov 2007 16:42:19 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuxKs-0002us-Mn for tcpm@ietf.org; Wed, 21 Nov 2007 16:42:18 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2007 13:42:18 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALLgHkw022560; Wed, 21 Nov 2007 13:42:17 -0800 Received: from [10.21.104.30] (sjc-vpnasa1-30.cisco.com [10.21.104.30]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALLgHb4009536; Wed, 21 Nov 2007 21:42:17 GMT Message-ID: <4744A639.2080404@cisco.com> Date: Wed, 21 Nov 2007 13:42:17 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=984; t=1195681338; x=1196545338; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=0A=20Re=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=qSYWfAUasVfdT8N/xvIv8ljZ1IViujla+Y0g6eYla8Y=; b=evEwsYTWQwbVoG5TmoGwdmwPskRyMezbt3dTS+cSrWbNFG6sDRu18jourAgTMNFJvL0SbUP0 Qg1mi5TYjcYmks6zP/n6ZTW8AstM1XrlCXjss3XrXV+cJfZ5Ku08L/2Q; Authentication-Results: sj-dkim-2; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: > 1) It is asking to correct/clarify the verbiage of RFC 1122. ie., RFC > 1122 tells the connections MUST persist forever as long as ACK's are > received. Now, clearly as demonstrated in the draft, there needs to be > some ammount of robustness that can be built into the TCP layer, which > can allow the connection to be aborted after some stipulated time. Is > this considered a change in the standards I want to try to bring some focus back on the above point that the draft is trying to make. If we agree that there is a problem and the solution lies in aborting the connection, however it is done, i.e. by application or by some TCP implementation, then at the minimum we believe that a change is required in the verbiage of RFC 1122. The change is to say that in case of reliable ACK's coming back from the receiver, it is NOT a requirement for the sender to keep the connection open indefinitely. Can we agree on this? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 17:15:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuxr8-0006pP-3c; Wed, 21 Nov 2007 17:15:38 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iuxr6-0006pK-NK for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:15:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuxr6-0006pC-Cd for tcpm@ietf.org; Wed, 21 Nov 2007 17:15:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuxr5-0004Ie-Vd for tcpm@ietf.org; Wed, 21 Nov 2007 17:15:36 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 21 Nov 2007 14:15:35 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALMFZB1027126; Wed, 21 Nov 2007 14:15:35 -0800 Received: from [10.21.104.30] (sjc-vpnasa1-30.cisco.com [10.21.104.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lALMFZAx000748; Wed, 21 Nov 2007 22:15:35 GMT Message-ID: <4744AE06.1090808@cisco.com> Date: Wed, 21 Nov 2007 14:15:34 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ted Faber Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <20071121192901.GF13024@hut.isi.edu> <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com> <20071121213610.GH13024@hut.isi.edu> In-Reply-To: <20071121213610.GH13024@hut.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1634; t=1195683335; x=1196547335; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=0A=20Re=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=IL5OzTe76hc8xPWRecwpFxf+2HgGIx7qo5v2fyc6N2k=; b=NGl5bmEuUx6WmCI2qKcvaEZvyBNSpeN2RnWmpCfcCljZNe3RBs6xSuRGC/pd9wBtZ5GUsogD bMYl4PSmKNbeHO+mlBJivw/PanmxSJ0OeHr/rzIxOkSuLSwLbT4nWFybVFeAFcCf+okc4u4jE1 GAtR9DVUN63isf2ZLFhr4sYB8=; Authentication-Results: sj-dkim-1; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I saw this e-mail just after I had hit the send button for my last e-mail. Ted Faber wrote: > I (personally) don't see the point of publishing an RFC that describes > a technique that a conformant TCP cannot implement. > I do not see any reason why the proposed solution cannot be implemented. Are you suggesting that because we cannot implement it is why it should not be implemented? > > > While one might dismiss a legitimate connection holding a zero window > for a long time as a corner case (though doing so is projecting > application semantics into the transport), the more telling criticism is > the first case. > > An attacker who wanted to mount the DoS attack described in the draft > could defeat your proposed mitigation by asking for the same large > window and then draining it slowly rather than simply holding the zero > window. The draft mentions that the silly window avoidance makes this > difficult, but it just requires the attacker to ACK an MSS worth of data > less frequently then if they read a single byte This is a *proposed* solution. This is not a solution that we want to standardize on. I am sure with bright minds on this list we can come up with better solutions to the problem and I am fine with that. To answer your question, yes, they could. That situation is no different from a connection that is slow but is making progress. In fact at that point it is not a persist connection. It is not advertising zero window. We are specifically concerned about connections that take advantage of RFC 1122 verbiage to keep the connection in persist state. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 17:25:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuy0Q-0005er-T2; Wed, 21 Nov 2007 17:25:14 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iuy0N-0005eb-V4 for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:25:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuy0N-0005eJ-K8 for tcpm@ietf.org; Wed, 21 Nov 2007 17:25:11 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuy0K-0008AB-E1 for tcpm@ietf.org; Wed, 21 Nov 2007 17:25:11 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Nov 2007 14:25:07 -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 lALMP70a002339; Wed, 21 Nov 2007 14:25:07 -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 lALMOevE029598; Wed, 21 Nov 2007 22:25:07 GMT 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); Wed, 21 Nov 2007 14:24:55 -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: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Date: Wed, 21 Nov 2007 14:24:54 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58044CE0C4@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20071121213610.GH13024@hut.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Thread-Index: AcgshsDDU9ZyEQ50RGe3YxqlgaJNTwAAsTjA From: "Anantha Ramaiah (ananth)" To: "Ted Faber" X-OriginalArrivalTime: 21 Nov 2007 22:24:55.0289 (UTC) FILETIME=[57AAEE90:01C82C8D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2495; t=1195683907; x=1196547907; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=K8jQ5nLtfNVlf6tFzqf4VNX75bR72stYN8aRZNaaDQM=; b=Et8mDE0Yxk0kVB3bhRmG4Yhm0FYMPS83imepwmd7WJjHaWeYaklr2YpxHdalq5hCMdDrDOVM 3OrP7E4ioXhegIaHvXm2WTKyuaBNRDQiK2XjA8uyD153plPFKUyEjcXe; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 >=20 > I don't understand your snicker quotes around standardize. =20 > Changing a MUST NOT to a MAY or SHOULD NOT in 1122 is about=20 > as serious as standardizarion effort as one can undertake in TCPM. Actually I asked the same question below :-) My understanding was the same ie., changing verbiage is indeed a standardization effort.=20 >=20 > I (personally) don't see the point of publishing an RFC that=20 > describes a technique that a conformant TCP cannot implement. I agree. So my understanding is that wherever the solution lies, be it a socket option that can be set by the application OR an implicit timer within TCP or whatever means, irrrespective of the method chosen, this warrants a change in the RFC 1122 or atleast a clarification in the existing verbiage w.r.t zero window probes? Do you agree? If so then do we agree as a WG to make the change since this is required irrespective of the fact where the solution lies? OR do folks in the list have some solution in mind which can be done without touching the standards? Sorry, I haven't yet seen this particular discussion happening which is the main purpose of my email. The only thing so far was a few people saying that there is no need to change RFC 1122, but I am afraid I haven't seen the reasons and/or alternate proposals. >=20 > > It also mentions about the role of the=20 > > application, which is again needed to be treated as=20 > informational. Do=20 > > you see the need for making further clarifications that would make=20 > > this look better?. >=20 > Section 3 of the draft is very hard to follow and is unclear=20 > on what's being proposed. If the work were taken up, I'd=20 > recommend rewriting it. Ok. >=20 > While one might dismiss a legitimate connection holding a=20 > zero window for a long time as a corner case (though doing so=20 > is projecting application semantics into the transport), the=20 > more telling criticism is the first case. >=20 > An attacker who wanted to mount the DoS attack described in=20 > the draft could defeat your proposed mitigation by asking for=20 > the same large window and then draining it slowly rather than=20 > simply holding the zero window. The draft mentions that the=20 > silly window avoidance makes this difficult, but it just=20 > requires the attacker to ACK an MSS worth of data less=20 > frequently then if they read a single byte. Agreed. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 17:38:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyDJ-0001Sn-Qf; Wed, 21 Nov 2007 17:38:33 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuyDI-0001NU-Ss for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:38:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyDI-0001LJ-HB for tcpm@ietf.org; Wed, 21 Nov 2007 17:38:32 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuyDD-0000Io-16 for tcpm@ietf.org; Wed, 21 Nov 2007 17:38:32 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lALMc0I2020479; Wed, 21 Nov 2007 14:38:01 -0800 (PST) Message-ID: <4744B33B.10501@isi.edu> Date: Wed, 21 Nov 2007 14:37:47 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC58044CE030@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CE030@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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="===============1212853445==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1212853445== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1393CCA96A508EB0ABCC9F31" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1393CCA96A508EB0ABCC9F31 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. >> I don't think the doc should change 1122's text; IMO, TCP=20 >> isn't the one who ought to make this decision, thus TCP ought=20 >> to hang out as long as the application lets it. >=20 > Pl see my response to Ted where I explicitly ask a question and provide= > why I think there is "some" element of standarization here, your > responses are welcome. I saw your responses; I don't agree. >> I don't think the doc should mention whether the timer should=20 >> be embedded in TCP as an implementation decision. IMO, that=20 >> crosses into a TCP mod, and since it isn't absolutely=20 >> necessary, I don't see a reason to do so there. I do think it=20 >> would be more useful to give the example of putting this in=20 >> the kernel as a shared mechanism, with discussion to motivate it. >=20 > Hmm.. An informational RFC CAN recommend stuff, confused here?? Informational shouldn't recommend anything. It should state stuff. BCPs are for recommendations, IMO. Joe --------------enig1393CCA96A508EB0ABCC9F31 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRLNBE5f5cImnZrsRAgvoAJsHKA0QdcqCAT++SQVXkEvjKdi53wCfdGUb pevXs1dyqjReN4CsA86nw84= =xMgr -----END PGP SIGNATURE----- --------------enig1393CCA96A508EB0ABCC9F31-- --===============1212853445== 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 --===============1212853445==-- From tcpm-bounces@ietf.org Wed Nov 21 17:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyIQ-0007OM-60; Wed, 21 Nov 2007 17:43:50 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuyIO-0007Ma-G5 for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:43:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyIN-0007MB-VU for tcpm@ietf.org; Wed, 21 Nov 2007 17:43:48 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuyIK-0000XE-Lx for tcpm@ietf.org; Wed, 21 Nov 2007 17:43:47 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lALMhJNF021996; Wed, 21 Nov 2007 14:43:20 -0800 (PST) Message-ID: <4744B47F.8060306@isi.edu> Date: Wed, 21 Nov 2007 14:43:11 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tcpm@ietf.org, Ted Faber 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="===============1407937839==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1407937839== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0ED568ACDE7C73CBF9FCBBDB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0ED568ACDE7C73CBF9FCBBDB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. > WHY WE BELIEVE THERE IS A NEED FOR STANDARD CHANGE/EXISTING STANDARD > CLARIFICATION ? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > [Few people have echoed this question, the response below ] >=20 > I think there is a need for some standards change. Reason : I'll give a= n > example of a TCP proxy which doesn't have an application on top per se.= That doesn't exist. TCP always has an application on top. TCP proxies may have a relatively trivial one, and it may be implemented in the kernel, but TCP delivers data to an application. I.e., to TCP, "application" means "software I deliver data to". It doesn't mean "user space program". There are TCP "proxies" that translate packets directly; they don't implement TCP. To implement TCP is to originate and terminate a connectio= n. Joe --------------enig0ED568ACDE7C73CBF9FCBBDB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRLR/E5f5cImnZrsRAjUiAKCAiagrpeTqRQ8VHQhi0NLxlfvxlQCgrXnK i/9M7/tT41RxCVWrpAyZg64= =PipS -----END PGP SIGNATURE----- --------------enig0ED568ACDE7C73CBF9FCBBDB-- --===============1407937839== 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 --===============1407937839==-- From tcpm-bounces@ietf.org Wed Nov 21 17:45:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyKL-0003Is-2G; Wed, 21 Nov 2007 17:45:49 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuyKJ-0003Ig-On for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:45:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyKJ-0003IY-FE for tcpm@ietf.org; Wed, 21 Nov 2007 17:45:47 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuyKG-0000du-Sl for tcpm@ietf.org; Wed, 21 Nov 2007 17:45:47 -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 lALMjEns019157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Nov 2007 14:45:15 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lALMjEEM020428; Wed, 21 Nov 2007 14:45:14 -0800 (PST) (envelope-from faber) Date: Wed, 21 Nov 2007 14:45:14 -0800 From: Ted Faber To: Mahesh Jethanandani Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Message-ID: <20071121224514.GJ13024@hut.isi.edu> References: <20071121192901.GF13024@hut.isi.edu> <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com> <20071121213610.GH13024@hut.isi.edu> <4744AE06.1090808@cisco.com> Mime-Version: 1.0 In-Reply-To: <4744AE06.1090808@cisco.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0421971426==" Errors-To: tcpm-bounces@ietf.org --===============0421971426== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SCOJXUq1iwCn05li" Content-Disposition: inline --SCOJXUq1iwCn05li Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 21, 2007 at 02:15:34PM -0800, Mahesh Jethanandani wrote: > I saw this e-mail just after I had hit the send button for my last e-mail. >=20 > Ted Faber wrote: > >I (personally) don't see the point of publishing an RFC that describes > >a technique that a conformant TCP cannot implement. > > =20 > I do not see any reason why the proposed solution cannot be implemented.= =20 > Are you suggesting that because we cannot implement it is why it should= =20 > not be implemented? The conformant TCP cannot implement the fix because it would violate 1122 and then no longer be a conformant TCP.=20 I understand you can write the code. --=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 --SCOJXUq1iwCn05li Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRLT6aUz3f+Zf+XsRArmHAJ4gb7KtrYMYts8yXDTjoJirUpZg6QCfakOv KMLlFjVfUohJV/utHJlVPKs= =Nxbs -----END PGP SIGNATURE----- --SCOJXUq1iwCn05li-- --===============0421971426== 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 --===============0421971426==-- From tcpm-bounces@ietf.org Wed Nov 21 17:47:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyLh-0004TE-4w; Wed, 21 Nov 2007 17:47:13 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuyLg-0004PJ-7g for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:47:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyLf-0004P6-UG for tcpm@ietf.org; Wed, 21 Nov 2007 17:47:11 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuyLc-0000iN-Fp for tcpm@ietf.org; Wed, 21 Nov 2007 17:47:11 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lALMkt7V022932; Wed, 21 Nov 2007 14:46:56 -0800 (PST) Message-ID: <4744B557.1080100@isi.edu> Date: Wed, 21 Nov 2007 14:46:47 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC58044CE07B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CE07B@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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="===============1393996843==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1393996843== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3B53E06738C68B9C3632555C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B53E06738C68B9C3632555C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > John: > =20 >>> A) Do we agree that it is a problem ? [the title of the thread] >>> >>> Most people seem to agree on this. >> I would like to step back even further, and work on the=20 >> definition of "it" -- the problem we want to solve. In my=20 >> mail on Nov 14 (which did not elicit a response), I tried to=20 >> make the case that the issues framed in the draft are in fact=20 >> only a special case of a more general problem. >=20 > Sorry I haven't read that. Will do. >=20 >> I do not believe the indefinite nature of TCP's persist state=20 >> is intrinsically something we need to fix -- in fact, it is=20 >> clearly an important and useful feature of TCP. It might not=20 >> be terrible for a TCP implementation to provide a switch for=20 >> an implicit ABORT after a long persist timeout. However, in=20 >> my opinion this is not the best solution, or even a solution=20 >> at all to the more general problem. >=20 > Pl see the question I posed to in response to Ted's email. Having an > implicit ABORT or having a socket option is very useful thing. It is th= e > "basic infrastructure" needed in TCP and TCP API layer (like sockets). > Now, if I follow RFC 1122 language, it seems to preclude me from doing > the above. Doing such a thing is an RFC voliation? Does it need some > clarification? RFC1122 allows you to abort a connection explicitly. It allows you to have an user application timer to abort a connection explicitly. It allows you to have an OS timer that aborts a connection explicitly. To TCP, the OS and/or user application are not distinguishable. Now if you "set a local timer that initiates an explicit call" and want to call that "implicit", that's fine. It's still explicit ultimately (i.e., a real abort call is issued), and still supported by RFC793 and RFC1122. Joe --------------enig3B53E06738C68B9C3632555C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRLVXE5f5cImnZrsRAseOAJ4tru8d2EPBE40aCpxxvpMsmvXg9ACgqWmT NHkVpLl50lbVNTgseEpj6kw= =wGjy -----END PGP SIGNATURE----- --------------enig3B53E06738C68B9C3632555C-- --===============1393996843== 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 --===============1393996843==-- From tcpm-bounces@ietf.org Wed Nov 21 17:49:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyNS-0006zJ-Fg; Wed, 21 Nov 2007 17:49:02 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuyNR-0006yt-GB for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:49:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyNR-0006yf-4c for tcpm@ietf.org; Wed, 21 Nov 2007 17:49:01 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuyNN-0000mR-LG for tcpm@ietf.org; Wed, 21 Nov 2007 17:49:01 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lALMmexW024145; Wed, 21 Nov 2007 14:48:41 -0800 (PST) Message-ID: <4744B5C0.2050102@isi.edu> Date: Wed, 21 Nov 2007 14:48:32 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mahesh Jethanandani Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> <4744A639.2080404@cisco.com> In-Reply-To: <4744A639.2080404@cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1012308602==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1012308602== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62B247A911643801CA331DA1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62B247A911643801CA331DA1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani wrote: > Anantha Ramaiah (ananth) wrote: >> 1) It is asking to correct/clarify the verbiage of RFC 1122. ie., RFC >> 1122 tells the connections MUST persist forever as long as ACK's are >> received. Now, clearly as demonstrated in the draft, there needs to be= >> some ammount of robustness that can be built into the TCP layer, which= >> can allow the connection to be aborted after some stipulated time. Is >> this considered a change in the standards > I want to try to bring some focus back on the above point that the draf= t > is trying to make. >=20 > If we agree that there is a problem and the solution lies in aborting > the connection, however it is done, i.e. by application or by some TCP > implementation, then at the minimum we believe that a change is require= d > in the verbiage of RFC 1122. The change is to say that in case of > reliable ACK's coming back from the receiver, it is NOT a requirement > for the sender to keep the connection open indefinitely. >=20 > Can we agree on this? RFC1122 says that the connection MUST persist as long as ACKs are received. That means that TCP must not abort it. There is no restriction that the user (application) must not abort it. Joe --------------enig62B247A911643801CA331DA1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRLXAE5f5cImnZrsRAsYuAKCAe5FFrD0ph5PYBl0IleU4TgpI+QCgtAjU kjO4t5/MC4/kFMQqSYKtJ1g= =6tW7 -----END PGP SIGNATURE----- --------------enig62B247A911643801CA331DA1-- --===============1012308602== 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 --===============1012308602==-- From tcpm-bounces@ietf.org Wed Nov 21 17:56:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyUV-0003l9-Nl; Wed, 21 Nov 2007 17:56:19 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuyUU-0003jE-Q3 for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 17:56:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuyUU-0003j6-GS for tcpm@ietf.org; Wed, 21 Nov 2007 17:56:18 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuyUS-0001Cw-18 for tcpm@ietf.org; Wed, 21 Nov 2007 17:56:18 -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 lALMscTc022717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Nov 2007 14:54:38 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lALMschV020597; Wed, 21 Nov 2007 14:54:38 -0800 (PST) (envelope-from faber) Date: Wed, 21 Nov 2007 14:54:38 -0800 From: Ted Faber To: Mahesh Jethanandani Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Message-ID: <20071121225437.GK13024@hut.isi.edu> References: <20071121192901.GF13024@hut.isi.edu> <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com> <20071121213610.GH13024@hut.isi.edu> <4744AE06.1090808@cisco.com> Mime-Version: 1.0 In-Reply-To: <4744AE06.1090808@cisco.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0070623278==" Errors-To: tcpm-bounces@ietf.org --===============0070623278== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/jkxxxtAhYIHVDuh" Content-Disposition: inline --/jkxxxtAhYIHVDuh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just me, not a chair. On Wed, Nov 21, 2007 at 02:15:34PM -0800, Mahesh Jethanandani wrote: > Ted Faber wrote: > >An attacker who wanted to mount the DoS attack described in the draft > >could defeat your proposed mitigation by asking for the same large > >window and then draining it slowly rather than simply holding the zero > >window. The draft mentions that the silly window avoidance makes this > >difficult, but it just requires the attacker to ACK an MSS worth of data > >less frequently then if they read a single byte > This is a *proposed* solution. This is not a solution that we want to=20 > standardize on. I am sure with bright minds on this list we can come up= =20 > with better solutions to the problem and I am fine with that. >=20 > To answer your question, yes, they could. That situation is no different= =20 > from a connection that is slow but is making progress. In fact at that=20 > point it is not a persist connection. It is not advertising zero window.= =20 > We are specifically concerned about connections that take advantage of=20 > RFC 1122 verbiage to keep the connection in persist state. It seems to me that this is the same attack that motivated your defense, just made *slightly* trickier. To the owner of the attacked server there's not much difference in the result. I'm not thrilled to standardize something so easy to work around. I suspect that something hard to work around would be to complex and application-dependent to standardize into TCP. --=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 --/jkxxxtAhYIHVDuh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRLctaUz3f+Zf+XsRApK0AJ0ejhdHhz9PY06/A/1Q83zvcoApGgCgpwXp vCWsgcaFdKBtv4NX1pq/x2M= =wZaD -----END PGP SIGNATURE----- --/jkxxxtAhYIHVDuh-- --===============0070623278== 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 --===============0070623278==-- From tcpm-bounces@ietf.org Wed Nov 21 18:42:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuzCp-0003dA-Ev; Wed, 21 Nov 2007 18:42:07 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuzCn-0003WG-99 for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 18:42:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuzCm-0003Tr-TK for tcpm@ietf.org; Wed, 21 Nov 2007 18:42:04 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuzCm-0008GX-GS for tcpm@ietf.org; Wed, 21 Nov 2007 18:42:04 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Nov 2007 15:42:03 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALNg3u4026835; Wed, 21 Nov 2007 15:42:03 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lALNg3us025226; Wed, 21 Nov 2007 23:42:03 GMT 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, 21 Nov 2007 15:42:03 -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: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Date: Wed, 21 Nov 2007 15:42:03 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58044CE135@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4744B557.1080100@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Thread-Index: AcgskHVdDaPp4FB8Rr225a32/kl3gwABNm1Q From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 21 Nov 2007 23:42:03.0360 (UTC) FILETIME=[1E368600:01C82C98] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1442; t=1195688523; x=1196552523; c=relaxed/simple; s=sjdkim1004; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=sWVKhA34cmxb3fz1cJwywl2quzHAIT9ehixqrzbY6ME=; b=I7fWovjT4qwPQeEvNdwkfbUS93/SztW/B4A23Nu5T9vTeWKqW4ik4oWWJV45jo89S1MhRYYf k3CLpr7A/6L0O3nEp+U3vxDTx0mB5LI4eCFmIFNDXKaNxFLt4562KPUnltTyAFxC+brMLjEBLd hF+YAXmY/wXzDOzeq7naik0cE=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 >=20 > RFC1122 allows you to abort a connection explicitly. It=20 > allows you to have an user application timer to abort a=20 > connection explicitly. It allows you to have an OS timer that=20 > aborts a connection explicitly. To TCP, the OS and/or user=20 > application are not distinguishable. >=20 > Now if you "set a local timer that initiates an explicit=20 > call" and want to call that "implicit", that's fine. It's=20 > still explicit ultimately (i.e., a real abort call is=20 > issued), and still supported by RFC793 and RFC1122. Ok, I am not sure if the rest of the WG feels the same way you do. If what you say is true, implicit abort isn't an issue, so in theory I CAN have a timer inside my embedded system (it can running anywhere inhe system), and it can abort the connection through some interface. Actually no-one would even notice this behaviour since one really can't determine from "outside"" whether the connection was aborted implicitly or explicitly. So I gather that there is no need to have a standards change, since you seem to say that RFC allows you to abort a connection which everyone is aware of. But it is the same RFC that says you MUST persist a connection indefinetly as long as you receive ACKS, so you are now providing an external override for this MUST behaviour.=20 Hmm... I would also like to get others comment on this...=20 -Anantha >=20 > Joe >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 18:54:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuzOO-0007h6-O4; Wed, 21 Nov 2007 18:54:04 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuzON-0007fi-5u for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 18:54:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuzOM-0007fZ-RF for tcpm@ietf.org; Wed, 21 Nov 2007 18:54:02 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuzOM-0000f1-AJ for tcpm@ietf.org; Wed, 21 Nov 2007 18:54:02 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lALNrj9u011336; Wed, 21 Nov 2007 15:53:46 -0800 (PST) Message-ID: <4744C501.4090801@isi.edu> Date: Wed, 21 Nov 2007 15:53:37 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC58044CE135@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CE135@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 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="===============0962375473==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0962375473== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig04E66331E2B01237DAEA3D6D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig04E66331E2B01237DAEA3D6D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >=20 >> RFC1122 allows you to abort a connection explicitly. It=20 >> allows you to have an user application timer to abort a=20 >> connection explicitly. It allows you to have an OS timer that=20 >> aborts a connection explicitly. To TCP, the OS and/or user=20 >> application are not distinguishable. >> >> Now if you "set a local timer that initiates an explicit=20 >> call" and want to call that "implicit", that's fine. It's=20 >> still explicit ultimately (i.e., a real abort call is=20 >> issued), and still supported by RFC793 and RFC1122. >=20 > Ok, I am not sure if the rest of the WG feels the same way you do. If > what you say is true, implicit abort isn't an issue, so in theory I CAN= > have a timer inside my embedded system (it can running anywhere inhe > system), and it can abort the connection through some interface. > Actually no-one would even notice this behaviour since one really can't= > determine from "outside"" whether the connection was aborted implicitly= > or explicitly. That's right. > So I gather that there is no need to have a standards change, since you= > seem to say that RFC allows you to abort a connection which everyone is= > aware of. But it is the same RFC that says you MUST persist a connectio= n > indefinetly as long as you receive ACKS, so you are now providing an > external override for this MUST behaviour.=20 I think the relevant text is: 4.2.2.17 Probing Zero Windows: RFC-793 Section 3.7, page 42 Probing of zero (offered) windows MUST be supported. A TCP MAY keep its offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open. TCP. Not the user. Users get to abort connections. 4.2.2.13 Closing a Connection: RFC-793 Section 3.5 A TCP connection may terminate in two ways: (1) the normal TCP close sequence using a FIN handshake, and (2) an "abort" in which one or more RST segments are sent and the connection state is immediately discarded. FWIW. Joe --------------enig04E66331E2B01237DAEA3D6D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRMUBE5f5cImnZrsRAgkPAJ9OeNIyM+iOCPIZzgyRx4bq3dyqhQCgyhi7 1ggZg84FbUqVNdDuL3376y4= =Rggj -----END PGP SIGNATURE----- --------------enig04E66331E2B01237DAEA3D6D-- --===============0962375473== 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 --===============0962375473==-- From tcpm-bounces@ietf.org Wed Nov 21 19:10:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuzef-000765-1d; Wed, 21 Nov 2007 19:10:53 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iuzed-000760-T0 for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 19:10:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuzed-00075U-9m for tcpm@ietf.org; Wed, 21 Nov 2007 19:10:51 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuzea-000526-TL for tcpm@ietf.org; Wed, 21 Nov 2007 19:10: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 lAM0ARis021672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Nov 2007 16:10:28 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lAM0AR9n022497; Wed, 21 Nov 2007 16:10:27 -0800 (PST) (envelope-from faber) Date: Wed, 21 Nov 2007 16:10:27 -0800 From: Ted Faber To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Message-ID: <20071122001027.GL13024@hut.isi.edu> References: <20071121213610.GH13024@hut.isi.edu> <0C53DCFB700D144284A584F54711EC58044CE0C4@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CE0C4@xmb-sjc-21c.amer.cisco.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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="===============1135523226==" Errors-To: tcpm-bounces@ietf.org --===============1135523226== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uwB7x3tnyrZQfZJI" Content-Disposition: inline --uwB7x3tnyrZQfZJI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 21, 2007 at 02:24:54PM -0800, Anantha Ramaiah (ananth) wrote: > =20 > >=20 > > I don't understand your snicker quotes around standardize. =20 > > Changing a MUST NOT to a MAY or SHOULD NOT in 1122 is about=20 > > as serious as standardizarion effort as one can undertake in TCPM. >=20 > Actually I asked the same question below :-) My understanding was the > same ie., changing verbiage is indeed a standardization effort.=20 That's because you're asking to change the standard. There's no issue of clarification here. A conformant TCP implementation allows connections to hold a zero window indefinitely. Consumers of the stack's service (OS,applications) can abort TCP connections at will. Admittedly that's a fine distinction, but that's not necessarily a bad thing. It basically gives you the leeway to manage your local resources. > >=20 > > I (personally) don't see the point of publishing an RFC that=20 > > describes a technique that a conformant TCP cannot implement. >=20 > I agree. So my understanding is that wherever the solution lies, be it a > socket option that can be set by the application OR an implicit timer > within TCP or whatever means, irrrespective of the method chosen, this > warrants a change in the RFC 1122 or atleast a clarification in the > existing verbiage w.r.t zero window probes? Do you agree? I think 1122 is perfectly clear and perfectly workable. The TCP stack cannot terminate those connections. The OS or an application may. People who wish to manage their resources in the way the authors advocate can do it in the OS or the application. The admitted fuzzyness of the lines between OS and TCP stack allows a broad interpretation of whether a given piece of code is in the OS or TCP stack. I don't see a pressing need to change the standards to implement a persist state killer in the OS. >=20 > If so then do we agree as a WG to make the change since this is required > irrespective of the fact where the solution lies? I categorically disagree. Having your OS terminate a TCP connection through TCP's abort interface violates no RFC that I can see. FWIW, I think that looking for the persist state rather than resource use and slow progress is the wrong way to select connections for abort, but I believe that the standards allow the OS to do either. > OR do folks in the list have some solution in mind which can be done > without touching the standards? I believe the author's solution violates no RFC.=20 >=20 > Sorry, I haven't yet seen this particular discussion happening which is > the main purpose of my email. The only thing so far was a few people > saying that there is no need to change RFC 1122, but I am afraid I > haven't seen the reasons and/or alternate proposals. The application can identify connections making slow progress when alerted by the OS that there is resource contention, or when resource use by the application passes a threshold. The application can implement the authors' scheme exactly using information from the STATUS call in RFC 793, which TCP implementations provide. Put it in a library so other apps can link to it. The application can cull connections holding a zero window when the OS alerts it to low resources. The OS can terminate the connections with the largest memory usage in the face of resource exhaustion. The OS can terminate connections that have been open the longest in times of resource contention. The OS can terminate connections that have been open longer than a fixed threshold. The OS can terminate applications using a large amount of resources in time of contentention or deadlock, terminating their connections=20 > > An attacker who wanted to mount the DoS attack described in=20 > > the draft could defeat your proposed mitigation by asking for=20 > > the same large window and then draining it slowly rather than=20 > > simply holding the zero window. The draft mentions that the=20 > > silly window avoidance makes this difficult, but it just=20 > > requires the attacker to ACK an MSS worth of data less=20 > > frequently then if they read a single byte. >=20 > Agreed. Didn't you just agree that the proposed system has a simple workaround? --=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 --uwB7x3tnyrZQfZJI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRMjzaUz3f+Zf+XsRArWgAJ9W44AgzvpoUR2GyDpAMEhjiabdzwCfY/pw tIHoXt8Hy7HZSfJ8VyzF0eo= =H95i -----END PGP SIGNATURE----- --uwB7x3tnyrZQfZJI-- --===============1135523226== 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 --===============1135523226==-- From tcpm-bounces@ietf.org Wed Nov 21 19:10:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuzei-000788-FG; Wed, 21 Nov 2007 19:10:56 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iuzeg-00077k-Ti for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 19:10:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuzeg-00076k-8m for tcpm@ietf.org; Wed, 21 Nov 2007 19:10:54 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuzeb-000529-Ax for tcpm@ietf.org; Wed, 21 Nov 2007 19:10:54 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-6.cisco.com with ESMTP; 21 Nov 2007 16:10:48 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id lAM0AmdT026605; Wed, 21 Nov 2007 16:10:48 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAM0AmAx020253; Thu, 22 Nov 2007 00:10:48 GMT 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, 21 Nov 2007 16:10:48 -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: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Date: Wed, 21 Nov 2007 16:10:49 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580452BB46@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4744C501.4090801@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Thread-Index: Acgsmcs9rxAPDSYlShuFi8ARR4u+vQAAMPxA From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 22 Nov 2007 00:10:48.0735 (UTC) FILETIME=[229DDAF0:01C82C9C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2099; t=1195690248; x=1196554248; c=relaxed/simple; s=sjdkim8002; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=tLcx546y30aeOKBTSD0bJmpr+Ez6QTivu7S//lyHcRU=; b=I1MdN0JLGaouKdAWTFESOQoBxHo9SgUXNZHZonX8yQQqCs3iYOz1no8F674L8aClOJSJrRQa k6/RJSMDIp+GkM2ih0F+vZc7npAeava87w1SL1W7eSBLl0YqF6o2FThx; Authentication-Results: sj-dkim-8; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 >=20 > > So I gather that there is no need to have a standards change, since=20 > > you seem to say that RFC allows you to abort a connection which=20 > > everyone is aware of. But it is the same RFC that says you MUST=20 > > persist a connection indefinetly as long as you receive=20 > ACKS, so you=20 > > are now providing an external override for this MUST behaviour. >=20 > I think the relevant text is: >=20 > 4.2.2.17 Probing Zero Windows: RFC-793 Section 3.7, page 42 >=20 > Probing of zero (offered) windows MUST be supported. >=20 > A TCP MAY keep its offered receive window closed > indefinitely. As long as the receiving TCP continues to > send acknowledgments in response to the probe=20 > segments, the > sending TCP MUST allow the connection to stay open. >=20 > TCP. Not the user. Users get to abort connections. >=20 > 4.2.2.13 Closing a Connection: RFC-793 Section 3.5 >=20 > A TCP connection may terminate in two ways: (1) the normal > TCP close sequence using a FIN handshake, and (2)=20 > an "abort" > in which one or more RST segments are sent and the > connection state is immediately discarded. >=20 > FWIW. I know I have read the above text many times, but there is an inconsitency here. While it says that TCP MUST keep the persist connection open, in the other hand it also says users can abort the connection no matter what state it is in. So implementations can chose to have some optimal schemes built inside TCP module on behalf of the applications ( it is just a matter of programming/implementation) and have an implicit timer inside TCP which kills the TCP connection when timer expires and can inform the application about the connection death. [All the above actions are compliant to the RFC since RFC doesn't talk about how to implement TCP and it just gives a guidance, the term user/application and TCP are just used to illustrate the concept.] -Anantha >=20 > Joe >=20 >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 21 19:14:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuziK-0008QB-AL; Wed, 21 Nov 2007 19:14:40 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuziI-0008PA-QU for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 19:14:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuziI-0008OB-EX for tcpm@ietf.org; Wed, 21 Nov 2007 19:14:38 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuziH-0001nl-VA for tcpm@ietf.org; Wed, 21 Nov 2007 19:14:38 -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 lAM0DBOd022462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Nov 2007 16:13:12 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lAM0DB3C022568; Wed, 21 Nov 2007 16:13:11 -0800 (PST) (envelope-from faber) Date: Wed, 21 Nov 2007 16:13:11 -0800 From: Ted Faber To: Joe Touch Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Message-ID: <20071122001311.GM13024@hut.isi.edu> References: <0C53DCFB700D144284A584F54711EC58044CDF71@xmb-sjc-21c.amer.cisco.com> <4744A639.2080404@cisco.com> <4744B5C0.2050102@isi.edu> Mime-Version: 1.0 In-Reply-To: <4744B5C0.2050102@isi.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0200148283==" Errors-To: tcpm-bounces@ietf.org --===============0200148283== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="muT+E17Lr9urPYYJ" Content-Disposition: inline --muT+E17Lr9urPYYJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable No hat. On Wed, Nov 21, 2007 at 02:48:32PM -0800, Joe Touch wrote: >=20 >=20 > Mahesh Jethanandani wrote: > > Anantha Ramaiah (ananth) wrote: > >> 1) It is asking to correct/clarify the verbiage of RFC 1122. ie., RFC > >> 1122 tells the connections MUST persist forever as long as ACK's are > >> received. Now, clearly as demonstrated in the draft, there needs to be > >> some ammount of robustness that can be built into the TCP layer, which > >> can allow the connection to be aborted after some stipulated time. Is > >> this considered a change in the standards > > I want to try to bring some focus back on the above point that the draft > > is trying to make. > >=20 > > If we agree that there is a problem and the solution lies in aborting > > the connection, however it is done, i.e. by application or by some TCP > > implementation, then at the minimum we believe that a change is required > > in the verbiage of RFC 1122. The change is to say that in case of > > reliable ACK's coming back from the receiver, it is NOT a requirement > > for the sender to keep the connection open indefinitely. > >=20 > > Can we agree on this? >=20 > RFC1122 says that the connection MUST persist as long as ACKs are > received. That means that TCP must not abort it. There is no restriction > that the user (application) must not abort it. The OS may also abort a TCP connection for arbitary reason, in my reading. --=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 --muT+E17Lr9urPYYJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRMmXaUz3f+Zf+XsRAuB4AJ0TWrZwwhRX1HXtGir/FHr+v7BdVwCfRDBm 3XraN0Io93iFleGuI0ScSas= =r6CN -----END PGP SIGNATURE----- --muT+E17Lr9urPYYJ-- --===============0200148283== 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 --===============0200148283==-- From tcpm-bounces@ietf.org Wed Nov 21 19:38:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv054-0002l5-Un; Wed, 21 Nov 2007 19:38:10 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iv053-0002bD-Jr for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 19:38:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv053-0002Zm-9v for tcpm@ietf.org; Wed, 21 Nov 2007 19:38:09 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv04z-0006LC-E6 for tcpm@ietf.org; Wed, 21 Nov 2007 19:38:09 -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 lAM0anq6000893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Nov 2007 16:36:49 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lAM0an8C022876; Wed, 21 Nov 2007 16:36:49 -0800 (PST) (envelope-from faber) Date: Wed, 21 Nov 2007 16:36:48 -0800 From: Ted Faber To: Mahesh Jethanandani Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Message-ID: <20071122003648.GN13024@hut.isi.edu> References: <20071121192901.GF13024@hut.isi.edu> <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com> <20071121213610.GH13024@hut.isi.edu> <4744AE06.1090808@cisco.com> <20071121224514.GJ13024@hut.isi.edu> Mime-Version: 1.0 In-Reply-To: <20071121224514.GJ13024@hut.isi.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0933977406==" Errors-To: tcpm-bounces@ietf.org --===============0933977406== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OAiy6VLsECigG9dy" Content-Disposition: inline --OAiy6VLsECigG9dy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As an individual. On Wed, Nov 21, 2007 at 02:45:14PM -0800, Ted Faber wrote: > On Wed, Nov 21, 2007 at 02:15:34PM -0800, Mahesh Jethanandani wrote: > > I saw this e-mail just after I had hit the send button for my last e-ma= il. > >=20 > > Ted Faber wrote: > > >I (personally) don't see the point of publishing an RFC that describes > > >a technique that a conformant TCP cannot implement. > > > =20 > > I do not see any reason why the proposed solution cannot be implemented= .=20 > > Are you suggesting that because we cannot implement it is why it should= =20 > > not be implemented? >=20 > The conformant TCP cannot implement the fix because it would violate > 1122 and then no longer be a conformant TCP.=20 >=20 > I understand you can write the code. This is actually pretty unclear of me. I seem to be arguing both that the mechanism in the draft violates 1122 and doesn't. Let me be more careful: A system that requires an IETF standard interface to the TCP stack that specifies a timeout to abort connections holding a zero window longer than that timeout violates 1122, IMHO. Because the interface is to TCP that implies that TCP would do the abort and this action (TCP doing the abort) would violate 1122. You can't describe the system as an interface to TCP and not have it violate 1122. A system that adds an OS interface to do the same thing would not violate 1122. The interface needn't pass through the IETF, which doesn't standardize application <-> OS interfaces. The OS aborting a TCP connection violates no RFC I can think of. No IETF standards action required here, though if you wanted to make it part of a standard OS interface, the interface would need to be reviewed by the relevant body. I realize that there's an odd something going on here in that the same action, described slightly differently, does or doesn't require a standards change. The difference is that the first choice - creating a new TCP interface - has ramifications (admittedly small ones) to other TCP implementations. Ramifications to other TCP interfaces means the changes need to conform to other standards. Given that you can implement the mitigation either with or without changing standards, why change them? --=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 --OAiy6VLsECigG9dy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHRM8gaUz3f+Zf+XsRAhwGAJ9WR/aA4nVd3TrOHNwGx4zER0+BjACg7tNg 3Sd49TvW8b+BjQBYCaz4UYA= =6jx8 -----END PGP SIGNATURE----- --OAiy6VLsECigG9dy-- --===============0933977406== 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 --===============0933977406==-- From tcpm-bounces@ietf.org Thu Nov 22 00:10:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv4Kp-0001ZW-5v; Thu, 22 Nov 2007 00:10:43 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iv4Km-0001N2-Vv for tcpm-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 00:10:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv4Km-0001Jg-6o for tcpm@ietf.org; Thu, 22 Nov 2007 00:10:40 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv4Kl-0005Au-KL for tcpm@ietf.org; Thu, 22 Nov 2007 00:10:40 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAM5AS0X024390; Wed, 21 Nov 2007 21:10:29 -0800 (PST) Message-ID: <47450F3C.6030000@isi.edu> Date: Wed, 21 Nov 2007 21:10:20 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC580452BB46@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580452BB46@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 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: , Content-Type: multipart/mixed; boundary="===============0240889932==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0240889932== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4D084203696B370DC90D4447" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4D084203696B370DC90D4447 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >>> So I gather that there is no need to have a standards change, since=20 >>> you seem to say that RFC allows you to abort a connection which=20 >>> everyone is aware of. But it is the same RFC that says you MUST=20 >>> persist a connection indefinetly as long as you receive=20 >> ACKS, so you=20 >>> are now providing an external override for this MUST behaviour. >> I think the relevant text is: >> >> 4.2.2.17 Probing Zero Windows: RFC-793 Section 3.7, page 42 >> >> Probing of zero (offered) windows MUST be supported. >> >> A TCP MAY keep its offered receive window closed >> indefinitely. As long as the receiving TCP continues to >> send acknowledgments in response to the probe=20 >> segments, the >> sending TCP MUST allow the connection to stay open. >> >> TCP. Not the user. Users get to abort connections. >> >> 4.2.2.13 Closing a Connection: RFC-793 Section 3.5 >> >> A TCP connection may terminate in two ways: (1) the normal= >> TCP close sequence using a FIN handshake, and (2)=20 >> an "abort" >> in which one or more RST segments are sent and the >> connection state is immediately discarded. >> >> FWIW. >=20 > I know I have read the above text many times, but there is an > inconsitency here. While it says that TCP MUST keep the persist > connection open, in the other hand it also says users can abort the > connection no matter what state it is in.=20 There is no inconsistency. TCP keeps things open until told to do otherwise by the application. The point of the text is that it is not TCP's decision to close the connection - that's precisely because the application can do so if needed= =2E TCP always does as instructed by the user - i.e., when an ABORT or CLOSE is issued. The point of the text is that TCP doesn't make a decision to close the connection itself, not that the user can't make that command. > So implementations can chose > to have some optimal schemes built inside TCP module on behalf of the > applications ( it is just a matter of programming/implementation) and > have an implicit timer inside TCP which kills the TCP connection when > timer expires and can inform the application about the connection death= =2E That timer would need to have a default of "infinite" - i.e., it would default to never going off - to be compliant with RFC1122. Only if the application instructed it otherwise could it activate. Putting the timer inside TCP does nothing useful at that point except complicate TCP. The timer can be in the OS or in the application with exactly the same effect. > [All the above actions are compliant to the RFC since RFC doesn't talk > about how to implement TCP and it just gives a guidance, the term > user/application and TCP are just used to illustrate the concept.] If the timer defaults to "infinite", then yes, it would be compliant with RFC1122. That doesn't change current behavior, though. Joe --------------enig4D084203696B370DC90D4447 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRQ88E5f5cImnZrsRAmSbAJkBxyPzAi3Fxsl1kz5VYL8j4RItUgCdFpZX T4oeik/JdS7pKIQl55pug4M= =i3KB -----END PGP SIGNATURE----- --------------enig4D084203696B370DC90D4447-- --===============0240889932== 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 --===============0240889932==-- From tcpm-bounces@ietf.org Thu Nov 22 00:33:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv4h7-0007ts-02; Thu, 22 Nov 2007 00:33:45 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iv4h5-0007tm-Fg for tcpm-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 00:33:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv4h5-0007te-4n for tcpm@ietf.org; Thu, 22 Nov 2007 00:33:43 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv4h4-0005rq-NA for tcpm@ietf.org; Thu, 22 Nov 2007 00:33:43 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 21 Nov 2007 21:33:42 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAM5Xg4S013910; Wed, 21 Nov 2007 21:33:42 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAM5Xfb4012738; Thu, 22 Nov 2007 05:33:41 GMT 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); Wed, 21 Nov 2007 21:33:41 -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: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Date: Wed, 21 Nov 2007 21:33:41 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580452BBAB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47450F3C.6030000@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Thread-Index: AcgsxgfdN2Y8N/TeQyaYu6GS87TdXQAAUxug From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 22 Nov 2007 05:33:41.0716 (UTC) FILETIME=[3DD02940:01C82CC9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1709; t=1195709622; x=1196573622; c=relaxed/simple; s=sjdkim1004; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=6gWcWCyV+F0SJeRc25bJCrrO8Puul+SvrYr/0EdiUaQ=; b=EY24EzecMxN1gLiPZLmE39B6x9m0osviMhMgDZx6WSlxu5v833W3Jdi6sCX9ewzixOoQMc+f 05tsgujn2U3kNQOKG2n7bkaz+ux5U+LAWoQqTURub/CV0L8uSk1aMKETu0ofcgQzooEBu0sHZ7 gAAT6TBNhsy2FMxrSSv18f5qA=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org =20 >=20 > > So implementations can chose > > to have some optimal schemes built inside TCP module on=20 > behalf of the=20 > > applications ( it is just a matter of=20 > programming/implementation) and=20 > > have an implicit timer inside TCP which kills the TCP=20 > connection when=20 > > timer expires and can inform the application about the=20 > connection death. >=20 > That timer would need to have a default of "infinite" - i.e.,=20 > it would default to never going off - to be compliant with=20 > RFC1122. Only if the application instructed it otherwise=20 > could it activate. >=20 > Putting the timer inside TCP does nothing useful at that=20 > point except complicate TCP. The timer can be in the OS or in=20 > the application with exactly the same effect. That is your viewpoint, I can list the advantages of why putting the timer inside TCP works for me. It may add some extra code to TCP but make the application(s) life easier.=20 =20 >=20 > > [All the above actions are compliant to the RFC since RFC=20 > doesn't talk=20 > > about how to implement TCP and it just gives a guidance, the term=20 > > user/application and TCP are just used to illustrate the concept.] >=20 > If the timer defaults to "infinite", then yes, it would be=20 > compliant with RFC1122. That doesn't change current behavior, though. Yes, needless to say the timer would be initialised to infinity OR the timer would never be started unless it is programmed to do so. So, I think we are in agreement here that it doesn't matter from which context you are aborting the TCP connection which is hanging in the persist state. Any abort is compliant with the RFC.=20 -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 22 06:10:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9we-0005dj-Cq; Thu, 22 Nov 2007 06:10:08 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iv9wb-0005Yc-7z for tcpm-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 06:10:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9wa-0005YT-Rj for tcpm@ietf.org; Thu, 22 Nov 2007 06:10:04 -0500 Received: from bgerelbas01.asiapac.hp.net ([15.219.201.134]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv9wa-0001Zj-5u for tcpm@ietf.org; Thu, 22 Nov 2007 06:10:04 -0500 Received: from bgeexg11.asiapacific.cpqcorp.net (bgeexg11.asiapacific.cpqcorp.net [16.150.33.26]) by bgerelbas01.asiapac.hp.net (Postfix) with ESMTP id 267223303E for ; Thu, 22 Nov 2007 16:40:48 +0530 (IST) Received: from BGEEXC07.asiapacific.cpqcorp.net ([16.150.33.19]) by bgeexg11.asiapacific.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 16:39:34 +0530 Received: from [16.181.46.93] ([16.181.46.93]) by BGEEXC07.asiapacific.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 16:39:35 +0530 From: Kuthonuzo Luruo To: tcpm@ietf.org Content-Type: text/plain Date: Thu, 22 Nov 2007 16:44:36 +0530 Message-Id: <1195730077.4802.68.camel@knuth.india.hp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Nov 2007 11:09:35.0350 (UTC) FILETIME=[2A50A960:01C82CF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [tcpm] PAWS wraparound 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 Consider a TCP connection that is long-lived enough (> 24 days, with timestamp clock frequency of 1ms) for timestamp wraparound to occur at one end. Assume that the connection has *not* been idle for more than 24 days. According to RFC1323, the PAWS check would drop all incoming segments from the host that wrapped, since TSVal would be less than TSRecent and TSRecent will not get updated. Am I missing something here? thanks -thonuzo _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 22 14:25:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvHfP-0005JR-E0; Thu, 22 Nov 2007 14:24:51 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IvHfO-0005Ie-L5 for tcpm-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 14:24:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvHfN-0005IW-Vb for tcpm@ietf.org; Thu, 22 Nov 2007 14:24:49 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvHfJ-0003fT-Sv for tcpm@ietf.org; Thu, 22 Nov 2007 14:24:49 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAMJOTRZ021723; Thu, 22 Nov 2007 11:24:29 -0800 (PST) Message-ID: <4745D765.2090706@isi.edu> Date: Thu, 22 Nov 2007 11:24:21 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC580452BBAB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580452BBAB@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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="===============0837970782==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0837970782== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA08E7463A2F43F4B51F07083" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA08E7463A2F43F4B51F07083 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. > Yes, needless to say the timer would be initialised to infinity OR the > timer would never be started unless it is programmed to do so. >=20 > So, I think we are in agreement here that it doesn't matter from which > context you are aborting the TCP connection which is hanging in the > persist state. Any abort is compliant with the RFC.=20 Any abort under application control is compliant with 1122. At which point, putting it inside the TCP code vs. elsewhere in the OS, vs. in the application are all implementation decisions. That would not be a change to TCP, and would not include a recommendation to implement it inside TCP. If you're asking to extend the TCP API to include access to a TCP timer for this purpose - and thus to make that standard (which is what an API extension would require), I think the consensus has been that lazy application design is not a motivation for unnecessarily overcomplicating the TCP API. Joe --------------enigA08E7463A2F43F4B51F07083 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRddlE5f5cImnZrsRArXJAKD+6TiHJ4UMZkWPpRcVsAlzDq+tWwCfc2Cq SKIlAvcgOOMGhTtLcFXsjJE= =zAVS -----END PGP SIGNATURE----- --------------enigA08E7463A2F43F4B51F07083-- --===============0837970782== 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 --===============0837970782==-- From tcpm-bounces@ietf.org Thu Nov 22 23:01:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvPjH-0001GH-QW; Thu, 22 Nov 2007 23:01:23 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IvPjH-0001BN-2S for tcpm-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 23:01:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvPjG-000193-M8 for tcpm@ietf.org; Thu, 22 Nov 2007 23:01:22 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvPjG-0001Pr-Ay for tcpm@ietf.org; Thu, 22 Nov 2007 23:01:22 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 22 Nov 2007 20:01:21 -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 lAN41Loq029092; Thu, 22 Nov 2007 20:01:21 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAN41LAx012225; Fri, 23 Nov 2007 04:01:21 GMT 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); Thu, 22 Nov 2007 20:01:21 -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: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Date: Thu, 22 Nov 2007 20:01:19 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580452BBEF@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4745D765.2090706@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Thread-Index: AcgtPVc54hKlQJkdTciPV87a1/lJqgARJyEg From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 23 Nov 2007 04:01:21.0393 (UTC) FILETIME=[81EFB610:01C82D85] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1058; t=1195790481; x=1196654481; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=/py4iq4uS+PKViagckt4vsPnrpg5s8PcxIy+ZMlRyKQ=; b=Qmvq8PRsasUoh6jtjmHoS0L+VHa1AidJ/8w7dOh8GLSy17d9RI4KlnTlmrvUzWr4YSxvnhZO wz3qnAPtLFEujyEG78KaHl94kaky5yu/1JJNA7HTcrPKSRG13YqJwNAn; 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: 9182cfff02fae4f1b6e9349e01d62f32 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 >=20 > Any abort under application control is compliant with 1122. >=20 > At which point, putting it inside the TCP code vs. elsewhere=20 > in the OS, vs. in the application are all implementation=20 > decisions. That would not be a change to TCP, and would not=20 > include a recommendation to implement it inside TCP. Correct. Anways an informational RFC should not be recommending anything (which you also pointed out) >=20 > If you're asking to extend the TCP API to include access to a=20 > TCP timer for this purpose - and thus to make that standard=20 > (which is what an API extension would require), I think the=20 > consensus has been that lazy application design is not a=20 > motivation for unnecessarily overcomplicating the TCP API. Not sure what you mean above. RFC Compliance applies to protocol, not to API. API is a local thing. One implementation can use sockets, whereas other can using something totally different, what matters is what is sent on the wire and the response which is received.=20 -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 23 02:13:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvSjG-0007b0-1v; Fri, 23 Nov 2007 02:13:34 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IvSjE-0007Px-3R for tcpm-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 02:13:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvSjD-0007JD-Ic for tcpm@ietf.org; Fri, 23 Nov 2007 02:13:31 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvSjD-0006DD-1m for tcpm@ietf.org; Fri, 23 Nov 2007 02:13:31 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAN7DEpS022011; Thu, 22 Nov 2007 23:13:15 -0800 (PST) Message-ID: <47467D82.9070501@isi.edu> Date: Thu, 22 Nov 2007 23:13:06 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC580452BBEF@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580452BBEF@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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="===============0968010222==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0968010222== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig37A3E05A4D7F36D98DC97DD9" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig37A3E05A4D7F36D98DC97DD9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: =2E.. >> If you're asking to extend the TCP API to include access to a=20 >> TCP timer for this purpose - and thus to make that standard=20 >> (which is what an API extension would require), I think the=20 >> consensus has been that lazy application design is not a=20 >> motivation for unnecessarily overcomplicating the TCP API. >=20 > Not sure what you mean above. RFC Compliance applies to protocol, not t= o > API.=20 Please see RFC793. It specifies an API. Although the IETF avoided APIs for a while, my understanding is that they are again considered relevant standards work. > API is a local thing. One implementation can use sockets, whereas > other can using something totally different, what matters is what is > sent on the wire and the response which is received.=20 A protocol is defined by: - formats of packets sent on the wire - state at the endpoints - events that cause state transitions, packet emissions, and signals to the application, triggered by: - packets arriving - upper layer commands (i.e., "application" events) - time RFC793 is a good example of this set. The upper layer commmands and signals to the upper layer constitute the API, and it is as much a part of the protocol as packets on the wire. Although there are a variety of ways to implement a SEND, RECEIVE, OPEN, CLOSE, STATUS, or ABORT, all TCP implementations must include them in their API, and they and their basic arguments are specified in RFC793. Joe --------------enig37A3E05A4D7F36D98DC97DD9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHRn2CE5f5cImnZrsRAjmTAJ9GUwdsMGTZDSOYLZ01b0pckGm9kACffvHl u2+o5k7zqU4Wiu7L2Xnz/MI= =B3Dv -----END PGP SIGNATURE----- --------------enig37A3E05A4D7F36D98DC97DD9-- --===============0968010222== 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 --===============0968010222==-- From tcpm-bounces@ietf.org Fri Nov 23 13:24:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvdCf-0000Ll-NA; Fri, 23 Nov 2007 13:24:37 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IvdCd-0000Lc-Md for tcpm-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 13:24:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvdCd-0000LU-Cm for tcpm@ietf.org; Fri, 23 Nov 2007 13:24:35 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvdCa-0001a3-Jz for tcpm@ietf.org; Fri, 23 Nov 2007 13:24:35 -0500 Received: from pc6 (1Cust54.tnt9.lnd4.gbr.da.uu.net [62.188.138.54]) by blaster.systems.pipex.net (Postfix) with SMTP id 35682E0002FE for ; Fri, 23 Nov 2007 18:24:30 +0000 (GMT) Message-ID: <027601c82df5$a92b8c20$0601a8c0@pc6> From: "Tom Petch" Cc: References: <0C53DCFB700D144284A584F54711EC58044CE135@xmb-sjc-21c.amer.cisco.com> Subject: Re: Summary of responses so far and proposal moving forward [WasRe: [tcpm] Is this a problem?] Date: Fri, 23 Nov 2007 16:04:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -98.0 (---------------------------------------------------) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org ----- Original Message ----- From: "Anantha Ramaiah (ananth)" To: "Joe Touch" Cc: Sent: Thursday, November 22, 2007 12:42 AM Subject: RE: Summary of responses so far and proposal moving forward [WasRe: [tcpm] Is this a problem?] > > RFC1122 allows you to abort a connection explicitly. It > allows you to have an user application timer to abort a > connection explicitly. It allows you to have an OS timer that > aborts a connection explicitly. To TCP, the OS and/or user > application are not distinguishable. > > Now if you "set a local timer that initiates an explicit > call" and want to call that "implicit", that's fine. It's > still explicit ultimately (i.e., a real abort call is > issued), and still supported by RFC793 and RFC1122. Ok, I am not sure if the rest of the WG feels the same way you do. If what you say is true, implicit abort isn't an issue, so in theory I CAN have a timer inside my embedded system (it can running anywhere inhe system), and it can abort the connection through some interface. Actually no-one would even notice this behaviour since one really can't determine from "outside"" whether the connection was aborted implicitly or explicitly. So I gather that there is no need to have a standards change, since you seem to say that RFC allows you to abort a connection which everyone is aware of. But it is the same RFC that says you MUST persist a connection <> Anantha No, that is not what the RFC says; as Joe has pointed out, the RFC says what TCP MUST do (and that changing it is a big deal). Note the title of the RFC - 'Requirements for Internet Hosts - Communication Layers' - and that there is a companion RFC1123, dated now because applications have moved on, but you will not find in the latter prohibitions on applications terminating connections. RFC1122 defines what is available for applications to use, what applications can rely on; it does not define what those applications do with that functionality. So; is there a problem? Yes, but it could be regarded as an implementation problem rather than a protocol one, and certainly not worth a change in TCP. Worth an RFC? may be. Tom Petch <> indefinetly as long as you receive ACKS, so you are now providing an external override for this MUST behaviour. Hmm... I would also like to get others comment on this... -Anantha > > Joe > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Nov 24 02:53:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivppi-00046I-Mv; Sat, 24 Nov 2007 02:53:46 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ivpph-0003wq-Qd for tcpm-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 02:53:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivppc-0003gP-AG for tcpm@ietf.org; Sat, 24 Nov 2007 02:53:40 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivppb-0002O7-PR for tcpm@ietf.org; Sat, 24 Nov 2007 02:53:40 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Nov 2007 23:53:39 -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 lAO7rd9M010104; Fri, 23 Nov 2007 23:53:39 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAO7rdb4018426; Sat, 24 Nov 2007 07:53:39 GMT 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); Fri, 23 Nov 2007 23:53:38 -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: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Date: Fri, 23 Nov 2007 23:53:37 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580452BC32@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47467D82.9070501@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Thread-Index: AcgtoFpOgt2rNyvPSV26pdUJJ4LQZgAyeaQg From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 24 Nov 2007 07:53:38.0893 (UTC) FILETIME=[1FBF2FD0:01C82E6F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3170; t=1195890819; x=1196754819; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=rIPip7uwkAgdnWMojRpaFCV3nBEE5F3BalhDw0sQIlU=; b=C+LfKgObUPLupCtqXEby2w9KDg/LZwiRl8c9N5oQd/ekdCg8TlYp67MWEVDZ0ytBe7Yl9f9P 2HtXwJETX6LBUsCrIAao6qUktIM+is0/lkv7oqIX0I7y5Pp1f3hnPXBG; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 > > Not sure what you mean above. RFC Compliance applies to=20 > protocol, not=20 > > to API. >=20 > Please see RFC793. It specifies an API. Although the IETF=20 > avoided APIs for a while, my understanding is that they are=20 > again considered relevant standards work. I don't think so. The API's specified by 793 needs to treated as illustrational purposes only, they are not supposed to be interpreted as standards. Like you noted above : "It specifies an API" not "the API". Now RFC 793 doesn't talk about sockets, it doesn't talk about SO_LINGER and SO_KEEPALIVE for example, does it mean that any stack which implements API's not mentioned by RFC 793, isn't compliant? Nope. =20 Again for example Keepalive option is very common in all TCP stacks, now RFC doesn't mention about TCP keepalives,=20 does it make a particular TCP stack which implements Keepalive non-compliant, if so all TCP stacks out there (BSD, Linux etc.,) would become non-compliant :-) So, the point in short is if I have an socket API, which tells TCP, abort this connection after a stipulated time in persist state, the TCP implementation can start a timer (a new timer OR overload an unused timer) the moment the connection enters persist state, and can tear down the connection after the timer expiry. This action would be treated as compliant to 1122 as would the OS running a timer in it's own context and killing the TCP connection. The key point is that resulting action is the same no matter which method you chose to exercise a particular protocol action. >=20 > > API is a local thing. One implementation can use sockets, whereas=20 > > other can using something totally different, what matters=20 > is what is=20 > > sent on the wire and the response which is received. >=20 > A protocol is defined by: >=20 > - formats of packets sent on the wire > - state at the endpoints > - events that cause state transitions, packet emissions, > and signals to the application, triggered by: > - packets arriving > - upper layer commands (i.e., "application" events) > - time True but protocol (TCP) is one thing, upper (application) and lower layer (IP) interfaces is another. The protocol compliance is measured by "if I send something, what do you I get in response" "If I send something in state X, is the behaviour as defined by the standard?". Upper layer and lower interface are simply local and they tend to evolve and that is benefit of a generic design of a particular protocol layer. >=20 > RFC793 is a good example of this set. >=20 > The upper layer commmands and signals to the upper layer=20 > constitute the API, and it is as much a part of the protocol=20 > as packets on the wire. > Although there are a variety of ways to implement a SEND,=20 > RECEIVE, OPEN, CLOSE, STATUS, or ABORT, all TCP=20 > implementations must include them in their API, and they and=20 > their basic arguments are specified in RFC793. Right, but these are the basic API's. The API's tend to expand and evolve and as long as their evolution doesn't "disturb" the standard, then we are golden. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Nov 24 03:07:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivq2t-0000d5-7c; Sat, 24 Nov 2007 03:07:23 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ivq2s-0000cv-2P for tcpm-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 03:07:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivq2r-0000cn-Ny for tcpm@ietf.org; Sat, 24 Nov 2007 03:07:21 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivq2r-0002qy-CC for tcpm@ietf.org; Sat, 24 Nov 2007 03:07:21 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 24 Nov 2007 00:07:20 -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 lAO87KHx017341; Sat, 24 Nov 2007 00:07:20 -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 lAO87Jb4025117; Sat, 24 Nov 2007 08:07:20 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 00:07:19 -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: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Date: Sat, 24 Nov 2007 00:07:18 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580452BC33@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <027601c82df5$a92b8c20$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Thread-Index: Acgt/lQv4OqAaSjCRwygUo/+nL5+aQAcQm8w From: "Anantha Ramaiah (ananth)" To: "Tom Petch" X-OriginalArrivalTime: 24 Nov 2007 08:07:19.0882 (UTC) FILETIME=[09182AA0:01C82E71] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1107; t=1195891640; x=1196755640; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward[WasRe=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=z7KYseB6tLiWMQDQFVo2GoHZagF9MCubUf7lPuVkUYM=; b=PO6WM7TTdeR8A2kfOQCQt/0f5cquz5JgOLL5lCFqrt+/Cen2dh+G3M+RlfN/t3Cvk195xrEF jmYFszjPbyHRaGSafLjgdWVjorksCrrC6hcJkYJA5SW8R1+TwWmjyiK9; Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 >=20 > No, that is not what the RFC says; as Joe has pointed out,=20 > the RFC says what TCP MUST do (and that changing it is a big=20 > deal). Note the title of the RFC - 'Requirements for=20 > Internet Hosts - Communication Layers' - and that there is a=20 > companion RFC1123, dated now because applications have moved=20 > on, but you will not find in the latter prohibitions on=20 > applications terminating connections. > RFC1122 defines what is available for applications to use,=20 > what applications can rely on; it does not define what those=20 > applications do with that functionality. >=20 > So; is there a problem? Yes, but it could be regarded as an=20 > implementation problem rather than a protocol one, and=20 > certainly not worth a change in TCP. > Worth an RFC? may be. IMO, the informational RFC which is what is being attempted, should clarify this. The whole point of my question was to understand whether terminating a connection stuck in persist state is considered RFC 1122 compliant. It appears from responses so far, it is compliant. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Nov 24 12:11:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvyWu-0008WB-Ru; Sat, 24 Nov 2007 12:10:56 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IvyWt-0008W6-JU for tcpm-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 12:10:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvyWt-0008Vy-9n for tcpm@ietf.org; Sat, 24 Nov 2007 12:10:55 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvyWq-0000qv-E4 for tcpm@ietf.org; Sat, 24 Nov 2007 12:10:55 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAOHA9jR018842; Sat, 24 Nov 2007 09:10:10 -0800 (PST) Message-ID: <47485AE9.6030209@isi.edu> Date: Sat, 24 Nov 2007 09:10:01 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC580452BC32@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580452BC32@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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="===============1926183827==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1926183827== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig07271F618EDC64A3D32A6238" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig07271F618EDC64A3D32A6238 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >>> Not sure what you mean above. RFC Compliance applies to=20 >> protocol, not=20 >>> to API. >> Please see RFC793. It specifies an API. Although the IETF=20 >> avoided APIs for a while, my understanding is that they are=20 >> again considered relevant standards work. >=20 > I don't think so. The API's specified by 793 needs to treated as > illustrational purposes only, they are not supposed to be interpreted a= s > standards.=20 Please review RFC793. It does talk about the fact that considerable flexibility is afforded to the implementer, but also expects the basic functions described there. =2E Like you noted above : "It specifies an API" not "the API". > Now RFC 793 doesn't talk about sockets,=20 Sockets are implementation-specific. > it doesn't talk about SO_LINGER > and SO_KEEPALIVE for example, does it mean that any stack which > implements API's not mentioned by RFC 793, isn't compliant? Nope. =20 1122 talks about keepalives; how they're implemented is up to the coder. Some of the functions of so_linger are an artifact of blocking OS calls; it is expected that apps can call ABORT at any time, and so if calls block, there needs to be a mechanism to get around it. > Again for example Keepalive option is very common in all TCP stacks, no= w > RFC doesn't mention about TCP keepalives,=20 > does it make a particular TCP stack which implements Keepalive > non-compliant, if so all TCP stacks out there (BSD, Linux etc.,) would > become non-compliant :-) See 1122. > So, the point in short is if I have an socket API, which tells TCP, > abort this connection after a stipulated time in persist state, the TCP= > implementation can start a timer (a new timer OR overload an unused > timer) the moment the connection enters persist state, and can tear dow= n > the connection after the timer expiry. This action would be treated as > compliant to 1122 as would the OS running a timer in it's own context > and killing the TCP connection. The key point is that resulting action > is the same no matter which method you chose to exercise a particular > protocol action. That is true. However, just like we don't require everyone to implement so_linger, we would not accept a requirement for that timer option to TCP= =2E >>> API is a local thing. One implementation can use sockets, whereas=20 >>> other can using something totally different, what matters=20 >> is what is=20 >>> sent on the wire and the response which is received. >> A protocol is defined by: >> >> - formats of packets sent on the wire >> - state at the endpoints >> - events that cause state transitions, packet emissions, >> and signals to the application, triggered by: >> - packets arriving >> - upper layer commands (i.e., "application" events) >> - time >=20 > True but protocol (TCP) is one thing, upper (application) and lower > layer (IP) interfaces is another. The protocol compliance is measured b= y > "if I send something, what do you I get in response" "If I send > something in state X, is the behaviour as defined by the standard?". > Upper layer and lower interface are simply local and they tend to evolv= e > and that is benefit of a generic design of a particular protocol layer.= Upper and lower layers to given protocol define its semantics and the semantics it expects from the lower layer. While implementations evolve, the requirements - the minimums required for correct interoperation - don't unless they are accompanied by changes to the specification. >> RFC793 is a good example of this set. >> >> The upper layer commmands and signals to the upper layer=20 >> constitute the API, and it is as much a part of the protocol=20 >> as packets on the wire. >> Although there are a variety of ways to implement a SEND,=20 >> RECEIVE, OPEN, CLOSE, STATUS, or ABORT, all TCP=20 >> implementations must include them in their API, and they and=20 >> their basic arguments are specified in RFC793. >=20 > Right, but these are the basic API's. The API's tend to expand and > evolve and as long as their evolution doesn't "disturb" the standard, > then we are golden. If you want to extend your implementation's API, that's fine, but not an RFC. If you want to extend the basic minimum required API, that would require a change to the protocol - as other changes (e.g., keepalives, nagle, ecn, etc.) have over the years. Joe --------------enig07271F618EDC64A3D32A6238 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHSFrpE5f5cImnZrsRAs7qAJ0fxLiJCcLetFbh8YZsTkblK2PLEACfaNnP U++Z0PX57osY9C2P5aoh0H8= =1OyA -----END PGP SIGNATURE----- --------------enig07271F618EDC64A3D32A6238-- --===============1926183827== 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 --===============1926183827==-- From tcpm-bounces@ietf.org Sun Nov 25 18:19:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwQku-0004HJ-PH; Sun, 25 Nov 2007 18:19:16 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwQkt-0004HE-ON for tcpm-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 18:19:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwQkt-0004H6-Ep for tcpm@ietf.org; Sun, 25 Nov 2007 18:19:15 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwQkq-0002FY-3M for tcpm@ietf.org; Sun, 25 Nov 2007 18:19:15 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 25 Nov 2007 15:19:11 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAPNJB1G026396; Sun, 25 Nov 2007 15:19:11 -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 lAPNJBus019346; Sun, 25 Nov 2007 23:19:11 GMT 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); Sun, 25 Nov 2007 15:19:11 -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: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Date: Sun, 25 Nov 2007 15:19:05 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580452BC88@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <47485AE9.6030209@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] Thread-Index: AcguvPhdYQLBWlEKRk+xbIyHMShS0gA9EqvA From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 25 Nov 2007 23:19:11.0213 (UTC) FILETIME=[960081D0:01C82FB9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1332; t=1196032751; x=1196896751; c=relaxed/simple; s=sjdkim1004; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=09[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=kJo5xRnJXNf8ds6Qq3UL7NmCrc8YaMrbVznoCKoOy54=; b=V2nMTpaFy1CBnFqoeH5mk6ksH2pvK9JU6URZMS1WDva/9faSzNdsD2JqW1VLzlZ8rfTkIMyn env3KQPUZAM8ZfdXfAFJf6+HXK1ZHEIInwPU0OpUV7USAVm31Q0wo9QjIGux423A74VXmctQbD kyIC4bAq8YzUP93QzOXtqSzRc=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) 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 Snipped most of the thread, since I don't intend to start a debate on "TCP keepalives" :-) >=20 > > So, the point in short is if I have an socket API, which tells TCP,=20 > > abort this connection after a stipulated time in persist state, the=20 > > TCP implementation can start a timer (a new timer OR overload an=20 > > unused > > timer) the moment the connection enters persist state, and can tear=20 > > down the connection after the timer expiry. This action would be=20 > > treated as compliant to 1122 as would the OS running a=20 > timer in it's=20 > > own context and killing the TCP connection. The key point is that=20 > > resulting action is the same no matter which method you chose to=20 > > exercise a particular protocol action. >=20 > That is true. However, just like we don't require everyone to=20 > implement so_linger, we would not accept a requirement for=20 > that timer option to TCP. I think based on the collective wisdom of the responses so far, that you don't need to change the standard for solving the problem described in the draft. ( any solution, for that matter, and not necessarliy the ones suggested in the draft). In other words, the text specified in the draft doesn't voilate any TCP standard (RFC 1122) which was my original question :-).=20 -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 26 00:00:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwW4o-0007Is-6N; Mon, 26 Nov 2007 00:00:10 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwW4n-0007Cs-0V for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 00:00:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwW4m-0007AB-Kf for tcpm@ietf.org; Mon, 26 Nov 2007 00:00:08 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwW4m-00055G-2Z for tcpm@ietf.org; Mon, 26 Nov 2007 00:00:08 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAQ4xHRg021615; Sun, 25 Nov 2007 20:59:18 -0800 (PST) Message-ID: <474A5299.8040301@isi.edu> Date: Sun, 25 Nov 2007 20:59:05 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC580452BC33@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580452BC33@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org, Tom Petch 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="===============0270871271==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0270871271== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig74796F6B10C378E13DD4BDE2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig74796F6B10C378E13DD4BDE2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >=20 >> No, that is not what the RFC says; as Joe has pointed out,=20 >> the RFC says what TCP MUST do (and that changing it is a big=20 >> deal). Note the title of the RFC - 'Requirements for=20 >> Internet Hosts - Communication Layers' - and that there is a=20 >> companion RFC1123, dated now because applications have moved=20 >> on, but you will not find in the latter prohibitions on=20 >> applications terminating connections. >> RFC1122 defines what is available for applications to use,=20 >> what applications can rely on; it does not define what those=20 >> applications do with that functionality. >> >> So; is there a problem? Yes, but it could be regarded as an=20 >> implementation problem rather than a protocol one, and=20 >> certainly not worth a change in TCP. >> Worth an RFC? may be. >=20 > IMO, the informational RFC which is what is being attempted, should > clarify this. The whole point of my question was to understand whether > terminating a connection stuck in persist state is considered RFC 1122 > compliant. It appears from responses so far, it is compliant. 1122 allows terminating a connection at any time for the reason that the application has instructed so. 1122 makes no distinction about the progress of a connection affecting that control. Joe --------------enig74796F6B10C378E13DD4BDE2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHSlKZE5f5cImnZrsRAswQAJ9aViji8p0aOjJGIwTRg7RfvOKW8ACg32rf NJZAaYPO5THKM9BzpeKqgww= =A6WI -----END PGP SIGNATURE----- --------------enig74796F6B10C378E13DD4BDE2-- --===============0270871271== 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 --===============0270871271==-- From tcpm-bounces@ietf.org Mon Nov 26 01:04:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwX5S-0000A1-R9; Mon, 26 Nov 2007 01:04:54 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwX5S-00009w-CI for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 01:04:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwX5S-00009o-1X for tcpm@ietf.org; Mon, 26 Nov 2007 01:04:54 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwX5R-0006P7-M8 for tcpm@ietf.org; Mon, 26 Nov 2007 01:04:53 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Nov 2007 22:04:53 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAQ64qgJ021643; Sun, 25 Nov 2007 22:04:52 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAQ64qb4016254; Mon, 26 Nov 2007 06:04:52 GMT 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); Sun, 25 Nov 2007 22:04:52 -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: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Date: Sun, 25 Nov 2007 22:04:51 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580452BCE0@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <474A5299.8040301@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Thread-Index: Acgv6TQcvWwnfUnEQqu2N2Rq4YL9FgABbqWw From: "Anantha Ramaiah (ananth)" To: "Joe Touch" X-OriginalArrivalTime: 26 Nov 2007 06:04:52.0165 (UTC) FILETIME=[42570750:01C82FF2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1009; t=1196057092; x=1196921092; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=09forward[WasRe=3A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=aZyLEuJXZQaaTHcdUPb3SUHgzpY55CpCxUHbAZpvRPs=; b=gO8FI9sdq6y52so8rjJS8rGXhUviaRdzHdHf2UP68iItr9s17Wn+Yb4ScDJG54QPC9zsao9x D/aBbTnMZSt8TLzM0uH0cU8/M4/r9XLTd8+ashblxEIaOOMZOqQYRJ0N; Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tcpm@ietf.org, Tom Petch 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 > >=20 > > IMO, the informational RFC which is what is being attempted, should=20 > > clarify this. The whole point of my question was to=20 > understand whether=20 > > terminating a connection stuck in persist state is=20 > considered RFC 1122=20 > > compliant. It appears from responses so far, it is compliant. >=20 > 1122 allows terminating a connection at any time for the=20 > reason that the application has instructed so. 1122 makes no=20 > distinction about the progress of a connection affecting that control. Implicit above OR an example scenario of the above statement is :, "1122 allows terminating connection stuck in persist state". Now how and where it is done is beyond the scope of any standard RFC (including 1122) and there are several ways to implement the rules. Now "progress of a connection and taking some action" all fall under implementation section, aborting of the connection is like a knob, you turn it when you determine that you need it. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 26 01:56:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwXtQ-00086C-S9; Mon, 26 Nov 2007 01:56:32 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwXtP-000866-CH for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 01:56:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwXtP-00085x-1L for tcpm@ietf.org; Mon, 26 Nov 2007 01:56:31 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwXtJ-0004Xt-JE for tcpm@ietf.org; Mon, 26 Nov 2007 01:56:31 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAQ6uATY014112; Sun, 25 Nov 2007 22:56:11 -0800 (PST) Message-ID: <474A6DFE.4000600@isi.edu> Date: Sun, 25 Nov 2007 22:55:58 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <0C53DCFB700D144284A584F54711EC580452BCE0@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580452BCE0@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: tcpm@ietf.org, Tom Petch 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="===============1405003570==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1405003570== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6909AA396E986CE6C5B7E34A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6909AA396E986CE6C5B7E34A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >>> IMO, the informational RFC which is what is being attempted, should=20 >>> clarify this. The whole point of my question was to=20 >> understand whether=20 >>> terminating a connection stuck in persist state is=20 >> considered RFC 1122=20 >>> compliant. It appears from responses so far, it is compliant. >> 1122 allows terminating a connection at any time for the=20 >> reason that the application has instructed so. 1122 makes no=20 >> distinction about the progress of a connection affecting that control.= >=20 > Implicit above OR an example scenario of the above statement is :, "112= 2 > allows terminating connection stuck in persist state". Now how and wher= e > it is done is beyond the scope of any standard RFC (including 1122) and= > there are several ways to implement the rules. Explicit above is that the application must initiate ABORTs - either by control of a timer or directly. 1122 prohibits TCP from, absent explicit indication from an application, deciding to abort a connection based on the lack of progress. > Now "progress of a connection and taking some action" all fall under > implementation section, aborting of the connection is like a knob, you > turn it when you determine that you need it. 1122 specifically prohibits TCP from deciding to abort a connection because the offered window isn't open (sec 4.2.2.17). The difference of which entity controls the abort - the application or TCP - is important to whether 1122 prohibits it or permits it. Timers inside TCP are equivalent to user action outside TCP, but events inside TCP that depend on state that TCP can determine but applications cannot are not equivalent in that regard. I.e., there is latitude in implementation, but it is not full latitude. Joe --------------enig6909AA396E986CE6C5B7E34A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHSm3+E5f5cImnZrsRAp9VAKD4zaYM1Gh7bc7m7GhYvGXWFRoIfACg1Czs UGnBXz6Y68pNSmTGegRgcj8= =m3kU -----END PGP SIGNATURE----- --------------enig6909AA396E986CE6C5B7E34A-- --===============1405003570== 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 --===============1405003570==-- From tcpm-bounces@ietf.org Mon Nov 26 06:14:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwbub-0006aP-P9; Mon, 26 Nov 2007 06:14:01 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwbub-0006aJ-5j for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 06:14:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwbua-0006aB-SP for tcpm@ietf.org; Mon, 26 Nov 2007 06:14:00 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwbuV-0002lI-7R for tcpm@ietf.org; Mon, 26 Nov 2007 06:14:00 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A72BE28000354; Mon, 26 Nov 2007 12:13:54 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyuXCoqeXFHh; Mon, 26 Nov 2007 12:13:54 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7CFFB28000303; Mon, 26 Nov 2007 12:13:44 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8301D.68699389" Date: Mon, 26 Nov 2007 12:13:43 +0100 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF317C7A@mx1.office> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-schuetz-tcpm-tcp-rlci-02.txt Thread-Index: AcgqkemR2filvGOwSHK+YLDvy+fHUwFigDSg From: "Simon Schuetz" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: draft-schuetz-tcpm-tcp-rlci@tools.ietf.org Subject: [tcpm] FW: I-D Action:draft-schuetz-tcpm-tcp-rlci-02.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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C8301D.68699389 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We submitted a revision of the TCP RLCI draft. Major changes/improvements: - state machine now implements 3-way handshake to guarantee delivery of = connectivity-change indication - better "stale ack" detection - improved handling in case of out-of-order delivery Comments welcome, Simon > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Monday, November 19, 2007 10:50 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-schuetz-tcpm-tcp-rlci-02.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : TCP Response to Lower-Layer=20 > Connectivity-Change Indications > Author(s) : S. Schuetz, et al. > Filename : draft-schuetz-tcpm-tcp-rlci-02.txt > Pages : 32 > Date : 2007-11-19 >=20 > When the path characteristics between two hosts change abruptly, TCP > can experience significant delays before resuming transmission in an > efficient manner or TCP can behave unfairly to competing traffic. > This document describes TCP extensions that improve transmission > behavior in response to advisory, lower-layer connectivity-change > indications. The proposed TCP extensions modify the local behavior > of TCP and introduce a new TCP option to signal locally received > connectivity-change indications to remote peers. Performance gains > result from a more efficient transmission behavior and there is no > difference in aggressiveness in comparison to a newly-started > connection. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-schuetz-tcpm-tcp-rlci-02.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message. > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then > "get draft-schuetz-tcpm-tcp-rlci-02.txt". >=20 > 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 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-schuetz-tcpm-tcp-rlci-02.txt". >=20 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014=20 ------_=_NextPart_001_01C8301D.68699389 Content-Type: application/octet-stream; name="draft-schuetz-tcpm-tcp-rlci-02.URL" Content-Transfer-Encoding: base64 Content-Description: draft-schuetz-tcpm-tcp-rlci-02.URL Content-Disposition: attachment; filename="draft-schuetz-tcpm-tcp-rlci-02.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zY2h1ZXR6LXRjcG0tdGNwLXJsY2ktMDIudHh0DQo= ------_=_NextPart_001_01C8301D.68699389 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm ------_=_NextPart_001_01C8301D.68699389-- From tcpm-bounces@ietf.org Mon Nov 26 09:44:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfC2-0006JE-GM; Mon, 26 Nov 2007 09:44:14 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwfC0-0006J4-Oj for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 09:44:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfC0-0006Iw-Dm for tcpm@ietf.org; Mon, 26 Nov 2007 09:44:12 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwfBz-0001yJ-Qy for tcpm@ietf.org; Mon, 26 Nov 2007 09:44:12 -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 lAQEiAJt001352 for ; Mon, 26 Nov 2007 06:44:10 -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 6552212619BC for ; Mon, 26 Nov 2007 09:44:05 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8F2E62FBFFD for ; Mon, 26 Nov 2007 09:26:35 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] In-Reply-To: <474A6DFE.4000600@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Walk on the Wild Side MIME-Version: 1.0 Date: Mon, 26 Nov 2007 09:26:35 -0500 Message-Id: <20071126142635.8F2E62FBFFD@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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="===============1522233682==" Errors-To: tcpm-bounces@ietf.org --===============1522233682== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [hat off] I am not sure where in this thread to weigh in, so I am just replying to the last thing in my inbox. I think a couple of things: + I disagree with everyone who says this problem of a bunch of clients wedging connections on a server into ZWP in the attempt to consume a large number of resources can be mitigated effectively at the application layer. Perhaps if a server has one application process (or a bunch of tightly coupled processes under one app controller) then this could be handled. But, fundamentally a set of applications cannot be expected to have the cross-connection and cross-application viewpoint that TCP or the operating system has. Therefore, applications cannot solve such a problem. + I disagree with the reading of RFCs 793 & 1122 that a connection that is doing zero window probing must remain up forever as long as the probes are being ACKed. I think in 'times of trouble' a TCP is well within its rights to terminate a connection and I do not think that should in any way be viewed as non-compliant. TCP connections are local resources and therefore should remain under local control. If something locally determines that resources are low and connection should be terminated for whatever reason then I don't see how that is any of anyone else's business. That doesn't mean I think the words in 1122 are wrong. That means I think that if folks would call a stack that has run out of memory (or, hits some threshold, say) and therefore kills some connections that are doing ZWP "non-conformant" then they are simply wrong and applying too much protocol lawyering and too little common sense. Hence, I don't think the standards need changed in any way. + I believe that managing local resources according to local policy is reasonable. Therefore, I don't think we need to standardize *a* way to mitigate the attack described in this document. I think stacks can be free to mitigate it (or not) as they see fit. + I would not have a problem with a crisp and clean document that showed *a* solution to the problem. Especially good would be a demonstration that the problem is a problem in the wild and has not been mitigated. [See my previous---unanswered as far as I can tell---note on why I think the tests in the draft are inconclusive at best.] This document could be a technical report or a short workshop paper or an informational RFC. (As an example, see the SYN-flood RFC. This describes a fully local solution to a problem in an informational way. There is no strict reason to standardize anything in that document, but it is crisp, clean and complete and the WG found it something nice to have documented. This persist document is a far cry from the SYN flood document at the moment, but I suppose one could envision that a document that covers purging connections when resource constrained could be developed.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHStebWyrrWs4yIs4RAt3kAJ9c4syGtEl7coVcfgCa7aAoLwTgTACghlSy IdlIGMDm+0eoSWZnND58rD8= =m9mr -----END PGP SIGNATURE----- --=_bOundary-- --===============1522233682== 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 --===============1522233682==-- From tcpm-bounces@ietf.org Mon Nov 26 09:44:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfCC-0006QQ-O0; Mon, 26 Nov 2007 09:44:24 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwfCA-0006Q5-Mn for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 09:44:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfCA-0006Px-By for tcpm@ietf.org; Mon, 26 Nov 2007 09:44:22 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwfC9-0001yf-Sj for tcpm@ietf.org; Mon, 26 Nov 2007 09:44:22 -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 lAQEiADl001350; Mon, 26 Nov 2007 06:44:10 -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 653EF12619BB; Mon, 26 Nov 2007 09:44:05 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 713D92FC035; Mon, 26 Nov 2007 09:29:16 -0500 (EST) To: Ted Faber From: Mark Allman Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?] In-Reply-To: <20071121192901.GF13024@hut.isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Walk on the Wild Side MIME-Version: 1.0 Date: Mon, 26 Nov 2007 09:29:16 -0500 Message-Id: <20071126142916.713D92FC035@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" 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="===============1583168823==" Errors-To: tcpm-bounces@ietf.org --===============1583168823== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [hat on] > I haven't spoken to Mark about this, so this is me speaking for myself. > > On Wed, Nov 21, 2007 at 10:12:44AM -0800, Anantha Ramaiah (ananth) wrote: > > B) Do we think this is an issue to be dealt at the transport layer? > > > > Here there seems to be mixed reaction. Granted that there may be many > > people feeling that this is an application issue and not a transport > > issue. > > That's not my assessment. > > It looks to me that there is considerable resistance to standardizing > the proposed solution, both on the grounds of placement in the stack and > on the limitations of the solution. > > [ For example, connections that advertise a large initial window and then > read a byte every (proposed timer size -1) seconds will replicate the > problem in the limit. Using timers alone penalizes stopped connections > when there is no resource shortage. ] > > Despite the fairly lively discussion, I have seen little support for > standardizing this mechanism in TCP, outside the authors and their > collaborators, and strong resistance from the members of the WG. > > Again, I'm not assessing consensus officially here, but that's how I see > it. My view is largely the same. I think folks have a variety of reasoning that leads them to the same place, as Ted notes above. I would like to flip this around and ask for folks who might not have chimed in yet, but do support this document to please speak up. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHStg8WyrrWs4yIs4RArTPAJ4seEayvyzvXfhra7GI7yyckM8I2wCgipcb wYcoKmu2Mgt8jq7cfAexrJY= =xWR8 -----END PGP SIGNATURE----- --=_bOundary-- --===============1583168823== 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 --===============1583168823==-- From tcpm-bounces@ietf.org Mon Nov 26 10:53:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgGY-00033i-AS; Mon, 26 Nov 2007 10:52:58 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwgGX-00031F-DK for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 10:52:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgGX-00030F-1a for tcpm@ietf.org; Mon, 26 Nov 2007 10:52:57 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwgGW-0003wm-I0 for tcpm@ietf.org; Mon, 26 Nov 2007 10:52:56 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAQFqUsg025779; Mon, 26 Nov 2007 07:52:31 -0800 (PST) Message-ID: <474AEBB4.9010803@isi.edu> Date: Mon, 26 Nov 2007 07:52:20 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126142635.8F2E62FBFFD@lawyers.icir.org> In-Reply-To: <20071126142635.8F2E62FBFFD@lawyers.icir.org> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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="===============2100680170==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2100680170== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig67901968E989F5BB7A7B6BB1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig67901968E989F5BB7A7B6BB1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: > [hat off] >=20 > I am not sure where in this thread to weigh in, so I am just replying t= o > the last thing in my inbox. >=20 > I think a couple of things: =2E.. > + I disagree with the reading of RFCs 793 & 1122 that a connection > that is doing zero window probing must remain up forever as long as= > the probes are being ACKed. I think in 'times of trouble' a TCP is= > well within its rights to terminate a connection and I do not think= > that should in any way be viewed as non-compliant. TCP connections= > are local resources and therefore should remain under local > control. If something locally determines that resources are low an= d > connection should be terminated for whatever reason then I don't se= e > how that is any of anyone else's business. The point of 1122 is that TCP isn't the one to decide this, AND that connections with zero windows with ACKs aren't to be singled out. Applications can kill connections, and certainly the OS can just shut down. However, an OS that decides to kill connections because it runs out of resources is noncompliant. That OS is required to reserve per-connection resources when connections are created. It can halt new connections. It *CANNOT* kill existing connections to make up for poor resource management and call itself compliant with the current language in 1122. > That doesn't mean I think the words in 1122 are wrong. That means = I > think that if folks would call a stack that has run out of memory > (or, hits some threshold, say) and therefore kills some connections= > that are doing ZWP "non-conformant" then they are simply wrong and > applying too much protocol lawyering and too little common sense. The lack of common sense came when the OS designer failed to allocate sufficient per-connection resources. Throw your stones in their direction, please. Joe --------------enig67901968E989F5BB7A7B6BB1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFHSuu0E5f5cImnZrsRAkbMAJdXsebSU4FXGRTNazkN40GwKVQ1AKCqB/KH 3HuXgb6AOeKafb4+F2m4XQ== =FPRW -----END PGP SIGNATURE----- --------------enig67901968E989F5BB7A7B6BB1-- --===============2100680170== 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 --===============2100680170==-- From tcpm-bounces@ietf.org Mon Nov 26 11:13:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgaV-0006CV-MZ; Mon, 26 Nov 2007 11:13:35 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwgaU-0006CE-DF for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:13:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgaU-0006C5-2O for tcpm@ietf.org; Mon, 26 Nov 2007 11:13:34 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwgaT-0004Te-I6 for tcpm@ietf.org; Mon, 26 Nov 2007 11:13:33 -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 lAQGDWKW002976; Mon, 26 Nov 2007 08:13:32 -0800 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id F07FE12621C8; Mon, 26 Nov 2007 11:13:27 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 29EFA2FC343; Mon, 26 Nov 2007 11:12:59 -0500 (EST) To: Joe Touch From: Mark Allman Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] In-Reply-To: <474AEBB4.9010803@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Walk on the Wild Side MIME-Version: 1.0 Date: Mon, 26 Nov 2007 11:12:59 -0500 Message-Id: <20071126161259.29EFA2FC343@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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="===============0357636511==" Errors-To: tcpm-bounces@ietf.org --===============0357636511== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Joe- You and I are just going to disagree. > That OS is required to reserve per-connection resources when > connections are created. It can halt new connections. If this is the general reading of the spec then TCP has a built-in DoS vulnerability that we need to fix. > It *CANNOT* kill existing connections to make up for poor resource > management and call itself compliant with the current language in > 1122. I disagree. > > That doesn't mean I think the words in 1122 are wrong. That means I > > think that if folks would call a stack that has run out of memory > > (or, hits some threshold, say) and therefore kills some connections > > that are doing ZWP "non-conformant" then they are simply wrong and > > applying too much protocol lawyering and too little common sense. > > The lack of common sense came when the OS designer failed to allocate > sufficient per-connection resources. Throw your stones in their > direction, please. Huh? The lack of allocation of sufficient per-connection resources? What? The problem here is that the OS *did* allocate resources and with a low-rate handshake those resources can be tied up indefinitely. I have no idea how the OS "failed to allocate sufficient per-connection resources". If a TCP were omniscient and could know the workload to be imposed on it arbitrarily far into the future then perhaps it could wisely allocate resources to avoid this problem. But, since that is impossible then a host can get into resource contention problems and in that case it should have the flexibility to mitigate these problems. It is absurd to me that a TCP (or any protocol) would allow a peer to indefinitely tie up a local resource without being subject to local policies on that resource. I cannot imagine that such a notion falls within the spirit of 793 & 1122. If we have wide-spread agreement that your interpretation is right then I support a one-page standards-track RFC that says it is not. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHSvCKWyrrWs4yIs4RAisoAJ0cW8TIRYR3VZNIusNU8uEpDVvFLQCffA0o AHtdZr7BvsgJJG4qOq/F5+0= =1izU -----END PGP SIGNATURE----- --=_bOundary-- --===============0357636511== 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 --===============0357636511==-- From tcpm-bounces@ietf.org Mon Nov 26 11:25:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwglz-0002P2-TG; Mon, 26 Nov 2007 11:25:27 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwglz-0002Ov-17 for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:25:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgly-0002On-Nm for tcpm@ietf.org; Mon, 26 Nov 2007 11:25:26 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwgls-0002Ig-A6 for tcpm@ietf.org; Mon, 26 Nov 2007 11:25:26 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAQGOs6d005137; Mon, 26 Nov 2007 08:24:54 -0800 (PST) Message-ID: <474AF34B.40805@isi.edu> Date: Mon, 26 Nov 2007 08:24:43 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126161259.29EFA2FC343@lawyers.icir.org> In-Reply-To: <20071126161259.29EFA2FC343@lawyers.icir.org> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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="===============2136038378==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2136038378== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD5E292E9E173FB965FA7927B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD5E292E9E173FB965FA7927B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: > Joe- >=20 > You and I are just going to disagree. >=20 >> That OS is required to reserve per-connection resources when >> connections are created. It can halt new connections. >=20 > If this is the general reading of the spec then TCP has a built-in DoS > vulnerability that we need to fix. There's nothing in TCP that says that new connections will ALWAYS succeed= =2E Or can you find that in the requirements? =2E.. > It is absurd to me that a TCP (or any protocol) would allow a peer to > indefinitely tie up a local resource without being subject to local > policies on that resource. It's very specifically in 1122. Local policies can kill applications, but can't go around gleaning connections it *thinks* aren't useful. If you want a new RFC that allows connection revocation, then it's *definitely* a standards change. I would favor a BCP that says that: --- an OS under attack MAY terminate applications to recover their resources, and the decision of which applications to terminate is a matter of local policy. when such applications are terminated, their TCP sessions would, as usual, be aborted --- Note also that DOS attacks would likely not keep TCP connections around with zero windows AND continue to ACK - they'd stop ACKing, the connection would drop for *that* reason, and be recovered. I would object to an RFC that allows TCP connection revocation to compensate for not wanting to kill the apps. Joe --------------enigD5E292E9E173FB965FA7927B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHSvNLE5f5cImnZrsRAoEHAJ96cLCuaBJb3lbZ4kWm4Mw9h9PtzgCdFSKy ocXQkI8PXPYMWpxGPQUoIiE= =y32z -----END PGP SIGNATURE----- --------------enigD5E292E9E173FB965FA7927B-- --===============2136038378== 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 --===============2136038378==-- From tcpm-bounces@ietf.org Mon Nov 26 11:33:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgu4-0005hV-I1; Mon, 26 Nov 2007 11:33:48 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwgu3-0005dk-0k for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:33:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgu2-0005db-NR for tcpm@ietf.org; Mon, 26 Nov 2007 11:33:46 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwgtw-0002fo-21 for tcpm@ietf.org; Mon, 26 Nov 2007 11:33:46 -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 lAQGXc7h003394; Mon, 26 Nov 2007 08:33:39 -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 07DBC1262583; Mon, 26 Nov 2007 11:33:34 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 326192FC402; Mon, 26 Nov 2007 11:33:05 -0500 (EST) To: Joe Touch From: Mark Allman Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] In-Reply-To: <474AF34B.40805@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Walk on the Wild Side MIME-Version: 1.0 Date: Mon, 26 Nov 2007 11:33:05 -0500 Message-Id: <20071126163305.326192FC402@lawyers.icir.org> 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 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="===============0624671319==" Errors-To: tcpm-bounces@ietf.org --===============0624671319== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Mark Allman wrote: > > Joe- > > > > You and I are just going to disagree. > > > >> That OS is required to reserve per-connection resources when > >> connections are created. It can halt new connections. > > > > If this is the general reading of the spec then TCP has a built-in DoS > > vulnerability that we need to fix. > > There's nothing in TCP that says that new connections will ALWAYS > succeed. Can you find a prohibition on connections failing? Joe, you surely see the problem, right? I am not saying that new connections always have to succeed. I am saying that if the spec allows for a case whereby an attacker can coax a host into a state whereby all new connections will fail that is a DoS attack. Do you disagree with that? > It's very specifically in 1122. Local policies can kill applications, > but can't go around gleaning connections it *thinks* aren't useful. Nobody said it thought these connections were not useful. I don't read the standards as saying that when resources are severely constrained then action cannot be taken based on some local policy decisions. But, that is just me. > If you want a new RFC that allows connection revocation, then it's > *definitely* a standards change. I don't think we need to change anything. I think the current version covers this fine. You and I just disagree on this point. If consensus is with you, then I would agree that it would be a standards track change. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHSvVAWyrrWs4yIs4RAjN5AKCNCIg3/GYebyeKlzEkwrINOhRgdACfUsjC kkeIJg490Rcr5dVLt55iEw4= =bSnP -----END PGP SIGNATURE----- --=_bOundary-- --===============0624671319== 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 --===============0624671319==-- From tcpm-bounces@ietf.org Mon Nov 26 11:59:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhIU-0007er-Fi; Mon, 26 Nov 2007 11:59:02 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwhIT-0007eh-GR for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:59:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhIT-0007eA-5R for tcpm@ietf.org; Mon, 26 Nov 2007 11:59:01 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwhIS-00069t-JJ for tcpm@ietf.org; Mon, 26 Nov 2007 11:59:01 -0500 Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAQGwSL3016145; Mon, 26 Nov 2007 08:58:29 -0800 (PST) Message-ID: <474AFB2A.9080504@isi.edu> Date: Mon, 26 Nov 2007 08:58:18 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mallman@icir.org Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126163305.326192FC402@lawyers.icir.org> In-Reply-To: <20071126163305.326192FC402@lawyers.icir.org> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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="===============0537265008==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0537265008== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09AE333D83F48610DF9B9CEE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09AE333D83F48610DF9B9CEE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: >> Mark Allman wrote: >>> Joe- >>> >>> You and I are just going to disagree. >>> >>>> That OS is required to reserve per-connection resources when >>>> connections are created. It can halt new connections. >>> If this is the general reading of the spec then TCP has a built-in Do= S >>> vulnerability that we need to fix. >> There's nothing in TCP that says that new connections will ALWAYS >> succeed. >=20 > Can you find a prohibition on connections failing? >=20 > Joe, you surely see the problem, right? I see an OS that has to decide how to allocate resources: a- leave them with existing apps and prohibit new ones b- terminate existing apps to make room for new ones I expect that a reasonable, modern OS would do (a). > I am not saying that new > connections always have to succeed. I am saying that if the spec allow= s > for a case whereby an attacker can coax a host into a state whereby all= > new connections will fail that is a DoS attack. Do you disagree with > that? I agree that attackers, as well as legitimate users, can consume local resources on servers, and that such consumption can reach a limit beyond what the server can support. The question is "what do you do when you run out of resources?" TCP allows killing connections where the other end doesn't respond, via timeouts. We're all talking about what to do when the attacker is willing to commit more resources, i.e., to keep ACKing, or even just go very slowly. IMO, under those conditions you cannot know the difference between a legitimate user and an attacker. Under those conditions, 1122 specifically claims that not making progress due to an ACKd zero window isn't a connection failure. IMO, the application (i.e., service) ought to determine when to give up on a connection, and issue ABORTs. That solves the problem entirely and is entirely within the scope of 1122 as it currently exists. I don't agree that the OS has any business terminating connections to make up for poorly-written, and thus DOS-susceptible applications, or that 1122 should be modified to either permit or encourage this sloppy handling of DOS attacks. Joe --------------enig09AE333D83F48610DF9B9CEE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHSvsqE5f5cImnZrsRAtmnAJ9U8wNTdpHMl4tNmR08mr5MxZBdJwCg6AIc tEoDylmzoASpgP3tK+Brsd0= =gonA -----END PGP SIGNATURE----- --------------enig09AE333D83F48610DF9B9CEE-- --===============0537265008== 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 --===============0537265008==-- From tcpm-bounces@ietf.org Mon Nov 26 14:38:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjmz-0002TL-7B; Mon, 26 Nov 2007 14:38:41 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwjmx-0002TG-E5 for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:38:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjmx-0002T7-3J for tcpm@ietf.org; Mon, 26 Nov 2007 14:38:39 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwjmw-0003BY-IY for tcpm@ietf.org; Mon, 26 Nov 2007 14:38:39 -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 lAQJcbcC007171; Mon, 26 Nov 2007 11:38:37 -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 6293C1263D7A; Mon, 26 Nov 2007 14:38:32 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 585E12FC5BE; Mon, 26 Nov 2007 14:38:03 -0500 (EST) To: Joe Touch From: Mark Allman Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] In-Reply-To: <474AFB2A.9080504@isi.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Walk on the Wild Side MIME-Version: 1.0 Date: Mon, 26 Nov 2007 14:38:03 -0500 Message-Id: <20071126193803.585E12FC5BE@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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="===============0008497595==" Errors-To: tcpm-bounces@ietf.org --===============0008497595== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > The question is "what do you do when you run out of resources?" Yep. > TCP allows killing connections where the other end doesn't respond, > via timeouts. We're all talking about what to do when the attacker is > willing to commit more resources, i.e., to keep ACKing, or even just > go very slowly. Yep. > IMO, under those conditions you cannot know the difference between a > legitimate user and an attacker. Under those conditions, 1122 > specifically claims that not making progress due to an ACKd zero > window isn't a connection failure. I agree that you cannot tell the difference, per se. But, IMO, one can look around at the context and make a good guess and accept the collateral damage. I.e., if I see a zillion of these ZWP connections when I normally see ~none I could decide that this is an attack and take what I consider appropriate actions, knowing full well that everything in the class of connections may not be an attack. > IMO, the application (i.e., service) ought to determine when to give > up on a connection, and issue ABORTs. That's great, but the problem with that is that an application hasn't the context of the underlying TCP or OS. Clearly you could feed something to the app that says "kill some connections" and the apps might or might not. So, that might or might not solve the problem and it is more complicated and depends on much more software being right. > That solves the problem entirely and is entirely within the scope of > 1122 as it currently exists. I see a TCP solution as being within the scope of the 1122 we have. > I don't agree that the OS has any business terminating connections to > make up for poorly-written, and thus DOS-susceptible applications, or > that 1122 should be modified to either permit or encourage this sloppy > handling of DOS attacks. I can't even believe I am having this discussion, Joe. It isn't the app that is DoS-ed. Like I said: you and I are not going to agree about how to interpret RFC112 (in 2007). It would be good to hear other opinions. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHSyCbWyrrWs4yIs4RAkLRAJ4tdcwCczWXrsKjf2tT+c//buHuFwCfahnw wZyUrnK7M6Kf68PSe5cxq9g= =CGPi -----END PGP SIGNATURE----- --=_bOundary-- --===============0008497595== 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 --===============0008497595==-- From tcpm-bounces@ietf.org Mon Nov 26 14:42:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjqC-0003jx-VT; Mon, 26 Nov 2007 14:42:00 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwjqB-0003js-DZ for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:41:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwjqB-0003jk-2u for tcpm@ietf.org; Mon, 26 Nov 2007 14:41:59 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwjqA-0003Fv-Lr for tcpm@ietf.org; Mon, 26 Nov 2007 14:41:59 -0500 Received: from [128.182.160.132] (ice.psc.edu [128.182.160.132]) (authenticated bits=0) by mailer2.psc.edu (8.14.1/8.13.3) with ESMTP id lAQJfr4b017999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 14:41:56 -0500 (EST) Message-ID: <474B2181.7050103@psc.edu> Date: Mon, 26 Nov 2007 14:41:53 -0500 From: John Heffner User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Joe Touch Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126142635.8F2E62FBFFD@lawyers.icir.org> <474AEBB4.9010803@isi.edu> In-Reply-To: <474AEBB4.9010803@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 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 Joe Touch wrote: > > Mark Allman wrote: >> [hat off] >> >> I am not sure where in this thread to weigh in, so I am just replying to >> the last thing in my inbox. >> >> I think a couple of things: > ... >> + I disagree with the reading of RFCs 793 & 1122 that a connection >> that is doing zero window probing must remain up forever as long as >> the probes are being ACKed. I think in 'times of trouble' a TCP is >> well within its rights to terminate a connection and I do not think >> that should in any way be viewed as non-compliant. TCP connections >> are local resources and therefore should remain under local >> control. If something locally determines that resources are low and >> connection should be terminated for whatever reason then I don't see >> how that is any of anyone else's business. > > The point of 1122 is that TCP isn't the one to decide this, AND that > connections with zero windows with ACKs aren't to be singled out. > Applications can kill connections, and certainly the OS can just shut > down. However, an OS that decides to kill connections because it runs > out of resources is noncompliant. > > That OS is required to reserve per-connection resources when connections > are created. It can halt new connections. > > It *CANNOT* kill existing connections to make up for poor resource > management and call itself compliant with the current language in 1122. I really have to disagree here; I do not believe an OS terminating a connection violates the spirit of 1122. Things like processes, address spaces, etc., are well outside the TCP standard's realm. In my view, an operating system (the kernel, a helper daemon, or other) can be considered a "User" of TCP (in RFC793 terminology), and be fully compliant when making API calls (including ABORT) to connections that might be "owned" by some other process. One question: is the deleteTCB(12) state of RFC4022 in conflict with RFC1122/RFC793? -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 26 14:56:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwk3r-0006sv-0F; Mon, 26 Nov 2007 14:56:07 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwk3p-0006rm-Cg for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:56:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwk3p-0006re-3E for tcpm@ietf.org; Mon, 26 Nov 2007 14:56:05 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwk3l-0001iN-2U for tcpm@ietf.org; Mon, 26 Nov 2007 14:56:05 -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 lAQJrpVU004215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Nov 2007 11:53:52 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lAQJrpPs045480; Mon, 26 Nov 2007 11:53:51 -0800 (PST) (envelope-from faber) Date: Mon, 26 Nov 2007 11:53:51 -0800 From: Ted Faber To: John Heffner Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Message-ID: <20071126195351.GE32459@hut.isi.edu> References: <20071126142635.8F2E62FBFFD@lawyers.icir.org> <474AEBB4.9010803@isi.edu> <474B2181.7050103@psc.edu> Mime-Version: 1.0 In-Reply-To: <474B2181.7050103@psc.edu> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tcpm@ietf.org, mallman@icir.org, Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0546405033==" Errors-To: tcpm-bounces@ietf.org --===============0546405033== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aYDVKSzuImP48n7V" Content-Disposition: inline --aYDVKSzuImP48n7V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 26, 2007 at 02:41:53PM -0500, John Heffner wrote: > I really have to disagree here; I do not believe an OS terminating a=20 > connection violates the spirit of 1122. Things like processes, address= =20 > spaces, etc., are well outside the TCP standard's realm. In my view, an= =20 > operating system (the kernel, a helper daemon, or other) can be=20 > considered a "User" of TCP (in RFC793 terminology), and be fully=20 > compliant when making API calls (including ABORT) to connections that=20 > might be "owned" by some other process. I agree with this interpetation, you know, as a regular guy. > One question: is the deleteTCB(12) state of RFC4022 in conflict with=20 > RFC1122/RFC793? There's nothing there that offends me. That looks like a request by a manager to an operating system to call ABORT on a connection. I assume that the managed entity might choose to ignore such a request (e.g. it is a request to terminate the connection to the manager over which the request came :-)). --=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 --aYDVKSzuImP48n7V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHSyROaUz3f+Zf+XsRAsa6AKCMKI0VxeV8kbjujPUKUpet2AS5/ACgvgAw F2WvKhz/L9N/0tRP+zuBUQw= =G9pv -----END PGP SIGNATURE----- --aYDVKSzuImP48n7V-- --===============0546405033== 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 --===============0546405033==-- From tcpm-bounces@ietf.org Mon Nov 26 15:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwklU-0007gY-AI; Mon, 26 Nov 2007 15:41:12 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwklT-0007gS-9S for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 15:41:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwklS-0007gJ-Vk for tcpm@ietf.org; Mon, 26 Nov 2007 15:41:10 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwklP-0002hG-JG for tcpm@ietf.org; Mon, 26 Nov 2007 15:41:10 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Nov 2007 12:41:07 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAQKf6vT027314 for ; Mon, 26 Nov 2007 12:41:06 -0800 Received: from [171.69.75.93] (dhcp-171-69-75-93.cisco.com [171.69.75.93]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAQKf6b4010837 for ; Mon, 26 Nov 2007 20:41:06 GMT Message-ID: <474B2F61.6000606@cisco.com> Date: Mon, 26 Nov 2007 12:41:05 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=490; t=1196109666; x=1196973666; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Agenda=20request=20for=20IETF=2070. |Sender:=20; bh=aRJkjB/3h2ybHkFdTAuqQY4NwYJoWNR7yxRlxWdExP4=; b=MI2YKj9OpkiHYX02eo7UPUDTiTnQBKe4uXZ71EwDMDKwOM1apK2L/xZPmyLiHLgfHJA2wDOb tVl7M6amMFcm47eyUF3tkT6geq20gzoQsbd4O4DpExR2DY8j7KqwXmAk; Authentication-Results: sj-dkim-2; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [tcpm] Agenda request for IETF 70. 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 We had requested and were granted by the chairs of tcpm a time slot to discuss the persist draft in the upcoming IETF 70 meeting in Vancouver. However, after the recent discussions on the mailing list and list of open items, we are requesting that a time slot to discuss the draft be deferred to a future meeting. That should hopefully give us more time to address the issues that been brought up in the mailing list. Thanks for your understanding and support. -- /mahesh _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 26 16:03:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwl7J-0007TY-Hd; Mon, 26 Nov 2007 16:03:45 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwl7H-0007TS-J6 for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 16:03:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwl7H-0007TK-9a for tcpm@ietf.org; Mon, 26 Nov 2007 16:03:43 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwl7C-0003EM-FR for tcpm@ietf.org; Mon, 26 Nov 2007 16:03:43 -0500 X-IronPort-AV: E=Sophos;i="4.23,215,1194217200"; d="scan'208";a="158824298" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Nov 2007 22:03:38 +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 lAQL3b4D026120; Mon, 26 Nov 2007 22:03:37 +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 lAQL3bZZ018187; Mon, 26 Nov 2007 21:03:37 GMT Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4147.cisco.com [10.61.80.50]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id VAA27187; Mon, 26 Nov 2007 21:03:31 GMT Message-Id: <200711262103.VAA27187@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Nov 2007 21:03:07 +0000 To: Joe Touch , mallman@icir.org From: Lloyd Wood Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] In-Reply-To: <474AFB2A.9080504@isi.edu> References: <20071126163305.326192FC402@lawyers.icir.org> <474AFB2A.9080504@isi.edu> 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: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Monday 26/11/2007 08:58 -0800, Joe Touch wrote: >I see an OS that has to decide how to allocate resources: > > a- leave them with existing apps and prohibit new ones > > b- terminate existing apps to make room for new ones > >I expect that a reasonable, modern OS would do (a). That presumes that all TCP connections are long-lived. It permits a few long-lived connections to tie up resources that could service short-lived connections. (http, beep, xml-rpc and other short-lived transactions over TCP weren't invented when RFC1122 was written.) L. Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 26 16:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlcT-0004Kw-0l; Mon, 26 Nov 2007 16:35:57 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwlcR-0004KT-Pv for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 16:35:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwlcR-0004KF-Fq for tcpm@ietf.org; Mon, 26 Nov 2007 16:35:55 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwlcR-0000HZ-5c for tcpm@ietf.org; Mon, 26 Nov 2007 16:35:55 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Nov 2007 13:35:54 -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 lAQLZspq020073; Mon, 26 Nov 2007 13:35:54 -0800 Received: from [171.69.75.93] (dhcp-171-69-75-93.cisco.com [171.69.75.93]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAQLZnus016985; Mon, 26 Nov 2007 21:35:49 GMT Message-ID: <474B3C35.30207@cisco.com> Date: Mon, 26 Nov 2007 13:35:49 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Joe Touch Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126161259.29EFA2FC343@lawyers.icir.org> <474AF34B.40805@isi.edu> In-Reply-To: <474AF34B.40805@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=414; t=1196112954; x=1196976954; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward[WasRe=3A=0A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=+DsupvZpotajFu7SMJEkt5cvqSs5TIECh4mn1H7tmFY=; b=np4bnkgzlO3wuYbI5pbfCs+WQ0vnj811xyWsFkaBrfO79MTa39nhcN2f+IIh2jLqWzElThsy OfWqUC3Qs7RzAXEIgsAFaW2ueXSdnSDcJqvhVcP/w9+TlPz7ujrjz0El; Authentication-Results: sj-dkim-4; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Joe Touch wrote: > > Note also that DOS attacks would likely not keep TCP connections around > with zero windows AND continue to ACK - they'd stop ACKing, the > connection would drop for *that* reason, and be recovered. Quite the contrary. Our experimentation revealed that DoS attackers responded reliably with an ACK to all zero window probes and that connections stayed in established state for days. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Nov 26 19:07:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwnyZ-0005el-2F; Mon, 26 Nov 2007 19:06:55 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwnyY-0005eg-2f for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 19:06:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwnyX-0005eY-Lx for tcpm@ietf.org; Mon, 26 Nov 2007 19:06:53 -0500 Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwnyX-0000cP-9X for tcpm@ietf.org; Mon, 26 Nov 2007 19:06:53 -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 lAR06qJD011979 for ; Mon, 26 Nov 2007 16:06:52 -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 E4F381265AFE for ; Mon, 26 Nov 2007 19:06:42 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9C1642FCAA3 for ; Mon, 26 Nov 2007 18:40:12 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Walk on the Wild Side MIME-Version: 1.0 Date: Mon, 26 Nov 2007 18:40:12 -0500 Message-Id: <20071126234012.9C1642FCAA3@lawyers.icir.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [tcpm] WGLC for ECN-SYN 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="===============1092153346==" Errors-To: tcpm-bounces@ietf.org --===============1092153346== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- This note serves to kick off a WGLC for the ECN-SYN document: draft-ietf-tcpm-ecnsyn-03.txt We believe all the issues have been worked out of this I-D. Please yell if you still have issues. Notes of support for forwarding this draft are also appreciated and help us out. This draft is slated to be forwarded as a PS. Since IETF is next week and we are getting into the time of the year that folks start taking much needed time off we are planning an extended WGLC that lasts until Dec/21. Mark tcpm co-chair --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFHS1lcWyrrWs4yIs4RAt/qAKCbgDcAvnkhUCo9/zsIw/3kwMc3EwCdEObH oclg718TZ+e/xIB2sPVB8Po= =QeCk -----END PGP SIGNATURE----- --=_bOundary-- --===============1092153346== 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 --===============1092153346==-- From tcpm-bounces@ietf.org Mon Nov 26 19:47:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwoc1-0004rJ-Ab; Mon, 26 Nov 2007 19:47:41 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwobz-0004r0-PI for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 19:47:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwobz-0004qp-F0 for tcpm@ietf.org; Mon, 26 Nov 2007 19:47:39 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwobz-0005oH-1Q for tcpm@ietf.org; Mon, 26 Nov 2007 19:47:39 -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 lAR0lKiI026695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Nov 2007 16:47:21 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lAR0lKVx005001 for tcpm@ietf.org; Mon, 26 Nov 2007 16:47:20 -0800 (PST) (envelope-from faber) Date: Mon, 26 Nov 2007 16:47:20 -0800 From: Ted Faber To: tcpm@ietf.org Message-ID: <20071127004720.GD3385@hut.isi.edu> Mime-Version: 1.0 User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [tcpm] WGLC: 2581bis 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="===============0357552188==" Errors-To: tcpm-bounces@ietf.org --===============0357552188== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TybLhxa8M7aNoW+V" Content-Disposition: inline --TybLhxa8M7aNoW+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mark and I would like to start a WGLC for the revision of 2581 from Proposed Standard to Draft Standard. As you know, this is a central document in TCP and the revision pretty much just recognized that and adds an implementation report. The implementation report notes that basically all TCPs support the algorithms in the document interoperably. We believe this is ready for publication. Other than the addition of the report, changes to the document from the published Proposed Standard are minimal. Please read and let us know if you agree or disagree and why. This will be a long WGLC to accomodate for the IETF meeting next week and the holiday season. The WGLC will end 21 Dec 2007. --=20 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 --TybLhxa8M7aNoW+V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHS2kYaUz3f+Zf+XsRAilCAKDXugPhn2kCE9/CP3nZtzeresurkQCfQFzv XVbYTalXj7xqMkmTGKuhJZU= =6d3Y -----END PGP SIGNATURE----- --TybLhxa8M7aNoW+V-- --===============0357552188== 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 --===============0357552188==-- From tcpm-bounces@ietf.org Mon Nov 26 22:46:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwrPS-0004yU-17; Mon, 26 Nov 2007 22:46:54 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwrPQ-0004yI-0z for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 22:46:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwrPP-0004y8-MZ for tcpm@ietf.org; Mon, 26 Nov 2007 22:46:51 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwrPP-0005zD-6c for tcpm@ietf.org; Mon, 26 Nov 2007 22:46:51 -0500 Received: from [70.211.147.178] (178.sub-70-211-147.myvzw.com [70.211.147.178]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAR3kGlb022710; Mon, 26 Nov 2007 19:46:18 -0800 (PST) Message-ID: <474B92FA.7020902@isi.edu> Date: Mon, 26 Nov 2007 19:46:02 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lloyd Wood Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126163305.326192FC402@lawyers.icir.org> <474AFB2A.9080504@isi.edu> <200711262103.VAA27187@cisco.com> In-Reply-To: <200711262103.VAA27187@cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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="===============1204135438==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1204135438== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig55BCF3F81A943803ADF9EC7F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig55BCF3F81A943803ADF9EC7F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lloyd Wood wrote: > At Monday 26/11/2007 08:58 -0800, Joe Touch wrote: >=20 >> I see an OS that has to decide how to allocate resources: >> >> a- leave them with existing apps and prohibit new ones >> >> b- terminate existing apps to make room for new ones >> >> I expect that a reasonable, modern OS would do (a). >=20 > That presumes that all TCP connections are long-lived. It permits a > few long-lived connections to tie up resources that could service > short-lived connections. >=20 > (http, beep, xml-rpc and other short-lived transactions over TCP > weren't invented when RFC1122 was written.)=20 It presumes only that a connection shouldn't be terminated to make room for new ones. It says nothing about the duration of the connection. 1122 says that connections that are active - i.e., actively exchanging packets - MUST NOT be terminated. Connections are terminated only when applications indicate, OR when the endpoints cannot communicate. If you start "robbing Peter to pay Paul" - i.e., killing some connections to make room for others - you end up with a very unreliable kind of TCP. One where connections just disappear. Modern OS's don't kill apps to make room for new ones (presuming they're static in resource use). This is the connection equivalant. I agree that having the OS - who is SOLELY in view of shared resources - informing the application when resources are critical, and applications being designed to decide which connections to keep and which to drop based on *knowlege about the connections they alone possess*. However, once a connection is opened, I don't agree that it's the OS's perogative to kill it for any reason, any more than it would kill a process that isn't running away. Holding resources already granted is how current app/OS interfaces work; revocation isn't normal. Yes, this means that *applications* can be DOS attacked, and they need to be written to react accordingly. Joe --------------enig55BCF3F81A943803ADF9EC7F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHS5L6E5f5cImnZrsRAiUjAJ9kOprZwr3VRWQ9X/gzV6ayKFtxUgCfWGTR pedyY9um3ZvffOGmdIC5j4Y= =1UFK -----END PGP SIGNATURE----- --------------enig55BCF3F81A943803ADF9EC7F-- --===============1204135438== 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 --===============1204135438==-- From tcpm-bounces@ietf.org Mon Nov 26 22:48:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwrQr-0007VU-Az; Mon, 26 Nov 2007 22:48:21 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwrQq-0007UF-Gg for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 22:48:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwrQq-0007Rh-5i for tcpm@ietf.org; Mon, 26 Nov 2007 22:48:20 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwrQl-0003sO-S5 for tcpm@ietf.org; Mon, 26 Nov 2007 22:48:20 -0500 Received: from [70.211.147.178] (178.sub-70-211-147.myvzw.com [70.211.147.178]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAR3luVL022873; Mon, 26 Nov 2007 19:47:57 -0800 (PST) Message-ID: <474B935E.4040207@isi.edu> Date: Mon, 26 Nov 2007 19:47:42 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mahesh Jethanandani Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126161259.29EFA2FC343@lawyers.icir.org> <474AF34B.40805@isi.edu> <474B3C35.30207@cisco.com> In-Reply-To: <474B3C35.30207@cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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="===============1375872469==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1375872469== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1627A40E5B44D049B55A644A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1627A40E5B44D049B55A644A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani wrote: > Joe Touch wrote: >> >> Note also that DOS attacks would likely not keep TCP connections aroun= d >> with zero windows AND continue to ACK - they'd stop ACKing, the >> connection would drop for *that* reason, and be recovered. > Quite the contrary. Our experimentation revealed that DoS attackers > responded reliably with an ACK to all zero window probes and that > connections stayed in established state for days. OK - so how do you know these were attacks? Or are you calling any consumption of resources you don't expect an attack? I.e., all flash crowds are attacks? Joe --------------enig1627A40E5B44D049B55A644A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHS5NeE5f5cImnZrsRAukwAJ4jGpG2wTKQX2rt5FbewtbdbWtnqQCghcSe fSuKRnVYwe7UN6qrcwz5suE= =oj19 -----END PGP SIGNATURE----- --------------enig1627A40E5B44D049B55A644A-- --===============1375872469== 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 --===============1375872469==-- From tcpm-bounces@ietf.org Tue Nov 27 06:30:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwye2-00041I-HY; Tue, 27 Nov 2007 06:30:26 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwye0-00041B-Qy for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 06:30:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwydv-0003s4-95 for tcpm@ietf.org; Tue, 27 Nov 2007 06:30:19 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwydr-0002ma-Q1 for tcpm@ietf.org; Tue, 27 Nov 2007 06:30:19 -0500 X-IronPort-AV: E=Sophos;i="4.23,219,1194217200"; d="scan'208";a="158876090" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Nov 2007 12:30:13 +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 lARBUCs0003127; Tue, 27 Nov 2007 12:30:12 +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 lARBUBZZ015330; Tue, 27 Nov 2007 11:30:11 GMT Received: from lwood-wxp01.cisco.com (rtp-vpn3-67.cisco.com [10.82.216.67]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA11778; Tue, 27 Nov 2007 11:30:09 GMT Message-Id: <200711271130.LAA11778@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Nov 2007 11:30:06 +0000 To: Joe Touch From: Lloyd Wood Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] In-Reply-To: <474B92FA.7020902@isi.edu> References: <20071126163305.326192FC402@lawyers.icir.org> <474AFB2A.9080504@isi.edu> <200711262103.VAA27187@cisco.com> <474B92FA.7020902@isi.edu> 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: -4.0 (----) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 At Monday 26/11/2007 19:46 -0800, Joe Touch wrote: >Lloyd Wood wrote: >> At Monday 26/11/2007 08:58 -0800, Joe Touch wrote: >> >>> I see an OS that has to decide how to allocate resources: >>> >>> a- leave them with existing apps and prohibit new ones >>> >>> b- terminate existing apps to make room for new ones >>> >>> I expect that a reasonable, modern OS would do (a). >> >> That presumes that all TCP connections are long-lived. It permits a >> few long-lived connections to tie up resources that could service >> short-lived connections. >> >> (http, beep, xml-rpc and other short-lived transactions over TCP >> weren't invented when RFC1122 was written.) > >It presumes only that a connection shouldn't be terminated to make room >for new ones. It says nothing about the duration of the connection. well, obviously. that's because all connections were presumed to be long-lived. >1122 says that connections that are active - i.e., actively exchanging >packets - MUST NOT be terminated. If only it said connections actively exchanging data... >Connections are terminated only when >applications indicate, OR when the endpoints cannot communicate. > >If you start "robbing Peter to pay Paul" - i.e., killing some >connections to make room for others - you end up with a very unreliable >kind of TCP. One where connections just disappear. I'd argue we have that unreliable TCP already - e.g. varying # of SYNs repeated to ensure a connection is opened on different OSs, with different application behaviour as a result. Your connection just disappeared because the SYN and the sole repeat Windows sends were lost? Hit reload in your web browser! (How applications handle end-to-end reliability across TCP is a separate problem, but the end-to-end argument suggests that TCP can be unreliable - it's not the highest level.) >Modern OS's don't kill apps to make room for new ones (presuming they're >static in resource use). This is the connection equivalant. What's the connection equivalent of swapping an unused app out to virtual memory and forgetting about it? L. >I agree that having the OS - who is SOLELY in view of shared resources - >informing the application when resources are critical, and applications >being designed to decide which connections to keep and which to drop >based on *knowlege about the connections they alone possess*. > >However, once a connection is opened, I don't agree that it's the OS's >perogative to kill it for any reason, any more than it would kill a >process that isn't running away. Holding resources already granted is >how current app/OS interfaces work; revocation isn't normal. > >Yes, this means that *applications* can be DOS attacked, and they need >to be written to react accordingly. > >Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 27 09:11:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix19R-0006va-Re; Tue, 27 Nov 2007 09:11:01 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ix19Q-0006vO-Tf for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 09:11:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix19Q-0006vC-Iw for tcpm@ietf.org; Tue, 27 Nov 2007 09:11:00 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix19Q-00029q-3k for tcpm@ietf.org; Tue, 27 Nov 2007 09:11:00 -0500 Received: from [12.170.144.92] (245ahost92.starwoodbroadband.com [12.170.144.92]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAREATf4025253; Tue, 27 Nov 2007 06:10:30 -0800 (PST) Message-ID: <474C2548.1060608@isi.edu> Date: Tue, 27 Nov 2007 06:10:16 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Lloyd Wood Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126163305.326192FC402@lawyers.icir.org> <474AFB2A.9080504@isi.edu> <200711262103.VAA27187@cisco.com> <474B92FA.7020902@isi.edu> <200711271130.LAA11778@cisco.com> In-Reply-To: <200711271130.LAA11778@cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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="===============1203202947==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1203202947== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig27D45D7F94D6BB7E8F42A66E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig27D45D7F94D6BB7E8F42A66E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lloyd Wood wrote: =2E.. >> 1122 says that connections that are active - i.e., actively exchanging= >> packets - MUST NOT be terminated.=20 >=20 > If only it said connections actively exchanging data... See 1122 sec 4.2.2.17, as I cited before. Active exchange of probes is sufficient. >> Connections are terminated only when >> applications indicate, OR when the endpoints cannot communicate. >> >> If you start "robbing Peter to pay Paul" - i.e., killing some >> connections to make room for others - you end up with a very unreliabl= e >> kind of TCP. One where connections just disappear. >=20 > I'd argue we have that unreliable TCP already - e.g. varying # of > SYNs > repeated to ensure a connection is opened on different OSs, with > different application behaviour as a result. Your connection just > disappeared because the SYN and the sole repeat Windows sends were lost= ? > Hit reload in your web browser! (How applications handle end-to-end > reliability across TCP is a separate problem, but the end-to-end > argument suggests that TCP can be unreliable - it's not the highest lev= el.) I agree that unpredictable OPEN behavior isn't good, but it's not unreliable. TCP is reliable only after a connection is open, not on the open itself. >> Modern OS's don't kill apps to make room for new ones (presuming they'= re >> static in resource use). This is the connection equivalant. >=20 > What's the connection equivalent of swapping an unused app out to virtu= al memory and forgetting about it? Sounds like advertising a zero window would be similar; note that starvation-free OS's don't "forget" about swapped processes, though -- so I wouldn't expect either to starve a process/connection indefinitely, or to just kill a connection/process. Joe --------------enig27D45D7F94D6BB7E8F42A66E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHTCVIE5f5cImnZrsRApXBAJ9jhMbjF2eBPSpcOnhwvAp9phgxDgCgr/DY SbYNi0oDoAbw/eovZdFfWl0= =VIIy -----END PGP SIGNATURE----- --------------enig27D45D7F94D6BB7E8F42A66E-- --===============1203202947== 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 --===============1203202947==-- From tcpm-bounces@ietf.org Tue Nov 27 09:58:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1tl-0007xS-1f; Tue, 27 Nov 2007 09:58:53 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ix1tk-0007xF-2R for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 09:58:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1tj-0007x5-P4 for tcpm@ietf.org; Tue, 27 Nov 2007 09:58:51 -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 1Ix1ti-0008Mb-1k for tcpm@ietf.org; Tue, 27 Nov 2007 09:58:51 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id lAREwhVp008641; Tue, 27 Nov 2007 06:58:43 -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); Tue, 27 Nov 2007 06:58:43 -0800 Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 06:58:43 -0800 Message-Id: <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> From: David Borman To: Mark Allman , Joe Touch In-Reply-To: <20071126193803.585E12FC5BE@lawyers.icir.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Date: Tue, 27 Nov 2007 08:58:40 -0600 References: <20071126193803.585E12FC5BE@lawyers.icir.org> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 27 Nov 2007 14:58:43.0285 (UTC) FILETIME=[00C9D050:01C83106] X-Spam-Score: -1.0 (-) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Ok, I haven't chimed in yet on this conversation. While I agree with the document on the identification of the problem, I disagree with the proposed solution (changing TCP to time out connections in persist state). Having a connection stay in persist state for long periods of time (i.e., zero window probes continue to be ACKed) by itself is not a bad thing. That is how TCP was designed to work. Connections can survive through lots of adversity. If a connection is stuck because it is waiting for user action and the user walked away and went home for the day, he should be able to come back the next morning and do what needs to be done, and then the connection will continue. As has already been stated, the issue is what should the OS do when it runs out of resources. TCP implementations typically oversubscribe their resources, and run into problems when all the open connections try to use up all the resources that they've been told they can use. In this situation, the OS has to figure out some way to free up resources. There may be some things it can do without killing connections (e.g., flush TCP resequencing queues), but usually that won't be sufficient if you have a runaway or malicious source that is causing the resource problem in the first place. In this situation, anything the OS decides to do, including killing TCP connections, is at the discretion of the OS, and I don't that view as violating any RFC. You're out of resources, you have to do something. This is not a TCP protocol issue, it is an OS implementation issue. Now, it might be that connections that have been in persist state for a long period of time are good candidates for the OS to abort to free up resources. But doing that has to be a decision of the OS or the application, not of TCP. TCP can keep track of how long connections are in persist state, so that if the OS or application asks, it can judiciously choose which ones are the best to abort. Let's look at keep-alives. They are not part of the TCP specification. They aren't perfect. In RFC 1122, we acknowledged their existence, and placed restrictions on them. The must default to off. The default interval for sending keep-alives must be at least 2 hours. You don't drop a connection due to just one missed keep- alive. "A TCP keep-alive mechanism should only be invoked in server applications that might otherwise hang indefinitely and consume resources unnecessarily if a client crashes or aborts a connection during a network failure." But they do serve a useful purpose. In the end, it is the responsibility of the application to place limits on its TCP connections. If the OS provides a simple way for the application to say "ABORT this TCP connection if it remains in persist state (or idle state, or...) for more than X period of time", I don't have any objection to that. That's an agreement between the application and the OS. It has the nice advantage that the OS knows what to do with the connection after the application has written all its data and closed its side of the connection, and hence is no longer able to ABORT the connection. When the system runs out of resources, it is the responsibility of the OS to decide how to deal with that situation. If TCP is consuming large amounts of resources, then the OS will have to have some way to tell TCP how to free up resources, including ABORTing connections. There have always been ways that TCP implementation can tie up resources, and we've been working to mitigate those things all along. (The first one I remember dealing with was the "send each octet in a separate packet, but don't send the first octet". That tied up resources on BSD on the TCP resequencing queue.) One difference between now and 15-20 years ago, is that back then many of the resource issues were not intentional, but due to poorly written applications or just new scenarios that hadn't been exercised before. But what hasn't changed is that the problems are usually due to implementation issues, not problems with the TCP protocol. And that holds true in this case. -David Borman On Nov 26, 2007, at 1:38 PM, Mark Allman wrote: ... > >> Like I said: you and I are not going to agree about how to interpret > RFC112 (in 2007). It would be good to hear other opinions. > > allman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 27 10:06:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix20m-0004p8-3x; Tue, 27 Nov 2007 10:06:08 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ix20j-0004oM-Gu for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 10:06:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix20g-0004nT-F1 for tcpm@ietf.org; Tue, 27 Nov 2007 10:06:02 -0500 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix20g-0003lx-5s for tcpm@ietf.org; Tue, 27 Nov 2007 10:06:02 -0500 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 831F3C22D for ; Tue, 27 Nov 2007 10:06:01 -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 lARF61Oc027710; Tue, 27 Nov 2007 10:06:01 -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 lARF60H8029216; Tue, 27 Nov 2007 10:06:00 -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 LYYDJEkwo37Y; Tue, 27 Nov 2007 10:06:00 -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 lARF5uum029206;Tue, 27 Nov 2007 10:05:56 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 75FC514052; Tue, 27 Nov 2007 10:04:44 -0500 (EST) Date: Tue, 27 Nov 2007 10:04:44 -0500 From: weddy@grc.nasa.gov To: David Borman Subject: Re: Summary of responses so far and proposal movingforward[WasRe:[tcpm] Is this a problem?] Message-ID: <20071127150444.GD19701@grc.nasa.gov> References: <20071126193803.585E12FC5BE@lawyers.icir.org> <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-imss-version: 2.046 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 2.1 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: TCP Maintenance and Minor Extensions WG 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 Tue, Nov 27, 2007 at 08:58:40AM -0600, David Borman wrote: > > While I agree with the document on the identification of the problem, I > disagree with the proposed solution (changing TCP to time out connections > in persist state). I'm in harmony with this and everything else Dave said. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 27 16:57:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix8QL-0000Ak-4t; Tue, 27 Nov 2007 16:56:57 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ix8QJ-0000AH-Vj for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 16:56:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix8QJ-0000A6-Gy for tcpm@ietf.org; Tue, 27 Nov 2007 16:56:55 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix8QH-00085o-TV for tcpm@ietf.org; Tue, 27 Nov 2007 16:56:55 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Nov 2007 13:56:53 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lARLuroW009628; Tue, 27 Nov 2007 13:56:53 -0800 Received: from [171.69.75.93] (dhcp-171-69-75-93.cisco.com [171.69.75.93]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lARLur1f009526; Tue, 27 Nov 2007 21:56:53 GMT Message-ID: <474C92A5.7070208@cisco.com> Date: Tue, 27 Nov 2007 13:56:53 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Joe Touch Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126161259.29EFA2FC343@lawyers.icir.org> <474AF34B.40805@isi.edu> <474B3C35.30207@cisco.com> <474B935E.4040207@isi.edu> In-Reply-To: <474B935E.4040207@isi.edu> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2583; t=1196200613; x=1197064613; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward[WasRe=3A=0A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=s7DjzkpKA9VfcN81b28l5Cd36YeRolopMY0qYhzQm34=; b=iUruYdykA2j3Au3/OZLVccDDId7KGNIRXQnJqWXyGtaRhdNNl1cLHoZ4Jjpms5agq2H/nC7S lQR8/2hNBD9eFcf7VXozfCzUJof5KLbjxA2p6j4Nv+I6AZApw3OCoKZq; Authentication-Results: sj-dkim-3; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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="===============0916968574==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0916968574== Content-Type: multipart/alternative; boundary="------------020100090708000507010205" This is a multi-part message in MIME format. --------------020100090708000507010205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Joe Touch wrote: > Mahesh Jethanandani wrote: > >> Joe Touch wrote: >> >>> Note also that DOS attacks would likely not keep TCP connections around >>> with zero windows AND continue to ACK - they'd stop ACKing, the >>> connection would drop for *that* reason, and be recovered. >>> >> Quite the contrary. Our experimentation revealed that DoS attackers >> responded reliably with an ACK to all zero window probes and that >> connections stayed in established state for days. >> > > OK - so how do you know these were attacks? Or are you calling any > consumption of resources you don't expect an attack They were attacks because we had initiated them as such. The point is that (and you seemed to have accepted it by saying ok) that you cannot rely on the attacker giving up and going away to free the resources. -- /mahesh --------------020100090708000507010205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Joe Touch wrote: 
Mahesh Jethanandani wrote:
  
Joe Touch wrote:
    
Note also that DOS attacks would likely not keep TCP connections around
with zero windows AND continue to ACK - they'd stop ACKing, the
connection would drop for *that* reason, and be recovered.
      
Quite the contrary. Our experimentation revealed that DoS attackers
responded reliably with an ACK to all zero window probes and that
connections stayed in established state for days.
    

OK - so how do you know these were attacks? Or are you calling any
consumption of resources you don't expect an attack
They were attacks because we had initiated them as such.

The point is that (and you seemed to have accepted it by saying ok) that you cannot rely on the attacker giving up and going away to free the resources.
--
/mahesh
--------------020100090708000507010205-- --===============0916968574== 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 --===============0916968574==-- From tcpm-bounces@ietf.org Tue Nov 27 18:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9kY-0007pn-Vf; Tue, 27 Nov 2007 18:21:54 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ix9kX-0007pH-Dz for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 18:21:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9kX-0007p8-4J for tcpm@ietf.org; Tue, 27 Nov 2007 18:21:53 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix9kU-0005Fw-Ln for tcpm@ietf.org; Tue, 27 Nov 2007 18:21:53 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 27 Nov 2007 15:21:50 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lARNLo9F013602; Tue, 27 Nov 2007 15:21:50 -0800 Received: from [171.69.75.93] (dhcp-171-69-75-93.cisco.com [171.69.75.93]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lARNLdnb003871; Tue, 27 Nov 2007 23:21:39 GMT Message-ID: <474CA683.2030600@cisco.com> Date: Tue, 27 Nov 2007 15:21:39 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Borman Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126193803.585E12FC5BE@lawyers.icir.org> <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> In-Reply-To: <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9001; t=1196205710; x=1197069710; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward[WasRe=3A=0A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=ZdW85VMHQKCslR68oxx68AXQEf4gPitl64IbziZESIU=; b=L2yeUUbRRjeveNK15txYMdW6lOom5p6zMucKyfjUd1XU47J6JD8pFvB0ugiDArZWCu8sc66+ jqZF9wluCpPkIRm4uuOrYFwYuaa7pc3YmsqIj7xez0zrpHRZzm8U7EQ/; Authentication-Results: sj-dkim-4; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: 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="===============0897513013==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0897513013== Content-Type: multipart/alternative; boundary="------------020506050301090709010003" This is a multi-part message in MIME format. --------------020506050301090709010003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Borman wrote: > Ok, I haven't chimed in yet on this conversation. I am glad you finally did :-) > > While I agree with the document on the identification of the problem, > I disagree with the proposed solution (changing TCP to time out > connections in persist state). Having a connection stay in persist > state for long periods of time (i.e., zero window probes continue to > be ACKed) by itself is not a bad thing. That is how TCP was designed > to work. Connections can survive through lots of adversity. If a > connection is stuck because it is waiting for user action and the user > walked away and went home for the day, he should be able to come back > the next morning and do what needs to be done, and then the connection > will continue. My understanding of rfc 1122 is and I quote from the rfc itself: > A TCP MAY keep its offered receive window closed > indefinitely. As long as the receiving TCP continues to > send acknowledgments in response to the probe segments, the > sending TCP MUST allow the connection to stay open. > > DISCUSSION: > It is extremely important to remember that ACK > (acknowledgment) segments that contain no data are not > reliably transmitted by TCP. If zero window probing is > not supported, a connection may hang forever when an > ACK segment that re-opens the window is lost. > This tells me that the concern was with ACK's getting lost in the network and that is why the need to keep the connection open. The point we bring up in the draft is in the case the ACK's are being received reliably then the need to keep the connection open just to make sure the ACK has made it to the other end goes away. That is why the request to change the language to say that *in case of reliable ACK*, TCP MAY tear the connection down if it is not able to service existing or new connections. We seem to agree on the user scenario you describe above. That is why we make it clear in the draft that we should not tear down a connection just because the connection is open for a long time. Where there is one or a few connections that are keeping the connection open, the solution will not tear the connection down. The problem happens is when lots of users (or attackers) do the same. > > As has already been stated, the issue is what should the OS do when it > runs out of resources. TCP implementations typically oversubscribe > their resources, and run into problems when all the open connections > try to use up all the resources that they've been told they can use. > In this situation, the OS has to figure out some way to free up > resources. There may be some things it can do without killing > connections (e.g., flush TCP resequencing queues), but usually that > won't be sufficient if you have a runaway or malicious source that is > causing the resource problem in the first place. In this situation, > anything the OS decides to do, including killing TCP connections, is > at the discretion of the OS, and I don't that view as violating any > RFC. You're out of resources, you have to do something. This is not > a TCP protocol issue, it is an OS implementation issue. True. But it was caused by TCP's insistence on keeping the connection open that causes the OS to even run out of resources, even if the reason to keep the connection open (unreliable ACKs) may not be true. I know there is very little support for this argument, but for a reader reading the rfc there is sufficient confusion on whether the connection can be cleared or not. Why not change the MUST to a MAY for reliable ACKs? People on this mailing list have been arguing on the point of if connections can even be cleared and this is tcpm mailing list!! Everybody is a TCP expert here. Is it not telling of a problem in the language of the rfc? /mahesh --------------020506050301090709010003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

David Borman wrote:
Ok, I haven't chimed in yet on this conversation.
I am glad you finally did :-)

While I agree with the document on the identification of the problem, I disagree with the proposed solution (changing TCP to time out connections in persist state).  Having a connection stay in persist state for long periods of time (i.e., zero window probes continue to be ACKed) by itself is not a bad thing.  That is how TCP was designed to work.  Connections can survive through lots of adversity.  If a connection is stuck because it is waiting for user action and the user walked away and went home for the day, he should be able to come back the next morning and do what needs to be done, and then the connection will continue.
My understanding of rfc 1122 is and I quote from the rfc itself:

A TCP MAY keep its offered receive window closed
            indefinitely.  As long as the receiving TCP continues to
            send acknowledgments in response to the probe segments, the
            sending TCP MUST allow the connection to stay open.

            DISCUSSION:
                 It is extremely important to remember that ACK
                 (acknowledgment) segments that contain no data are not
                 reliably transmitted by TCP.  If zero window probing is
                 not supported, a connection may hang forever when an
                 ACK segment that re-opens the window is lost.
This tells me that the concern was with ACK's getting lost in the network and that is why the need to keep the connection open. The point we bring up in the draft is in the case the ACK's are being received reliably then the need to keep the connection open just to make sure the ACK has made it to the other end goes away. That is why the request to change the language to say that in case of reliable ACK, TCP MAY tear the connection down if it is not able to service existing or new connections.

We seem to agree on the user scenario you describe above.  That is why we make it clear in the draft that we should not tear down a connection just because the connection is open for a long time. Where there is one or a few connections that are keeping the connection open, the solution will not tear the connection down. The problem happens is when lots of users (or attackers) do the same.

As has already been stated, the issue is what should the OS do when it runs out of resources.  TCP implementations typically oversubscribe their resources, and run into problems when all the open connections try to use up all the resources that they've been told they can use.  In this situation, the OS has to figure out some way to free up resources.  There may be some things it can do without killing connections (e.g., flush TCP resequencing queues), but usually that won't be sufficient if you have a runaway or malicious source that is causing the resource problem in the first place.  In this situation, anything the OS decides to do, including killing TCP connections, is at the discretion of the OS, and I don't that view as violating any RFC.  You're out of resources, you have to do something.  This is not a TCP protocol issue, it is an OS implementation issue.
True. But it was caused by TCP's insistence on keeping the connection open that causes the OS to even run out of resources, even if the reason to keep the connection open (unreliable ACKs) may not be true.

I know there is very little support for this argument, but for a reader reading the rfc there is sufficient confusion on whether the connection can be cleared or not. Why not change the MUST to a MAY for reliable ACKs?

People on this mailing list have been arguing on the point of if connections can even be cleared and this is tcpm mailing list!! Everybody is a TCP expert here. Is it not telling of a problem in the language of the rfc?

/mahesh
--------------020506050301090709010003-- --===============0897513013== 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 --===============0897513013==-- From tcpm-bounces@ietf.org Tue Nov 27 18:34:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9ws-0003jr-Kg; Tue, 27 Nov 2007 18:34:38 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ix9wr-0003jl-Q9 for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 18:34:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9wr-0003ja-F3 for tcpm@ietf.org; Tue, 27 Nov 2007 18:34:37 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix9wq-0003N8-Sg for tcpm@ietf.org; Tue, 27 Nov 2007 18:34:37 -0500 Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ix9wk-0002jp-Dg for tcpm@ietf.org; Tue, 27 Nov 2007 23:34:36 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 1186D2BE21 for ; Tue, 27 Nov 2007 18:34:27 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 417C02842B; Tue, 27 Nov 2007 18:34:27 -0500 (EST) Date: Tue, 27 Nov 2007 18:34:27 -0500 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Message-ID: <20071127233427.GA20243@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <20071126193803.585E12FC5BE@lawyers.icir.org> <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> <474CA683.2030600@cisco.com> MIME-Version: 1.0 In-Reply-To: <474CA683.2030600@cisco.com> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -102.6 (---------------------------------------------------) X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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="===============1955261237==" Errors-To: tcpm-bounces@ietf.org --===============1955261237== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani spake unto us the following wisdom: > RFC1122: > A TCP MAY keep its offered receive window closed > indefinitely. As long as the receiving TCP continues to > send acknowledgments in response to the probe segments, the > sending TCP MUST allow the connection to stay open. > > DISCUSSION: > It is extremely important to remember that ACK > (acknowledgment) segments that contain no data are not > reliably transmitted by TCP. If zero window probing is > not supported, a connection may hang forever when an > ACK segment that re-opens the window is lost. > > This tells me that the concern was with ACK's getting lost in the=20 > network and that is why the need to keep the connection open. The point= =20 > we bring up in the draft is in the case the ACK's are being received=20 > reliably then the need to keep the connection open just to make sure the= =20 > ACK has made it to the other end goes away. That is why the request to=20 > change the language to say that *in case of reliable ACK*, TCP MAY tear= =20 > the connection down if it is not able to service existing or new=20 > connections. I hate to wade back into this, and this may be tangential to the discussion at hand, but the reason for allowing TCP connections to persist indefinitely is NOT because ACKs may be lost; it is because applications may be busy indefinitely. ACK loss is merely the reason for continued ZWP. > >As has already been stated, the issue is what should the OS do when it= =20 > >runs out of resources. TCP implementations typically oversubscribe=20 > >their resources, and run into problems when all the open connections=20 > >try to use up all the resources that they've been told they can use. =20 > >In this situation, the OS has to figure out some way to free up=20 > >resources. There may be some things it can do without killing=20 > >connections (e.g., flush TCP resequencing queues), but usually that=20 > >won't be sufficient if you have a runaway or malicious source that is=20 > >causing the resource problem in the first place. In this situation,=20 > >anything the OS decides to do, including killing TCP connections, is=20 > >at the discretion of the OS, and I don't that view as violating any=20 > >RFC. You're out of resources, you have to do something. This is not=20 > >a TCP protocol issue, it is an OS implementation issue. > > True. But it was caused by TCP's insistence on keeping the connection=20 > open that causes the OS to even run out of resources, even if the reason= =20 > to keep the connection open (unreliable ACKs) may not be true. Only in the *very specific* *corner case* that the open connections are connections in PERSIST. As best I can tell, you have noted elsewhere that you have never even seen this in the wild; you ran your own DoS with a homemade tool and called that the wild. Again, unreliable ACKs are NOT the reason to keep the connection open, you misread or misunderstood 1122. Your argument seems to dance around a lot, which makes it difficult to discuss. 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 --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTKmCr9kA9Ig8HBQRAmWHAJ0YXKB1qfZR1zL/N4ZUtp3ky4kTqACfVo2n sEzCX6mmsynYgcBha8Mnsng= =vmLU -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- --===============1955261237== 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 --===============1955261237==-- From tcpm-bounces@ietf.org Tue Nov 27 18:37:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9zs-00069I-Ig; Tue, 27 Nov 2007 18:37:44 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ix9zr-00068z-40 for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 18:37:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9zq-00068k-PC for tcpm@ietf.org; Tue, 27 Nov 2007 18:37:42 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix9zq-0004AY-Ce for tcpm@ietf.org; Tue, 27 Nov 2007 18:37:42 -0500 Received: from [67.59.55.189] (helo=elb.elitists.net) by psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ix9zk-0002va-DA for tcpm@ietf.org; Tue, 27 Nov 2007 23:37:42 +0000 Received: from colt.internal (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id DB56D2BE21 for ; Tue, 27 Nov 2007 18:37:33 -0500 (EST) Received: by colt.internal (Postfix, from userid 3000) id 26C362842B; Tue, 27 Nov 2007 18:37:33 -0500 (EST) Date: Tue, 27 Nov 2007 18:37:33 -0500 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Message-ID: <20071127233733.GB20243@elb.elitists.net> Mail-Followup-To: tcpm@ietf.org References: <20071126161259.29EFA2FC343@lawyers.icir.org> <474AF34B.40805@isi.edu> <474B3C35.30207@cisco.com> <474B935E.4040207@isi.edu> <474C92A5.7070208@cisco.com> MIME-Version: 1.0 In-Reply-To: <474C92A5.7070208@cisco.com> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -103.1 (---------------------------------------------------) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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="===============0745033313==" Errors-To: tcpm-bounces@ietf.org --===============0745033313== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani spake unto us the following wisdom: > Joe Touch wrote: > >Mahesh Jethanandani wrote: > >>Joe Touch wrote: > >>>Note also that DOS attacks would likely not keep TCP connections around > >>>with zero windows AND continue to ACK - they'd stop ACKing, the > >>>connection would drop for *that* reason, and be recovered. > >> > >>Quite the contrary. Our experimentation revealed that DoS attackers > >>responded reliably with an ACK to all zero window probes and that > >>connections stayed in established state for days. > > > >OK - so how do you know these were attacks? Or are you calling any > >consumption of resources you don't expect an attack > > They were attacks because we had initiated them as such. This is _very different_ from what you claimed before. You are claiming that attacks *do exist* which reliably ACK zero window probes -- but you don't know that, and have no support for it. You have support for the fact that an attack *can be created* which ACKs zero window probes. Joe's point, and I think it is valid, is that this is an attack which requires a commitment of resources on the part of the attacker. That said, I agree that such an attack *could* be created, though it appears that no one has. 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 --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTKo9r9kA9Ig8HBQRAj4zAKCmNeSpHCquK79dGc8MZnWXrfWiXgCdFpmw aY0r0zwGXkvGxC42+uYt0vw= =HcNL -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- --===============0745033313== 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 --===============0745033313==-- From tcpm-bounces@ietf.org Tue Nov 27 18:51:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxADH-00030n-9R; Tue, 27 Nov 2007 18:51:35 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxADG-00030f-PI for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 18:51:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxADG-00030N-D2 for tcpm@ietf.org; Tue, 27 Nov 2007 18:51:34 -0500 Received: from web31708.mail.mud.yahoo.com ([68.142.201.188]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxADF-0007lf-DO for tcpm@ietf.org; Tue, 27 Nov 2007 18:51:34 -0500 Received: (qmail 53304 invoked by uid 60001); 27 Nov 2007 23:51:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=A49GALXot5fD+npU5nuLLob3ga0H59INSyTI5ui0M4mabPkJJal1jrp8r59ipFhzhuLd94sxzzVvTOPyE/5iNtYtVVy1prGVDUCpm0nwAdPbq5+P0vjX6dFsh35MGZ195JJEC8IKTc1ksf7W/Nde4IVKggcKcwPk9/Sc5ST2ZAo=; X-YMail-OSG: qkGiRQcVM1k35G1PtgLlaqub6fYJ3P33UlzQJ4snGv.XCxFVzgNVR1x.EMSuauSO9DAkWg5zmbfBfeJ8yrmiMDIelrYzyf9oNd4ltR5__y0g4Ry4eRU- Received: from [69.3.29.18] by web31708.mail.mud.yahoo.com via HTTP; Tue, 27 Nov 2007 15:51:32 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157 Date: Tue, 27 Nov 2007 15:51:32 -0800 (PST) From: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] To: David Borman , Mark Allman , Joe Touch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <362265.35986.qm@web31708.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org ----- Original Message ---- > From: David Borman > To: Mark Allman ; Joe Touch > Cc: TCP Maintenance and Minor Extensions WG > Sent: Tuesday, November 27, 2007 6:58:40 AM > Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] > > Ok, I haven't chimed in yet on this conversation. > > While I agree with the document on the identification of the problem, > I disagree with the proposed solution (changing TCP to time out > connections in persist state). Having a connection stay in persist > state for long periods of time (i.e., zero window probes continue to > be ACKed) by itself is not a bad thing. That is how TCP was designed > to work. Connections can survive through lots of adversity. If a > connection is stuck because it is waiting for user action and the > user > > walked away and went home for the day, he should be able to come back > the next morning and do what needs to be done, and then the > connection > > will continue. This is fine for a telnet/rlogin type of connection, it's never the normal behaviour for the web or http/xml type of connections (u don't click on a link today and come back the next day to see the page). And this is precisely the environment and circumstance that the RFC addresses and mandates the TCP sender persist indefinitely. Things have changed a lot since those days. Today TCP sender behaviour has to accomodate for a wide range of application usage. For the web application, i can tell you with confidence that for a sender to be persisting indefinitely for several hours together and for a large number of connections at that, definitely indicates anomalous receiver behaviour. On a per application basis, we are suggesting the app has the flexibility to enable this different TCP behaviour of not persisting indefinitely. Or the administrator enables this globally for the system. The default behaviour continues to be the same as today. > > As has already been stated, the issue is what should the OS do when > it > > runs out of resources. TCP implementations typically oversubscribe > their resources, and run into problems when all the open connections > try to use up all the resources that they've been told they can use. > In this situation, the OS has to figure out some way to free up > resources. There may be some things it can do without killing > connections (e.g., flush TCP resequencing queues), but usually that > won't be sufficient if you have a runaway or malicious source that is > causing the resource problem in the first place. In this situation, > anything the OS decides to do, including killing TCP connections, is > at the discretion of the OS, and I don't that view as violating any > RFC. You're out of resources, you have to do something. This is not > a TCP protocol issue, it is an OS implementation issue. There are 2 finite resources at stake here, TCP sender (not receiver) buffer resources and TCP connections. OS keeps resources for the entire system including other protocols, for example UDP could be running on the system too, and frequently TCP can reach a limit on the resources it is allowed to use and yet the OS/system cannot detect this since from a system point of view, it does have resources. The OS certainly cannot detect TCP connection pool being exhausted. Seems like TCP should clean up its own resources taking total connection availability and total buffer pool into account. A clean solution shouldn't be lumping OS and TCP together. > > Now, it might be that connections that have been in persist state for > a long period of time are good candidates for the OS to abort to free > up resources. But doing that has to be a decision of the OS or the > application, not of TCP. TCP can keep track of how long connections > are in persist state, so that if the OS or application asks, it can > judiciously choose which ones are the best to abort. Since you going down this path, what's wrong with TCP doing it by itself having received go-ahead from the application and/or the administrator of the system? Seems as if we are going to extreme lengths and playing with system boundary definitions here to avoid making a change where it hurts most (TCP). > > Let's look at keep-alives. They are not part of the TCP > specification. They aren't perfect. In RFC 1122, we acknowledged > their existence, and placed restrictions on them. The must default > to > > off. The default interval for sending keep-alives must be at least 2 > hours. You don't drop a connection due to just one missed keep- > alive. "A TCP keep-alive mechanism should only be invoked in server > applications that might otherwise hang indefinitely and consume > resources unnecessarily if a client crashes or aborts a connection > during a network failure." But they do serve a useful purpose. > > In the end, it is the responsibility of the application to place > limits on its TCP connections. If the OS provides a simple way for > the application to say "ABORT this TCP connection if it remains in > persist state (or idle state, or...) for more than X period of time", > I don't have any objection to that. That's an agreement between the > application and the OS. It has the nice advantage that the OS knows > what to do with the connection after the application has written all > its data and closed its side of the connection, and hence is no > longer > Why should the OS and not TCP that should be doing the abort, it's TCP responsibility after all to abort a connection? Or by OS do you mean the TCP implementation here? > able to ABORT the connection. When the system runs out of resources, > it is the responsibility of the OS to decide how to deal with that > situation. If TCP is consuming large amounts of resources, then the > OS will have to have some way to tell TCP how to free up resources, > including ABORTing connections. > > There have always been ways that TCP implementation can tie up > resources, and we've been working to mitigate those things all along. > > (The first one I remember dealing with was the "send each octet in a > separate packet, but don't send the first octet". That tied up > resources on BSD on the TCP resequencing queue.) One difference > between now and 15-20 years ago, is that back then many of the > resource issues were not intentional, but due to poorly written > applications or just new scenarios that hadn't been exercised before. > > But what hasn't changed is that the problems are usually due to > implementation issues, not problems with the TCP protocol. And that > holds true in this case. > In this instance, the implementation issue stems from the protocol definition itself, the TCP protocol implementation has faithfully followed the RFC here i.e persist indefinitely and not abort, and for the OS to be aborting connections without considering connection state and context would definitely lead to non-compliant TCP behaviour. I don't agree that Aborting an idle connection falls in the same category as this issue. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Nov 27 19:16:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxAbb-0005T0-A1; Tue, 27 Nov 2007 19:16:43 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxAba-0005M2-Dt for tcpm-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 19:16:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxAbZ-0005Lf-W9 for tcpm@ietf.org; Tue, 27 Nov 2007 19:16:42 -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 1IxAbY-0002Gy-D2 for tcpm@ietf.org; Tue, 27 Nov 2007 19:16:41 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id lAS0GVHq024457; Tue, 27 Nov 2007 16:16:31 -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); Tue, 27 Nov 2007 16:16:31 -0800 Received: from [172.25.34.21] ([172.25.34.21]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 16:16:31 -0800 Message-Id: <3EE5954A-5E50-4B1E-82BC-7A5FD55AEF1F@windriver.com> From: David Borman To: Mahesh Jethanandani In-Reply-To: <474CA683.2030600@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Date: Tue, 27 Nov 2007 18:16:29 -0600 References: <20071126193803.585E12FC5BE@lawyers.icir.org> <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> <474CA683.2030600@cisco.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Nov 2007 00:16:31.0515 (UTC) FILETIME=[ED686EB0:01C83153] X-Spam-Score: -1.0 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 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 Nov 27, 2007, at 5:21 PM, Mahesh Jethanandani wrote: > My understanding of rfc 1122 is and I quote from the rfc itself: > >> A TCP MAY keep its offered receive window closed >> indefinitely. As long as the receiving TCP continues to >> send acknowledgments in response to the probe segments, >> the >> sending TCP MUST allow the connection to stay open. >> >> DISCUSSION: >> It is extremely important to remember that ACK >> (acknowledgment) segments that contain no data are >> not >> reliably transmitted by TCP. If zero window >> probing is >> not supported, a connection may hang forever when an >> ACK segment that re-opens the window is lost. >> > This tells me that the concern was with ACK's getting lost in the > network and that is why the need to keep the connection open. The > point we bring up in the draft is in the case the ACK's are being > received reliably then the need to keep the connection open just to > make sure the ACK has made it to the other end goes away. That is > why the request to change the language to say that in case of > reliable ACK, TCP MAY tear the connection down if it is not able to > service existing or new connections. You are misreading this. This section (4.2.2.1) has two requirements: 1) Zero Window Probing must be supported (to guard against lost window updates), and 2) as long as you get responses to the ZWP, you must keep the connection open. That's it. You aren't keeping it open to get lost ACKs, you're keeping it open because the other side of the connection is still there and responding. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 28 01:52:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGm6-00073r-K3; Wed, 28 Nov 2007 01:51:58 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxGm4-00073l-O4 for tcpm-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 01:51:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGm4-00073d-BA for tcpm@ietf.org; Wed, 28 Nov 2007 01:51:56 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxGm3-0004RD-Ub for tcpm@ietf.org; Wed, 28 Nov 2007 01:51:56 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Nov 2007 22:51:55 -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 lAS6ptYt005791; Tue, 27 Nov 2007 22:51:55 -0800 Received: from [10.21.104.26] (sjc-vpnasa1-26.cisco.com [10.21.104.26]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAS6pm1f022654; Wed, 28 Nov 2007 06:51:48 GMT Message-ID: <474D1004.9030100@cisco.com> Date: Tue, 27 Nov 2007 22:51:48 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Borman Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126193803.585E12FC5BE@lawyers.icir.org> <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> <474CA683.2030600@cisco.com> <3EE5954A-5E50-4B1E-82BC-7A5FD55AEF1F@windriver.com> In-Reply-To: <3EE5954A-5E50-4B1E-82BC-7A5FD55AEF1F@windriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1552; t=1196232715; x=1197096715; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward[WasRe=3A=0A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=h+CZOfgSlkZ63PFRKAejZE1hkEN3oT2bXJPwC3btpbU=; b=nwu3zmQRkVQTxSDHTNWhoBO2ESImqbpw7Il1C6kHEq80j+PTNogwV2zO1+8t2jKQwClF6BrR r8+neQvCeRikSE2VtNUgJjEOaCzD+vsTBuydOSZOUSOvapJrSCg/VJoY; Authentication-Results: sj-dkim-4; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 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 David Borman wrote: >> >>> A TCP MAY keep its offered receive window closed >>> indefinitely. As long as the receiving TCP continues to >>> send acknowledgments in response to the probe segments, the >>> sending TCP MUST allow the connection to stay open. >>> > > You are misreading this. This section (4.2.2.1) has two requirements: > 1) Zero Window Probing must be supported (to guard against lost window > updates), and 2) as long as you get responses to the ZWP, you must > keep the connection open. That's it. You aren't keeping it open to > get lost ACKs, you're keeping it open because the other side of the > connection is still there and responding. You are right. Thanks for correcting that perception. What I should have said is that the fact that the above statement in RFC 1122 that "TCP MUST allow the connection to stay open" in response to probes has caused a lot of confusion. We have opinions all the way from it is ok for TCP to terminate the connection "in times of trouble" to it is not for TCP to terminate any connection. We have had mails that have said that it is ok for application/OS/socket layer to terminate the connection but it is not ok for TCP to terminate the connection. Does it mean that if socket interface makes a call to tcp_abort() to abort a connection, that it is not TCP that is aborting the connection, but it is socket interface that is, and therefore it is fine? Would it not help to clarify the statement in the rfc? -- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 28 08:22:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMrZ-0007HM-AV; Wed, 28 Nov 2007 08:22:01 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxMrY-0007H7-0q for tcpm-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:22:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMrW-0007Gs-SE for tcpm@ietf.org; Wed, 28 Nov 2007 08:21:58 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxMrW-0004Xc-CH for tcpm@ietf.org; Wed, 28 Nov 2007 08:21:58 -0500 Received: from [75.197.89.138] (138.sub-75-197-89.myvzw.com [75.197.89.138]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lASDLKoZ011228; Wed, 28 Nov 2007 05:21:22 -0800 (PST) Message-ID: <474D6B3C.7050402@isi.edu> Date: Wed, 28 Nov 2007 05:21:00 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Mahesh Jethanandani Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <20071126193803.585E12FC5BE@lawyers.icir.org> <61806008-0CBC-417D-B5EB-46A7EE18446F@windriver.com> <474CA683.2030600@cisco.com> <3EE5954A-5E50-4B1E-82BC-7A5FD55AEF1F@windriver.com> <474D1004.9030100@cisco.com> In-Reply-To: <474D1004.9030100@cisco.com> X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: tcpm@ietf.org, David Borman , Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1544669682==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1544669682== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2DD36F5EF7EC015746967AC1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2DD36F5EF7EC015746967AC1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani wrote: =2E.. > What I should have said is that the fact that the above statement in RF= C > 1122 that "TCP MUST allow the connection to stay open" in response to > probes has caused a lot of confusion. We have opinions all the way from= > it is ok for TCP to terminate the connection "in times of trouble" to i= t > is not for TCP to terminate any connection. We have had mails that have= > said that it is ok for application/OS/socket layer to terminate the > connection but it is not ok for TCP to terminate the connection. Does i= t > mean that if socket interface makes a call to tcp_abort() to abort a > connection, that it is not TCP that is aborting the connection, but it > is socket interface that is, and therefore it is fine? >=20 > Would it not help to clarify the statement in the rfc? It would be useful to clarify that in the Unix man pages for tcp_abort(), if there is in fact any real confusion in the Unix community on this issue. As Dave noted, RFC1122 is clear on the context of not aborting connections within TCP due to zero windows with active probes. The rest of this discussion has been addressing a moving target based on falsified claims of a vulnerability, which, as others have noted, is not more advantageous than many others in TCP, e.g., slowly draining buffers. It makes no sense to single out "victims" of this "attack" by "cleaning up" TCP state to save resources vs. any other mechanism to limit resource overuse (e.g., prohibiting new connections, deleting those with the largest socket buffers, etc.). The key issue is that a zero receive window with active probes is a valid, active TCP connection - as valid as any other in its use of resources. If we need a document to describe what to do in the event of resource overuse (and I don't think we do), the current document - and motivating threat - are notable only in how NOT to single out connections for resource recovery. Joe --------------enig2DD36F5EF7EC015746967AC1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHTWtBE5f5cImnZrsRAln8AJoC59TBRna0FTX2Ryjfnlu3Sfa2aQCdEw0R QO0kaGRBJjsmjqXsOLh/MtU= =FtCj -----END PGP SIGNATURE----- --------------enig2DD36F5EF7EC015746967AC1-- --===============1544669682== 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 --===============1544669682==-- From tcpm-bounces@ietf.org Wed Nov 28 11:40:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxPxY-0001Hp-4h; Wed, 28 Nov 2007 11:40:24 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxPxX-0001He-5Y for tcpm-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 11:40:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxPxW-0001HS-Qy for tcpm@ietf.org; Wed, 28 Nov 2007 11:40:22 -0500 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxPxW-0005Yr-85 for tcpm@ietf.org; Wed, 28 Nov 2007 11:40:22 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id lASGeEU9010110; Wed, 28 Nov 2007 08:40:14 -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, 28 Nov 2007 08:40:14 -0800 Received: from [172.25.34.21] ([172.25.34.21]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 08:40:14 -0800 Message-Id: <7B02FD5F-2D84-452B-95D4-61F809CD5992@windriver.com> From: David Borman To: MURALI BASHYAM In-Reply-To: <362265.35986.qm@web31708.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Date: Wed, 28 Nov 2007 10:40:12 -0600 References: <362265.35986.qm@web31708.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 28 Nov 2007 16:40:14.0196 (UTC) FILETIME=[59AAD340:01C831DD] X-Spam-Score: -1.0 (-) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: TCP Maintenance and Minor Extensions WG , Joe Touch , Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Nov 27, 2007, at 5:51 PM, MURALI BASHYAM wrote: >> Now, it might be that connections that have been in persist state for >> a long period of time are good candidates for the OS to abort to free >> up resources. But doing that has to be a decision of the OS or the >> application, not of TCP. TCP can keep track of how long connections >> are in persist state, so that if the OS or application asks, it can >> judiciously choose which ones are the best to abort. > > Since you going down this path, what's wrong with TCP doing it by > itself having > received go-ahead from the application and/or the administrator of > the system? > Seems as if we are going to extreme lengths and playing with system > boundary > definitions here to avoid making a change where it hurts most (TCP). Ok. Don't confuse the protocol design with the implementation. To paraphrase David Clark from many years ago: Strict protocol layering is a great way to design a protocol, but a terrible way to implement it. In the RFCs, we are dealing with the protocol design, not the implementation, so we need crisp boundaries, and clarity on which side of the boundary things are on. The implementation is free to do as much blurring between the boundaries as it wants, as long as what goes on the wire is still correct. RFC 793 and 1122 talk about how to process a *single* TCP stream. They do not discuss interaction between TCP multiple streams (because from a protocol design standpoint, there shouldn't be any). When we get into the area of resource starvation, we are now talking about how multiple TCP streams interact between each other through the use of common resources. Dealing with that is not part of the design of TCP. If the user timeout on the SEND call is not sufficient for the application when dealing with a connection, then we would need a proposal to add a new timer to TCP, with a clear description of how the application sets the timer, when TCP should clear/restart the timer, and what to do when the timer goes off. That has nothing to do resource starvation. If the timeout on the SEND call would be sufficient for the application, but the TCP implementation does not provide the ability to set a timer on the SEND call, then that is an implementation issue. If you want to have a higher-level view that goes through and aborts connections in persist state when resources are low, perhaps based on how long they've been in persist state, that is not part of the TCP design. It might be *implemented* right in the middle of the TCP code, but it is not part of the TCP protocol design. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 28 14:06:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSF9-0005rc-81; Wed, 28 Nov 2007 14:06:43 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxSF7-0005pz-MT for tcpm-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 14:06:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSF7-0005oj-Bf for tcpm@ietf.org; Wed, 28 Nov 2007 14:06:41 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxSF6-0003CL-SF for tcpm@ietf.org; Wed, 28 Nov 2007 14:06:41 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 28 Nov 2007 11:06:40 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lASJ6eg1027543; Wed, 28 Nov 2007 11:06:40 -0800 Received: from [10.21.104.24] (sjc-vpnasa1-24.cisco.com [10.21.104.24]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lASJ6dgK023726; Wed, 28 Nov 2007 19:06:40 GMT Message-ID: <474DBC41.4090000@cisco.com> Date: Wed, 28 Nov 2007 11:06:41 -0800 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: John Heffner Subject: Re: [tcpm] Is this a problem? References: <121882.10140.qm@web31702.mail.mud.yahoo.com> <4730B50A.1030102@isi.edu> <20071106190845.GC5881@elb.elitists.net> <4730BC89.5000909@isi.edu> <20071106192746.GE5881@elb.elitists.net> <20071106193912.GF5881@elb.elitists.net> <4730C9D6.1020700@cisco.com> <20071106203212.GG5881@elb.elitists.net> <47333FD9.8010508@cisco.com> <473B1851.2020502@psc.edu> In-Reply-To: <473B1851.2020502@psc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1992; t=1196276800; x=1197140800; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20 |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=GDQTmF6HOsJ/YmGhi1oT6OA3aSOhj1JVhdOOtNbmBiw=; b=CpPwMT6ISlFeSKHFMJ4YmZFW/Av43VyKhtNxCbD+bDqb6gOPX1dsqwjfFeha+LkIzmOcUXFW p5NftQ/1c8qa81RCpvlYuUGB7DeQshvsOjrkuLcEdVZMoM8nV8NSjChS; Authentication-Results: sj-dkim-3; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org John Heffner wrote: > It's actually an easy and generally more effective attack to just drop > all the packets on the floor rather than continue ACKing with zero > window. The connection will eventually time out, but it takes so > long, it's easy to initiate another one in this time to take its > place. Once again, please look carefully at Stas's netkill: > . It's a simple short perl script. The > defense you are proposing does nothing for this attack. That is true. The attack is very similar to the one we describe. It applies to a different state in TCP - FIN_WAIT_1. I would suggest that your attack is not just a "mbuf exhaustion" but also a TCP connection resource attack. It is possible to run either or both of them out. The defense we propose is specifically for connections in persist condition. We found it more tricky to simulate the situation you describe because it required the amount of data requested to fit in the receiver advertised window. In addition, it does have a timeout (albeit a long one) and requires more active clients to attack the server. However ... > > I don't think it's critical to determine whether a connection is > stalled while limited by cwnd or rwin. This *may* be useful > information, but it's not the most important. In my view, the more > important thing to know is (1) whether the connection is making > progress, and (2) how much memory (the contended resource) it is > using. Using this information, you can implement a policy that > resets connections that are consuming resources with no benefit > (progress). This solves the more general problem -- both the netkill > attack and a persist attack. ... our solution keeps track of connections that are in persist condition and keeps track of connections that are not making progress and consuming memory. The framework of the solution is amenable to include connections in FIN_WAIT_1 state. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Nov 28 20:32:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxYGA-0002Q7-EP; Wed, 28 Nov 2007 20:32:10 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxYG8-0002Q1-V8 for tcpm-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 20:32:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxYG8-0002Pt-L9 for tcpm@ietf.org; Wed, 28 Nov 2007 20:32:08 -0500 Received: from web31710.mail.mud.yahoo.com ([68.142.201.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxYG7-0005D4-Vz for tcpm@ietf.org; Wed, 28 Nov 2007 20:32:08 -0500 Received: (qmail 79971 invoked by uid 60001); 29 Nov 2007 01:32:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=nsdD8Y/dWepDkeIyWgXyYQBz7p58p+a4by24WDjEm+n/LClJvi+/bTHxzLF3lh1RukarsUjjFJLHxpAQry/Q2imp/HHarRIQrJSjzArx+C0R8c5GFA+q0JBbBImrLfwH0DmnoSp6nUS3olxpK5eKmERBODHF5p5mskN/DfWlPvg=; X-YMail-OSG: J1knrxEVM1lvlzfpxUCBXiX7EXhuexQmYAcDGEiHRgekUq7HMFbDDkHsmrvbJQpX7S5sCFLXrqoFvSI35yhPffK_xcUTjfnZgny3em9UYbkMIhtNvfU- Received: from [69.3.29.18] by web31710.mail.mud.yahoo.com via HTTP; Wed, 28 Nov 2007 17:32:07 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157 Date: Wed, 28 Nov 2007 17:32:07 -0800 (PST) From: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] To: David Borman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <389727.79747.qm@web31710.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: TCP Maintenance and Minor Extensions WG , Joe Touch , Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org ----- Original Message ---- > From: David Borman > To: MURALI BASHYAM > Cc: Mark Allman ; Joe Touch ; TCP Maintenance and Minor Extensions WG > Sent: Wednesday, November 28, 2007 8:40:12 AM > Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] > > > On Nov 27, 2007, at 5:51 PM, MURALI BASHYAM wrote: > > >> Now, it might be that connections that have been in persist > state > for > >> a long period of time are good candidates for the OS to abort > to > free > >> up resources. But doing that has to be a decision of the OS or the > >> application, not of TCP. TCP can keep track of how long connections > >> are in persist state, so that if the OS or application asks, it can > >> judiciously choose which ones are the best to abort. > > > > Since you going down this path, what's wrong with TCP doing it by > > itself having > > received go-ahead from the application and/or the administrator of > > the system? > > Seems as if we are going to extreme lengths and playing with system > > boundary > > definitions here to avoid making a change where it hurts most (TCP). > > Ok. > > Don't confuse the protocol design with the implementation. To > paraphrase David Clark from many years ago: Strict protocol layering > is a great way to design a protocol, but a terrible way to implement > it. In the RFCs, we are dealing with the protocol design, not the > implementation, so we need crisp boundaries, and clarity on which > side > > of the boundary things are on. The implementation is free to do as > much blurring between the boundaries as it wants, as long as what > goes > > on the wire is still correct. > > RFC 793 and 1122 talk about how to process a *single* TCP stream. > They do not discuss interaction between TCP multiple streams (because > from a protocol design standpoint, there shouldn't be any). When we > get into the area of resource starvation, we are now talking about > how > > multiple TCP streams interact between each other through the use of > common resources. Dealing with that is not part of the design of TCP. > > If the user timeout on the SEND call is not sufficient for the > application when dealing with a connection, then we would need a > proposal to add a new timer to TCP, with a clear description of how > the application sets the timer, when TCP should clear/restart the > timer, and what to do when the timer goes off. That has nothing to > do > > resource starvation. If the timeout on the SEND call would be > sufficient for the application, but the TCP implementation does not > provide the ability to set a timer on the SEND call, then that is an > implementation issue. I am viewing it this way too, there are 2 aspects here, First aspect : the resource starvation mechanism is a TCP implementation notion, i agree. I've agreed to that point of view in an earlier email. The DOS issue discussed here, and the solution presented (by no means the only one, others definitely exist) make for an informational nature of draft. There does not need to be standard ways of handling this. The second aspect is the ability of the application to explicitly cause the TCP connection to leave the ZWP state at the specified time independent of available resources. There are applications where having this level of control over the TCP connection makes sense (web, game servers). But aborting this connection with trigger from TCP or OS or application is a protocol violation, i don't buy the fact that if the OS does it, it's not a violation, that's what i was referring to as pure wordplay. A protocol is a contract between the sender and receiver here, and the contract defines the wire behaviour. I care about the wire behaviour of the connection, and if i observe the behaviour of the connection in the ZWP state prior to this change, i see ACKs and probes exchanged infinitely. With this change (no matter who does it, OS, app, TCP), i see ACKs and probes being exchanged for some time, followed by a RST segment to abort the connection. Do you agree that if we do the latter without changing the wording of RFC1122, it's a protocol violation? My claim all along has been that it is. If we agree that it's a violation, then it's a standards track nature of draft. Murali > > If you want to have a higher-level view that goes through and aborts > connections in persist state when resources are low, perhaps based on > how long they've been in persist state, that is not part of the TCP > design. It might be *implemented* right in the middle of the TCP > code, but it is not part of the TCP protocol design. > > -David Borman > > ____________________________________________________________________________________ Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 29 07:35:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixic9-0005W3-J9; Thu, 29 Nov 2007 07:35:33 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ixic8-0005RE-CW for tcpm-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 07:35:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixic7-0005Pq-UF for tcpm@ietf.org; Thu, 29 Nov 2007 07:35:31 -0500 Received: from harrier.viasat.com ([12.198.241.131] helo=VGAEXCH02.hq.corp.viasat.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixic7-0004wS-7C for tcpm@ietf.org; Thu, 29 Nov 2007 07:35:31 -0500 Received: from VGAEXCH01.hq.corp.viasat.com ([172.31.1.20]) by VGAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 07:35:56 -0500 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] WGLC: 2581bis Date: Thu, 29 Nov 2007 07:36:18 -0500 Message-ID: <0B0A20D0B3ECD742AA2514C8DDA3B065A70706@VGAEXCH01.hq.corp.viasat.com> In-Reply-To: <20071127004720.GD3385@hut.isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] WGLC: 2581bis Thread-Index: Acgwj0ZfCkaNAx6eRWqVgc6wso8SxAB8f9xA From: "Agarwal, Anil" To: "Ted Faber" , , X-OriginalArrivalTime: 29 Nov 2007 12:35:56.0281 (UTC) FILETIME=[63483E90:01C83284] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 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 Mark, Ted, Here are some belated comments on draft-ietf-tcpm-rfc2581bis-03.txt. Most of these suggestions seek to add clarity to and remove ambiguities from the rfc. 1. Section 2. "FLIGHT SIZE: The amount of data that has been sent but not yet acknowledged." Would be useful to clarify that Flight Size is not reduced by SACK info. Flight Size =3D snd.max - snd.una 2. Section 2. "DUPLICATE ACKNOWLEDGMENT: ... Alternatively, a TCP that utilizes selective acknowledgments [RFC2018,RFC2883] can determine an incoming ACK is a "duplicate" if the ACK contains previously unknown SACK information." This statement can be misinterpreted that this rule is an alternative=20 to the previous 5 rules. Perhaps, it should be stated that this is an alternative to=20 rule (e) only? 3. Section 3.1 "When larger initial windows are implemented along with Path MTU Discovery [RFC1191], and the MSS being used is found to be too large ..." Clarify, what "larger initial windows" means.=20 Perhaps, this statement should apply to any IW, large or small.=20 Alternatively, cwnd should be reduced by the ratio mentioned,=20 but need not be reduced below the value of IW according to the equations above as applied to the new segment size. 4. Section 3.1 "The initial value of ssthresh SHOULD be set arbitrarily high (e.g., to the size of the largest possible advertised window),..." Clarify what "largest possible advertised window" means for a=20 TCP transmitter, which has not sent or received any "advertisements" yet. 5. Section 3.1 "During slow start, a TCP increments cwnd by at most SMSS=20 bytes for each ACK received that acknowledges new data." Would be useful to clarify that ACK with old ack value=20 but new SACK info., does not qualify for above.=20 The ACK should advance snd.una. 6. Section 3.1 After the slow start description, it might be useful to add a note:=20 During slow-start, cwnd increases approximately by 50% every RTT when receiver sends delayed ACKs. Lost ACK segments cause a reduction in cwnd growth rate. 7. Section 3.1 "During congestion avoidance, .. The basic guidelines for incrementing cwnd during congestion avoidance are: * MAY increment cwnd by SMSS bytes * SHOULD increment cwnd per equation (2) * MUST NOT increment cwnd by more than SMSS bytes" Would be useful to clarify that these are per RTT, not per ACK. Add note that for 2nd bullet, N in equation (2) refers to bytes acknowledged in last RTT. 8. Section 3.1 "The RECOMMENDED way to increase cwnd during congestion avoidance is to count the number of bytes that have been acknowledged by ACKs for new data. (A drawback of this implementation is that it requires maintaining an additional state variable.) =20 When the number of bytes acknowledged reaches cwnd, then cwnd can be incremented by up to SMSS bytes." Could use some more precision about when to start and re-start counting. 9. Section 3.1 "We note that [RFC3465] allows for cwnd increases of more than SMSS bytes for incoming acknowledgments during slow start on an experimental basis, however such behavior is not allowed as part of the standard." Move this para before previous para? 10. Section 3.1 "Implementation Note: Since integer arithmetic is usually used in TCP implementations, the formula given in equation 3 can fail to increase cwnd when the congestion window is larger than SMSS*SMSS. If the above formula yields 0, the result SHOULD be rounded up to 1 byte." Might be useful to add a note that this violates the rule=20 "MUST NOT increment cwnd by more than SMSS bytes (per RTT)",=20 but is allowed by the rfc. 11. Section 3.2 "On the first and second duplicate ACKs received at a sender, a TCP SHOULD send a segment of previously unsent data per [RFC3042] provided that the receiver's advertised window allows, the total FlightSize would remain less than or equal to cwnd plus 2*SMSS ..." Sounds like the cwnd plus 2*MSS rule applies even after the first=20 duplicate ACK, which seems incorrect. =20 12. Section 3.2 "The lost segment MUST be retransmitted and cwnd set to ssthresh plus 3*SMSS." ... Would be useful to clarify that a single segment with send sequence number =3D snd.una must be retransmitted. 13. Section 3.2 "Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window." This rule needs a MUST or a SHOULD. Add a note that the sender may not transmit a segment if cwnd becomes too large and buffer size limitations prevent it from accepting new=20 user data. 14. Section 4.1 Would be useful to mention that this technique is not just for avoiding traffic bursts, but also that cwnd, which reflects network congestion state, is inaccurate after a long idle period and hence should be=20 re-estimated using slow-start. 15. Section 4.1 The description in this section does not completely eliminate=20 packet bursts. As well all know, large transmit bursts can occur for other reasons - e.g., lost ACKs, sender not using its full cwnd for some period of time, sender going quiet for less than one RTT, receiver sending a large window update. Might be beneficial to refer to other useful techniques for reducing burst transmits, such as pacing and note that this as an area that may benefit from additional attention, experimentation and specification. Regards, Anil Anil Agarwal ViaSat Inc. Germantown, MD 20876 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 29 12:09:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmtR-00077q-CB; Thu, 29 Nov 2007 12:09:41 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxmtQ-00077f-Ig for tcpm-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 12:09:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmtP-00077V-V3 for tcpm@ietf.org; Thu, 29 Nov 2007 12:09:40 -0500 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxmtP-0008CZ-At for tcpm@ietf.org; Thu, 29 Nov 2007 12:09:39 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id lATH9V4A007897; Thu, 29 Nov 2007 09:09:31 -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); Thu, 29 Nov 2007 09:09:31 -0800 Received: from [172.25.34.21] ([172.25.34.21]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 09:09:31 -0800 Message-Id: From: David Borman To: MURALI BASHYAM In-Reply-To: <389727.79747.qm@web31710.mail.mud.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Date: Thu, 29 Nov 2007 11:09:29 -0600 References: <389727.79747.qm@web31710.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 29 Nov 2007 17:09:31.0193 (UTC) FILETIME=[9B550A90:01C832AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: TCP Maintenance and Minor Extensions WG , Mark Allman , Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Nov 28, 2007, at 7:32 PM, MURALI BASHYAM wrote: ... > The second aspect is the ability of the application to explicitly > cause the TCP connection > to leave the ZWP state at the specified time independent of > available resources. There are > applications where having this level of control over the TCP > connection makes sense (web, game servers). > But aborting this connection with trigger from TCP or OS or > application is a protocol violation, i don't buy the fact > that if the OS does it, it's not a violation, that's what i was > referring to as pure wordplay. Fine. Call it wordplay. There's nothing wrong with that, because you *have* to get the words right. You have to be crisp on the protocol definition. The implementation can blur the boundaries, but the protocol definition can't. The aborting of a connection (whether in persist or any other state) when the other side is alive and responding has to be done by the application. TCP should not be doing that without direct instructions from the application. Whether that is done directly by the application by using the existing abort or user timeout interface, or whether a new interface is defined to allow the application tells the OS to run a timer and abort the connection when the timer goes off, it is still being done under the direction of the application. > A protocol is a contract between the sender and receiver here, and > the contract defines the wire > behaviour. The TCP protocol is what is defined in RFC 793/1122, and any other RFCs that are applicable. It is more than just the wire behavior. > I care about the wire behaviour of the > connection, and if i observe the behaviour of the connection in the > ZWP state prior to this change, i see > ACKs and probes exchanged infinitely. With this change (no matter > who does it, OS, app, TCP), i see > ACKs and probes being exchanged for some time, followed by a RST > segment to abort the connection. > > Do you agree that if we do the latter without changing the wording > of RFC1122, it's a protocol > violation? > My claim all along has been that it is. There already exists two mechanisms for the application to abort a connection, directly with the abort interface, or indirectly with the user timeout on the send interface, and you will get the same wire behavior, a connection in persist state gets aborted. The only protocol problem here is to have TCP abort a connection in ZWP state without the application having first explicitly asked for that to happen. And if you need a new interface to provide that functionality, then that will be a change to the TCP protocol. The OS freeing up resources when they run out by doing things like aborting connections is not a protocol violation, because it isn't TCP making that decision. Take that to the extreme, and you'd be arguing that the system crashing is a TCP protocol violation, and that's just silly. > > > If we agree that it's a violation, then it's a standards track > nature of draft. If it changes TCP, in this case adding a new User/TCP interface, then it should be on the standards track. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 29 12:30:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxnDY-0003Y4-B5; Thu, 29 Nov 2007 12:30:28 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxnDX-0003Xj-2x for tcpm-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 12:30:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxnDW-0003XZ-Nv for tcpm@ietf.org; Thu, 29 Nov 2007 12:30:26 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxnDW-0003Tj-6F for tcpm@ietf.org; Thu, 29 Nov 2007 12:30:26 -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 lATHRgWo010594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Nov 2007 09:27:43 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lATHRgUC017220; Thu, 29 Nov 2007 09:27:42 -0800 (PST) (envelope-from faber) Date: Thu, 29 Nov 2007 09:27:42 -0800 From: Ted Faber To: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] Message-ID: <20071129172742.GC15498@hut.isi.edu> References: <389727.79747.qm@web31710.mail.mud.yahoo.com> Mime-Version: 1.0 In-Reply-To: <389727.79747.qm@web31710.mail.mud.yahoo.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: TCP Maintenance and Minor Extensions WG , David Borman , Mark Allman , Joe Touch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0979006714==" Errors-To: tcpm-bounces@ietf.org --===============0979006714== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O3RTKUHj+75w1tg5" Content-Disposition: inline --O3RTKUHj+75w1tg5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Speaking only for myself. On Wed, Nov 28, 2007 at 05:32:07PM -0800, MURALI BASHYAM wrote: > The second aspect is the ability of the application to explicitly > cause the TCP connection to leave the ZWP state at the specified time > independent of available resources. There are applications where > having this level of control over the TCP connection makes sense (web, > game servers). But aborting this connection with trigger from TCP or > OS or application is a protocol violation, i don't buy the fact that > if the OS does it, it's not a violation, that's what i was referring > to as pure wordplay. >=20 > A protocol is a contract between the sender and receiver here, and the > contract defines the wire behaviour. I care about the wire behaviour > of the connection, and if i observe the behaviour of the connection in > the ZWP state prior to this change, i see ACKs and probes exchanged > infinitely. With this change (no matter who does it, OS, app, TCP), i > see ACKs and probes being exchanged for some time, followed by a RST > segment to abort the connection. >=20 > Do you agree that if we do the latter without changing the wording of > RFC1122, it's a protocol violation? My claim all along has been that > it is. If you believe that aborting a connection advertising a zero window is a violation of the TCP specs, there's a lot of violation going on. Any time a process is killed or a machine goes down, TCP connections are aborted (some advertising a zero window). I find it hard to consider all of those as non-conforming TCPs. Now, looking at the text in front of us (RFC1122 in particular), one can either believe that the TCP designers really intended for zero-window connections to be maintained by any means possible, including starving the host of memory and processing power, or that they intended what David Borman described - to lay out the behavior of the protocol in the absence of resource contention. I prefer the latter; I'm sure the designers considered the possibility of resource exhaustion and David's interpretation allows plenty of room for operating systems and applications to address it through calling ABORT on well-chosen connections. --=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 --O3RTKUHj+75w1tg5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHTvaOaUz3f+Zf+XsRAswaAJ9qbC4sTRgFLE0p6LKVOoDou/po4wCeO9hr ITGQdMwyVSMx3QFpQkI81uo= =ePiB -----END PGP SIGNATURE----- --O3RTKUHj+75w1tg5-- --===============0979006714== 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 --===============0979006714==-- From tcpm-bounces@ietf.org Thu Nov 29 13:04:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixnki-000821-IS; Thu, 29 Nov 2007 13:04:44 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ixnkh-00081M-Js for tcpm-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 13:04:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixnkh-00080w-3z for tcpm@ietf.org; Thu, 29 Nov 2007 13:04:43 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixnkf-0001yS-ID for tcpm@ietf.org; Thu, 29 Nov 2007 13:04:43 -0500 Received: from [75.214.228.148] (148.sub-75-214-228.myvzw.com [75.214.228.148]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lATI4ISo005826; Thu, 29 Nov 2007 10:04:20 -0800 (PST) Message-ID: <474EFF10.30401@isi.edu> Date: Thu, 29 Nov 2007 10:04:00 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Borman Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?] References: <389727.79747.qm@web31710.mail.mud.yahoo.com> In-Reply-To: X-Enigmail-Version: 0.95.5 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: TCP Maintenance and Minor Extensions WG , 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="===============0585575989==" Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0585575989== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6F83ABB7F931FCF4EE8D7DF9" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6F83ABB7F931FCF4EE8D7DF9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FWIW, I agree with David's position here, and appreciate his raising the distinction between implementation and specification. Whether the app or the OS decides to terminate via the existing TCP API ABORT call, that's an implementation issue. I'd have opinions as to which is more correctly *implemented*, but that's an implementation issue, not a protocol issue. When resources are starved, I think good implementations inform the app and let the app decide what to do. I don't think they have the OS run down things it *thinks* aren't useful and free them. Again, however, that's an implementation issue. I'll argue it, but it's not relevant to the key question of whether we need a new protocol mechanism. One final point: David Borman wrote: >=20 > On Nov 28, 2007, at 7:32 PM, MURALI BASHYAM wrote: =2E.. >> A protocol is a contract between the sender and receiver here, and the= >> contract defines the wire >> behaviour. >=20 > The TCP protocol is what is defined in RFC 793/1122, and any other RFCs= > that are applicable. It is more than just the wire behavior. This is as I have stated on multiple lists. If there is a strong need for an RFC to explain concepts that are ambiguous, this is MUCH more important than any other raised in this entire thread. Joe --------------enig6F83ABB7F931FCF4EE8D7DF9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHTv8QE5f5cImnZrsRAuJjAJ9iuCLorCBihxQktSUczhwGRr7PhgCg4iSV uJ85T9ijFRLf4r8hqG2JdXo= =q4cK -----END PGP SIGNATURE----- --------------enig6F83ABB7F931FCF4EE8D7DF9-- --===============0585575989== 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 --===============0585575989==-- From tcpm-bounces@ietf.org Thu Nov 29 19:16:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxtWT-0000U7-H8; Thu, 29 Nov 2007 19:14:25 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxtWS-0000Tl-Ky for tcpm-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 19:14:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxtWS-0000Tc-9w for tcpm@ietf.org; Thu, 29 Nov 2007 19:14:24 -0500 Received: from smtpoutm.mac.com ([17.148.16.76]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxtWR-0001VC-QC for tcpm@ietf.org; Thu, 29 Nov 2007 19:14:24 -0500 Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout013/MantshX 4.0) with ESMTP id lAU0ENZp028477 for ; Thu, 29 Nov 2007 16:14:23 -0800 (PST) Received: from [192.168.1.101] (adsl-70-132-20-192.dsl.snfc21.sbcglobal.net [70.132.20.192]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id lAU0EGtP007814 for ; Thu, 29 Nov 2007 16:14:16 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v624) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: tcpm From: Sally Floyd Date: Thu, 29 Nov 2007 16:14:23 -0800 X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [tcpm] draft-floyd-tcpm-ackcc-02.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 An updated version of: Adding Acknowledgement Congestion Control to TCP, draft-floyd-tcpm-ackcc-02.txt, is available at: "http://tools.ietf.org/html/draft-floyd-tcpm-ackcc-02". This version (from November 18) includes the following changes: Changes from draft-floyd-tcpm-ackcc-01.txt: * Added a section on "Keep-alive Packets". From a question raised in the working group. * Added a section on "Possible Complication: TCP Implementations that Skip ACK Packets". Motivated by reports at IETF that many high-bandwidth TCPs don't follow the MUST of sending an ACK for every other packet, if they don't have time. * Added that receivers might have buffer limitations that require that they ack at least every K packets, for some K. Feedback from Sara Landstrom. * Added to the discussion of "Possible Complication: Two-Way Traffic". Feedback from Sara Landstrom. * Added a section on "Possible Complication: Router or Middlebox-based ACK Mechanisms". Feedback from Sara Landstrom. * Added that SACK is required with ACK congestion control. Feedback from Sara Landstrom. * Added a discussion of "Reducing the TCP Acknowledgment Frequency" to the related work section. * Moved the Related Work section to the appendix. Feedback from Alfred Henes. * General editing from feedback from Alfred Hoenes. * Added an appendix on "Design Considerations", with a subsection on "The TCP ACK Ratio Option, or an AckNow bit in data packets?". A newer version, not yet submitted, is also available from: "http://www.icir.org/floyd/papers/draft-floyd-tcpm-ackcc-03a.txt" and "http://www.icir.org/floyd/papers/draft-floyd-tcpm-ackcc-03a.ps", with some general editing from feedback from Alfred Hoenes. Feedback would be appreciated. The ACK Congestion Control mechanism is pretty much specified, but is in need of simulations and such before it is ready for a more complete evaluation. - Sally http://www.icir.org/floyd/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 29 20:01:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxuE4-000873-Id; Thu, 29 Nov 2007 19:59:28 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxuE2-00086g-Ah for tcpm-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 19:59:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxuE1-00086X-Qu for tcpm@ietf.org; Thu, 29 Nov 2007 19:59:25 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxuE0-0005X2-IT for tcpm@ietf.org; Thu, 29 Nov 2007 19:59:25 -0500 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 00:59:24 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 00:59:24 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1196384361747; Fri, 30 Nov 2007 00:59:21 +0000 Received: from mut.jungle.bt.co.uk ([10.73.95.185]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id lAU0wjDI015361; Fri, 30 Nov 2007 00:58:53 GMT Message-Id: <5.2.1.1.2.20071129221357.04986008@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 30 Nov 2007 00:59:15 +0000 To: Sally Floyd From: Bob Briscoe In-Reply-To: References: <5.2.1.1.2.20071128164030.03e1aa48@pop3.jungle.bt.co.uk> <5.2.1.1.2.20071128164030.03e1aa48@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.201 () ALL_TRUSTED,MIME_QP_LONG_LINE X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 30 Nov 2007 00:59:24.0162 (UTC) FILETIME=[3FA6B620:01C832EC] X-Spam-Score: 1.8 (+) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: Aleksandar Kuzmanovic , "K. K. Ramakrishnan" , Amit Mondal , tcpm@ietf.org Subject: [tcpm] Re: draft-ietf-tcpm-ecnsyn-03.txt backwards compatibility X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Sally, [tcpm list added to distr] At 21:16 28/11/2007, Sally Floyd wrote: >Bob - > >>Hi, we (Toby & I) generally support this I-D, but one big concern on=20 >>backward compatibility that Toby just pointed out. Sorry about this=20 >>coming during last call, but that always focuses the mind. > >Sure. It is also fine to take this to the list - I believe that it has=20 >already been discussed >in the working group, but perhaps not recently. I tried to search the list before mailing you, but didn't find previous=20 discussion on backward compatibility. Any clues on keywords to find the=20 discussion? >>" Backwards compatibility: >>... >> In order for TCP node B to send a SYN/ACK packet as ECN-Capable, node >> B must have received an ECN-setup SYN packet from node A. However, >> it is possible that node A supports ECN, but either ignores the CE >> codepoint on received SYN/ACK packets, or ignores SYN/ACK packets >> with the ECT or CE codepoint set. If the TCP sender ignores the CE >> codepoint on received SYN/ACK packets, this would mean that the TCP >> connection would not respond to this congestion indication. >>However, >> this seems to us an acceptable cost to pay in the incremental >> deployment of ECN-Capability for TCP's SYN/ACK packets. It would >> mean that the sender of the SYN/ACK packet would not reduce the >> initial congestion window from two, three, or four segments down to >> one segment, as it should. However, the TCP sender would still >> respond correctly to any subsequent CE indications on data packets >> later on in the connection. > >If the server with the new ECN implementation uses ECN-Capable SYN/ACK >packets, and the clients use ECN without ECN-Capable SYN/ACK packets, then >the TCP server's window will open to at most 4380 bytes (RFC 3390). Sorry, yes, 4380 bytes. I've corrected my repetitions of this mistake in=20 the rest of this posting so as not to confuse those joining the thread. >So if all of the data transfers are at most 4380 bytes, then you are=20 >right, there won't be effective end-to-end congestion control. > >In the worst case, the buffer at the congested link will overflow, and=20 >some of the future arriving SYN/ACK packets will be dropped rather than=20 >ECN-marked. So the worst case would be to revert to a Drop-Tail world,=20 >losing the benefit of ECN. Yes, I'd considered that. But the worst case is worse. Arriving packets=20 from /other/ ECN-capable transfers sharing the link will also be dropped,=20 not just arriving SYN/ACK packets from the server(s) that aren't responding= =20 to ECN notifications. It's worse still. It's like the difference between Good-ECN and Bad-ECN=20 under mild congestion in your note at=20 , quoting: "...The performance differences between "Good ECN" and "Bad ECN" TCP can be similarly dramatic. In an environment of mild congestion, the "Bad ECN" TCP will receive much more bandwidth than the "Good ECN" TCP. ..." It is likely that the short flows won't drive a link into serious=20 congestion because the response of Good-ECNs will keep it in a state of=20 mild congestion, which gives maximum benefit to the defective ECN+ flows. This is because an ECN-capable router that is driven to drop, will also be= =20 ECN-marking a high proportion of the ECN-capable packets it forwards. The=20 rate of ECN-capable TCPs sharing the link will be driven down, while the=20 short flows that erroneously claim to be ECN-capable will only respond to=20 drops, not to ECN marks. >So, as you say, the question is whether it is necessary to add a TCP=20 >option or flag for the TCP initiator to say "I understand ECN-capable=20 >SYN/ACK packets.". This would be simple to add, and I don't much care one= =20 >way or another, but I don't actually think it is necessary. Why? (1)=20 >Because the worse case is to default to Drop-Tail in any case. True, the possibility of servers saying they are ECN-capable but then not=20 responding to ECN notifications is not the end of the world. But the=20 pathological effects on other ECN flows shouldn't be dismissed lightly -=20 see above. >(2) Because I assume that clients will upgrade to ECN implementations that= =20 >understand ECN-Capable SYN/ACK packets as fast as servers will upgrade to= =20 >them, and as fast as routers will upgrade to deploying ECN. On what evidence is this assumption based? It seems shakey to me. >(3) In the worst case, a server experiencing serious problems could turn= =20 >off ECN-Capability for SYN/ACK packets. It wouldn't neessarily know it was causing nasty problems to others. >But I am happy for it to be raised on the list, and if I am out-voted,=20 >then we can add a TCP option or flag. That would not be a big deal. The= =20 >reason >not to do it is that it would require either the added bytes for a TCP=20 >option or the added cost of using one of the remaining TCP flags, and the= =20 >added overhead of checking the TCP option or flag on arriving SYN packets,= =20 >in perpetuity, for what seems to me to be a transient and not very serious= =20 >problem. (And it would require changes to procedures that servers use for= =20 >not having to keep state for SYN packets, if the server wanted to use=20 >ECN-Capability on SYN/ACK packets. But I assume that would be for someone= =20 >else to take care of.) Yes, I don't like the idea of a TCP flag for this at all. But this=20 shouldn't stop us exploring all the potentially nasty scenarios that may=20 arise if we don't have one. >>" >>Scenario: A server has deployed ECN+, but many clients of the server have= =20 >>deployed 3168 ECN but not ECN+. The traffic from the server may=20 >>experience congestion, so a few percent of SYN-ACKs will get CE marked.=20 >>However, the clients don't set ECN in their ACK of the SYN-ACK. On the=20 >>next round, let's say the server opens its initial window to 3 segments=20 >>(~4kB) on every connection. With the 3168 ECN clients, it will do this=20 >>irrespective of whether congestion was experienced. The lack of=20 >>congestion response within a RTT causes the congestion to worsen, so=20 >>future data transfers see more CE or get driven into loss. If most=20 >>connections continue for more than three data segments, as you say there= =20 >>will be a congestion response, but it won't be ideal. >> >>However, if most responses are satisfied within 3 segments, there will be= =20 >>absolutely no congestion response on most of the connections with legacy= =20 >>clients. >> >>According to, "File Size Distribution on UNIX Systems=97Then and Now", by= =20 >>A.Tanenbaum (http://www.cs.vu.nl/~ast/publications/osr-jan-2006.pdf), the= =20 >>distribution of Web file sizes implies (by interpolation) that about 71%= =20 >>of Web transfers were less than 4380B in 2006: >><4096B 70.64% >><8192B 79.69% I made another error; these stats are about the percentage of files in the= =20 file-system of a Web server, not the percentage of files served by the Web= =20 server. However, I guess this is indicative of the likely size of files= served. >Just a nit - what matters most is not the fraction of *transfers* that are= =20 >short, >but the fraction of *packets* that are from short transfers. Indeed. That's not such a nit, because the large files in the long-tail=20 represent a disproportionate contribution. Pimple on your nit: what matters most is not the fraction of packets, but=20 the fraction of bytes in short transfers. Because congestion is generally=20 caused by bytes. >>Even worse, it may be a server farm where the admin has upgraded all the= =20 >>servers to the latest version (e.g. of Linux), while most of the clients= =20 >>are using a release of Windows without ECN on SYN-ACKs. >> >>We didn't want to post this damaging scenario to the list in case you've= =20 >>taken this into account. But if this is a truly dangerous scenario, ECN+= =20 >>will have to have a capability negotiation flag in the TCP options of the= =20 >>first SYN. This seems rather a small increment to use the scarce TCP=20 >>option flags for, so you may have better ideas. >> >>You may also want to discuss how/whether ECN+ should be used on a T/TCP=20 >>server (RFC1644), given a similar issue. > >I don't know much about T/TCP. Could you say more? I briefly looked into T/TCP many years ago. It carries data and the FIN in= =20 the SYN & SYN/ACK for data exchanges that are expected to be short (e.g. an= =20 RPC or a database query). It was intended for where UDP couldn't be used=20 because repeating a query if no response was received would confuse the=20 server (e.g. transactional databases). Geoff Huston did a good summary: It's experimental status and no-one has taken it thru further=20 standardisation. This doesn't necessarily mean it isn't used tho. According= =20 to this characterisation study (conducted 10/03-01/04), 0.01% of packets at= =20 two of 11 measurement points used T/TCP (the rest rounded to 0.00%). Nearly= =20 as much as ECN ;) However, T/TCP may be more prevalent within enterprises. Given ECN and ECN+ give most gain for short flows, I figured if anyone had= =20 gone to the bother of implementing T/TCP, they would most likely want to=20 implement ECN+. Also ECN T/TCP clients talking to ECN+ T/TCP servers would raise similar=20 issues to those in the main body of this mail if the response carried over= =20 more than one segment. Cheers Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196= =20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Nov 29 22:23:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwRK-0000Da-4a; Thu, 29 Nov 2007 22:21:18 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IxwRI-0000DN-OG for tcpm-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 22:21:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwRI-0000DF-C7 for tcpm@ietf.org; Thu, 29 Nov 2007 22:21:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxwRH-0006jF-A2 for tcpm@ietf.org; Thu, 29 Nov 2007 22:21:16 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 19:21:14 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3LEo7005929; Thu, 29 Nov 2007 19:21:14 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lAU3LAgK025671; Fri, 30 Nov 2007 03:21:10 GMT 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); Thu, 29 Nov 2007 19:21:10 -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: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] Date: Thu, 29 Nov 2007 19:21:07 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5804597A88@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] Thread-Index: Acgyqr+YWa5juMFZT+uGzGRouICCZQAATuRQ From: "Anantha Ramaiah (ananth)" To: "David Borman" X-OriginalArrivalTime: 30 Nov 2007 03:21:10.0437 (UTC) FILETIME=[0DC94550:01C83300] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7735; t=1196392874; x=1197256874; c=relaxed/simple; s=sjdkim2002; 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=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward[WasRe=3A[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=55ALsYuaMpa5Xux/x8yxU9woqBEO7lF3E+asdvs51vI=; b=f6P1zq34F6X+VQsjxj8guQ06PpHF35nboND8k4zCA6UqlXuZgZYQV8hTKPMZafNgaMgq4vt5 1koxkEd046Q6QB4uhykFEUGOS6/HhSAzVLgYNY1fBsMUY2CgM4zk8I1z; Authentication-Results: sj-dkim-2; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi David, Firstly, I appreciate your explanations on TCP design and the differences between standard and implementation, those are all good.=20 That said, it appears that this is what is being said (at least that is what is being inferred in the email exchanges) :- Case 1: Abort by the application and OS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D "The application OR any entity (like OS) which is instructed by the application to abort the TCP connection when deemed necessary". "The OS can abort the TCP connection when deemed necessary". These actions seems to enjoy full compliance of RFC 793/1122.=20 Also an example : if there are 270 connections hanging out in persist state for 110 days, the system administrator chooses to clear some of these connections, now system administrator is acting on behalf of the system and may not be the application, this is not a violation of the RFC, it appears. WHEREAS Case 2: Aborts done inside TCP layer =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Assuming that one implementation chooses to have a design like : instructs each individual components in the system like transports layer to abort some connections and thereby relinquish system resources when deemed necessary using an explicit or implicit feedback from the OS. Now this action seems to be violating the RFC since it was done inside the jurisdiction of TCP code. I am having hard time understanding this. To me, it is pure implementation thingy. To me all the above actions (case 1 and 2), either are all compliant to RFC OR all of them aren't. May be it is just me. Please read on... Lets take the example of one mitigation for "SYN attacks" (I think also mentioned in the recent SYN flood informational RFC) It talks about detecting "possibly" malicious connections hanging out there in half-ESTAB state and the possible mitigations. One of the simple mitigations is to toss the "oldest" embryos and make room for the "new ones" and all of these actions doesn't violate any RFC.=20 It could be argued for SYN flood case : Why should one do that, they can let the connections hang out forever, timeout happens OR the host crashes etc., the point is that you want to make an "attempt" to permit new, possibly legitimate connections, conserve system resources for legitimate clients. Is this foolproof?, no, there are corner cases everywhere in every solution. That doesn't mean you shouldn't be having anti-DOS solutions in place. Now the above draft talks about connections which are going to be established and NOT already established. But I can see a lot of similarities in the goals between the SYN flood and persist drafts.=20 Now, I know people may say that the persist draft is totally different since you are talking about connection that are in >=3D ESTAB state. The state of affairs so far seems to be : you can't simply touch the TCP connection persisting since RFC 1122 tells you to keep this forever, but wait, you can kill them, but please do so only in the context of the application and may be OS, but not inside TCP since doing so violates RFC. But remember, it could be that someone chose to enhance the their TCP stack's anti-DOS capabilities with some algorithm they believed would help, terming that as a RFC violation seems too far fetched. Anyways, I am stuck on the way RFC compliance is measured here and I am thinking we are applying too much layering here than mandated by the generic nature of the existing RFC. $0.02, -Anantha > -----Original Message----- > From: David Borman [mailto:david.borman@windriver.com]=20 > Sent: Thursday, November 29, 2007 9:09 AM > To: MURALI BASHYAM > Cc: TCP Maintenance and Minor Extensions WG; Mark Allman; Joe Touch > Subject: Re: Summary of responses so far and proposal moving=20 > forward[WasRe:[tcpm] Is this a problem?] >=20 >=20 > On Nov 28, 2007, at 7:32 PM, MURALI BASHYAM wrote: > ... > > The second aspect is the ability of the application to explicitly=20 > > cause the TCP connection to leave the ZWP state at the=20 > specified time=20 > > independent of available resources. There are applications where=20 > > having this level of control over the TCP connection makes=20 > sense (web,=20 > > game servers). > > But aborting this connection with trigger from TCP or OS or=20 > > application is a protocol violation, i don't buy the fact=20 > that if the=20 > > OS does it, it's not a violation, that's what i was referring to as=20 > > pure wordplay. >=20 > Fine. Call it wordplay. There's nothing wrong with that, because you > *have* to get the words right. You have to be crisp on the=20 > protocol definition. The implementation can blur the=20 > boundaries, but the =20 > protocol definition can't. The aborting of a connection=20 > (whether in =20 > persist or any other state) when the other side is alive and=20 > responding has to be done by the application. TCP should not=20 > be doing that without direct instructions from the=20 > application. Whether that is done directly by the=20 > application by using the existing abort or user timeout=20 > interface, or whether a new interface is defined to allow the=20 > application tells the OS to run a timer and abort the=20 > connection when the timer goes off, it is still being done=20 > under the direction of the application. >=20 >=20 > > A protocol is a contract between the sender and receiver=20 > here, and the=20 > > contract defines the wire behaviour. >=20 > The TCP protocol is what is defined in RFC 793/1122, and any=20 > other RFCs that are applicable. It is more than just the=20 > wire behavior. >=20 >=20 > > I care about the wire behaviour of the connection, and if i observe=20 > > the behaviour of the connection in the ZWP state prior to=20 > this change,=20 > > i see ACKs and probes exchanged infinitely. With this change (no=20 > > matter who does it, OS, app, TCP), i see ACKs and probes being=20 > > exchanged for some time, followed by a RST segment to abort the=20 > > connection. > > > > Do you agree that if we do the latter without changing the=20 > wording of=20 > > RFC1122, it's a protocol violation? > > My claim all along has been that it is. >=20 > There already exists two mechanisms for the application to=20 > abort a connection, directly with the abort interface, or=20 > indirectly with the user timeout on the send interface, and=20 > you will get the same wire behavior, a connection in persist=20 > state gets aborted. >=20 > The only protocol problem here is to have TCP abort a=20 > connection in ZWP state without the application having first=20 > explicitly asked for that to happen. And if you need a new=20 > interface to provide that functionality, then that will be a=20 > change to the TCP protocol. >=20 > The OS freeing up resources when they run out by doing things=20 > like aborting connections is not a protocol violation,=20 > because it isn't TCP making that decision. Take that to the=20 > extreme, and you'd be arguing that the system crashing is a=20 > TCP protocol violation, and that's just silly. >=20 > > > > > > If we agree that it's a violation, then it's a standards=20 > track nature=20 > > of draft. >=20 > If it changes TCP, in this case adding a new User/TCP=20 > interface, then it should be on the standards track. >=20 > -David Borman >=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 Fri Nov 30 12:49:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9zC-0004Na-7H; Fri, 30 Nov 2007 12:49:10 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iy9zA-0004N1-Qn for tcpm-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 12:49:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9zA-0004Mh-EA for tcpm@ietf.org; Fri, 30 Nov 2007 12:49:08 -0500 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy9z9-0004MO-Qb for tcpm@ietf.org; Fri, 30 Nov 2007 12:49:08 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id lAUHn6DP017784; Fri, 30 Nov 2007 09:49:06 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 09:49:06 -0800 Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 09:49:05 -0800 Message-Id: <132F65F6-0F5B-4025-87C0-64556FD984C3@windriver.com> From: David Borman To: Anantha Ramaiah (ananth) In-Reply-To: <0C53DCFB700D144284A584F54711EC5804597A88@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] Date: Fri, 30 Nov 2007 11:49:04 -0600 References: <0C53DCFB700D144284A584F54711EC5804597A88@xmb-sjc-21c.amer.cisco.com> X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 30 Nov 2007 17:49:05.0479 (UTC) FILETIME=[4CEE1570:01C83379] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Anantha, You're still hung up on the differentiation between the protocol design and the implementation. You have to make a choice. Something is either specified within the TCP protocol, and hence is on the standards track, or it is outside the scope of the TCP protocol and would only be an informational RFC; there may be things in both areas. But if you can't cleanly separate the protocol design from the implementation, then you will not be able to make progress in either area. The issue is not about where the functionality is implemented, but how it is documented and whether or not it changes the design of the TCP protocol. My guess is that the best you can hope for in modifying TCP is to add a User/TCP interface that allows the application to set a new timer to abort the connection if it remains too long in persist state (and you'll probably still have resistance). The interface has to be clearly defined, as well as the semantics on when the timer gets started, restarted and disabled, and what happens when the timer goes off. Think of it this way: what would you add to RFC 793? A separate description would describe how an application/OS might make use of this, but that would be informational only. -David Borman On Nov 29, 2007, at 9:21 PM, Anantha Ramaiah (ananth) wrote: > Hi David, > > Firstly, I appreciate your explanations on TCP design and the > differences between standard and implementation, those are all good. > > That said, it appears that this is what is being said (at least that > is > what is being inferred in the email exchanges) :- > > Case 1: > Abort by the application and OS > ================================== > > "The application OR any entity (like OS) which is instructed by the > application to abort the TCP connection when deemed necessary". "The > OS > can abort the TCP connection when deemed necessary". These actions > seems > to enjoy full compliance of RFC 793/1122. > > Also an example : if there are 270 connections hanging out in persist > state for 110 days, the system administrator chooses to clear some of > these connections, now system administrator is acting on behalf of the > system and may not be the application, this is not a violation of the > RFC, it appears. > > WHEREAS > > Case 2: > Aborts done inside TCP layer > ============================ > > Assuming that one implementation chooses to have a design like : > instructs each individual components in the system like transports > layer > to abort some connections and thereby relinquish system resources when > deemed necessary using an explicit or implicit feedback from the OS. > Now > this action seems to be violating the RFC since it was done inside the > jurisdiction of TCP code. I am having hard time understanding this. To > me, it is pure implementation thingy. > > To me all the above actions (case 1 and 2), either are all compliant > to > RFC OR all of them aren't. May be it is just me. ... _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 30 13:40:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAmt-0000i6-R9; Fri, 30 Nov 2007 13:40:31 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IyAmt-0000hZ-3u for tcpm-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 13:40:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAms-0000hL-PM for tcpm@ietf.org; Fri, 30 Nov 2007 13:40:30 -0500 Received: from mx.neterion.com ([72.1.205.142] helo=owa.neterion.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyAms-0001wb-8w for tcpm@ietf.org; Fri, 30 Nov 2007 13:40:30 -0500 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: Summary of responses so far and proposal movingforward[WasRe:[tcpm] Is this a problem?] Date: Fri, 30 Nov 2007 13:40:11 -0500 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77029FB9FA@nekter> In-Reply-To: <0C53DCFB700D144284A584F54711EC5804597A88@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of responses so far and proposal movingforward[WasRe:[tcpm] Is this a problem?] Thread-Index: Acgyqr+YWa5juMFZT+uGzGRouICCZQAATuRQADTyeEA= References: <0C53DCFB700D144284A584F54711EC5804597A88@xmb-sjc-21c.amer.cisco.com> From: "Caitlin Bestler" To: "Anantha Ramaiah \(ananth\)" , "David Borman" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] > Sent: Thursday, November 29, 2007 7:21 PM > To: David Borman > Cc: TCP Maintenance and Minor Extensions WG > Subject: RE: Summary of responses so far and proposal > movingforward[WasRe:[tcpm] Is this a problem?] >=20 > Hi David, >=20 > Firstly, I appreciate your explanations on TCP design and the > differences between standard and implementation, those are all good. >=20 > That said, it appears that this is what is being said (at least that is > what is being inferred in the email exchanges) :- >=20 > Case 1: > Abort by the application and OS > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > "The application OR any entity (like OS) which is instructed by the > application to abort the TCP connection when deemed necessary". "The OS > can abort the TCP connection when deemed necessary". These actions > seems > to enjoy full compliance of RFC 793/1122. >=20 > Also an example : if there are 270 connections hanging out in persist > state for 110 days, the system administrator chooses to clear some of > these connections, now system administrator is acting on behalf of the > system and may not be the application, this is not a violation of the > RFC, it appears. >=20 System administrators can kill an application. Allowing them to kill just some of the application's connections only helps the application. There is no point in any RFC telling sys admins/users that they MUST NOT do things that they inherently have the capability and right to do. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Nov 30 21:02:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyHgW-0000Jl-FW; Fri, 30 Nov 2007 21:02:24 -0500 Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IyHgV-0000JU-5V for tcpm-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 21:02:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyHgU-0000JI-SH for tcpm@ietf.org; Fri, 30 Nov 2007 21:02:22 -0500 Received: from web31710.mail.mud.yahoo.com ([68.142.201.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyHgS-0007KZ-0v for tcpm@ietf.org; Fri, 30 Nov 2007 21:02:22 -0500 Received: (qmail 6334 invoked by uid 60001); 1 Dec 2007 02:02:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=HYVyunCNx2COKg6s8zkZKEjKBadyn0bDZP6hhVh+7ktDbQz2IDdjoSYY52gZQRnpHiUCt6dZtnJ3d3V5FpIffmzckTQ7T7w8jd3HmoNJCcgNDcyxiWGluM594YcnfTXYlsit5tE5tTnBeksl6lGMY225XkRxaucX6kRThE7AG5c=; X-YMail-OSG: P.158tgVM1kbYIZhptRFyfAXNIf0kvv8YxM2xruiRjWRGkzylXtTkV3vsCuZQMETV0Ypi5XWK_hO6rDdzv2e_5vmJPbSZa1JybDnIcxHqtOTVwlcBP9t8ed1Yu9K.g-- Received: from [69.3.29.18] by web31710.mail.mud.yahoo.com via HTTP; Fri, 30 Nov 2007 18:02:19 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157 Date: Fri, 30 Nov 2007 18:02:19 -0800 (PST) From: MURALI BASHYAM Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] To: David Borman , Anantha Ramaiah MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <354788.4675.qm@web31710.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: TCP Maintenance and Minor Extensions WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org ----- Original Message ---- > From: David Borman > To: Anantha Ramaiah > Cc: TCP Maintenance and Minor Extensions WG > Sent: Friday, November 30, 2007 9:49:04 AM > Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?] > > Anantha, > > You're still hung up on the differentiation between the protocol > design and the implementation. You have to make a choice. Something > is either specified within the TCP protocol, and hence is on the > standards track, or it is outside the scope of the TCP protocol and > would only be an informational RFC; there may be things in both > areas. > > But if you can't cleanly separate the protocol design from the > implementation, then you will not be able to make progress in either > area. > > The issue is not about where the functionality is implemented, but > how > > it is documented and whether or not it changes the design of the TCP > protocol. My guess is that the best you can hope for in modifying > TCP > > is to add a User/TCP interface that allows the application to set a > new timer to abort the connection if it remains too long in persist > state (and you'll probably still have resistance). The interface has > to be clearly defined, as well as the semantics on when the timer > gets > > started, restarted and disabled, and what happens when the timer goes > off. Think of it this way: what would you add to RFC 793? A > separate > > description would describe how an application/OS might make use of > this, but that would be informational only. I think we have enough clarity to do this. The protocol events that start, and stop the timer are very well-defined. Timer is started when the receiver advertises a zero window and we enter a state where we are going to be probing the receiver. Timer is stopped when the receiver advertises a non-zero window that actually allows the sender to send data out. Note the distinction that requires the sender to actually stop the timer when it is allowed by the receiver to send data out, preventing tiny window (smaller than MSS) advertisements from prematurely stopping the timer (should not happen if the receiver silly window avoidance is in effect). Possibly, there is some merit in restarting the timer when the receiver offers a tiny window, allowing the receiver some grace period. Upon timer expiry, we terminate the connection. If TCP terminates the connection, it works under all circumstances. The issue here is that TCP cannot inform the application and have the application initiate the abort, because it is not necessary that the application has that connection state around anymore, it could have been destroyed already, i've alluded to this issue before. > > -David Borman > > On Nov 29, 2007, at 9:21 PM, Anantha Ramaiah (ananth) wrote: > > > Hi David, > > > > Firstly, I appreciate your explanations on TCP design and the > > differences between standard and implementation, those are all good. > > > > That said, it appears that this is what is being said (at least > that > > > is > > what is being inferred in the email exchanges) :- > > > > Case 1: > > Abort by the application and OS > > ================================== > > > > "The application OR any entity (like OS) which is instructed by the > > application to abort the TCP connection when deemed necessary". > "The > > > OS > > can abort the TCP connection when deemed necessary". These actions > > seems > > to enjoy full compliance of RFC 793/1122. > > > > Also an example : if there are 270 connections hanging out in persist > > state for 110 days, the system administrator chooses to clear some of > > these connections, now system administrator is acting on behalf > of > the > > system and may not be the application, this is not a violation of the > > RFC, it appears. > > > > WHEREAS > > > > Case 2: > > Aborts done inside TCP layer > > ============================ > > > > Assuming that one implementation chooses to have a design like : > > instructs each individual components in the system like transports > > layer > > to abort some connections and thereby relinquish system > resources > when > > deemed necessary using an explicit or implicit feedback from the > OS. > > > Now > > this action seems to be violating the RFC since it was done > inside > the > > jurisdiction of TCP code. I am having hard time understanding > this. > To > > me, it is pure implementation thingy. > > > > To me all the above actions (case 1 and 2), either are all > compliant > > > to > > RFC OR all of them aren't. May be it is just me. > ... > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > ____________________________________________________________________________________ Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm