From owner-freebsd-net@FreeBSD.ORG Mon Sep 13 10:54:41 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2678C1065673 for ; Mon, 13 Sep 2010 10:54:41 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 875138FC20 for ; Mon, 13 Sep 2010 10:54:40 +0000 (UTC) Received: (qmail 49253 invoked from network); 13 Sep 2010 10:49:51 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Sep 2010 10:49:51 -0000 Message-ID: <4C8E02EF.6030600@freebsd.org> Date: Mon, 13 Sep 2010 12:54:39 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Randall Stewart References: <4C7A7B25.9040300@freebsd.org> <4C7D0089.1020104@freebsd.org> <4C8AA863.4060908@xiplink.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Robert Watson , Karim Fodil-Lemelin , freebsd-net@freebsd.org Subject: Re: Removal of deprecated implied connect for TCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 10:54:41 -0000 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