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 Status: RO Content-Length: 1204 Lines: 34 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.