Heartbeat

[oberstet]

Goal:

Make it possible to automatically / adaptively keep the radio state on a mobile connection in low-latency, active state.

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

2 options: either make that some "standard RPC", but more cleanly, make it possible to implement within library/framework protocol implementation.

2 messages:

PING: [TYPE_ID_PING, echo, discard, reply_discard_length]

echo: <object | null>
discard: | null
reply_discard_length: >=0

The peer should reply with a PONG. The "echo" MUST be returned untouched. The "discard" is thrown away. The "reply_discard_length" specifies the length of "discard" in PONG.

The "discard" string SHOULD be randomly generated. Can be any cheap, unsecure pseudo RNG. Rationale: make it impossible for intermediaries to "optimize" away that payload.

Since the "discard" is effectively used to "pump up the up-/downstream traffic rate so that radio state can be kept up. I.e. target discard rate : 4kb/s ..

PONG: [TYPE_ID_PONG, echo, reply_discard]
echo: the echo'ed object | null
reply_discard: string

The reply_discard string SHOULD be a random string, and MUST be of length "reply_discard_length". When reply_discard_length = 0, then this is an empty string, (not null!).

[cboden]

Does the WebSocket protocol not already handle this with its protocol Ping/Pong frames?

[oberstet]

No. The semantics of WS Ping/Pongs require the payload to be returned verbatim. There is no "discard" and "request discard length". If i.e. it would be sufficient to keep up the radio state to only have 2kb/s downstream, then I don't wanna consume upstream bandwidth, but only do PINGs that request that amount via request_discard_length.

Also the payload is limited to 125 octets. I didnt yet do systematic investigation whether it makes a difference having 4kb/s in more smaller payloads, or fewer larger payloads.

Another issue: WS Pings are not required to reach the other peer (endpoint). Intermediaries might take a shortcut and do the Pong reply themselves. They are hop-by-hop ..

I dont think WS Ping/Pongs have been designed well enough, i.e. with mobile in mind ..

[oberstet]

Here is the test heartbeat proggy using WS Ping/Pongs I used.

https://github.com/oberstet/scratchbox/blob/master/python/heartbeat/client.py

Totally unscientific and lacking .. but it worked for me to keep the HSPA actually in "snappy state" all the time.

Would be very interesting in tests on your mobile network whatever .. tweak the

BEAT_SIZE = 100
BEATS_PER_SEC = 5

and see what happens to the RTTs.

And good implementation would adapt to the network:

“Probing network defined HSPA radio state promition and demotion timeouts.”

and then tune BEAT_SIZE up/down and BEATS_PER_SEC dynamically ..

[oberstet]

Someone send me this very interesting study:

http://www.stevesouders.com/blog/2011/09/21/making-a-mobile-connection/

Main takeaway: there is a tradeoff between initial latency and power consumption.

Well, right. Thats obvious. But: the timeouts for radio state transitions seems to be chosen by carrier, and different.

There are 2 more points:

The author suggests that web app developers might do periodic fetches of some 1 pixel img. Nice idea, since then I can consume someones else server bandwidth;)

So why include PING/PONG in WAMP then?

Fetching imgs via HTTP only works for browser clients.

A comment points out a simple fact: when I am on power plugged, there is no reason to conserve the last mW! So in that situation, I basically always want the highest radio state. Carriers might view that differently of course .. they wanna downgrade radio so less resources are consumed on their side.

[oberstet]

This is in WAMPv2:

[HEARTBEAT,         IncomingSeq|integer, OutgoingSeq|integer]
[HEARTBEAT,         IncomingSeq|integer, OutgoingSeq|integer, Discard|string]

The heartbeat allows to notify the peer up to which incoming heartbeat all incoming WAMP messages have been processed, and announce an outgoing hearbeat sequence number in the same message.

It also allows to inject discarded payload for the radio channel thingy discussed above.

[oberstet]

part of AP

[oberstet]

not sure why this is still open, but keeping the network alive is a transport layer job