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

Re: Keeping up data channel

From: SUN Yang <sun.yang.nj@gmail.com>
Date: Wed, 13 Jun 2012 21:33:56 +0800
Message-ID: <CAO6ZCZ2M8hEs=xZXCq8kCvNM1qsJC9C+2NpUEXN3tOvP_q1naA@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: Markus.Isomaki@nokia.com, public-webrtc@w3.org
If there are 3 udp ports used by a PeerConnection between A and B.
For example, 1 for mediastream, 2 for data streams.
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 13:34:32 UTC

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