From owner-freebsd-net@FreeBSD.ORG Wed Sep 13 18:56:57 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 B68F116A5CF for ; Wed, 13 Sep 2006 18:56:57 +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 5FC9A43D5A for ; Wed, 13 Sep 2006 18:56:48 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 23778 invoked from network); 13 Sep 2006 18:40:29 -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 ; 13 Sep 2006 18:40:29 -0000 Message-ID: <45085472.5040903@freebsd.org> Date: Wed, 13 Sep 2006 20:56:50 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Igor Sysoev References: <44FAE332.4010209@freebsd.org> <20060913190241.S13138@is.park.rambler.ru> In-Reply-To: <20060913190241.S13138@is.park.rambler.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, 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: Wed, 13 Sep 2006 18:56:57 -0000 Igor Sysoev wrote: > On Sun, 3 Sep 2006, Andre Oppermann wrote: > >> I've pretty much rewritten our implementation of TCP syncookies to get >> rid of some locking in TCP syncache and to improve their functionality. >> >> The RFC1323 timestamp option is used to carry the full TCP SYN+SYN/ACK >> optional feature information. This means that a FreeBSD host may run >> with syncookies only and not degrade TCP connections made through it. >> All important TCP connection setup negotiated options are preserved >> (send/receive window scaling, SACK, MSS) without storing any state on >> the host during the SYN-SYN/ACK phase. As a nice side effect the >> timestamps we respond with are randomized instead of directly using >> ticks (which reveals out uptime). > > As I understand syncache is used to retransmit SYN/ACK. > What would be if > > 1) a client sent SYN, > 2) we sent SYN/ACK with cookie, > 3) the client sent ACK, but the ACK was lost If the client sent ACK it will retry again after the normal retransmit timeout. If our SYN-ACK back to client is lost we won't resend it with syncookies. The client then has to try again which is does after the syn retransmit timeout. The only brokeness with syncookies used to be that we would not be able to use RFC1323 features, most prominently window scaling. This would seriously affect throughput on todays links. The improved syncookies can carry all that information in the timestamp if present and thus get rid of the limitations of the original syncookie concept and implementation. -- Andre