Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb

RTT is round trip time, isn’t it? Our 250 ms was just one way – so same finding.

Satellite links do certainly add lots of delay – speed of light again.

/Karl

Från: Justin Uberti [mailto:juberti@google.com] 
Skickat: den 1 maj 2013 18:01
Till: Karl Stahl
Kopia: Cullen Jennings (fluffy); Harald Alvestrand; rtcweb@ietf.org
Ämne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb

This doesn't match what we are seeing. I pulled some Chrome stats on average RTT seen across various network connections; on 3G, close to half of users had RTTs > 250 ms. 4G is somewhat better. 2G is considerably worse.

India continues to be especially bad, partially because of the above, partially because of use of satellite links, which due to physics incur 500 ms RTTs.

On Wed, May 1, 2013 at 4:12 AM, Karl Stahl <karl.stahl@intertex.se> wrote:

Regarding delays...

Today, packets over the Internet reach any point on the earth within 250 ms
as Cullen found - There are simply nowhere packet are stored/buffered in any
amount to give higher delays (Where would Gbps be stored for a second?).
Routers drop packets at congestion, they don't store them (and light takes
140 ms for a turn around the earth, somewhat slower in a fiber).

So, the problem with voice/video quality (if overall bandwidth for the
RTP/UDP is sufficient and up) is only dropped packets, which "only" happens
at congestion points where the pipe gets filled by TCP data (surf, email,
file transfer), when TCP end-points regulate down to share the pipe in their
hunger for infinite transfer speed. Then both TCP and RTP/UPD packets are
dropped as a consequence of intense TCP-flows initiation. (The static
situation is ok - no packets are dropped)

Second long packet delays must come from retransmission of lost packets. If
DTLS, it must be a higher level retransmission, I believe.

Questions:

1) Does DTLS take long time to set up in itself in the browser (Aren't self
signed certificate generated and exchanged?) while SRTP/DES is less CPU
intense with ready certificate over the signaling path (I think)? But is
this significant on let's say a 1 GHz smartphone which would be the lowest
CPU power to consider?

2) Are packet drops during TLS-setup more likely over the UDP channel
between browsers (as for DTLS) than over the signaling channel (for
SRTP/DES). And are there more packets that safely need to arrive with DTLS
setup?

3) SRTP/DES setup rely on TCP retransmission if packets are lost (correct me
if I am wrong), while DTLS must rely on some other higher level
retransmission mechanisms. Are there longer timers involved then? I think
this may be the real explanation for reports of slow DTLS setup, isn't it?

The only cure against dropped UPD packets is IP-level QoS, such as traffic
shaping in firewalls/routers (but they need to be aware of traffic type) and
diffserv or reservation over the transport network- but that is (currently)
not enabled over the Internet, where all traffic is best effort class.

/Karl

-----Ursprungligt meddelande-----
Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Cullen
Jennings (fluffy)
Skickat: den 1 maj 2013 07:10
Till: Harald Alvestrand
Kopia: rtcweb@ietf.org
Ämne: [rtcweb] Network times … was SDP Security Descriptions (RFC 4568) and
RTCWeb

On Apr 29, 2013, at 2:29 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> Would it be possible to get real data on 1) and 2) here, so that we can
stop talking about "slow" and instead talk about "N milliseconds"?
>

I did try and round up a bunch of data for ping times from India to
Singapore as some people were suggesting these were 1500ms.

I got measurements from both home DSL and more business class from a range
of sources in India. It seems that anywhere one could run video, you can
ping any of Singapore, Tokyo, Boston, Palo Alto, and London in less than 250
ms one way. If someone has an actually link that is getting 1500 ms out of
India, I'd love to get the info so I can see what I can learn (the buffer
bloat folks want to hear about this :-)

_______________________________________________
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