Re: Keeping up data channel

ISTM that the major issue here is need for frequent keep alives over 
UDP. If it were TCP then the keep alives wouldn't be an issue.
And we're using SCTP over UDP because native SCTP won't get thru nats 
and/or some networks don't support inbound (or outbound?) SCTP. If nats 
supported SCTP, I would think (without any real facts to justify) that 
the timeout would be more like TCP.

What about defining an alternative data channel mapping over a stack 
with SCTP at the bottom, and defining ICE for SCTP (and I suppose TURN 
for SCTP), and then using ICE to determine whether to use native SCTP or 
SCTP over UDP? That would provide some incentive to get native SCTP 
supported - especially in the mobile networks. And if it started being 
used in mobile networks, maybe that would provide some pull to get it 
supported elsewhere.

An approach like this could be viewed as an optimization that could be 
taken up in a future version of rtcweb.

 Thanks,
 Paul

On 6/13/12 3:20 AM, Randell Jesup wrote:
> On 6/12/2012 7:01 PM, Martin Thomson wrote:
>> On 12 June 2012 13:15, Stefan Hakansson LK
>> <stefan.lk.hakansson@ericsson.com> wrote:
>>> I think we need to make developers close the PeerConnection when it
>>> is not
>>> needed. A way to promote this would of course be to make
>>> PeerConnection set
>>> up fast.
>>
>> Unfortunately, responsiveness is also a trait that is valued highly.
>> Setup for data channels is currently prohibitively long. Applications
>> that are not specifically targeting mobile users will have abysmal
>> performance on mobile networks initially. Expect the radio to remain
>> on constantly.
>>
>> I expect that many developers will come down on the wrong side of the
>> tradeoff, especially since we give them such an awful set of choices -
>> massive latency or massive battery use. Natural selection of a sort
>> will prevail. I suspect that problems will surface pretty quickly.
>> Mobile applications that are bad at this tend to get a reputation
>> pretty quickly and people stop using them.
>
> So, the issues here are continuing consent, and keeping the NAT mappings
> alive.
>
> Continuing consent for an SCTP association over DTLS/UDP would seem
> likely to be different than for RTP. If the receiver doesn't want to
> continue receiving, it can simply close the DTLS connection. Since
> on-path attackers are out of scope (they could DoS on their own), that
> should cause the sender to stop. (This analysis may already be in the
> security doc; I didn't have time/energy to check.)
>
> NAT mappings are the problem. If we knew there was no NAT, or if it had
> long timeouts, we could go silent for long times. But if there might be
> a NAT, we have to send every 30 seconds to maintain mappings.
>
> NATs will keep TCP mappings alive (much) longer, though no forever with
> no traffic (generally). So for data-only persistent (but usually idle)
> mobile connections a UDP protocol is generally not going to be great for
> battery life. That's a class of usage which simply won't work as well.
> For non-persistent connections or ones in parallel to audio/video, this
> restriction isn't an issue.
>
> If we somehow knew there was no NAT, we could greatly extend or remove
> the idle traffic (though if the other side sends NAT keepalives, those
> will keep us awake anyways, so even knowing your mobile device has no
> NAT doesn't help. (Note: there's a trick for NAT keepalives that reduces
> or eliminates this issue, by using a low TTL (~7) on the requests, so
> they exit the NAT but typically never make it to the far end.)
>

Received on Monday, 16 July 2012 05:28:26 UTC