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

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.

On Wed, May 1, 2013 at 4:46 AM, Roy, Radhika R CIV USARMY (US) <
radhika.r.roy.civ@mail.mil> wrote:

> 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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of
> Karl Stahl
> Sent: Wednesday, May 01, 2013 7:12 AM
> To: 'Cullen Jennings (fluffy)'; 'Harald Alvestrand'
> Cc: rtcweb@ietf.org
> 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: 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 :-)
>
>
>
>
>
>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>