Re: gaps in a tcp flow

Mark Allman <mallman@grc.nasa.gov> Wed, 30 April 2003 19:36 UTC

Message-Id: <200304301936.PAA01712@guns.lerc.nasa.gov>
To: tcp-impl@grc.nasa.gov
From: Mark Allman <mallman@grc.nasa.gov>
Reply-To: Rick Jones <rick_jones2@hp.com>
Subject: Re: gaps in a tcp flow
Organization: BBN Technologies/NASA GRC
Song-of-the-Day: Dead Flowers
Date: Wed, 30 Apr 2003 15:36:08 -0400
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 2104
Lines: 53

 

------- Forwarded Message

Date: Wed, 30 Apr 2003 12:04:12 -0700
From: Rick Jones <rick_jones2@hp.com>
Reply-To: raj@cup.hp.com
Organization: the Unofficial HP
To: tcp-impl@lerc.nasa.gov
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