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

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 28 Jun 2012 19:49:09 +0000

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

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

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 29 Jun 2012 13:56:45 +0300

as I said during the interim
we can reduce the 3 way handshake in the channel setup, but at cost of 
complicate "a little" the data framing

On 6/28/12 10:49 PM, Cullen Jennings (fluffy) wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Sat, 30 Jun 2012 08:50:28 -0400

> 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 "connect…

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.

>> -- 
>> Randell Jesup
>> [email-masked]