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

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

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

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

IP (Internet Protocol) 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 link layer 802.11 driver physical layer 802.11 WLAN 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

Simplified sender/receiver communication video source video sink sender buffer receiver buffer Explain how the buffers influence jitter and latency Explain why it’s not usefull to use the sender buffer bigger than the receiver buffer Explain that the size of the receiver buffer is oftern limited and that for sake of lower latency we may want smaller buffers With smaller buffers more data will get lost That’s why we need to consider sending first of all what is most important. If we need to drop data, then we drop pieces which influence our quality least wireless interface (sender) wireless inerface (receiver) 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

Link layer approach Sender Application/ encoder TCP/IP stack MAC-level retries video stream driver/scheduler buffer IP packets TCP/IP stack Explain here what the MAC retries means, how it influences the fullness of the scheduler buffer, how the jitter occurs. 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

I BBPBBPBB(I) MPEG encoding GOP (group-of-pictures): Frame types: I, P, B Typical GOP structure and dependances: I BBPBBPBB(I) So, losing B frames is less undesirable than P frames. Same with P and I accordingly. Importance of a frame decreases in following order: I, P, B 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

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 application layer transport layer network layer 802.11 driver link layer IP (Internet Protocol) TCP, UDP/RTP MPEG en-/decoder packet scheduler physical layer 802.11 WLAN MPEG-packetizer 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

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

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 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

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 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

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 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

TCP-RTM receiver – “read-over-hole” technique Receiving application Too late to resend - acknowledge step2 step3 segment consumed by application segment received but not yet consumed by application skipped segment empty buffer ? re-request on dup-acks step1 snd_cwnd ! So, this is the main idea of the TCP-RTM. The situation depict here is a “bad-luck” situation. Our interest is to have no losses visible to application at all. The receiving application should read as late as possible in order to let the protocol to resend eventually lost segments. It should be very clear at this point what and why we are doing. 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

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 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

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

Recovery price Burst loss size, packets rto is doubled with every packet loss Burst loss size, packets Minimum latency to cover the losses, mS 1 70 2 260 3 220 4 700 5… -* 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 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

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 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

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

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

Further work Link-layer Protocol-layer creating math. model evaluation 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) 4-May-19 Sergei N. Kozlov, s.n.kozlov@tue.nl TU/e Informatica, System Architecture and Networking

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