Re: Keeping up data channel

On Jun 13, 2012, at 3:33 PM, SUN Yang wrote:

> If there are 3 udp ports used by a PeerConnection between A and B.
> For example, 1 for mediastream, 2 for data streams.
As far as I understand the peer connection: We use one port number
on each side. Within the peer connection we will multiplex/demultiplex
the media streams and data streams. So the data streams don't use
additional UDP port numbers.

Best regards
Michael
> I am not sure whether there will be  3 keep-alive messages between A and B every 30 secondes?
> If so, can we converge them into 1 keep-alive message?
> 
> 
> On Tue, Jun 12, 2012 at 1:36 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
> 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.
> 
> 
> 
> 
> 
> -- 
> Yang
> Huawei
>

Received on Wednesday, 13 June 2012 15:16:39 UTC