Dynamically pick a sane value for network.http.connection-retry-timeout

NEW
Unassigned

Status

()

Core
Networking: HTTP
P3
normal
5 years ago
a month ago

People

(Reporter: kats, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog])

From IRC, lightly edited:

16:27:36 Andy: hmm, also, this isn't mobile specific
16:27:47 Andy: but would there be any point in me complaining about using https for google?
16:28:10 Andy: for people on net with bad ping like satellite, ssl connections make any page load take about 6x longer
<snip>
16:37:14 Andy: my average ping is 2500
16:37:17 Andy: just fyi
16:38:16 Andy: it's literally just a drawback of secure handshake negotiations
16:38:39 Andy: the few extra steps is painfully slow on bad-ping connections
16:38:45 kats: Andy: wow. i was actually looking at our networking code recently, and for HTTP requests we'll open a second TCP connection after 250ms if the first one doesn't receive a response. that means for you we'll always be opening two TCP connections instead of one
16:39:01 Andy: ogawd
16:39:03 Andy: T_T
16:39:06 Andy: that's like
16:39:08 Andy: bandwidth rape
16:39:17 kats: there's a pref you can adjust to twiddle that i believe
16:39:20 kats: lemme find it
16:39:25 Andy: yesplz
16:40:30 kats: Andy: network.http.connection-retry-timeout
16:40:42 Andy: awesomesauce
16:40:46 Andy: setting that to 10000
<snip>
16:41:43 Andy: does that change https at all?
16:42:08 Andy: cause it does seem to be quite a bit quicker
16:42:38 Andy: yeah, that makes it almost as quick as regular http

Conclusion: we should investigate how much the network.http.connection-retry-timeout actually affects high-RTT connections and see if it makes sense to dynamically adjust the pref based on actual RTT we're seeing, if the user hasn't set the pref manually.
For andy: 

The bandwidth of a parallel connection setup done on a hot radio is absolutely trivial, and its not blocking anything so the high latency is irrelevant too. So that's not the source of the slowness.

having extra connections already established when you need them is actually generally a win for high latency environments.

What do you think is the reason for the results you're seeing?

[btw I don't want to make a big deal of it, but 'rape' is unprofessional as used here. Please do it differently in the future.]
(In reply to Patrick McManus [:mcmanus] from comment #1)
> For andy: 
> 

I'll pass on the message to andy if I see him on IRC again. He's an extension developer who shows up occasionally.

> [btw I don't want to make a big deal of it, but 'rape' is unprofessional as
> used here. Please do it differently in the future.]

Sorry, should have edited that out.
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.