Cues for Congestion control in Interactive Multimedia

Summary of PhD Research.

Transcript

1. Introduction Congestion control for Multimedia Future Work A Rate-control Framework for RTP-based Multimedia Applications Varun Singh Comnet, Aalto University varun@comnet.tkk.fi May 23, 2012
2. Introduction Congestion control for Multimedia Future Work Classification of congestion cues based on their origin
3. Introduction Congestion control for Multimedia Future Work Congestion Control Requirements For Real Time Media Keep RTT low – means avoid queuing delay. Pre-buffer minimally: mainly for dejittering and A/V Sync. The algorithm must be fair to: (hard to define) Other real-time flows of the same kind. Short and long TCP flows. Deployable in a heterogeneous environment. TFRC is not applicable because it is oscillatory, which affects PSNR. This are is now emerging as a WG at the IETF.1 [BoF in July 2012] 1 http://www.ietf.org/iesg/evaluation/rmcat-charter.txt
4. Introduction Congestion control for Multimedia Future Work Unicast Video Communication Our Research so far Rate adaptation for conversational 3G Video; Singh V., Ott J., Curcio I., Proceedings of IEEE INFOCOM 2009. Rate-control for RTP-based multimedia applications; Singh V., Proceedings of IEEE WoWMoM 2011 (Poster). Rate-control for Conversational Video Communication in Heterogeneous Networks; Singh V., Ott J., Curcio I., Proceedings of IEEE WoWMoM 2012. Using FEC for Rate-control in Video Communication; Nagy M., Singh V., Ott J., Curcio I. — under preparation. Moving towards . . . Co-authoring a draft: Circuit-breaker for Unicast RTP Flows (http://tools.ietf.org/html/draft-perkins-avtcore-rtp-circuit-breakers) Implementing Google’s straw man algorithm and proposing solutions for the deficiencies. (http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion)
5. Introduction Congestion control for Multimedia Future Work Multipath RTP Features: Send media packets over multiple paths. At the receiver adapt playout delay to compensate for mismatched RTT. Based on reported path-characteristics vary media throughput on each path. Extend RTP and RTCP for enabling MPRTP. Scheduling Algorithm: CBR video is split over multiple paths. Paths with same RTT are grouped together. Further, sort paths in decreasing order based on T hroughput Delay . I-frames are sent on the path with highest T hroughput Delay . Path A Queue To Receiver Sender’s Buffer Fractional distribution based on Sublow reports Path B Queue
6. Introduction Congestion control for Multimedia Future Work MPRTP continues. . . Results Compared performance of scheduling to single path in different scenarios. Namely: Varying path char., subflows sharing a common bottleneck, WLAN + 3G, two 3G paths. Implemented in Gstreamer/x264, MPRTPLib and Dummynet/Netem. Additional header overhead: 1.3 kbps for media packets (@1Mbps), RTCP: 0.25 kbps (2-paths), 0.4 kbps (3-paths).
7. Introduction Congestion control for Multimedia Future Work Coverage Maps Figure shows coverage 2G–3G–4G between Las Vegas and Los Angeles. (from: http://www.wireless.att.com/coverageviewer/ Outages can be greater than the pre-buffer size (typically, 5 − 10s) http://m.youtybe.com streams over RTSP instead of HTTP.
8. Introduction Congestion control for Multimedia Future Work Using cues from a Coverage Map Server Coverage Map server collects information and uses K-means algorithm to group points within a neighborhood (10–100m). Streaming client queries the map server to seek out areas with poor coverage (lookahead) and sends throughput updates of areas it travels through. If it detects areas with poor coverage, the stream client either rate-switches to lower rate or pre-buffers the content. Implemented in: Gstreamer/x264, postgreSQL, web2py. Streaming   Client   Streaming   Client   Streaming   Client   Streaming   Server   Congestion  Map   Service   RTP Throughput Updates Look-ahead Request Available Throughput RTCP Streaming   Client  
9. Introduction Congestion control for Multimedia Future Work Results Throttle sending rate when there is enough time to pre-buffer. Rate-switch when there is too little time to pre-buffer. Rate-switch if the streaming client notices inconsistencies in the updates coming from the coverage map server. 0 500 1000 1500 2000 0 50 100 150 200 250 Throughput (kbps) a) No Adaptation 3G Link Receiver Rate 0 500 1000 1500 2000 0 50 100 150 200 250 Throughput (kbps) time (s) c) Rate Switching 0 500 1000 1500 2000 0 50 100 150 200 250 b) Omniscient 0 500 1000 1500 2000 0 50 100 150 200 250 time (s) d) Late Scheduling
10. Introduction Congestion control for Multimedia Future Work Framework