- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Sun, 24 Jun 2012 14:55:23 +0200
- To: Justin Uberti <juberti@google.com>
- CC: Roman Shpount <roman@telurix.com>, public-webrtc@w3.org
- Message-ID: <4FE70E3B.7010700@alvestrand.no>
On 06/22/2012 08:55 PM, Justin Uberti wrote: > 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. And - chastising myself since I was the one who renamed the thread without transferring it - this being a protocol issue, it belongs in RTCWEB, not in WEBRTC.. > > 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 > <mailto:roman@telurix.com>> wrote: > > > On Fri, Jun 22, 2012 at 1:09 PM, Harald Alvestrand > <harald@alvestrand.no <mailto: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 Sunday, 24 June 2012 12:55:54 UTC