Re: gaps in a tcp flow

Murali Bashyam <mbashyam@cisco.com> Wed, 30 April 2003 22:58 UTC

Message-ID: <3EB05519.393FBA5C@cisco.com>
Date: Wed, 30 Apr 2003 15:58:33 -0700
From: Murali Bashyam <mbashyam@cisco.com>
Organization: Cisco Systems Inc
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Rick Jones <rick_jones2@hp.com>
Cc: tcp-impl@grc.nasa.gov
Subject: Re: gaps in a tcp flow
References: <200304301936.PAA01712@guns.lerc.nasa.gov>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 2501
Lines: 63

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

>
>
> ------- 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