On the Scalability of RTCP Based Network Tomography for IPTV Services Ali C. Begen Colin Perkins Joerg Ott
Content Distribution over IP Receivers Content Distributor Network A Transit Provider A Transit Provider B Content Provider Network Content Distributor Network B Content Servers Receivers 2
Broadcast IPTV = IP Multicast Various Transports Native IP multicast, MPLS, L2, optical SSM: Source Specific Multicast (RFC 4604/4607 2006) Receivers subscribe (S,G) channels to receive traffic only from source S sent to G Primarily introduced (by IETF) for IPTV like services Transport Challenges Packet loss Out of order delivery Packet duplication Despite all the challenges, it is crucial to continuously monitor the quality of experience for all viewers, locate the problems and fix them right away 3
Real Time Transport Protocol (RTP) http://tools.ietf.org/html/rfc3550 Basics First specified by IETF in 1996, later updated in 2003 (RFC 3550) Runs over any transport layer protocol (Typically over UDP) Runs over both unicast and multicast No built in reliability Main Services Payload type identification Sequence numbering Timestamping Extensions Basic RTP functionality uses a 12 byte header RFC 5285 defines an RTP header extension mechanism Control Plane RTCP Provides minimal control and identification functionality Enables a scalable monitoring functionality (Sender, receiver, extended reports) 4
RTP Transport of MPEG2 Transport Streams http://tools.ietf.org/html/rfc2250 V=2 P X CC M PT Sequence Number Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifiers... N 188 byte MPEG2 TS Packets MPEG2 TS Payload...... RTP Encapsulation 8 bytes RTP MPEG2 TS Payload UDP Encapsulation 20/40 bytes UDP RTP MPEG2 TS Payload IP Encapsulation IP UDP RTP MPEG2 TS Payload Default IP header size is 20 and 40 bytes for IPv4 and IPv6, respectively 5
IPTV Distribution and a Scalable Monitoring Architecture Distribution Source Distribution Source Media Source Media Source Core/Aggregation Network Feedback Target Feedback Target Access Access Home IP STBs join the respective multicast session(s) for the desired TV channel Unicast feedback from IP STBs are collected by the feedback targets 6
Four RTCP Flows, Two RTCP Loops Distribution Source Distribution Source Media Source Feedback Targets Source Reception quality reports reporting quality of the path from source to the feedback target and summarizing Feedback Target reception quality for receivers Feedback Target Receivers Forward control information to manage feedback rates Core/Aggregation Network Access Feedback Target Source Receivers Media Source Receivers Feedback Target Reception quality reports Forward control information for lip synchronization, to indicate liveness and to identify the source 7
The RTCP Reception Quality Reports RTCP Receiver Reports summarize the reception quality Timestamp of (and delay from) the last received sender report Highest sequence number seen so far Number and fraction of the lost RTP packets Estimate of the interarrival jitter RTCP Extended Reports (XR) provide Detailed transport level stats and application specific information about the RTP transport Several advantages over traditional and proprietary monitoring solutions RTCP XR framework is easily extensible to report on Packet level loss events, loss patterns, mean time between losses, loss durations, etc. Correlation engines identify, characterize and isolate the problems Audiovisual reception quality Effectiveness of the loss repair methods Loss repair methods can be adapted and improved depending on the network conditions Effectiveness of channel change acceleration 8
RTCP Extended Reports (XR) http://tools.ietf.org/html/rfc3611 V=2 P RC PT=RR=201 Length Fraction Lost SSRC of Packet Sender SSRC of Distribution Source Cumulative Number of Packets Lost Extended Highest Sequence Number Received Interarrival Jitter Last SR (LSR) Delay since Last SR (DLSR) V=2 P SC PT=SDES=202 Length SSRC/CSRC_1 CNAME=1 Length Canonical Name (MAC Address) V=2 P Rsvd. PT=XR=207 Length SSRC BT Type Specific Block Length Type specific Block Contents 9
The Feedback Target Receivers RTCP Feedback Loop Impact of Group Size on the Reporting Interval With 1316 byte RTCP packets, each receiver in a group of ~500 may send a report at every 50 seconds Media bandwidth is 4.2 Mbps (400 pps) and RTCP packet size is from 100 to 1316 bytes 10
The Feedback Target Receivers RTCP Feedback Loop Required Thinning Factor for Receipt Time Reports In a group of ~500, each receiver may report on one in every 128 packets at every 50 seconds Media bandwidth is 4.2 Mbps (400 pps) and RTCP packet size is 1316 bytes 11
The Source Feedback Targets RTCP Feedback Loop Required Thinning Factor for Receipt Time Reports With 1316 byte RTCP packets, each feedback target may report on one in every 256 packets at every minute in a feedback target population of 500 (a total population of 250K receivers) RTCP packet size is 1316 bytes 12
RTCP XR Example: Loss RLE Reports http://tools.ietf.org/html/draft ietf avt post repair rtcp xr RTP Receiver Source and repair data Pre repair Buffer Loss repair Methods #1, #2,, #K Post repair Buffer Received/recovered packets Application Pre repair Loss RLE (RFC 3611) Post repair Loss RLE The difference tells us the aggregated performance of the loss repair methods 13
Fault Isolation through Network Tomography To Appear in IEEE Network in H1 of 2010 RTP DS Aggregated RTCP RTP X 1 FT 1 X 4 FT 3 Unicast RTCP Unicast RTCP X 2 X 3 FT 2 X 5 X 6 R 1 R 2 R 3 R 5 R 6 H 7 R 8 H 4 R 41 R 42 R 71 R 72 14
Summary An IPTV system needs to continuously monitor the viewer quality of experience with little or no human assistance RTCP provides a scalable monitoring architecture with little network overhead The IPTV system needs to process the incoming reports to diagnose and isolate the problem(s) and inefficiencies Instrumenting RTCP at endpoints and strategic middle boxes Enables efficient data collection Allows fault isolation through network tomography 15
Questions