Hello Jason, On Sat, Oct 19, 2019 at 11:10 AM Jason Baron <jba...@akamai.com> wrote: > The TCPI_OPT_SYN_DATA bit as part of tcpi_options currently reports whether > or not data-in-SYN was ack'd on both the client and server side. We'd like > to gather more information on the client-side in the failure case in order > to indicate the reason for the failure. This can be useful for not only > debugging TFO, but also for creating TFO socket policies. For example, if > a middle box removes the TFO option or drops a data-in-SYN, we can > can detect this case, and turn off TFO for these connections saving the > extra retransmits. > > The newly added tcpi_fastopen_client_fail status is 2 bits and has 4 > states: > > 1) TFO_STATUS_UNSPEC > > catch-all. > > 2) TFO_NO_COOKIE_SENT > > If TFO_CLIENT_NO_COOKIE mode is off, this state indicates that no cookie > was sent because we don't have one yet, its not in cache or black-holing > may be enabled (already indicated by the global > LINUX_MIB_TCPFASTOPENBLACKHOLE). > > 3) TFO_NO_SYN_DATA > > Data was sent with SYN, we received a SYN/ACK but it did not cover the data > portion. Cookie is not accepted by server because the cookie may be invalid > or the server may be overloaded. > > > 4) TFO_NO_SYN_DATA_TIMEOUT > > Data was sent with SYN, we received a SYN/ACK which did not cover the data > after at least 1 additional SYN was sent (without data). It may be the case > that a middle-box is dropping data-in-SYN packets. Thus, it would be more > efficient to not use TFO on this connection to avoid extra retransmits > during connection establishment. > > These new fields certainly not cover all the cases where TFO may fail, but > other failures, such as SYN/ACK + data being dropped, will result in the > connection not becoming established. And a connection blackhole after > session establishment shows up as a stalled connection.
I'm curious what would be the arguments compared to creating a new getsockopt() to fetch this data? Thanks, -- William
