Re: gaps in a tcp flow

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

Message-ID: <3EB01179.BB1F9C7A@cisco.com>
Date: Wed, 30 Apr 2003 11:10:01 -0700
From: Murali Bashyam <mbashyam@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: kunchanl <kunchanl@pollux.usc.edu>
Cc: tcp-impl@lerc.nasa.gov, klan@usc.edu
Subject: Re: gaps in a tcp flow
References: <Pine.GSO.4.33.0304300749360.5259-100000@pollux.usc.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 1550
Lines: 41


kunchanl wrote:

> Hi all,
>
>    I've observed quite a few number of flows in my tcpdump trace
> where there are always some big gaps (~70ms in the example below)
> when the client sends back ACK to sever during
> initiation and close of the connection.
> Does anybody know what aspect of TCP (or
> HTTP) protocol does this? Or is this just due to some particular
> implementation?

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.

Murali

>
>
> Thanks
> Kun-chan Lan
>
> 26403.250993 10.0.0.1.10098 > 10.0.0.2.80: S 727890358:727890358(0) win
> 65535
> 26403.253333 10.0.0.2.80 > 10.0.0.1.10098: S 574667003:574667003(0) ack
> 727890359 win 5792
> 26403.325641 10.0.0.1.10098 > 10.0.0.2.80: . ack 1 win 65535   <----
> 26403.325866 10.0.0.1.10098 > 10.0.0.2.80: P 1:358(357) ack 1 win 65535
> 26403.328784 10.0.0.2.80 > 10.0.0.1.10098: . ack 358 win 6432
> 26403.336044 10.0.0.2.80 > 10.0.0.1.10098: . 1:1449(1448) ack 358 win 6432
> 26403.337361 10.0.0.2.80 > 10.0.0.1.10098: . 1449:2897(1448) ack 358 win
> 6432
> 26403.337367 10.0.0.2.80 > 10.0.0.1.10098: FP 2897:3174(277) ack 358 win
> 6432
> 26403.412212 10.0.0.1.10098 > 10.0.0.2.80: . ack 2897 win 64252  <----
> 26403.412254 10.0.0.1.10098 > 10.0.0.2.80: F 358:358(0) ack 3175 win 65535
> 26403.415175 10.0.0.2.80 > 10.0.0.1.10098: . ack 359 win 6432

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