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

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 <randell-ietf@jesup.org>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
>>> randell-ietf@jesup.org
>>>
>> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>