Date: Wed, 02 Sep 2015 09:21:02 -0700 From: Rui Paulo <rpaulo@me.com> To: Patrick Kelsey <pkelsey@freebsd.org>, net@freebsd.org Subject: Re: TCP Fast Open (RFC7413) for FreeBSD Message-ID: <1441210862.1183.14.camel@me.com> In-Reply-To: <AEE23E04-C0B7-40D3-B55C-502A41B0D5BE@freebsd.org> References: <CAD44qMVK82rB_MM_fsFt7LXV%2BuwCFj3%2B9BXXj=30teUQs0gzrg@mail.gmail.com> <1441169643.1183.12.camel@me.com> <AEE23E04-C0B7-40D3-B55C-502A41B0D5BE@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2015-09-02 at 01:30 -0400, Patrick Kelsey wrote: > > > > > On Sep 2, 2015, at 12:54 AM, Rui Paulo <rpaulo@me.com> wrote: > > > > > On Tue, 2015-09-01 at 21:19 -0400, Patrick Kelsey wrote: > > > Hi, > > > > > > About two weeks from now, I will be starting work on server-side > > > TCP > > > Fast > > > Open (TFO) support for FreeBSD head and stable/10, with the > > > intention > > > of > > > having patches up for review by November. This message is an > > > attempt > > > to > > > uncover any existing work on TFO for FreeBSD, as the existence of > > > such work > > > may change my plans. > > > > > > Copying Sara Dickinson and Tom Jones due to this thread: > > > https://lists.freebsd.org/pipermail/freebsd-net/2015 > > > -January/040910.html. > > > > Have you performed any measurements on the likelihood that stateful > > packet inspectors (firewalls, NATs, etc.) will allow a SYN or a > > SYN/ACK > > to pass with data in it? > > I have not performed any such measurements. This issue is discussed > in section 7.1 of the RFC, which cites such studies and summarizes > the finding as being that 6% of the probed internet paths dropped SYN > packets with data or with unknown TCP options. > > > > > > How would this interact with our syncache? Does it just need to > > store > > the cookie? > > > > The exact interaction with the syncache is still TBD, but I do not > expect to be storing TFO cookies in the syncache as the cookies are > per client-server IP pair and not per-connection. > OK. The only request I have is to be conservative and leave it disabled for a while. The RFC is pretty much experimental for a good reason and we don't want to repeat the T/TCP mistake. -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1441210862.1183.14.camel>