From owner-freebsd-net@FreeBSD.ORG Thu Sep 14 15:21:26 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0635D16A4AB for ; Thu, 14 Sep 2006 15:21:26 +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 6C34B43D8F for ; Thu, 14 Sep 2006 15:21:07 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 34778 invoked from network); 14 Sep 2006 15:04:39 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Sep 2006 15:04:39 -0000 Message-ID: <45097364.9090603@freebsd.org> Date: Thu, 14 Sep 2006 17:21:08 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Ruslan Ermilov References: <44FAE332.4010209@freebsd.org> <20060913190241.S13138@is.park.rambler.ru> <45085472.5040903@freebsd.org> <20060913230748.P14337@is.park.rambler.ru> <45086AAF.108@freebsd.org> <20060914093006.GE26261@rambler-co.ru> In-Reply-To: <20060914093006.GE26261@rambler-co.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, Igor Sysoev , silby@FreeBSD.org Subject: Re: Improved TCP syncookie implementation 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: Thu, 14 Sep 2006 15:21:26 -0000 Ruslan Ermilov wrote: > On Wed, Sep 13, 2006 at 10:31:43PM +0200, Andre Oppermann wrote: >> Igor Sysoev wrote: >>> Well, suppose protocol similar to SSH or SMTP: >>> >>> 1) the client calls connect(), it sends SYN; >>> 2) the server receives SYN and sends SYN/ACK with cookie; >>> 3) the client receives SYN/ACK and sends ACK; >>> 4) the client returns successfully from connect() and calls read(); >>> 5) the ACK is lost; >>> 6) the server does not about this connection, so application can not >>> accept() it, and it can not send() HELO message. >>> 7) the client gets ETIMEDOUT from read(). >>> >>> Where in this sequence client may retransmit its ACK ? >> Never. You're correct. There is no data that would cause a retransmit >> if the application is waiting for a server prompt first. I shouldn't >> write wrong explanations when I'm tired, hungry and in between two tasks. ;) >> >> This problem is the reason why we don't switch entirely to syncookies >> and still keep syncache as is. >> > Perhaps it would be a good idea to remove net.inet.tcp.syncookies_only > then? In any case, please don't forget to update the syncache(4) manpage > to reflect your changes, and if you decide not to remove this sysctl, > please add a warning of its potential to break a protocol. This is a sysctl which is not enabled by default. TCP doesn't fall over if someone enables it. There is one case where a connection gets 'stuck' if the one ACK gets lost in the network. The advantage of doing syncookies only is that no memory is consumed for any amount of connection attempts. This may be of interest to certain uses like very high volume static content only servers (ie. picture servers). -- Andre