Date: Wed, 13 Sep 2006 22:31:43 +0200 From: Andre Oppermann <andre@freebsd.org> To: Igor Sysoev <is@rambler-co.ru> Cc: freebsd-net@freebsd.org, silby@freebsd.org Subject: Re: Improved TCP syncookie implementation Message-ID: <45086AAF.108@freebsd.org> In-Reply-To: <20060913230748.P14337@is.park.rambler.ru> References: <44FAE332.4010209@freebsd.org> <20060913190241.S13138@is.park.rambler.ru> <45085472.5040903@freebsd.org> <20060913230748.P14337@is.park.rambler.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Igor Sysoev wrote: > On Wed, 13 Sep 2006, Andre Oppermann wrote: > >> 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. > > 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. >> 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. > > Yes. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45086AAF.108>