Re: Keeping up data channel

On Wed, Jun 13, 2012 at 5:29 AM, Randell Jesup <randell-ietf@jesup.org>wrote:

> On 6/13/2012 3:07 AM, Harald Alvestrand wrote:
>
>> On 06/13/2012 01:01 AM, Martin Thomson wrote:
>>
>>> On 12 June 2012 13:15, Stefan Hakansson LK
>>> <stefan.lk.hakansson@ericsson.**com <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'm really looking forward to having an implementation up so that I can
>> test what the setup time is for various media path RTTs and signalling
>> path RTTs.
>>
>> How far down do you think we have to drive the setup time before you
>> would not call it "abysmal"?
>>
>> (for reference: the responder's time from hitting "allow" in Chromium to
>> having a video on the screen with apprtc.appspot.com is subjectively
>> quite short - below 2 seconds - I can't measure it more accurately
>> without generating logs for it.)
>>
>
> Well, I *want* time from "ok" to all media live to be on the order of
> 200ms or less (I'd like <100ms).  I may not get it with ICE, DTLS, etc, but
> that's what I want.
>
> These are the times I typically could get in a dedicated videophone, and
> that users of hardphones (analog POTS or SIP UAs) are used to.
>
> 2 seconds may seem good in webcam chat, but I feel it's already horrid at
> 2 seconds.
>
>
apprtc should be able to set up in <200 ms, 4 RTTs (1 page load, 1
offer/answer, 1-2 ICE). It's slow now (2 sec) because the author has been
lazy about fixing a call setup issue.

The data channel, as currently proposed, will likely require 8 RTTs for
setup.
(1 offer/answer, 1-2 ICE, 2 DTLS, 2 SCTP, 1 data channel proto). I think
there's a lot we can do there to reduce the number of RTTs though.

In short restarting a PeerConnection should be reasonably fast, and we will
work on making it faster in the future.