Transmitting Scalable Video over a DiffServ network EE368C Project Presentation Sangeun Han, Athina Markopoulou 3/6/01

Project Proposal Problem: Facts: Proposal Video transmission over the heterogeneous Internet Facts: Scalability: different parts of a video stream contribute unequally to the quality. DiffServ Networks can provide service differentiation, based on the marking of packets. Proposal Limit the effect of loss when it happens. Prioritize information according to importance and drop packets accordingly.

Specifics What type of scalability? H.263+, SNR Which DiffServ class? AF (priority dropping) EI EP EP EL EP BL I P P P conditioning classification AF11

Simulation scenario Single AF queue, 2 levels, 100KB 1.5Mbps Main stream: Foreman (10fps) 136Kbps, BL+EL, 2min 10-20 Interfering Streams BL+EL~=136Kbps random parts of 6 different streams Single AF queue, 2 levels, 100KB 1.5Mbps H.263+ Encoder + Layering RTP Packet. for H.263 (*) Depackt. Decoding+ [Error Conceal.] (**) Marker Loss info (*) Mode A: at frame level, Total header= IP(20)+UDP(8)+RTP(12)+H.263(4)=44B Original Stream (**) Freezing previous frame

Objective of the Project Show the benefit from using Priority Dropping for Scalable Video MUX gain Graceful Quality Degradation Handle short term congestion Configuration AF queue: buffer management, thresholds, other parameters Layering parameters base layer, temporal dependence Recommendation To Feedback or to Drop?

MUX gain Layered+PD Nonlayered

Graceful degradation with loss FGS + data loss NL, no loss Layered+loss Non Layered + loss

Short Term Congestion The source may react to congestion by adapting its transmission rate... Congestion time Rate BL EL D Reaction with no delay D=0 Reaction with Delay D>0 R

Reaction time vs.congestion duration Simple example: 10 streams + 5 more in [55sec,65sec] 10 streams react by dropping their EL in [55+D, 65+D]

Heavier congestion Heavy + non adaptive interfering traffic: 10 streams + 10 more in [55sec,65sec] 10 streams react by dropping their EL in [55+D, 65+D]

Priority dropping vs Feedback is limited by delay saves network resources requires coordination Priority Dropping is like reaction in D=0, by appropriate rate decrease may handle non adaptive sources Congestion time Rate BL EL R(t)

Configuration of AF queue Low drop Drop prob High drop Buffer occupancy 1 BL - low drop precedence EL - high drop precedence L_min L_max H_min,max Choices: Thresholds for the different priorities Buffer management: RED or DropTail? Observations: Not sensitive to choice of thresholds RED inappropriate: do not use Avg Qsize, set Lmin=Lmax Differentiation: (I) different thresholds (II) Occupancy

RED worse than DropTail For all loads…. and …for all thresholds

Threshold for EL(HP) By assigning the buffer thresholds we control the Queue Occupancy for BL, EL Threshold_HDP = 56 Threshold_HDP = 16

Threshold for EL(LP) …this way we distribute the loss among BL and EL ….and thus the quality Insensitive to: RED, DropTail BL choice [more sensitive to load]

Effect of BL (I): on quality degradation QP(BL)=12, 1:1, (BL=64kbps:EL=74kbps) QP(BL)=15, 1:2, (BL=50kbps:EL=86kbps) QP(BL)=30, 1:4, (BL=27kbps:EL=110kbps) Same target rate: BL+EL~=136kbps

Effect of BL (II): on thresholds QP(BL)=12, 1:1, (BL=64kbps:EL=74kbps) QP(BL)=15, 1:2, (BL=50kbps:EL=86kbps) QP(BL)=30, 1:4, (BL=27kbps:EL=110kbps) Same target rate: BL+EL~=136kbps

Transmission of Scalable Video Use feedback + adaptation at the source to match the transmission rate with the bottleneck bandwidth, to save network resources along the path Use Priority Dropping to handle short term congestion Quality Feedback BL2 BL1 PD Rate loss

Future work Improvements needed New experiments needed realistic feedback + adaptation >2 layers finish FGS New experiments needed Delay aspect: Loss at the playback buffer Entire streams having different delay requirements Multiple hops Single wireless hop (802.11 + QoS) Video + Data Larger Bandwidths Other types of scalability: FGS, Temporal, Spatial, DP