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

From: "Karl Stahl" <[email-masked]>
Date: Wed, 1 May 2013 13:12:19 +0200

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: [email-masked] [mailto:[email-masked]] För Cullen
Jennings (fluffy)
Skickat: den 1 maj 2013 07:10
Till: Harald Alvestrand
Kopia: [email-masked]
Ämne: [rtcweb] Network times … was SDP Security Descriptions (RFC 4568) and
RTCWeb

On Apr 29, 2013, at 2:29 AM, Harald Alvestrand <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Tim Panton <[email-masked]>
Date: Wed, 1 May 2013 12:41:47 +0100

> not enabled over the Internet, where all traffic is best effort class.

If we are seeing variability in DTLS setup times that don't seem to be justified 
by ping times it may be due to MTU issues.

DTLS has some rules (which I don't yet clearly understand) about how much
one can stuff into a packet based on an assumed/derived/calculated MTU. 
Guess too high and your packet will be dropped - forcing a retry with the data
broken over multiple packets. 

I suspect we may have a little learning to do in the implementations to select
an optimum MTU for the wild internet.

In these cases I'm sure packet captures set to the implementors would be most welcome.

Tim.

---

From: "Roy, Radhika R CIV USARMY (US)" <[email-masked]>
Date: Wed, 1 May 2013 11:46:31 +0000

Classification: UNCLASSIFIED
Caveats: NONE

Folks:

I am responding only on a part of this email about retransmissions of audio
or video packets.

Let us not consider the retransmission of audio or video packets. Let us
consider audio or video packets are sent only over UDP. Let MOS/QoS of audio
or video are considered in a way that retransmissions do not take place.

Then the question comes only about "data" traffic retransmissions. Data
traffic can tolerate much higher delays than that of audio or video. Data
has only QoS (and no MOS).

Let us divide the performance problems in two different parts.

In this case, we can have more focused solutions related to (Audio/Video)
MOS/QoS or (Data) QoS as explained above.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Karl Stahl
Sent: Wednesday, May 01, 2013 7:12 AM
To: 'Cullen Jennings (fluffy)'; 'Harald Alvestrand'
Cc: [email-masked]
Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC
4568) and RTCWeb

Regarding delays...

Questions:

/Karl

-----Ursprungligt meddelande-----

Classification: UNCLASSIFIED
Caveats: NONE

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 1 May 2013 13:39:03 +0000

> an optimum MTU for the wild internet.

How are you doing the MTU stuff? Just the openssl default or something else?

---

From: Justin Uberti <[email-masked]>
Date: Wed, 1 May 2013 09:01:25 -0700

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.

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 1 May 2013 18:18:12 +0200

> this may be the real explanation for reports of slow DTLS setup, isn't it?
In case of message loss of DTLS handshake messages, DTLS retransmits them.
Similar to what TCP would do timer based.

Best regards
Michael

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 1 May 2013 20:10:06 +0200

Just to clarify:
DTLS setup/key exchange goes over the UDP "voice/video channel".
/Karl 

-----Ursprungligt meddelande-----
Från: Roy, Radhika R CIV USARMY (US) [mailto:[email-masked]] 
Skickat: den 1 maj 2013 13:47
Till: Karl Stahl; 'Cullen Jennings (fluffy)'; 'Harald Alvestrand'
Kopia: [email-masked]
Ämne: RE: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568)
and RTCWeb (UNCLASSIFIED)

Folks:

BR/Radhika

-----Original Message-----

Regarding delays...

Questions:

/Karl

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 1 May 2013 20:13:34 +0200

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:[email-masked]] 
Skickat: den 1 maj 2013 18:01
Till: Karl Stahl
Kopia: Cullen Jennings (fluffy); Harald Alvestrand; [email-masked]
Ä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.

Regarding delays...

Questions:

/Karl

---

From: Randell Jesup <[email-masked]>
Date: Wed, 01 May 2013 11:18:32 -0700

> has only QoS (and no MOS).

It may not have MOS per-se, but unreliable data channels have equivalent 
issues - think of a first-person realtime game - unreliable 
position/state updates of the user and the world mean that what data is 
lost (and how much data is delayed but received) has a very strong 
impact on the user's perception of the world.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Wed, 01 May 2013 11:30:27 -0700

On 5/1/2013 9:01 AM, Justin Uberti wrote:
> 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.
>
> partially because of use of satellite links, which due to physics 
> incur 500 ms RTTs.

Those are all RTT measurements, so One Way Delay's of roughly half of 
that?  speed-of-light for a one-way satellite link would be around 280ms 
in theory - and of course that's just for that one physical link.

-- 
Randell Jesup
[email-masked]

---

From: "Roy, Radhika R CIV USARMY (US)" <[email-masked]>
Date: Wed, 1 May 2013 19:02:22 +0000

Inline [RRR]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Randell Jesup
Sent: Wednesday, May 01, 2013 2:19 PM
To: [email-masked]
Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC
4568) and RTCWeb (UNCLASSIFIED)

On 5/1/2013 4:46 AM, Roy, Radhika R CIV USARMY (US) wrote:
> I am responding only on a part of this email about retransmissions of 
> audio or video packets.
>
> Let us not consider the retransmission of audio or video packets. Let 
> us consider audio or video packets are sent only over UDP. Let MOS/QoS 
> of audio or video are considered in a way that retransmissions do not take
place.
>
> Then the question comes only about "data" traffic retransmissions. 
> Data traffic can tolerate much higher delays than that of audio or 
> video. Data has only QoS (and no MOS).

It may not have MOS per-se, but unreliable data channels have equivalent
issues - think of a first-person realtime game - unreliable position/state
updates of the user and the world mean that what data is lost (and how much
data is delayed but received) has a very strong impact on the user's
perception of the world.

[RRR] Yes, we need to have NEW threshold of delays (RTT) for data
performance.
--
Randell Jesup
[email-masked]

---

From: Justin Uberti <[email-masked]>
Date: Wed, 1 May 2013 13:35:40 -0700

There are several scenarios where retransmission of video, and possibly
audio, makes a lot of sense. If you have a low RTT to a server that can
retransmit a packet for you, this is by far the most efficient way to
repair a packet loss in a video stream.

The same can also be true for audio, especially in a LAN scenario (e.g.
AirPlay).

This does not mean it's appropriate for every situation, but we need to
provide retransmission as one of the tools to handle these situations.

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 1 May 2013 23:28:48 +0200

Correct, a geostationary satellite link adds minimum 240 ms of delay. That
would add 500 ms roundtrip which is bad for RTC (i.e. two way
communication). I would call it an Internet data-only access (which of
course is fine for streaming video though, that is one way, and can
retransmit using TCP and where a small extra delay doesn't matter). We
should not confuse. RTC is two way, and more than 500 ms round trip delay or
so, must be considered "not an RTC Internet access".

Narrow band access also adds delay. A 250 kbps 2G, 3G, or ADSL upstream
takes 50 ms to get a 1.5 kbyte Ethernet packet through. With a few packets
queued up, your voice packet may get 200 ms added if not prioritized in that
queue (which it is not over best-effort Internet).

So there are delays - and all accesses are not good enough for RTC.
 
Then we have packet loss is addition. There are tolerance in audio packet
loss (better with some codecs) and telephony 3.5 kHz voice is not hard to be
better than.

But WebRTC in itself allows teleprecense HD quality! Do we need loss-less
RTP transfer to utilize that over data crowded Internet access? We cannot
retransmit due to delay - Only IP-QoS, level 3 traffic shaping in congestion
points and diffserv or reservation gives loss-less RTP.

(A deviation from the DTLS delay question it started with, but
interesting...)

/Karl

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För Randell
Jesup
Skickat: den 1 maj 2013 20:30
Till: [email-masked]
Ämne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568)
and RTCWeb

> partially because of use of satellite links, which due to physics 

Those are all RTT measurements, so One Way Delay's of roughly half of that?
speed-of-light for a one-way satellite link would be around 280ms in theory
- and of course that's just for that one physical link.

--
Randell Jesup
[email-masked]

---

From: Bo Burman <[email-masked]>
Date: Thu, 2 May 2013 08:18:29 +0000

I agree that delay-limited retransmission can be an appropriate functionality also for media. Definitely for video, but maybe also for audio. I expect that actual loss and delay requirements will depend on how media (WebRTC) is used in the specific application use case, making it hard to set one single delay requirement.

For SRTP traffic, would not RFC 4588 (RTP retransmission) provide a good start, especially since you can set a maximum feasible (re-)transmission delay limit on a per-call and per-media basis in the SDP?

/Bo B

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roy, Radhika R CIV USARMY (US)
> Sent: den 1 maj 2013 21:02
> To: Randell Jesup; [email-masked]
> Subject: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568) and RTCWeb (UNCLASSIFIED)
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Randell Jesup
> It may not have MOS per-se, but unreliable data channels have equivalent issues - think of a first-person realtime game -
> unreliable position/state updates of the user and the world mean that what data is lost (and how much data is delayed
> but received) has a very strong impact on the user's perception of the world.
> 
> [RRR] Yes, we need to have NEW threshold of delays (RTT) for data performance.
> --
> Randell Jesup
> [email-masked]
> 
> 
> 
>

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 2 May 2013 10:41:56 +0200

If we discuss two-way communication as with RTC, retransmission of media is
not a way forward!
We are already at around 500 ms round trip delay, which is close to the
tolerable limit for a conversation.

If you are thinking of streaming one-way media, that can (and do) use TCP
since a few seconds delay is no problem. That is not RTC.

/Karl

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För Bo Burman
Skickat: den 2 maj 2013 10:18
Till: [email-masked]
Ämne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568)

I agree that delay-limited retransmission can be an appropriate
functionality also for media. Definitely for video, but maybe also for
audio. I expect that actual loss and delay requirements will depend on how
media (WebRTC) is used in the specific application use case, making it hard
to set one single delay requirement.

For SRTP traffic, would not RFC 4588 (RTP retransmission) provide a good
start, especially since you can set a maximum feasible (re-)transmission
delay limit on a per-call and per-media basis in the SDP?

/Bo B

> > I am responding only on a part of this email about retransmissions 
> > of audio or video packets.
> >
> > Let us not consider the retransmission of audio or video packets. 
> > Let us consider audio or video packets are sent only over UDP. Let 
> > MOS/QoS of audio or video are considered in a way that 
> > retransmissions do not take
> place.
> >
> It may not have MOS per-se, but unreliable data channels have 
> equivalent issues - think of a first-person realtime game - unreliable 
lost (and how much data is delayed but received) has a very strong impact on
the user's perception of the world.
performance.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 2 May 2013 10:45:25 +0200

> If we discuss two-way communication as with RTC, retransmission of media is
When discussion retransmission of media you have to separate audio,
video and other types of media. For audio, it doesn't really help. For video
it might prevent a full frame update request, which is a good thing.

/O

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 2 May 2013 10:55:45 +0200

-----Ursprungligt meddelande-----
Från: Olle E. Johansson [mailto:[email-masked]] 
Skickat: den 2 maj 2013 10:45
Till: Karl Stahl
Kopia: Olle E. Johansson; 'Bo Burman'; [email-masked]
Ämne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 4568)

2 maj 2013 kl. 10:41 skrev "Karl Stahl" <[email-masked]>:

> If we discuss two-way communication as with RTC, retransmission of 
> media is not a way forward!
When discussion retransmission of media you have to separate audio, video
and other types of media. For audio, it doesn't really help. For video it
might prevent a full frame update request, which is a good thing.
[KS] Having video out of sync with voice, a bit later you mean?

/O
> We are already at around 500 ms round trip delay, which is close to 
> the tolerable limit for a conversation.
> 
> If you are thinking of streaming one-way media, that can (and do) use 
> TCP since a few seconds delay is no problem. That is not RTC.
> 
> /Karl
> 
> 
> Ämne: Re: [rtcweb] Network times . was SDP Security Descriptions (RFC 
> audio. I expect that actual loss and delay requirements will depend on 
> how media (WebRTC) is used in the specific application use case, 
> making it hard to set one single delay requirement.
> 
> For SRTP traffic, would not RFC 4588 (RTP retransmission) provide a 
> good start, especially since you can set a maximum feasible 
> (re-)transmission delay limit on a per-call and per-media basis in the
SDP?
>> equivalent issues - think of a first-person realtime game - 
>> unreliable position/state updates of the user and the world mean that 
>> what data is

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Thu, 02 May 2013 11:42:32 +0200

On 5/1/13 8:13 PM, Karl Stahl wrote:
>
> RTT is round trip time, isn't it? Our 250 ms was just one way -- so 
> same finding.
>
Were these measurements involving rtp relays, or just point to point 
transmissions?

Considering the amount of symmetric nat firewalls, even with ICE, a 
relevant number of RTC sessions will require a public relay, TURN server 
or similar (unless everyone will be on IPv6 at the time of production 
WebRTC deployments, which seems to have a chance looking at some debates 
or issues/patents related to several WebRTC decisions :-) ).

As a new technology cannot satisfy everyone, but if it does not work 
good enough for majority, it will end up in a series of patches that 
will complicate everything (remember sip-nat relation). It is easier to 
digest and sell improvements brought by future extensions (e.g., 
alternative session setup mechanism for better security) than 
specifications doing actually downgrades.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
   * http://asipto.com/u/katu *

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 2 May 2013 14:00:50 +0200

Rtp relays are fast routing devices that should not add even 1 ms to the
delay. 

At least our (Ingates) SBCs add no significant delay when carrying SIP
media.

But if there is a TURN server on the other side of the earth, you can get
additional delays of course.

The 250 ms were Cullen’s pings, not RTP measurements, but the delay should
be about the same.

/Karl

Från: Daniel-Constantin Mierla [mailto:[email-masked]] 
Skickat: den 2 maj 2013 11:43
Till: Karl Stahl; 'Justin Uberti'
Kopia: 'Cullen Jennings (fluffy)'; [email-masked]
Ämne: 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.

Considering the amount of symmetric nat firewalls, even with ICE, a relevant
number of RTC sessions will require a public relay, TURN server or similar
(unless everyone will be on IPv6 at the time of production WebRTC
deployments, which seems to have a chance looking at some debates or
issues/patents related to several WebRTC decisions :-) ).

As a new technology cannot satisfy everyone, but if it does not work good
enough for majority, it will end up in a series of patches that will
complicate everything (remember sip-nat relation). It is easier to digest
and sell improvements brought by future extensions (e.g., alternative
session setup mechanism for better security) than specifications doing
actually downgrades.

Cheers,
Daniel

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 2 May 2013 14:02:27 +0200

/Karl

 

Cheers,
Daniel

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 2 May 2013 14:03:39 +0200

/Karl

 

Cheers,
Daniel

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 2 May 2013 14:45:29 +0200

/Karl

 

Cheers,
Daniel

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 02 May 2013 16:12:47 +0200

> DTLS setup/key exchange goes over the UDP "voice/video channel".

Now you've gotten me confused.

DTLS setup/key exchange goes via UDP packets.
These UDP packets are not sent over RTP (but I do expect them to use the 
same source and destination port numbers as the RTP streams).

I've always used "voice/video channel" (if I've ever used it) to mean RTP.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 May 2013 07:30:05 -0700

> I've always used "voice/video channel" (if I've ever used it) to mean RTP.

Just for maximum clarity, DTLS records go over UDP datagrams on the
same 5-tuple as the RTP and STUN packets (at least those corresponding
to the eventual RTP channel).

-Ekr

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Thu, 02 May 2013 16:48:13 +0200

On 5/2/13 2:45 PM, Karl Stahl wrote:
>
> Rtp relays are fast routing devices that should not add even 1 ms to 
> the delay.
>

By the 'routing device' do you mean some hardware based packet 
forwarding (e.g, done in the ethernet card) or an application doing the 
forwarding in user space?

> But if there is a TURN server on the other side of the earth, you can 
> get additional delays of course.
>
The point I wanted to make was that any new technology should not be 
designed for ideal cases, also not for worst cases, but to satisfy the 
majority of the possible users.

Daniel

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 2 May 2013 19:55:22 +0200

Yes, that was why I put it in within quotes.
I just wanted to make clear that DTLS setup/key exchange goes via UDP
packets. Those are NOT "normal data" that are error corrected/retransmitted
at that level (in ref to the previous email).
/Karl

-----Ursprungligt meddelande-----
Från: Harald Alvestrand [mailto:[email-masked]] 
Skickat: den 2 maj 2013 16:13
Till: Karl Stahl
Kopia: 'Roy, Radhika R CIV USARMY (US)'; 'Cullen Jennings (fluffy)';
[email-masked]
Ämne: Re: SV: [rtcweb] Network times . was SDP Security Descriptions (RFC
4568) and RTCWeb (UNCLASSIFIED)

> Ämne: RE: [rtcweb] Network times . was SDP Security Descriptions (RFC 
place.
> In this case, we can have more focused solutions related to 
> (Audio/Video) MOS/QoS or (Data) QoS as explained above.
>
> BR/Radhika
>
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Karl Stahl
> 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?).
> 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?
>
> 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.
> Från: [email-masked] [mailto:[email-masked]] För 
> Cullen Jennings (fluffy)
> Ämne: [rtcweb] Network times … was SDP Security Descriptions (RFC 
> 4568) and RTCWeb
>
>
> 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 :-)
>
>
>
>
>
>
>
>

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 2 May 2013 22:08:16 +0200

Skickat: den 2 maj 2013 16:48

By the 'routing device' do you mean some hardware based packet forwarding
(e.g, done in the ethernet card) or an application doing the forwarding in
user space?
[KS] Even without hw acceleration, and in user space, delays in packet
forwarding devices are not significant here. Our small embedded (264 MHz
ARM)  SIP E-SBC can carry 50 simultaneous G.711 calls with 20 ms voice
packets. That is 2500 packets each way, giving us 0.4 ms to handle each
packet – we do not buffer up packets, they are prioritized to go out first -
so that is the magnitude of delay introduced. And our big 3 GHz quad core
x86 machines handles 8000 simultaneous calls. We are talking 10 us per
packet (even in user space, which indeed is slower).

So, it not routers and RTP-relays that introduces delays. It is the distance
between them, slow access channels and the jitter buffers needed that
together make up the delays.

/Karl

Daniel

---

From: Dan Wing <[email-masked]>
Date: Thu, 2 May 2013 16:40:51 -0700

On May 2, 2013, at 7:48 AM, Daniel-Constantin Mierla <[email-masked]> wrote:

>> Rtp relays are fast routing devices that should not add even 1 ms to the delay.
> 
> By the 'routing device' do you mean some hardware based packet forwarding (e.g, done in the ethernet card) or an application doing the forwarding in user space?
> 
>> At least our (Ingates) SBCs add no significant delay when carrying SIP media.
>>  
>> But if there is a TURN server on the other side of the earth, you can get additional delays of course.
> The point I wanted to make was that any new technology should not be designed for ideal cases, also not for worst cases, but to satisfy the majority of the possible users.

https://developers.google.com/talk/libjingle/important_concepts#connections, 
  "This is because the data pathway can be either a direct connection (92% 
    of connection attempts can take place directly) or through a relay server 
    (8% of connection attempts require an intermediary relay server)." 

-d

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 2 May 2013 20:15:44 -0600

On May 1, 2013, at 12:30 PM, Randell Jesup <[email-masked]> wrote:

> Those are all RTT measurements, so One Way Delay's of roughly half of that?  speed-of-light for a one-way satellite link would be around 280ms in theory - and of course that's just for that one physical link.

By one way here, you mean up to the satellite link, then back down to the ground again which the satellite people often don't call one way but I agree it is the network latency measurement from browser to browser we are looking for. You are of course correct that, for geosync satellites that are at somewhere around 42,000 km up, we get around 240 to 280 ms depending on your relative location to the satellite. But, keep in mind the preferred satellites for this type of stuff are globalstar at 1400 km or iridium at less than 800 km which have way less latency than geosync. 

I'm still looking for the elusive 1500 ms.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 2 May 2013 23:01:05 -0700

Worldwide, a significant fraction of 2G and 3G mobile users experience RTT
> 1500 ms. I am not suggesting that we design for these extreme cases,
however.

On Thu, May 2, 2013 at 7:15 PM, Cullen Jennings <[email-masked]> wrote:

> that?  speed-of-light for a one-way satellite link would be around 280ms in
> theory - and of course that's just for that one physical link.
>
> By one way here, you mean up to the satellite link, then back down to the
> ground again which the satellite people often don't call one way but I
> agree it is the network latency measurement from browser to browser we are
> looking for. You are of course correct that, for geosync satellites that
> are at somewhere around 42,000 km up, we get around 240 to 280 ms depending
> on your relative location to the satellite. But, keep in mind the preferred
> satellites for this type of stuff are globalstar at 1400 km or iridium at
> less than 800 km which have way less latency than geosync.
>

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 3 May 2013 09:37:03 +0200

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För Cullen
Jennings
Skickat: den 3 maj 2013 04:16
Till: Randell Jesup
Kopia: [email-masked]
Ä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.

By one way here, you mean up to the satellite link, then back down to the
ground again which the satellite people often don't call one way but I agree
it is the network latency measurement from browser to browser we are looking
for. You are of course correct that, for geosync satellites that are at
somewhere around 42,000 km up, we get around 240 to 280 ms depending on your
relative location to the satellite. But, keep in mind the preferred
satellites for this type of stuff are globalstar at 1400 km or iridium at
less than 800 km which have way less latency than geosync. 

I'm still looking for the elusive 1500 ms. 
[KS] Such delays most likely come from packet drop and retransmission of key
exchange packets. If we regularly had that kind of delay over some channel,
it would be unusable for RTC anyway.

---

From: Henry Lum <[email-masked]>
Date: Mon, 6 May 2013 14:30:23 +0000

Chiming in late.

Speaking from a contact center perspective, a lot of calls are required to be recorded. In order to allow active recording (such as SIPREC), the contact center has to provide a media endpoint for bridging media so that a copy of the media can be created. The users will have to trust the contact center to handle the media anyways, and the media must be decrypted and re-encrypted by some media element within the contact center to perform recording. To me DTLS-SRTP-EKT does not provide any additional benefit over SDES for this type of use case.

Regards,
Henry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
Sent: April-26-13 9:57 AM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

On Apr 26, 2013, at 6:33 AM, Harald Alvestrand <[email-masked]> wrote:

> On 04/26/2013 03:16 PM, Tim Panton wrote:
>> 
>> On 26 Apr 2013, at 12:37, Iñaki Baz Castillo wrote:
>> 
>>> Such a solution requires a very expensive gateway. Good for vendors but bad for all the rest.
>>> 
>> 
>> I don't understand why the DTLS gateway would be so expensive. It is _exactly_ the same
>> (conceptually) as the ICE processing - you filter off a few UDP packets from the stream, do some
>> stuff, send replies then once you are happy you punt some dynamic settings back up to the (s)rtp
>> layer.
> 
> So you're saying that the gateway doesn't have to decrypt and re-encrypt the packets?

Correct - the gateway does not have to decrypt and re-encrypt the SRTP packets.  The gateway only has to interwork the signaling between SDES and DTLS-SRTP-EKT.  Such signaling interworking is necessary when the call is initially set up and when the SRTP key is changed (e.g., a new person joins a call using their own key, or the SRTP key is exhausted [pretty unlikely, even with video]).  This was summarized in http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf

> 
> I think EKT may be a problem, as Inaki pointed out, but I have less qualms about supporting DTLS and making it optional to use EKT on some calls than I have about mandating support for SDES.

-d

---

From: Dan Wing <[email-masked]>
Date: Mon, 6 May 2013 07:56:40 -0700

> Speaking from a contact center perspective, a lot of calls are required to be recorded. In order to allow active recording (such as SIPREC), the contact center has to provide a media endpoint for b…

Only DTLS-SRTP proves the call is actually to the call center (bank, stock broker, reservation company).  Security Descriptions cannot prove the call is actually to the call center.  That's a big difference in security to know the call is terminated at the call center (which does call recording or whatever it needs to do), versus trusting every SIP hop along the path to not record the media, not inject audio ("buy 100 shares" turned into "buy 100 thousand shares"), and to not lie about where media terminates.  Both can be recorded by the call center, which is one of the parties involved with the call.

-d

---

From: Henry Lum <[email-masked]>
Date: Mon, 6 May 2013 15:28:39 +0000

To clarify, the case where contact center does not control an endpoint recording a call, recording would happen on a media bridge (a SIP B2BUA) in the contact center. Using DTLS-SRTP can prove that it is a media bridge from the contact center while SDES does not as you pointed out. 

Does EKT provide any benefit in this case?

Henry

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: May-06-13 10:57 AM
To: Henry Lum
Cc: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

-d

---

From: Dan Wing <[email-masked]>
Date: Mon, 6 May 2013 08:38:47 -0700

> Does EKT provide any benefit in this case?

No, EKT doesn't provide strong identity unless the SRTP keying provides strong identity (e.g., MIKEY-RSA, DTLS-SRTP).

-d

---

From: Tim Panton <[email-masked]>
Date: Tue, 7 May 2013 09:49:38 +0100

> Speaking from a contact center perspective, a lot of calls are required to be recorded. In order to allow active recording (such as SIPREC), the contact center has to provide a media endpoint for b…

It can provide an identity benefit. A bank contact center can offer an x509 certificate (from a trusted CA) over the DTLS media stream. 
That's a big difference from the web server offering a cert over https - the channel that may be shared with the signalling channel, which in turn 
may have set up the media.

Direct assertion vs 2 uncertain hops.

Of course the utility of that depends on the combined UX of the browser chrome and the site, but at least it is possible...

There should perhaps be some extra chrome 'bling' if the cert that arrives over DTLS matches the HTTPS one that brought the signalling.

T.

---

From: Henry Lum <[email-masked]>
Date: Tue, 7 May 2013 14:55:38 +0000

Does the signalling and DTLS media stream need to use the same certificate or the certificates can be from the same organization right? The contact center gateway and the recording element would be different components and hence have different certificates from the same organization.

I agree it would be useful for a browser to warn the user that the media stream is coming from a different identity than the signalling if we agree that DTLS is the only transport.

Regards,
Henry

-----Original Message-----
From: Tim Panton [mailto:[email-masked]] 
Sent: May-07-13 4:50 AM
To: Henry Lum
Cc: Dan Wing; Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

T.

---

From: Dan Wing <[email-masked]>
Date: Tue, 7 May 2013 09:06:52 -0700

On May 7, 2013, at 7:55 AM, Henry Lum <[email-masked]> wrote:

> Does the signalling and DTLS media stream need to use the same certificate or the certificates

No, DTLS-SRTP does not require they have the same certificate.  It does require the certificate fingerprint be sent in call signaling (in the SDP a=fingerprint line), and that the certificate exchanged in DTLS match that fingerprint.  This binds the call signaling to the media.

-d

> can be from the same organization right? The contact center gateway and the recording element would be different components and hence have different certificates from the same organization.
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 May 2013 10:53:41 -0700

> No, DTLS-SRTP does not require they have the same certificate.  It does require the certificate fingerprint be sent in call signaling (in the SDP a=fingerprint line), and that the certificate excha…

That provides the "this is the call that I signaled" assertion.
Identity is provided separately.

As Tim points out, the certificate could be signed by a trusted CA and
contain identity information.  It might be the same identity as the
signaling channel, but it doesn't have to be the same private key.

Alternatively, identity could be provided by the generic IdP
mechanism.  Then the specific contents of the certificate are largely
irrelevant.

I wonder though.  Is there any point in discussing the advantages of
DTLS-SRTP on this thread?  We already agree that it is MUST implement.

Recording scenarios like this aren't especially interesting because
mostly they occur beyond the point at which peer identity
authentication occurs.  The gateway decrypts the media and sends it to
a recording point, or it just forwards it on with the necessary keys.
I doubt very much that the recording element would need to be
authenticated to the remote caller, unless recording is the only thing
you plan on doing.

---

From: Tim Panton <[email-masked]>
Date: Thu, 9 May 2013 09:58:20 +0100

> Does the signalling and DTLS media stream need to use the same certificate or the certificates can be from the same organization right? The contact center gateway and the recording element would be…

Yep, you are right - sloppy thinking on my part:
same identity != same certificate

In my view they should both identify themselves as secure.xyzbank.com - that doesn't mean the same certificate, just the same identity.
I'm less keen on writing rules that match mediaserver.xyzbank.com up with www.xyzbank.com  and presume that these are the same entity.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 May 2013 12:44:17 -0600

On May 6, 2013, at 8:56 AM, Dan Wing <[email-masked]> wrote:

> Only DTLS-SRTP proves the call is actually to the call center (bank, stock broker, reservation company). 

Uh, can you say a bit more about how DTLS-SRTP provides that?  The topic of how this is done and if it reduces to the same security as SDES has been controversial and would be good to get people understanding the issues her

---

From: Dan Wing <[email-masked]>
Date: Fri, 10 May 2013 15:48:47 -0700

On May 10, 2013, at 11:44 AM, Cullen Jennings <[email-masked]> wrote:

> Uh, can you say a bit more about how DTLS-SRTP provides that?  
> 

The certificate can be verified using an identity provider.  That can be a company like OneID, Facebook, a classic Certificate Authority, a privately-maintained list of previous certificates we used for that same identity (e.g., in my own addressbook, similar to the mechanism described by ZRTP), network notaries (similar to http://perspectives-project.org/notary-servers).  Identity can also be provided by the WEBRTC operator if the is sufficient (e.g., facebook can be the identity provider for facebook users).  The strength of this model is the identity provider can be anyone, so if a user wants to verify identity with a 3rd party, they can.

> The topic of how this is done and if it reduces to the same security as SDES has been controversial and would be good to get people understanding the issues her

Without separate identity, a bank or healthcare provider will be unable to certify their identity to a 3rd party (my local addressbook, Facebook, a network notary service, etc.).  Instead, their identity would be attested by whatever entity originates or terminates the RTCWEB session, and the user and the browser have no basis to build a stronger, more robust system to protect against such abuse.

-d