Indeed, there are applications with a valid desire to keep connections alive over a long period, and not only that,
but also keep network links in a low-latency state.

I once did some experiments with WebSocket on a mobile 3.5G network, where keeping the WebSocket connection
in a low-latency state ("HSPA DCH") required not only occasional pings/pongs, but a constant load of 4kb/s

http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/1083.html

WebSocket's ability of inducing traffic unrelated to app level using pings/pongs proved to be useful here.

Sidenote: as far as I know, IE11 is currently the only browser that actively uses WebSocket ping/pong (it sends unsolicited _pongs_ every couple of seconds upstream).

Ideally, there would be an API exposed to user apps to give hints to the radio link layer on mobile devices, like: keep up radio for the next 800ms, then go to low power.

This would make sense for the uplink direction. The downlink is more problematic. Unless it's periodic.

FWIW, here are 2 related resources

http://de.slideshare.net/zahidtg/gsma-fast-dormancy-best-practices
https://eggert.org/students/chemmagate-thesis.pdf

/Tobias



Von: hybi [mailto:hybi-bounces@ietf.org] Im Auftrag von Adam Rice
Gesendet: Montag, 17. Februar 2014 03:57
An: Roberto Peon
Cc: hybi@ietf.org
Betreff: Re: [hybi] Detection of broken WS connections

Consider an earthquake early-warning web app. It can provide a 15-second warning of an event which only happens a couple of times a year. If the warning is more than 5 seconds late, it is effectively useless.

Polling would be hideously inefficient for this use case. Even if the OS/network forces you to ping every 5 minutes to keep the connection alive, it is still going to be several orders of magnitude more efficient than polling.

There are legitimate uses for long-lived, idle connections. WebSocket is currently the least-worst browser technology available to satisfy them. If we can make it less bad, I think that would be worthwhile.

With respect for Salvatore's point, if the suspend/resume facility existed you could in principle tunnel SSL over it (ie. within the WebSocket payload) and still get the benefit without trusting the proxy more than you already have to trust your network provider anyway.

Adam

On 15 February 2014 04:21, Roberto Peon <fenix@google.com<mailto:fenix@google.com>> wrote:
Basically, keep-alives ties up enough network resources and/or device battery life that OS providers and network providers have strong incentive to consider a connection idle (and close it/blackhole it) for smaller and smaller time periods, eventually resulting in an arms race which increases inefficiencies everywhere.

-=R

On Fri, Feb 14, 2014 at 2:07 AM, Adam Rice <ricea@google.com<mailto:ricea@google.com>> wrote:
I don't think anyone has yet made the point that WebSocket connections cannot be assumed to be stateless, so browsers cannot implement transparent reconnection without an extension with some server-side state.

I have not so far seen a compelling argument that reconnection logic is better implemented as a protocol extension rather than at the application level. Hypothetically mobile networks could provide some kind of WebSocket proxy with suspend/resume capabilities, but so far no such thing exists.

Currently WebSocket applications can control keepalive behaviour by sending (or not) pings from the server.

I see two potential areas for improvement:
1) Client side detection of loss of connection
2) More efficient liveness detection

1) could be resolved with something as simple as an "expect_ping_when_idle" extension which told the client about whatever keepalive policy the server was attempting to enforce.

Roberto seems to be implying that 2) may in fact be counter-productive, although I'm not sure I fully understand the argument.

Adam Rice

On 14 February 2014 04:36, Roberto Peon <fenix@google.com<mailto:fenix@google.com>> wrote:


On Wed, Feb 12, 2014 at 9:14 PM, Takeshi Yoshino <tyoshino@google.com<mailto:tyoshino@google.com>> wrote:
On Thu, Feb 13, 2014 at 2:08 AM, Roberto Peon <fenix@google.com<mailto:fenix@google.com>> wrote:
On should steer away from keep-alive (which is anathema on mobile links), and use liveness detection when one needs to solve these problems.
(I believe that was what you essentially proposed, Martin)


I want to confirm my understanding on your terms. Do you mean that
- it's kinda illusion that we are able to keep an end-to-end connectivity alive
- but should just have a way to detect the peer is dead when wanted

yup.
Essentially, we don't want traffic black-holed (because the connection is dead but we haven't detected it), and we don't want to incent "the network" to kill connections unnecessarily (this is particularly an issue on shared bandwidth mediums like mobile networks).


A PING (application-layer equivalent if necessary) should be automatically generated when the client has been idle for some time and then has any message to send. If the PONG is not received within some reasonable timeout (preferably ~2-3RT or so, or within some other human-scale constant), the connection should be assumed dead, and another should be created.

imho, this should be done for you by the browser (not that it necessarily *is*, but it *should*)

Thinking of what browser vendors can do at this point:
a) have built-in default-on ping-generate/timeout-close (try to do something intelligent like TCP's RTO calculation?) feature in browser. one concern is that people may have skipped implementation of ping/pong
b) same as (a) but default-off and can be turned on by calling some method on WebSocket object
c) have one-shot ping sending method on WebSocket object with timeout arg
d) have one-shot ping sending method and pong received event. Sounds overkilling to me
e) periodical version of (c) or (d)

We have implemenation experience for (a) for HTTP/2/SPDY, and it seems to work pretty well.
HTTP2/SPDY has the same problem: if the connection is dead, it is a poor user experience to attempt to keep sending all traffic down it!

The design rationale behind the choice of (a) was:
it transparently fixed the biggest problem case without requiring any user involvement or knowledge.
It was important to use ping, because ping/pong requires no interaction with the application-layer logic, and thus is most likely to be consistent and have timing similar to TCP's PING.

-=R



Keep-alive is fairly evil at the infrastructure layer, and incents browsers, servers and carriers to do things to the tear down connection quickly/prematurely.

Liveness-detection doesn't solve the server notification problem (which requires at least some level of high-level polling, though hopefully on a longer timescale), but keep in mind that in seeking perfection, one is likely to cause a significant less than perfect response from the system and the players within it.

(It is pretty annoying that we've not developed good APIs or behaviors for doing decent things on mobile devices...)

-=R

On Tue, Feb 11, 2014 at 7:50 PM, Takeshi Yoshino <tyoshino@google.com<mailto:tyoshino@google.com>> wrote:
On Thu, Jan 9, 2014 at 9:13 PM, Tobias Oberstein <tobias.oberstein@tavendo.de<mailto:tobias.oberstein@tavendo.de>> wrote:
> The WS API is explicit about the fact that there is no way from JavaScript to
> generate PINGs or check for PONGs. So do I just create my own, application
> level equivalent, and send a ping-like message every so often and assume
You can have a WS server that does automatic ping-pong for connection keep-alive/loss-detection.

This works for server. For client, app level work is needed.

Or you can do it on app level from JS.

> the connection is dead when I don't get a reply "soonish"? Are there libraries
> that support such a mechanism? Or is every browser supported to regularly
> PINGPONG with the server, and call the onclose function when there's no
As far as I know, there is no JS API where you could request the browser to do automatic ping-pong upon opening a WS connection.

> answer?
>

Right. We've been saying that we should start discussing such a change on the API, but haven't.

// Send a ping (w/o body) every 5 sec
ws.pingInterval = 5;
// _Close the WebSocket connection_ when it passed 10 sec without receiving any byte (not limited to PONG)
ws.timeout = 10;


_______________________________________________
hybi mailing list
hybi@ietf.org<mailto:hybi@ietf.org>
https://www.ietf.org/mailman/listinfo/hybi




_______________________________________________
hybi mailing list
hybi@ietf.org<mailto:hybi@ietf.org>
https://www.ietf.org/mailman/listinfo/hybi