CING-YU CHU 2012.08.06 INFOCOM 2012 Outline Introduction Measurement Measurement Results Modeling Skype Behaviors Analysis on TCP-friendly Motivation Skype VoIP service is well studied while video service is not Skype video service consumes more bandwidth Up to 950 kbps Imperative for network providers and network researchers Key Questions Q1: How does a Skype video call adapt its sending rate, video rate and quality under different network conditions? Q2: Are Skype video calls friendly to TCP flows when they compete for network resources? Methodology Measurement Black-box approach Different network setting with ○ configurable packet loss, ○ propagation delay ○ available bandwidth Aim to measure ○ sending rate ○ throughput ○ RTT ○ video bit rate ○ frame rate Methodology Modeling Rate control model FEC model Video quality model Analysis User back-off ○ User-level rate control scheme TCP-friendliness Contribution Measures Skype’s stationary behaviors of video calls Sending rate is insensitive to packet loss when PLR < 10% Utilization of the available bandwidth is around 80% Overly aggressive FEC scheme, 4.5 times the PLR Contribution Derive various models to verify User back-offs react fast to congestion Skype video calls are TCP-friendly ○ Due to quality-driven user back-offs Measurement Test-bed Experiment Design TV news video sequence “Akiyo” From Joint Video Team (JVT) Head and shoulder movements Virtual video camera tool Data collection TCP-dump Skype technical reports Skype Video Call On2 video codec Video quantization step Video resolution Number of frames per seconds (FPS) Measurements Results Impact of Packet Loss Available Bandwidth Propagation Delay Impact of Packet Loss PLR varies from 0% to 12% Propagation delay: 50ms 3 available bandwidth settings 250 kbps 750 kbps 1000 kbps Impact of Packet Loss Forward Error Correction Two states PLR < 10% => NORM state PLR >= 10% => CONS state Different from TCP congestion control scheme Impact of Available bandwidth Available Bandwidth varies from 50 kbps to 1000kbps Two PLRs: 2% and 10% Propagation delay: 50ms Impact of Propagation Delay Propagation delay varies from 50ms to 2000ms Available bandwidth: 500 kbps PLR: 0% Modeling Sending rate Video rate Video Quality Sending Rate Model NORM and CONS states 25 scenarios with PLR: 0% to 12% Available bandwidth: 50 kbps to 1000 kbps γ = 0.77, μ = -10.8 and δ = 21 Video Rate Model FEC ratio FEC ratio model Ψ = 0.15 and ω = 4.5 Video Quality Model ITU-T Recommendation G.1070 video rate frame rate Video Quality Model Frame rate model Video Quality Model a = 1.431, b = 0.02228, c = 3.759, d = 184.1, e = 1.161, h = 1.446 and g = 0.03881 Model Validation Co-current UDP traffic (from iPerf) 0 kbps to 600 kbps Link capacity: 700 kbps Propagation delay: 50ms Available bandwidth for Skype Model Validation Pearson Correlation Coefficient Sending rate Video rate Frame rate 0.9898 0.9831 0.9545 Analysis Q1: How Skype video call users respond to quality degradation resulted from network impairments? How effective user back-offs are as a user-level rate control scheme? Q2: What is the performance of a Skype video call when it competes with other Skype calls and TCP flows? Is Skype video call TCP-friendly? Network Model LTE wireless network Multiple TCP and Skype users M/M/1/K queue using drop-tail Downlink: 100 Mbps, uplink: 50 Mbps TCP Model Reacts to packet loss and RTT p = pq + pc t = tq + tc User-level Rate Control Video drop-off probability Number of active users Effective traffic generated by all users User-level Rate Control Average traffic of each user Expected Skype sending rate Responsiveness to Loss Responsiveness to Delay Competition with TCP pc = 2% and tc = 50ms NT = # of TCP users, NS = # of Skype users Aggregate traffic For each Skype user Competition with TCP Scale-up factor: k Conclusion Measures Skype video traffic Shows that Skype is robust against mild packet loss and propagation delay Skype can efficiently utilize available bandwidth Models Skype video behaviors Shows that Skype video is indeed TCPfriendly Based on user back-off rate control scheme Q&A