Removal of deprecated implied connect for TCP

[Andre Oppermann]

On 11.09.2010 17:38, Randall Stewart wrote:
> All:
>
> One thing to note.. when you can do an implied connection setup, the
> 3-way hand shake has the potential to carry data (don't know if tcp does in FreeBSD)
> on the third leg of the 3-way handshake.
>
> This is one of the reasons SCTP uses this.. since we often will
> carry data an the third and even possibly the 4th leg of the handshake (we
> have one extra leg).
>
> Taking this feature out of TCP will make it so we will be like all other
> o/s's and the socket semantic will prevent you from doing data on the third leg..
>
> ----SYN---->
> <----SYN-ACK---
> ----ACK--->
>
> instead of
>
> ----SYN-->
> <---SYN-ACk--
> ---ACK+DATA-->
>
>
> In the past I have mentioned in classes I teach that TCP is capable of this but the O/S's
> of the world do not allow this later behavior..

The savings in TCP for the case you describe here are not that great.
With piggy-backing data on the third leg you save one (small) ACK packet
and one round-trip to userspace for the application to start sending data.
There is no need to wait for a full network round trip time to start
sending data.

The real savings from implied connected with RFC1644 came from sending
data together with initial SYN.  The receiving side would either queue
the data until the 3WHS was complete, or upon later invocations directly
create a socket upon SYN.  The trouble with the way of doing it in RFC1644
was the very weak protection against very simple DoS attacks.  Only a
connection count variable was used to prevent fake SYN's from opening
new sockets.  This plus the required socket layer changes (the implied
connect) caused a quick halt if any further RFC1644 adoption.

-- 
Andre