From e7d686ea0e38b95f7e739c85521fd8cc848b026b Mon Sep 17 00:00:00 2001 From: Otto Date: Tue, 11 May 2021 14:18:58 +0200 Subject: [PATCH] Better wording for fastopen docs. --- pdns/recursordist/docs/performance.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/pdns/recursordist/docs/performance.rst b/pdns/recursordist/docs/performance.rst index 15e4b48fea..da1ba47dd1 100644 --- a/pdns/recursordist/docs/performance.rst +++ b/pdns/recursordist/docs/performance.rst @@ -113,18 +113,18 @@ TCP Fast Open Support --------------------- On Linux systems, the recursor can use TCP Fast Open for passive (incoming, since 4.1) and active (outgoing, since 4.5) TCP connections. TCP Fast Open allows the initial SYN packet to carry data, saving one network round-trip. -For details, consult `:rfc:7413`. +For details, consult :rfc:`7413`. -To enable TCP Fast Open, it might be needed to change the value of the ``net.ipv4.tcp_fastopen`` sysctl. +On Linux systems, to enable TCP Fast Open, it might be needed to change the value of the ``net.ipv4.tcp_fastopen`` sysctl. Value 0 means Fast Open is disabled, 1 is only use Fast Open for active connections, 2 is only for passive connections and 3 is for both. The operation of TCP Fast Open can be monitored by looking at these kernel metrics:: netstat -s | grep TCPFastOpen -Please note that if active TCP Fast Open attempts fail in particular ways, the Linux kernel stops using active TCP Fast Open for a while for all connections, even connection to servers that previously worked. +Please note that if active (outgoing) TCP Fast Open attempts fail in particular ways, the Linux kernel stops using active TCP Fast Open for a while for all connections, even connection to servers that previously worked. This behaviour can be monitored by watching the ``TCPFastOpenBlackHole`` kernel metric and influenced by setting the ``net.ipv4.tcp_fastopen_blackhole_timeout_sec`` sysctl. -While developing active TCP Fast Open, it was needed to set ``net.ipv4.tcp_fastopen_blackhole_timeout_sec`` to zero to circumvent the issue, since it was triggered regularly while forcing TCP connections to nameservers for popular domains. +While developing active TCP Fast Open, it was needed to set ``net.ipv4.tcp_fastopen_blackhole_timeout_sec`` to zero to circumvent the issue, since it was triggered regularly when connecting to authoritative nameservers that did not respond. At the moment of writing, the Google operated nameservers (both recursive and authoritative) indicate Fast Open support in the TCP handshake, but do not accept the cookie they sent previously and send a new one for each connection. We can only hope Google will fix this issue soon. -- 2.47.2