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

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.
> 
> 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
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb