Re: Keeping up data channel

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

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Wednesday, 13 June 2012 01:22:20 UTC