1 / 32

Network QoS from RTP

Network QoS from RTP. Jim Warner University of California, Santa Cruz warner@ucsc.edu Internet 2 Techs February 13, 2007. RFC 1889 RTP: A Transport Protocol for Real-Time Applications (1996) Made obsolete by RFC 3550 [same title] (2003) These are STD standards track RFCs.

axl
Download Presentation

Network QoS from RTP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Network QoS from RTP Jim Warner University of California, Santa Cruz warner@ucsc.edu Internet 2 Techs February 13, 2007

  2. RFC 1889 RTP: A Transport Protocol for Real-Time Applications (1996) Made obsolete by RFC 3550 [same title] (2003) These are STD standards track RFCs.

  3. RTP services • Transport for audio and video • Timing recovery • Source synchronization • Jitter estimation • Loss detection • Payload and source ID • Member ID

  4. RTP is used for…. • VoIP • Internet radio • H.323 video conferencing • Multicast conferencing (mash, ip/tv…) • Vbricks (MPEG network encoders) RTP can send directly in UDP or it can be encapsulated in TCP

  5. Other similar acronyms… • RTSP Real Time Streaming Protocol • RDT RealNetworks Data Transport • RTCP Real-Time Control Protocol part of RTP, not a separate thing

  6. RTP provides: • Synchronization source identification • Payload type ID • Packet sequence numbers for loss detection • Timestamp (playback time and jitter measurement)

  7. RTP Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Timestamp is in units of media clock 8 KHz for voice, 90 KHz for video

  8. Real-Time Control Protocol (RTCP) • Monitors delivery of RTP packets • Feedback on quality via receiver reports • Info on timing for play out sync (lip-sync) • BYE packets for listener disconnects

  9. RTCP Receiver Report Packet Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| RC | PT=RR=201 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) |

  10. Fraction lost • Fraction lost has BP at left of 8-bit field • 0000 0001 means 0.4% loss • Calculated over the interval between last RTCP report and this report • RFC encourages use for fallback strategy. When far end sees too much loss this end should send less.

  11. Packets lost 24 bit report from the far end of dropped packets based on holes in the sequence number space.

  12. RTCP Receiver Report Packet Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| RC | PT=RR=201 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | fraction lost|cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) |

  13. Jitter calculation • Assume that packet ‘n’ arrives 80 ticks before its timestamp indicates it should play • The next packet ‘n+1’ arrives 70 ticks before its playout time • Then D(n,n+1) for this pair of packets is 10 ticks, taken as absolute value of the difference.

  14. Jitter con’t For each RTP packet that arrives, calculate its jitter as a comparison with the previous packet. Take the exponentially decaying average of the absolute value with a time constant 16 x Avg period. Jitter measurement does not require GPS quality clock synchronization.

  15. Why measure jitter? "The interarrival jitter field provides a second short-term measure of network congestion. Packet loss tracks persistent congestion while the jitter measure tracks transient congestion. The jitter measure may indicate congestion before it leads to packet loss. The interarrival jitter field is only a snapshot of the jitter at the time of a report and is not intended to be taken quantitatively. Rather, it is intended for comparison across a number of reports from one receiver over time or from multiple receivers, e.g., within a single network, at the same time. ... " [from RFC 3550]

  16. Jitter from queuing example

  17. Previous slide A half-duplex 40 Mb/s radio link (802.11a) to a remote facility sees moderate congestion from a 3 a.m. scheduled file transfer. Congestion is light and there is no packet loss. The picture is from smokeping that shows the dispersion of 20 RTTs as a black smudge.

  18. More extreme example Cogent Dulles, 2/10/07

  19. How can we get this stuff … • Another RFC – 2959 Real-Time Transport Protocol Management Information Base 1.3.6.1.2.1.10.87 /mgmt/mib-2/transmission/rtp Main table of sessions enumerates tables that hold RTP performance parameters Some interesting table entries…

  20. RtpRcvrEntry ::= SEQUENCE ... rtpRcvrRTT Gauge32, rtpRcvrLostPackets Counter64, rtpRcvrJitter Gauge32, rtpRcvrRRs Counter32, rtpRcvrRRTime TimeStamp, rtpRcvrPackets Counter64, rtpRcvrOctets Counter64, rtpRcvrStartTime TimeStamp

  21. Are we done yet …? • Polycom is a market leader for room video conference endpoints • UC Santa Cruz has a mix of new VSX7000 and older VS4000 systems • Web based configuration and management, one of the screens on the VS7000 looks like:

  22. Sample Polycom private MIB… polycomVSJitter OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "The current combined (audio/video) cumulative average jitter (in ms) when in an H.323 call." ::= { polycomViewStation 22 }

  23. Some observations • Object type for jitter should be GAUGE, not DISPLAY STRING • Combination of audio and video jitter together is not a good idea. We really want them separate.

  24. But sadly, the release notes say

  25. Bummer… Polycom has RTP information, and they are willing to share, but not via SNMP.

  26. Polycom’s plan: use telnet • ->advnetstats • Network Interface: NONE • IP Video Number: 128.114.xxx.xxx • ISDN Video Number: 1. • MP Enabled: KD5E-94DD-7C10-0000-0009 • H323 Enabled: True • FTP Enabled: False • HTTP Enabled: True • SNMP Enabled: True • ->call:0 tar:64 K rar:64 K tvr:352 K rvr:320 K • tvru:21 K rvru:177 K tvfr:30.0 rvfr:14.3 vfe 0 • tapl:136 rapl:142 taj:0 ms raj:26 ms tvpl:94 rvpl:62 • tvj:30 ms rvj:25 ms

  27. Audio vs video jitter

  28. Why Audio is better Video frames are not transmitted in the order that they play out. The codec flags the play time of each frame with its RTP timestamp. RTP sequence numbers are in order but cannot be used for jitter calc. This damages the assumption used to calculate the jitter. Audio frames are transmitted as they are generated, so less apparent jitter.

  29. Data from impaired session

  30. Polycom is not alone We connected to a Codian MCU and found that they do not send RTCP receiver reports. This is likely worse than Polycom since it means senders will not fall back to a lower transmission speed when network conditions warrant.

  31. What we want Full RTCP implementation is recommended but not required by the RFC. As customers, we want that feature, and we want fall-back in response to congestion. SNMP We want vendors to implement RFC2959 in addition to their private MIBs. We want R/O access to network stats and access list style protection for mgmt interface. R/W without R/O is a security risk.

More Related