Re: gaps in a tcp flow

Lloyd Wood <l.wood@eim.surrey.ac.uk> Thu, 01 May 2003 23:38 UTC

Date: Fri, 02 May 2003 00:38:50 +0100
From: Lloyd Wood <l.wood@eim.surrey.ac.uk>
X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk
Reply-To: Lloyd Wood <L.Wood@eim.surrey.ac.uk>
To: Murali Bashyam <mbashyam@cisco.com>
Cc: raj@cup.hp.com, tcp-impl@grc.nasa.gov
Subject: Re: gaps in a tcp flow
In-Reply-To: <3EB14538.5A99B417@cisco.com>
Message-ID: <Pine.GSO.4.50.0305020034380.8439-100000@artemis.ee.surrey.ac.uk>
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.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@ee.surrey.ac.uk>

gaps in a tcp flow kunchanl
Re: gaps in a tcp flow Murali Bashyam
Re: gaps in a tcp flow karen mclane thomas
Re: gaps in a tcp flow Mark Allman
Re: gaps in a tcp flow Murali Bashyam
Re: gaps in a tcp flow Mark Allman
Re: gaps in a tcp flow Murali Bashyam
Re: gaps in a tcp flow Lloyd Wood