W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: Keeping up data channel

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 12 Jun 2012 07:36:38 +0200
Message-ID: <4FD6D566.6060806@alvestrand.no>
To: Markus.Isomaki@nokia.com
CC: public-webrtc@w3.org
On 06/11/2012 03:58 PM, Markus.Isomaki@nokia.com wrote:
> Hi,
> In today's WebRTC meeting a discussion came up on how costly it is to keep an unused data channel connected.
> As long as we are using UDP, it is extremely costly for cellular connected mobile devices. In many networks keep-alives at least every 30 seconds are neeed to keep the UDP flow alive.
We also have to send something every 30 seconds to keep the 
consent-to-receive alive in the case of media (and to maintain NAT 
mappings). So as long as a PeerConnection remains unclosed, I think we 
should assume that a packet will be sent every 30 seconds.
>   And sending a packet wakes up a radio for some time. In worst case radio would be up all time, but even in a decent case quite high % of the overall cycle. That's quite different to e.g. normal websocket connection, where in the best case keep-alive period can be even more than 10 minutes.
> So, leaving data channels casually on, either by user or app, would be bad. At minimum some advice to app developers would be needed, but I'm afraind they might not pay attention to it. It's not clear to me what the options are, but it would be wise to close the channel after some time of inactivity and bring it up again when it's needed, even if that would require some delay. Or, alternatively, have the long-lived channels over TCP via a relay/server.
I think it's unwise to try to be "smart" about closing channels on 
behalf of the app.
We should focus on making sure the number of round trips required to 
bring up a PeerConnection is as small as possible; that will help give 
people confidence that they can take them down when they're not in use.
Received on Tuesday, 12 June 2012 05:37:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC