From owner-tcp-impl@grc.nasa.gov Thu May 1 12:52:58 2003 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22030 for ; Thu, 1 May 2003 12:52:43 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id BA87968A7D for ; Thu, 1 May 2003 12:35:42 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h41GIA1h023015 for tcp-impl-outgoing; Thu, 1 May 2003 12:18:10 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h41GI8uW023008 for ; Thu, 1 May 2003 12:18:08 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h41GI8bp008169 for ; Thu, 1 May 2003 12:18:08 -0400 (EDT) Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 43E036BA58 for ; Thu, 1 May 2003 12:18:07 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h41G35xI022625; Thu, 1 May 2003 09:03:05 -0700 (PDT) Received: from cisco.com (sjc-vpn2-6.cisco.com [10.21.112.6]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGQ75449; Thu, 1 May 2003 08:58:36 -0700 (PDT) Message-ID: <3EB14538.5A99B417@cisco.com> Date: Thu, 01 May 2003 09:03:04 -0700 From: Murali Bashyam X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: raj@cup.hp.com Cc: tcp-impl@grc.nasa.gov Subject: Re: gaps in a tcp flow References: <20030501025926.6F5166B2B7@lawyers.ir.bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Mark Allman wrote: > > ------- Forwarded Message > > Date: Wed, 30 Apr 2003 16:14:16 -0700 > From: Rick Jones > Reply-To: raj@cup.hp.com > Organization: the Unofficial HP > To: tcp-impl@grc.nasa.gov > Subject: Re: gaps in a tcp flow > > Murali Bashyam wrote: > > > > Mark Allman wrote: > > > > Doesn't this cause problems for the initial RTT estimate of the > > server ? And in the attached example the delay seems to be negligible > > so it's ok, but if the client is delaying the ACK by 70 ms to > > piggyback the GET request, it seems like a variant of stretch ack > > violation. > > I'll make the embarassing statement that I'm not familiar with "stretch > ack violation" and so a reference would be really nice. Refer to RFC2525 for this. Stretch ack is basically an ack that gets delayed by a huge amount either by the network or the receiver and ends up acknowledging a whole lot of segments as opposed to normal behaviour of 2 segments, resulting in bursty traffic, and RTT jitter. > > > Apart from that, it doesn't seem all that evil if the initial RTT is a > bit longer than it might be later. If anything that would seem to be > "conservative" in the sense that it leads to a longer RTO and so less > likely to have a spurrious RTO. On top of that, most stacks start with > an intial RTO for the SYN or the SYN|ACK of something much larger than > the standalone ACK timer anyway. The initial RTO of 3s is only a conservative estimate in the absence of that ACK, so SYN retransmission is not an issue. I agree the higher 'RTT' estimate on the server is only brief and in this case it does not affect the connection throughput in an adverse manner, since with the HTTP request-response transaction, the RTT should quickly converge in a few iterations when the ACK of the HTTP response starts coming back, to a much smaller and correct one. Piggybacking GET requests with the ACK of a syn|ack is a common feature, but i haven't seen the ACK delayed by as much as 70 ms. Murali > > > rick > - -- > Wisdom Teeth are impacted, people are affected by the effects of events. > these opinions are mine, all mine; HP might not want them anyway... :) > feel free to post, OR email to raj in cup.hp.com but NOT BOTH... > > ------- End of Forwarded Message From owner-tcp-impl@grc.nasa.gov Thu May 1 19:56:54 2003 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18787 for ; Thu, 1 May 2003 19:56:39 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 669A56BA72 for ; Thu, 1 May 2003 19:58:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h41NhLu4007215 for tcp-impl-outgoing; Thu, 1 May 2003 19:43:21 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h41NhKuW007210 for ; Thu, 1 May 2003 19:43:20 -0400 (EDT) Received: from seraph3.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h41NhHbp027329 for ; Thu, 1 May 2003 19:43:20 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 898116BA4D for ; Thu, 1 May 2003 19:43:13 -0400 (EDT) Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19BNdc-0000Dy-00; Fri, 02 May 2003 00:38:52 +0100 Date: Fri, 2 May 2003 00:38:50 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Murali Bashyam Cc: raj@cup.hp.com, "" Subject: Re: gaps in a tcp flow In-Reply-To: <3EB14538.5A99B417@cisco.com> Message-ID: References: <20030501025926.6F5166B2B7@lawyers.ir.bbn.com> <3EB14538.5A99B417@cisco.com> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-129.3 required=5.5 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *19BNdc-0000Dy-00*zVGo1M4c3Tw* (SECM, UniS) Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk On Thu, 1 May 2003, Murali Bashyam wrote: > Mark Allman wrote: > > > Murali Bashyam wrote: > > > > > > Mark Allman wrote: > > > > > > Doesn't this cause problems for the initial RTT estimate of the > > > server ? And in the attached example the delay seems to be negligible > > > so it's ok, but if the client is delaying the ACK by 70 ms to > > > piggyback the GET request, it seems like a variant of stretch ack > > > violation. > > > > I'll make the embarassing statement that I'm not familiar with "stretch > > ack violation" and so a reference would be really nice. > > Refer to RFC2525 for this. hmmm. has 'allman' on it. > Stretch ack is basically an ack that gets delayed > by a huge amount either by the network or the receiver and ends up > acknowledging a whole lot of segments as opposed to normal behaviour of 2 > segments, resulting in bursty traffic, and RTT jitter. stretch ack violations cannot result from network-induced delay. receiver delay in sending acks only. (It's imo an odd way to name a high delayed-ack threshold, but then we're in the world where an exponential increase gets called 'slow'.) L. From owner-tcp-impl@grc.nasa.gov Sun May 11 17:24:03 2003 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12935 for ; Sun, 11 May 2003 17:24:02 -0400 (EDT) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 33FF96BA4A for ; Sun, 11 May 2003 17:26:28 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) id h4BL3fEM001332 for tcp-impl-outgoing; Sun, 11 May 2003 17:03:41 -0400 (EDT) Received: from acs-viruswall.grc.nasa.gov (acs-viruswall.grc.nasa.gov [139.88.112.21]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h4BL3euW001328 for ; Sun, 11 May 2003 17:03:40 -0400 (EDT) Received: from seraph2.grc.nasa.gov (localhost [127.0.0.1]) by acs-viruswall.grc.nasa.gov (NASA GRC 8.12.9/8.12.3) with ESMTP id h4BL3ebp011911 for ; Sun, 11 May 2003 17:03:40 -0400 (EDT) Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id AB6DC68962 for ; Sun, 11 May 2003 17:03:39 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4BL3b6p002947; Sun, 11 May 2003 14:03:37 -0700 (PDT) Received: from cisco.com (sjc-vpn4-782.cisco.com [10.21.83.13]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGZ34167; Sun, 11 May 2003 13:57:36 -0700 (PDT) Message-ID: <3EBEBAA9.B07EF823@cisco.com> Date: Sun, 11 May 2003 14:03:37 -0700 From: Murali Bashyam X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: TCP Implementors Subject: Question on detecting duplicate segments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@grc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi This pertains to the subject of detecting duplicate segments from earlier incarnations of the same connection. For the same incarnation of a connection, RFC 1323 recommends PAWS and it works correctly to detect duplicate segments, but for a different incarnation (Appendix B.2 of the RFC), it seems to indicate that PAWS as it is will not work, and it needs to be augmented with a mechanism which maintains a per host timestamp cache which saves the last timestamp received from that host and this value is needed to be used in the PAWS test. I dont quite understand this, if the timestamp clock of the sender is guaranteed to increment by at least 1 since the last time the connection was closed, the duplicate which appears after the new incarnation of the connection has been established, should be detected by the PAWS test as is, without requiring any additional mechanism. My intent is to understand whether it is true that PAWS test (as it is w/o requiring any additional mechanism) can replace the functionality of detecting and expiring duplicate segments provided by the TIME-WAIT state. Thanks, Murali