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

["Karl Stahl" <[e-mail]>]

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:[e-mail]] 
Skickat: den 2 maj 2013 16:13
Till: Karl Stahl
Kopia: 'Roy, Radhika R CIV USARMY (US)'; 'Cullen Jennings (fluffy)';
[e-mail]
Ämne: Re: SV: [rtcweb] Network times . was SDP Security Descriptions (RFC
4568) and RTCWeb (UNCLASSIFIED)

On 05/01/2013 08:10 PM, Karl Stahl wrote:
> Just to clarify:
> 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.

> /Karl
>
> -----Ursprungligt meddelande-----
> Från: Roy, Radhika R CIV USARMY (US) 
> [mailto:[e-mail]]
> Skickat: den 1 maj 2013 13:47
> Till: Karl Stahl; 'Cullen Jennings (fluffy)'; 'Harald Alvestrand'
> Kopia: [e-mail]
> Ämne: RE: [rtcweb] Network times . was SDP Security Descriptions (RFC 
> 4568) and RTCWeb (UNCLASSIFIED)
>
> 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: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Karl Stahl
> Sent: Wednesday, May 01, 2013 7:12 AM
> To: 'Cullen Jennings (fluffy)'; 'Harald Alvestrand'
> Cc: [e-mail]
> Subject: Re: [rtcweb] Network times . was SDP Security Descriptions 
> (RFC
> 4568) and RTCWeb
>
> 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: [e-mail] [mailto:[e-mail]] För 
> Cullen Jennings (fluffy)
> Skickat: den 1 maj 2013 07:10
> Till: Harald Alvestrand
> Kopia: [e-mail]
> Ämne: [rtcweb] Network times … was SDP Security Descriptions (RFC 
> 4568) and RTCWeb
>
>
> On Apr 29, 2013, at 2:29 AM, Harald Alvestrand <[e-mail]>
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 :-)
>
>
>
>
>
>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>