WiSE Video: using in-band wireless loss notification to improve rate-controlled video streaming

1. WiSE Video:using in-band wireless loss notification to improve rate-controlled video streaming A. Markopoulou, E. Setton, M. Kalman, J. Apostolopoulos To appear in IEEE ICME 2004

2. Outline • WiSE Mechanism • WiSE Video • Simulation Results

3. Outline • WiSE Mechanism • WiSE Video • Simulation Results

4. M-ECN • opportunistic signaling, using bits of the IP header that are lightly utilized • Capacity of ECN “channel” • Stengths: no overhead, no dedicated packet fields, incrementally deployable • Limitations: low rate, delay … M-ECN • Network to higher layers signaling needed • E.g. signal congestion, announce available BW etc… • Ways to signal: ICMP, dedicated bits, …

5. wired wireless 1 2 3 WiSE: Wireless Signaling via ECN • TCP over wireless • Should not backoff in case of wireless loss • Wireless loss notification for TCP • Distinguish congestion from wireless losses • Avoid backing off in case of wireless loss • Many approaches [ELN, ETEN, …] • WiSE: • Use M-ECN to signal corruption vs. congestion • WiSE-Agent on router and WiSE-TCP to decode

6. Outline • WiSE Mechanism • WiSE Video • Simulation Results

7. … GOP … time I1 P2 P3 P12 P10 I11 Video Streaming • Characteristics: stream traffic, dependencies • Require: low loss and low delay • Rate-control • needed to react to congestion • rate-based vs. window-based

8. Rate Control Schemes considered • HTTP streaming • One description stored, sent over TCP • [TCP friendly] • Compute TCP friendly rate • Adjust parameters (Q,fps) to meet it • E.g. [RAP: Reja et.al], [Zakhor et.al], … • Switch Stream (SSRC) • Receiver sends feedback • Sender switches (at GOP borders) to • lower rate during congestion • higher rate otherwise TCP friendliness Natural to Video

9. Video over wireless • Problems in wireless • High values of loss and delay • High variability in loss and delay • Corruption can be misinterpreted as congestion • Solution: proxies, explicit messages • WiSE can help: • To distinguish congestion from corruption • In rate control: to avoid unnecessary decreases • In error resilience: to retransmit fast

10. Outline • WiSE Mechanism • WiSE Video • Simulation Results • Topology • Streaming 1: SSRC • Streaming 2: HTTP

11. Interfering traffic bottleneck WiSE Agent Wireless Link Video stream Video Source Playout buffer Video Rcvr n0 n1 n2 n3 n5 n4 Simulation Scenario • Topology • Links: wired (10Mbps, 10ms), wireless (1.1 Mbps, 100ms) • Congestion Loss: due to interfering traffic (FTP and HTTP) • Wireless Loss: model (bernoulli, bursty), rates 0-10%

12. Video Streaming Details • Foreman sequence • 10sec, 30fps, QCIF, H.264, GOP=15 (1I:14P), UDP/RTP • Streams of various rates are pre-stored • Switching among streams • only allowed at GOP borders • dictated by rate control scheme

13. SSRC Receiver If sequence gap, then send a NACK Sender If NACK received, then switch one stream lower Otherwise (and no NACK or increase recently), switch one stream higher WiSE SSRC Receiver If sequence gap, read WiSE message, send NACK + cause (congestion, corruption) Sender If congestion NACK, then switch one stream lower If corruption NACK, then retransmit + do not switch Otherwise (and no NACK or increase recently), switch one stream higher Rate Control 1: Switch Stream (SSRC)

14. SSRC vs. WiSE SSRC- an example

15. Quality metric: avg PSNR (dB) Demo (1) : SSRC vs. WiSE-SSRC • Scenario: No congestion, 4% bernoulli wireless loss • Improvement: better quality pictures, less freezes, 8dB

16. SSRC vs. WiSE SSRC – Bernoulli Wireless Loss

17. SSRC vs. WiSE SSRC- Bursty Wireless Loss

18. wired wireless 1 2 3 SSRC vs. WiSE SSRC - all (wireless, wired) losses wireless loss % wireless loss % wired loss % wired loss % SSRC: 31..22dB WiSE-SSRC: 36 ..28dB

19. TCP Receiver send ACKs Sender If congestion, then retransmit and half the window Otherwise (no congestion for some time), then increase WiSE TCP Receiver Send ACKs with echo set (WiSE marks) Sender If drop, then decode WiSE If congestion, then retransmit + half the window If corruption, then retransmit but do not half the window Otherwise (no congestion for sometime), then increase Rate Control 2: HTTP streaming • Video description #1 only. Viewed as a file to transfer • No notion of video-specifics, GOP, etc

20. TCP vs. WiSE TCP - an example • Video description #1, 200sec • wireless loss: 0.6% bursty • congestion: interfering long FTPs

21. TCP vs. WiSE TCP

22. Demo (2): TCP vs. WiSE TCP • With congestion, 2% wireless loss • Improvement: (much) less freezes

23. Conclusion • WiSE improves the quality of rate-controlled video over wireless, for a wide range of conditions • Further applications of network-to-application signaling ? • E.g. playout buffer, monitoring paths • Limitations • How much info? • How fast? (video: 30fps, WiSE: multiple packets for 1 bit, perceptible delays: ~150ms) • Compared to e2e?