TCP Fast Open

Michael Tuexen tuexen at
Fri Dec 6 19:27:24 UTC 2019

> On 6. Dec 2019, at 15:23, Jeremy Harris <jgh at> wrote:
> On 05/12/2019 20:31, Jeremy Harris wrote:
>> On 05/12/2019 20:17, Michael Tuexen wrote:
>>>> - tried TFO but the server didn't take it up
>>> I would expect on = 0.
>> Excellent; that's the most-useful one to know.
> Unfortunately, it seems not to be so; it appears
> to be recording the sending of a TFO option
> (of _either_ type; so a cookie-Request still
> gets it set).  This means I can't use it to log
> "TFO was actually doing something useful for
> this connection".
> The TCPOPT_FAST_OPEN bit in TCP_INFO says the same
> (either pre-ESTABLISHED or post-).
OK, looking up some documentation in the code:

* For passively-created sockets, the TCP_FASTOPEN socket option can be
* queried to determine whether the connection was established using TFO.
* Note that connections that are established via a TFO SYN, but that fall
* back to using a non-TFO SYN|ACK will have the TCP_FASTOPEN socket option
* set.

So this fits with what you observe. However, I think this should be improved...
I can put that on my list or you can file an issue at
> Another problem, this time server-side.  I was hoping
> to get the initial server output piggybacked on
> the SYN,ACK, given the TFO design notes in
> - but so far I'm not getting that.  Packet capture (on lo0):
>           SYN     ->               (TFO=C)
> 0.000224           <- SYN,ACK       (TFO=C  same value)
> 0.000078   SYN,ACK ->
> 0.001421           <- server_data
> The 224us response time for the SYN,ACK looks immediate, not
> a delack time as I'd expect.
That sounds like a bug. Let me test this and I report back.

Best regards
> -- 
> Cheers,
>  Jeremy
> _______________________________________________
> freebsd-transport at mailing list
> To unsubscribe, send any mail to "freebsd-transport-unsubscribe at"

More information about the freebsd-transport mailing list