Subject: Re: gaps in a tcp flow

From: karen mclane thomas <[email-masked]>
Date: Wed, 30 Apr 2003 14:45:58 -0400

Immediately remove the email address below from your distribution list.

[email-masked]

                      kunchanl                                                                            
                      <kunchanl@pollux.        To:       <[email-masked]>                         
                      usc.edu>                 cc:       <[email-masked]>                                   
                      Sent by:                 Subject:  gaps in a tcp flow                               
                      owner-tcp-impl@gr                                                                   
                      c.nasa.gov                                                                          

                      04/30/2003 11:03                                                                    
                      AM                                                                                  

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?

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

---

From: Mark Allman <[email-masked]>
Date: Wed, 30 Apr 2003 22:59:26 -0400

------- Forwarded Message

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

Murali Bashyam wrote:
> 
> 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.

I'll make the embarassing statement that I'm not familiar with "stretch
ack violation" and so a reference would be really nice.

Apart from that, it doesn't seem all that evil if the initial RTT is a
bit longer than it might be later.  If anything that would seem to be
"conservative" in the sense that it leads to a longer RTO and so less
likely to have a spurrious RTO. On top of that, most stacks start with
an intial RTO for the SYN or the SYN|ACK of something much larger than
the standalone ACK timer anyway.

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