849377 - Enable websocket keepalive pings by default

Status: RESOLVED WONTFIX

(Core :: Networking: WebSockets, defect)

Description

[Jason Duell]

Attachment: IRC discussion

If NATs are killing TCP connections that are idle for 30 seconds on average (see IRC conversation, toward end), then why don't we turn on websocket keepalive by default, at least on desktop?  And possibly on B2G (rather than doing bug 849364)?

Patrick, I seem to remember you being the one who really didn't want keepalives to be on.  Do you still think it's a bad idea?  Is there an issue besides power consumption on phones here? (and that seems to be murky, at least from my read of the IRC chat: we could also make pings less frequent on phones when screen is off).

Comment 1

[Patrick McManus [:mcmanus]]

(In reply to Jason Duell (:jduell) from comment #0)
> Created attachment 722913 [details]
> IRC discussion
> 
> If NATs are killing TCP connections that are idle for 30 seconds on average

they absolutely are not doing that.

I cited 60 as the mode of nat timeouts, honza claimed 30. Neither of us said that was an average. Our data comes from HTTP where we have a 3 minute timeout and I believe on average we reach that timeout or are actively closed by the server. There is still room for a lot of nat errors short of the error.

This is the data that made us use a ping frame for spdy (around 55 sec iirc), but we 
will only send ~3 of them. i.e. it isn't open-ended sucking power and data.

> (see IRC conversation, toward end), then why don't we turn on websocket
> keepalive by default, at least on desktop? 

open-ended keepallives tend to waste tremendous amounts of bandwidth - pages are idle a lot of the time. In various application level protocols they've been shown to consume 90% more of all the bytes the protocol uses.

If we wrote code that some random pings on idle websocket connections and it showed a lot of timeouts happening, then we should turn it on for desktop which can probably tolerate it. We don't have that data.


 And possibly on B2G (rather than
> doing bug 849364)?

that goes against pretty much all the mobile networking advice people give. We're talking about waking up the _radio_ when you otherwise aren't transmitting data. That sucks battery. That's orthogonal to the phone sleep/wakelock argument.

> 
> Patrick, I seem to remember you being the one who really didn't want
> keepalives to be on.

And I also wrote the code for them. So its all there with a pref or a simple idl shim.

  Do you still think it's a bad idea? 

yes. but I could be wrong.

 Is there an issue
> besides power consumption on phones here? 

data consumption on capped data plans.

Comment 2

[Jason Duell]

Doesn't seem likely we're going to do this by default for power/bandwidth issues.