New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 672959 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 704339
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

Blocked on:
issue 704339



Sign in to add a comment

Flywheel disabled due to ERR_CONNECTION_TIMED_OUT on slow network

Project Member Reported by mdw@chromium.org, Dec 9 2016

Issue description

Application Version (from "Chrome Settings > About Chrome"): 56.0.2924.18
Android Build Number (from "Android Settings > About Phone/Tablet"): LXI22.50-62
Device: Moto E

Steps to reproduce:

1) Put device on a slow network (e.g., GIN-2gpoor)
2) Enable Flywheel.
3) Try to load a page.

Observed behavior: 

In this case, I loaded a page successfully with Flywheel (with Lo-Fi and Lite Pages on). When I tapped on "Show original", the page load took a VERY long time and eventually resulted in an ERR_CONNECTION_TIMED_OUT error page. When I loaded the page again, Flywheel had been disabled.

Looking in chrome://net-internals#bandwidth, I see:

2016-12-08 11:18.49.765
net_error ERR_CONNECTION_TIMED_OUT
proxy https://proxy.googlezip.net:443

2016-12-08 11:18.49.765
net_error ERR_CONNECTION_TIMED_OUT
proxy compress.googlezip.net:80

Netlog from the entire session attached.

Expected behavior:

This is a typical problem for users in poor connectivity situations. When the device is on a slow network, we should reconsider our policy for timing out and retrying network connections (maybe in general, but at least for Flywheel). Disabling Flywheel in this case was probably harmful for the user, since the user would not get the benefit of compression and speedup. Clearly we also need to time out in cases where Flywheel really cannot be reached, but the expectation that Google is down would probably be less than the network were simply slow. In this case, we might want to retry the connection to Flywheel first and only give up if we are confident that nothing is getting through.


See internal doc for more details on experiment:
https://docs.google.com/a/google.com/document/d/19ctmz25Dd4FsCUeFJeaIhWGBTENcVo5_KD626fRE4DM/edit?usp=sharing
 
chrome-net-export-log 3.json
995 KB View Download
One possible solution here is to adjust the network timeouts based on the network quality. In cases where it is not possible to adjust timeouts, we should retry more often. 

Looking at event#127, the TCP socket timed out after ~127 seconds which caused bypass of https://proxy.googlezip.net:443. 

Event 361, 363 show DNS failure for compress.googlezip.net.

To get around the tradeoff between Flywheel actually unreachable vs. slow connection, one possible solution may be to keep retrying connection to Flywheel in the background even after proxy has been marked as unreachable. 


Thank you for your response what is flywheel
Flywheel is the alternative name of Chrome data saver (https://support.google.com/chrome/answer/2392284?co=GENIE.Platform%3DAndroid&hl=en).

Comment 4 by bengr@chromium.org, Dec 21 2016

Cc: -tbansal@chromium.org bengr@chromium.org
Owner: tbansal@chromium.org
Tarun, since this is related to work you're planning, I'm assigning to you.

To summarize the comments in this issue, I think there are several avenues to explore:
1) Tune proxy (and probably socket) timeouts using NQE.
2) Retry Google connections (or, to generalize, any highly reliable hosts), before giving up.
3) Use a combination of redundant connections and probes to restore a proxy after falling off of it.
Components: Internals>Network>NetworkQuality
Status: Started (was: Assigned)

Comment 7 by bengr@chromium.org, Mar 16 2017

Whatever you do, make sure we are still responsive when a connection attempt is black holed by a captive portal.
Blockedon: 704339
Blocking: 706546
Labels: M-61
Blocking: -706546
Blockedon: -704339
Mergedinto: 704339
Status: Duplicate (was: Started)
Blockedon: 704339

Sign in to add a comment