Subject: Re: gaps in a tcp flow

From: Mark Allman <[email-masked]>
Date: Wed, 30 Apr 2003 15:36:08 -0400

------- Forwarded Message

Date: Wed, 30 Apr 2003 12:04:12 -0700
From: Rick Jones <[email-masked]>
Reply-To: [email-masked]
Organization: the Unofficial HP
To: [email-masked]
Subject: Re: gaps in a tcp flow

> The ACK for the SYN-ACK should not be delayed at all, and certainly
> not by 70 ms, there is no aspect of TCP protocol that specifies such a
> behaviour. So i'd guess that it is either the implementation or the
> network that's causing this behaviour, although network seems less
> probable.

It is entirely possible that the ACK of a SYN|ACK could be delayed. 
Particularly if the implementation is wanting to try to bundle the ACK 
with the request data.

Here is a snippet of a netperf TCP_CRR test between an HP-UX 11 system
(tardy)  and an HP-UX 11.11 system (sweb156):

13:00:14.077265 tardy.43873 > sweb156.54430: S 217593471:217593471(0)
win 32768 <mss 1460,wscale 0,nop> (DF)
13:00:14.077399 sweb156.54430 > tardy.43873: S 3147399939:3147399967(28)
ack 217593472 win 4096
13:00:14.077583 tardy.43873 > sweb156.54430: P 1:2(1) ack 1 win 32768
(DF)
13:00:14.077806 sweb156.54430 > tardy.43873: P 1:2(1) ack 2 win 4096
13:00:14.077848 sweb156.54430 > tardy.43873: F 2:2(0) ack 2 win 4096
13:00:14.077888 tardy.43873 > sweb156.54430: . ack 3 win 32768 (DF)
13:00:14.077928 tardy.43873 > sweb156.54430: F 2:2(0) ack 3 win 0 (DF)

Notice how the initial single byte request is piggy-backed on the ACK of
the SYN|ACK from sweb156.

If you examine some of IBM's AIX SPECweb99* submittals - for example:

http://www.spec.org/osg/web99ssl/results/res2003q1/web99ssl-20030217-00046.html

In the client notes you will see a setting that delays the ACK by the
client of the SYN|ACK from the server.  It does the same thing (HP-UX
does not it seems from above :) for the ACK of FINs (at least according
to the discussion).

rick jones
- -- 
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: Murali Bashyam <[email-masked]>
Date: Wed, 30 Apr 2003 15:58:33 -0700

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.

Murali