Subject: RE: timeout value in TCP implementation

From: kunchanl <[email-masked]>
Date: Sun, 20 Apr 2003 11:15:00 -0700 (PDT)

Thanks! Bogdan.

Another question: I've also observed quite a number of http
connections where the client waits for about 60 seconds
to send out RST packet like the following example.
This 60-second looks like another timeout value to
me. Do you have any idea where I might be able to
find some pointer for it?

Regards,
Kun-chan

16:42:11.722789 10.0.0.1.2214 > 192.168.0.2.80: S 53128904:53128904(0) win
65535 <mss 1460,nop,nop,sackOK> (DF)
16:42:11.723963 192.168.0.2.80 > 10.0.0.1.2214: S 695356871:695356871(0)
ack 53128905 win 64240 <mss 1460,nop,nop,sackOK> (DF)
16:42:11.948538 10.0.0.1.2214 > 192.168.0.2.80: . ack 1 win 65535 (DF)
16:42:11.976663 10.0.0.1.2214 > 192.168.0.2.80: P 1:361(360) ack 1 win
65535 (DF)
16:42:11.978416 192.168.0.2.80 > 10.0.0.1.2214: P 1:142(141) ack 361 win
63880 (DF)
16:42:12.161741 10.0.0.1.2214 > 192.168.0.2.80: . ack 142 win 65394 (DF)
16:42:14.141897 10.0.0.1.2214 > 192.168.0.2.80: P 361:721(360) ack 142 win
65394 (DF)
16:42:14.143285 192.168.0.2.80 > 10.0.0.1.2214: P 142:283(141) ack 721 win
63520 (DF)
16:42:14.369179 10.0.0.1.2214 > 192.168.0.2.80: . ack 283 win 65253 (DF)
16:43:14.813957 10.0.0.1.2214 > 192.168.0.2.80: R 53129625:53129625(0) win
0 (DF)

On Sun, 20 Apr 2003, Bogdan Ghita wrote:

> Hello Kun-chan,
>
> 3 seconds is the recomended initial value for the TCP timeout timer (RTO).
> See RFC1122 (section 4.2.3.1) for details.
>
> Cheers,
> Bogdan
>
>
> -----Original Message-----
> From: kunchanl
> To: [email-masked]
> Sent: 20/04/03 17:57
> Subject: timeout value in TCP implementation
>
> Hi,
>
>     I've observed quiet a few of connections in my tcpdump trace
> has the SYN packet re-transmitted after about 3 seconds (as
> the example below). I'm wondering if this 3-second is related
> some particular timeout value in some tcp implementaton. Can
> anybody shed me some light?
>
> Thanks
> Kun-chan Lan
>
> 1036626828.477241 10.0.0.1.2355 > 192.168.0.2.80: S 12193306:12193306(0)
> win 8192 <mss 1460,nop,nop,sackOK> (DF)
> 1036626831.460768 10.0.0.1.2355 > 192.168.0.2.80: S 12193306:12193306(0)
> win 8192 <mss 1460,nop,nop,sackOK> (DF)
> 1036626831.784822 10.0.0.1.2355 > 192.168.0.2.80: . ack 3335637810 win
> 8760 (DF)
> 1036626831.792048 10.0.0.1.2355 > 192.168.0.2.80: P 0:758(758) ack 1 win
> 8760 (DF)
> 1036626831.852406 10.0.0.1.2355 > 192.168.0.2.80: . ack 124 win 8638
> (DF)
> 1036626831.852423 10.0.0.1.2355 > 192.168.0.2.80: R 12194065:12194065(0)
> win 0 (DF)
>
>
>

---

From: kunchanl <[email-masked]>
Date: Wed, 30 Apr 2003 08:03:41 -0700 (PDT)

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: Murali Bashyam <[email-masked]>
Date: Wed, 30 Apr 2003 11:10:01 -0700

> HTTP) protocol does this? Or is this just due to some particular

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