TCP FastOpen cannot be enabled when net.ipv4.tcp_fastopen is set to 3
Reported by
zzq1...@gmail.com,
Feb 14 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Enable TCP Fast Open in chrome://flags 2. execute in the terminal sudo sysctl -w net.ipv4.tcp_fastopen=3 3. execute ip tcp_metrics show | grep "fo_cookie" and nothing is produced What is the expected behavior? A list of IP addresses of TCP-FastOpen-enabled servers should be displayed. What went wrong? Read https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt and search for "tcp_fastopen" Both 1 and 3 are valid values to enable client-side TFO However, Chrome appears to check whether net.ipv4.tcp_fastopen is set to 1, otherwise TFO is disabled silently. Did this work before? No Chrome version: 56.0.2924.87 Channel: stable OS Version: Ubuntu 16.10 Flash Version: Try to divide net.ipv4.tcp_fastopen value by 2 and get the remainder. If the remainder is 1, client-side TCP Fast Open is enabled.
,
Feb 14 2017
The complete steps are below: 1. Open Chrome 2. Enable TCP Fast Open in chrome://flags 3. Close Chrome 4. execute in the terminal ---START HERE--- sudo sysctl -w net.ipv4.tcp_fastopen=3 sudo ip tcp_metrics flush ---END--- 5. Re-open Chrome 6. Go to a TCP-Fastopen-enabled website such as Google or Facebook 7. execute ip tcp_metrics show | grep "fo_cookie" and nothing is produced
,
Feb 14 2017
,
Feb 14 2017
Jana can you take a look?
,
Feb 14 2017
It's hard to tell what may be going on -- can you send a packet trace using tcpdump? Specifically, start the trace after step 5 and stop after 7. +ycheng, since this seems like a Linux issue and not a Chrome one (as far as I can tell.)
,
Feb 15 2017
When net.ipv4.tcp_fastopen is set to 3, curl --tcp-fastopen www.facebook.com (execute this multiple times) uses TCP Fast Open properly Execute ip tcp_metrics show | grep "fo_cookie" and got the Facebook IP address displayed
,
Feb 15 2017
Thanks for clarifying. A packet capture will be really helpful if you are able to provide it.
,
Feb 15 2017
TCP Fast Open is activated as long as the LSB of net.ipv4.tcp_fastopen is 1. See http://lxr.free-electrons.com/source/net/ipv4/tcp.c?v=4.9#L1077 so Chrome browser either didn't parse the setting correctly or has other bugs. btw it was nice to learn facebook has enabled Fast Open!
,
Feb 15 2017
,
Feb 16 2017
,
Feb 18 2017
I don't have tcpdump but I installed wireshark on Ubuntu. tcp_fastopen_1.pcapng is for net.ipv4.tcp_fastopen=1, TCP Fast Open is enabled as normal. tcp_fastopen_3.pcapng is for net.ipv4.tcp_fastopen=3, TCP Fast Open is disabled even if I haven't touched any chrome://flags setting. Also, I tried the two kernel settings for curl, and both of them works correctly (TCP Fast Open is enabled for both settings).
,
Feb 20 2017
apparently Chrome parses the flag incompletely. https://cs.chromium.org/chromium/src/net/socket/tcp_socket_posix.cc?type=cs&l=97
,
Feb 22 2017
,
Feb 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6d9ba1044c884aca683404f05509f18d4b63c818 commit 6d9ba1044c884aca683404f05509f18d4b63c818 Author: jri <jri@chromium.org> Date: Fri Feb 24 21:25:36 2017 Fix incorrect behavior in checking for TCP FastOpen platform support. BUG= 691881 Review-Url: https://codereview.chromium.org/2705323002 Cr-Commit-Position: refs/heads/master@{#452926} [modify] https://crrev.com/6d9ba1044c884aca683404f05509f18d4b63c818/net/socket/tcp_socket_posix.cc
,
Mar 9 2017
,
Dec 11
We're removing FastOpen. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by rbasuvula@chromium.org
, Feb 14 2017Labels: Needs-Feedback