CSE679: Multimedia and Networking Multimedia applications Challenges TCP and UDP limitations Rate adaptation

Multimedia Applications Video-on-demand Near-video-on-demand Travel/training videos Interactive games Teleconferencing IP Telephony

Multimedia Application Classes Streaming Clients request audio/video files from servers and pipeline reception over the network and display Interactive: user can control operation (similar to VCR: pause, resume, fast forward, rewind, etc.) Delay: from client request until display start can be 1 to 10 seconds

Multimedia Application Classes (more) Unidirectional Real-Time similar to existing TV and radio stations, but delivery on the network Non-interactive, just listen/view Interactive Real-Time Phone conversation or video conference More stringent delay requirement than Streaming and Unidirectional because of real-time nature Video: < 150 msec acceptable Audio: < 150 msec good, <400 msec acceptable

Multimedia Requirements Guarantees Throughput and/or delay guarantees Audio requires loss/delay guarantees Interactive apps. require low delay CBR & VBR Variable bit rate places extra burden

Challenges to the Current Internet TCP/UDP/IP suite provides best-effort, no guarantees on expectation or variance of packet delay Streaming applications delay of 5 to 10 seconds is typical and has been acceptable, but performance deteriorate if links are congested (transoceanic) Real-Time Interactive requirements on delay and its jitter have been satisfied by over-provisioning (providing plenty of bandwidth), what will happen when the load increases?...

Challenges to the Current Internet (more) Most router implementations use only First-Come-First-Serve (FCFS) packet processing and transmission scheduling To mitigate impact of “best-effort” protocols, we can: Use UDP to avoid TCP and its slow-start phase… Buffer content at client and control playback to remedy jitter Adapt compression level to available bandwidth

TCP and Multimedia Reliable delivery not needed for multimedia Timely delivery more important than in-order delivery. Late packet can be thrown away TCP’s reliability gets in the way.

UDP & Multimedia Put flow control, congestion control into application. Retransmit if packet deadline not past Move on if packet deadline is past Don’t respond to Congestion Not a “nice” citizen. Possible to cause congestion collapse

Multimedia Delivery Even when using UDP, applications should respond to congestion end-to-end. Need to promote “nice” behavior or “TCP-friendly” behavior. Emerging applications shouldn’t kill the performance of “nice” applications.

TCP-Friendly Throughput of a TCP connection P: the packet size p: the lost probability of a packet Limit flows to TCP-style BW Don’t know RTT exactly Why should everyone follow this exactly? Monitoring individual flows difficult

Rate-based Adaptation Have a notion of allowed rate -adjust rate to avoid congestion - reduce rate before packet loss. Packet-pair: Send a pair of packets, watch the time separation of acks The delay between acks gives an indication of bottleneck BW

Packet-pair

Packet-pair Technique Timestamp packets on receipt - t1, t2 Inform sender d = t2 - t1, bottleneck BW = (d)/P, P = size of first packet.

Issues of Packet-pair With parallel transfers, both packets may arrive simultaneously at the receiver -inflating available BW Ack compression leads to incorrect BW estimation. Can it be improved by sending more packets? Possible to decouple rate adaptation and reliable delivery

Conclusion Multimedia application classes Multimedia requirements Streaming Unidirectional real-time applications Interactive real-time applications Multimedia requirements Challenges TCP and UCP limitations Rate adaptation