Subject: Re: [rtcweb] Target numbers for setup time (Re: Keeping up data channel)

From: Justin Uberti <[email-masked]>
Date: Mon, 2 Jul 2012 13:00:17 -0700

We can certainly make the API allow instant creation of a data channel, but
the thing I'm bringing up is the <N RTT of data channel setup>, which is
currently the long pole in establishing a p2p flow. That's where 6 RTTs are
coming from.

Agree with Harald that this is an IETF matter though.

On Sat, Jun 30, 2012 at 5:50 AM, Randell Jesup <[email-masked]>wrote:

> On 6/28/2012 3:49 PM, Cullen Jennings (fluffy) wrote:
>
>> Agree - that's why I think this has to be done in zero RTT. I don't see
>> any problem with setting up a data channel and being ready to send media
>> before having the UI tell the user they are "connected and can start
>> talking".
>>
>
> I agree, and have suggested this as well, but it's really in the
> application domain (though we can give examples that use it and recommend
> it).  There are some mild security concerns with accepting the data-only
> connection before user decision, but manageable I believe.
>
> Roughly: call start (user)
>      caller-> Offer(SDP(data-only)) as "setup" -> server -> answerer
>             (also indicate if it's audio-only or audio+video)
>             (maybe offer data+audio (and video) to warm up ICE candidates)
>      answerer -> Answer (SDP(data-only)) as "setup" -> server -> answerer
>      answerer -> alert user
>      caller-> install Answer
>      <N RTT of data channel setup setting up "negotiation" channel>
>      caller-> Offer(SDP(data+media)) as "call" -> answerer (over
> "negotiation" channel)
>      ...
>      answerer (user) accepts
>      answerer-> Answer(SDP(data+media)) as "call" -> caller (over
> "negotiation" channel)
>      answerer starts sending
>      caller installs Answer
>      caller media starts sending
>
> From user accepts -> media starts, it's 0 RTT for answer sending, 1 RTT
> until he sees media from the caller, which is pretty much close to
> theoretical minimum.  (You can do better only by starting media channels
> "in the background" from the caller before user accepts, perhaps with an
> Answer(SDP(data+receive-only-**media)).)
>
> Again, I believe this is all possible in the application domain today with
> the spec.
>
>
>> Reducing from 7 RTT to 5 RTT does not help when you need to get to 0 RTT.
>>
>> On Jun 22, 2012, at 10:09 , Harald Alvestrand wrote:
>>
>>  On 06/22/2012 05:58 PM, Cullen Jennings (fluffy) wrote:
>>>
>>>> On Jun 13, 2012, at 5:29 , Randell Jesup wrote:
>>>>
>>>>  How far down do you think we have to drive the setup time before you
>>>>>> would not call it "abysmal"?
>>>>>>
>>>>> I'd probably consider above 250 ms abysmal but good news I don't see
>>>> any problem with getting it down around 100 ms in when both endpoints are
>>>> in a single country.
>>>>
>>>>  Coast-to-coast US is ~4800 km, so RTT (9600 km) is 32 ms (speed of
>>> light is 300 km/msec).
>>>
>>> So, without considering processing time, 3 RTT is 100 msec, 7 RTT is
>>> "abysmal".
>>>
>>> There are bigger countries than the US, but this will do for a
>>> back-of-the-envelope.
>>>
>>> --
>>> Randell Jesup
>>> [email-masked]
>>>
>> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Randell Jesup <[email-masked]>
Date: Mon, 02 Jul 2012 18:06:51 -0400

On 7/2/2012 4:00 PM, Justin Uberti wrote:
> We can certainly make the API allow instant creation of a data channel,
> but the thing I'm bringing up is the <N RTT of data channel setup>,
> which is currently the long pole in establishing a p2p flow. That's
> where 6 RTTs are coming from.

Agreed we want to reduce N RTT wherever possible; I was showing how you 
could hide it for one class of applications (classic 'voip'-type 
telephony) and get fast media pickup on user answer.  Both reducing and 
hiding are useful operations, though hiding is largely the purview of 
the application.

This is also an argument for my "#3" case on the W3 webrtc list for the 
DataChannel DOM API, where we allow pre-defining channels (and send it 
in the SDP).

-- 
Randell Jesup
[email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 5 Jul 2012 14:16:05 -0700

I think we are talking about different numbers here. I am concerned with the time from when the UI indicates you can start talking, to the time that you can start talking with a reasonable expectation that the other side will hear it. 

On Jul 2, 2012, at 13:00 , Justin Uberti wrote:

> We can certainly make the API allow instant creation of a data channel, but the thing I'm bringing up is the <N RTT of data channel setup>, which is currently the long pole in establishing a p2p flow. That's where 6 RTTs are coming from.
> 
> On Sat, Jun 30, 2012 at 5:50 AM, Randell Jesup <[email-masked]> wrote:
> Agree - that's why I think this has to be done in zero RTT. I don't see any problem with setting up a data channel and being ready to send media before having the UI tell the user they are "connected and can start talking".
> 
> I agree, and have suggested this as well, but it's really in the application domain (though we can give examples that use it and recommend it).  There are some mild security concerns with accepting the data-only connection before user decision, but manageable I believe.
> 
>      caller-> Offer(SDP(data+media)) as "call" -> answerer (over "negotiation" channel)
>      ...
>      answerer (user) accepts
>      answerer-> Answer(SDP(data+media)) as "call" -> caller (over "negotiation" channel)
>      answerer starts sending
>      caller installs Answer
> From user accepts -> media starts, it's 0 RTT for answer sending, 1 RTT until he sees media from the caller, which is pretty much close to theoretical minimum.  (You can do better only by starting media channels "in the background" from the caller before user accepts, perhaps with an Answer(SDP(data+receive-only-media)).)
> 
> Again, I believe this is all possible in the application domain today with the spec.
> 
> 
> I'd probably consider above 250 ms abysmal but good news I don't see any problem with getting it down around 100 ms in when both endpoints are in a single country.
> 
> Coast-to-coast US is ~4800 km, so RTT (9600 km) is 32 ms (speed of light is 300 km/msec).
> 
> So, without considering processing time, 3 RTT is 100 msec, 7 RTT is "abysmal".
> 
> There are bigger countries than the US, but this will do for a back-of-the-envelope.
> 
> -- 
> Randell Jesup
> [email-masked]
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Jul 2012 14:50:11 -0700

> I think we are talking about different numbers here. I am concerned with the time from when the UI indicates you can start talking, to the time that you can start talking with a reasonable expectat…

You assume an application that performs user alerting and requires
user acceptance prior to establishing media.  That is certainly an
important use case, but not the only one.  In some other use cases the
signaling must occur after the user hits a button.

--Martin