My thought on this //: Keeping up data channel

Hi Markus and all

As from an traditional telecom equipment vendor and as a former LTE standard engineer.
I have to agree with Markus on this point.

Nowadays, some mobile network both in America and EU both meet problem by keep-alive like small packet.
And some Smartphone providers they revised their message push mechanism to save the usage of radio interface.
And it works because the small packets can be restricted through improved and converged Client/Server model.

I think webrtc service is very promising due to non-plugin, open source implementation and unified API.
But p2p model of webrtc will bring some kind of burden over mobile network.

But if in wi-fi network, it is not a problem.

If in mobile network, we may need some schema like mentioned by markus to save the keep-alive messages over air.

Above is my 2 cents.

Yang 
Huawei



-----�ʼ�ԭ��-----
������: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] 
����ʱ��: 2012��6��11�� 21:58
�ռ���: public-webrtc@w3.org
����: Keeping up data channel 

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. 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.

Markus

Received on Tuesday, 12 June 2012 02:08:40 UTC