Re: [hybi] Websocket over TLS keep-alive overhead

[Jamie Lokier <[e-mail]>]

[e-mail] wrote:
> Hi,
> 
> Yes, these are all very good points. Just one comment.
> 
> Jamie Lokier wrote:
> >
> >(Of course over mobile links, it would make much more sense for power
> >efficiency to have a single, aggregated keepalive stream for all sockets rather
> >than one per active websocket, or some other way of taking advantage of the
> >phone's existing mobile link-level keepalives which it already does and are
> >designed for efficiency.)
> 

> Yes, aggregation is very important. If the keep-alive streams are
> independent, power consumption is typically also multiplied. But I'm
> not sure what type of "link-level" keep-alives you are thinking
> about. In both cellular and Wi-Fi links there is some
> messaging/paging going on, but that is typically in the timescale of
> hundreds of milliseconds. So, it's not relevant to TCP or websocket
> level keep-alives. 

Hi Markus,

It's the difference in timescale which makes it work.  A longer
keepalive at a higher layer in the stack can be piggybacked
efficiently ("free") on a shorter keepalive at a lower layer in the
stack.

(It can also make the keepalive even more effective than the usual "1
per minute" approach at application level, guaranteeing more rapid
notification to the application of when the link is lost, or more up
to date confirmation the link is still live so synchronised state is
still valid.)

This works for mobile, wireless, and wired links.  I don't know
details but suspect it's particularly effective in terms of mobile
power usage.

WebSocket/TLS level keepalive power can be *eliminated entirely*
(saving maximum possible power) if a protocol extension allows the
handset and mobile network to recognise them and, using an
intermediary-permitted transformation to the message stream, the
mobile network sends keepalives to the WS server as long as the
network has link-level confirmation of the handset presence, and the
handset sends keepalives to the WS client application as long as the
handset has link-level confirmation of the network's presence.

That can't happen as long as the keepalives are generated by the
applications in an application-specific way.

And it isn't safe to do it on the existing ping/pong messages, because
it does change the nature of the end-to-end guarantees, suitable for
some applications but not all, so it needs to be opt in by application.

And it can't be done with WS over TLS, unless there is a recognisable
TLS-level message the intermediary is able to transform.

Aside from link-level power savings, a very similar possibility
applies aggregating multiple keepalive streams from different
Javascript applications within a single browser, and different
keepalive streams from different non-browser applications; and even
from different machines behind any bandwidth-limited link.

Again it needs to be opt-in because it changes the nature of the
end-to-end guarantees, and it needs messages that are recognisable and
safe to change by an intermediary.

> However, synchronizing keep-alives with any other
> IP traffic the device sends/receives is useful.

Typically there are many applications where the keepalives are 90% or
more of the total traffic, because they are just to stay "present",
while very little is really happening.

For example an application simply checking for short messages, which
you don't receive often, but are expected to show on the client when
they do.

It needs a keepalive - or repeated connections - just to receive a
message from the server when something changes.  Especially if you
want fast notification.  Yet, that might only happen once a day, and
transfer just a few bytes - about 3 packets per day.  Whereas 1
keepalive per minute over TCP is 4320 packets per day.

In such applications, using the above figures keepalive is >99.9% of
the traffic.

That overhead can be mostly eliminated, with a protocol extension that
allows smart interaction with intermediaries, and this is useful for
saving handset power, and reducing bandwidth use in all applications
where you have a lot of applications per client with similar behaviour
- few data updates, lots of presence.  Mobile handsets tend to have
both of these at the same time, increasingly as more apps want to
subscribe to notifications from their own services.

(This whole idea can be developed further by ideas such as named
liveness subscriptions, which would provide stronger end-to-end
guarantees and so be suitable for more applications.)

Best,
-- Jamie