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