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 clock8 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 30 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 30 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, calculateits jitter as a comparison with the previouspacket. Take the exponentially decayingaverage 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

23

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 }

24

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.

25

But sadly, the release notes say

26

Bummer…

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

27

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

28

Audio vs video jitter

29

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.

30

Data from impaired session

31

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.

32

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.

SNMPWe 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.