Subject: Re: gaps in a tcp flow

From: Murali Bashyam <[email-masked]>
Date: Thu, 01 May 2003 09:03:04 -0700

Mark Allman wrote:

>
> ------- Forwarded Message
>
> Date: Wed, 30 Apr 2003 16:14:16 -0700
> From: Rick Jones <[email-masked]>
> Reply-To: [email-masked]
> Organization: the Unofficial HP
> To: [email-masked]
> 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: Lloyd Wood <[email-masked]>
Date: Fri, 2 May 2003 00:38:50 +0100 (BST)

On Thu, 1 May 2003, Murali Bashyam wrote:

> Refer to RFC2525 for this.

hmmm. has 'allman' on it.

> Stretch ack is basically an ack that gets delayed

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/><[email-masked]>