Subject: 3-way handshake delays

From: Constantinos Dovrolis <[email-masked]>
Date: Wed, 7 Nov 2001 11:17:58 -0500 (EST)

Hi all,

we have a question about the generation of the SYN-ACK
packet at the callee.

Is it always true that the callee sends the SYN-ACK packet
immediately after receiving the SYN packet? I am not
referring to delays that can be caused by other
higher-priority activity at the kernel, but about delays
that would be caused by the code that processes the
SYN packet and sends the SYN-ACK packet.

Similarly, is it always true that the caller sends the
first ACK packet immediately after receicing the SYN-ACK
packet?

Thanks much,

Constantinos

Computer and Information Sciences - University of Delaware

http://www.cis.udel.edu/~dovrolis/

---

From: Joe Touch <[email-masked]>
Date: Wed, 07 Nov 2001 08:50:44 -0800

> first ACK packet immediately after receicing the SYN-ACK

Are you asking about a timeliness requirement, or about typical 
implementations?

Once the packet is being processed by TCP, the process-send exchange is 
typically immediate. The process/update state/emit packet exchange is 
considered atomic in RFC793, although there could be intermediate 
internal states, they don't serve much use given the input and output IP 
  queues.

However there can be delays in those IP queues. If there is a noticible 
delay, these might be the place to check first.

Joe

---

From: Craig Partridge <[email-masked]>
Date: Wed, 07 Nov 2001 13:50:19 -0500

In message <[email-masked]>, Constantin

>first ACK packet immediately after receicing the SYN-ACK

It is a long time since I've looked at this issue, but I believe it is
perfectly acceptable to pause very briefly before sending back the ACK to
piggy-back data with the ACK.  I don't know of any implementation that
does so, however.

Craig

---

From: Erich Nahum <[email-masked]>
Date: Wed, 7 Nov 2001 14:10:03 -0500 (EST)

> piggy-back data with the ACK.  I don't know of any implementation that

There's at least one that does so: AIX.  It's run-time configurable.
I have a paper that includes this very topic that will appear in ToN
soon.  FreeBSD may have something similar as well.

More broadly, the SYN-ACK may be delayed an arbitrary amount of time
depending on the implementation.  For example, some implementations
run their networking code off the interrupt stack, which provides
a very quick response, while others may use a kernel thread of
some kind (e.g. BSD soft interrupts or linux bottom-half handlers).
If you do the latter and you're hit with a lot of hardware interrupts,
it may take some time to respond to the SYN.

-Erich

-- 
Erich M. Nahum                  IBM T.J. Watson Research Center
Networking Research             P.O. Box 704
[email-masked]            Yorktown Heights NY 10598

---

From: [email-masked]
Date: Wed, 7 Nov 2001 22:06:23 +0300 (MSK)

Hello!

> piggy-back data with the ACK.  I don't know of any implementation that

Linux does this, but only if application set a special option
on socket telling that active connector is going to send data first.

Alexey