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

DataChannel protocol (1) atop SCTP (2) atop DTLS (2) atop ICE (1) has 6 RTT
in the handshakes, minimum. That's not counting any signaling or candidate
gathering time.

If we want better perf, we need to collapse handshakes. This should be very
doable (see Martin's draft on running DTLS handshake over ICE), but I tend
to think this is something we can do later.

Just having *any* p2p working in the browser is a huge step from where we
are today.

On Fri, Jun 22, 2012 at 1:54 PM, Roman Shpount <roman@telurix.com> wrote:

>
> On Fri, Jun 22, 2012 at 1:09 PM, Harald Alvestrand <harald@alvestrand.no>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.
>>
>>
> IP packets rarely travel in straight lines and typically encounter 2-3
> routers along the way. In US, from east to west coast, between the data
> centers, 60-70 ms are typical. Residential to residential are about 80-100
> ms. So, 3 RTT in real life are "abysmal" by this standard.
>
> More reasonable point of view is that normally designed call setup should
> take 2 RTT (offer, answer and connectivity check in offerer's direction,
> offerer's connectivity check response and connectivity check in answerer's
> direction, answerer's connectivity check response). Everything else is
> adding latency for the sake of bad desing.
> _____________
> Roman Shpount
>
>

Received on Friday, 22 June 2012 18:56:14 UTC