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

Re: Keeping up data channel

From: Justin Uberti <juberti@google.com>
Date: Thu, 14 Jun 2012 11:31:30 -0400
Message-ID: <CAOJ7v-0Vq4CkmGhyOsD4W+tov-zx-VKKK_jgokj2-vdSHHHkTw@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Cc: public-webrtc@w3.org
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
(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.
Received on Thursday, 14 June 2012 15:32:23 UTC

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