PowerPoint Presentation - Route Injection and the

Network QoS from RTP
Jim Warner
University of California, Santa Cruz
[email protected]
Internet 2 Techs
February 13, 2007
1
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.
2
RTP services
•
•
•
•
•
•
•
Transport for audio and video
Timing recovery
Source synchronization
Jitter estimation
Loss detection
Payload and source ID
Member ID
3
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
4
Other similar acronyms…
• RTSP
• RDT
• RTCP
Real Time Streaming Protocol
RealNetworks Data Transport
Real-Time Control Protocol
part of RTP, not a separate thing
5
RTP provides:
• Synchronization source identification
• Payload type ID
• Packet sequence numbers for loss
detection
• Timestamp (playback time and jitter
measurement)
6
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
7
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
8
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)
|
9
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.
10
Packets lost
24 bit report from the far end of dropped
packets based on holes in the sequence
number space.
11
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)
|
12
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.
13
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.
14
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]
15
Jitter from queuing example
16
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.
17
More extreme example
Cogent Dulles, 2/10/07
18
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…
19
RtpRcvrEntry ::= SEQUENCE
...
rtpRcvrRTT
rtpRcvrLostPackets
rtpRcvrJitter
rtpRcvrRRs
rtpRcvrRRTime
rtpRcvrPackets
rtpRcvrOctets
rtpRcvrStartTime
Gauge32,
Counter64,
Gauge32,
Counter32,
TimeStamp,
Counter64,
Counter64,
TimeStamp
20
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:
21
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.
32