TCP Fast Open (RFC7413) for FreeBSD

[Patrick Kelsey]

> On Sep 2, 2015, at 12:21 PM, Rui Paulo <rpaulo at me.com> wrote:
> 
>> On Wed, 2015-09-02 at 01:30 -0400, Patrick Kelsey wrote:
>> 
>> 
>> 
>>>> On Sep 2, 2015, at 12:54 AM, Rui Paulo <rpaulo at 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.
> 

I agree completely.  This feature will be guarded with an #ifdef, default disabled.

-Patrick