Streaming video over wireless link

1. Streaming video over wireless link Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

2. Agenda • Main issues with streaming over wireless link • Link layer approach • Transport protocol approach (to be added) • Conclusions and future work Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

3. Video over wireless link • Typical scenario: video transmission from set-top box to the (mutiple) screens wireless Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

4. Video over wireless link (II) • Wireless link properties: • High losses • Low troughput • High jitter • Typical perceived quality issues: • Artefacts • “Hick-ups” Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

5. Techniques we look at OSI stack: application layer MPEG en-/decoder MPEG-packetizer transport layer TCP, UDP/RTP network layer IP (Internet Protocol) packet scheduler 802.11 driver link layer physical layer 802.11 WLAN Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

6. Simplified sender/receiver communication video source video sink sender buffer receiver buffer wireless interface (sender) wireless inerface (receiver) Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

7. Link layer approach Sender Application/ encoder MAC-level retries video stream driver/scheduler buffer IP packets TCP/IP stack Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

8. I BBPBBPBB(I) MPEG encoding • GOP (group-of-pictures): • Frame types: I, P, B • Typical GOP structure and dependances: • Importance of a frame decreases in following order: I, P, B Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

9. application layer MPEG en-/decoder MPEG-packetizer transport layer TCP, UDP/RTP network layer IP (Internet Protocol) packet scheduler 802.11 driver link layer 802.11 WLAN physical layer Scheduling of frames (I) • Packetizing • Assign prioritites to packets according to frame types: P(B) = 1 P(P) = 2 P(I) = 3 • Scheduling • Packets with higher priorities should get a better chance to be sent Involved layers Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

10. Scheduling of frames (II) • Scheduling algorithm (level of frames) buffered frame sent frame incoming frame Fi Fb Fs if P(Fi) >= P(Fb) Fb := Fi else Fi := 0 (discard Fi) Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

11. Advantages of link layer approach • We only need to modify the sending part • it will work with any terminals supporting RTP reception • it is an alternative to layered scalable video • it is very reactive against fast network fluctuations Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

12. Transport layer approach • If... • we don’t have direct access to the wireless interface • we don’t want to modify it • we want more reliability, than UDP/RTP does • ... then we would like to look at the tranport layer Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

13. TCP-RTM*: “semi-reliable” protocol • Combines retransmission abilities of TCP and non-blocking behavior of RTP • Retransmission mechanisms reused from TCP • Packets that cannot be delivered in timely fashion are being skipped • Application techniques resemble those for RTP (surveyed later) • Requires minimum of TCP-code modifications, can be implemented as another TCP-option * Sam Liang, David Cheriton, “TCP-RTM: Using TCP for Real Time Applications,” Submitted to IEEE ICNP ’02, 2002 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

14. Receiving application snd_cwnd step1 ? re-request on dup-acks Receiving application step2 ! Too late to resend - acknowledge Receiving application step3 segment received but not yet consumed by application empty buffer segment consumed by application skipped segment TCP-RTM receiver – “read-over-hole” technique Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

15. TCP-RTM – application techniques • Receiver application doesn’t read from the buffer until the data is needed for timely playback • this provides fixed play-back delay • timestamps are needed for this • TCP-RTM supports application-level framing (ALF) • one application frame per TCP-segment – hence, always integral application frames are lost • every application write/read operation deals with 1 application level frame • ALF helps effective recovery from the losses Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

16. Receiving application snd_cwnd step1 ? ? ? Receiving application step2 ? ? ? Receiving application re-send on rto step3 out-of-date received out-of-date segments empty buffer segments received but not yet consumed by application segments consumed by application TCP-RTM and burst losses Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

17. Recovery price • rto is doubled with every packet loss buf_size = 64K, frame_size=1K, frames sent every period=20mS Near-exponential dependency – congestion window doesn’t grow large enough to trigger the dup-ack retransmission * - TCP-buffer gets full Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

18. TCP-FCW vs TCP-RTM • TCP-RTM wasn’t meant to be used on burst losses networks • Losses of more than one segment in a row are not expected to happen • To be used on the real Internet • Be TCP friendly (use congestion avoidance) • TCP-FCW meets different assumptions • To be used on the QoS enabled networks with bandwidth reservations • “Send as fast as you can, but not faster than requested by the application” • Thus, we can control the bit-rate of the transmission on the application level • Provide “immediate recovery” – no slow start • It’s not meant to be used on the current Internet Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

19. Receiving application step1 ? ? ? Receiving application re-request – on dup-acks again step2 ! Receiving application resent step3 packet received but not consumed by application empty buffer skipped packet recovered packet packet consumed by application TCP-FCW: “free-congestion-window” Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

20. Evaluation • Result: exponential growth of latency in case of TCP-RTM vs linear growth in case of TCP-FCW Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

21. Further work • Link-layer • creating math. model • evaluation • Protocol-layer • combination TCP sender + TCP-RTM receiver • much higher bit-rates should become possible • the behavior of sliding window should be investigated • packetizing should be provided on the application level (i.e. by means of delimiters) • creating math. model • evaluation Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

22. Questions? Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking