CSE 679 Multimedia and Networking r Multimedia applications

CSE 679: Multimedia and Networking r Multimedia applications r Challenges r TCP and UDP limitations r Rate adaptation

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

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

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

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

Challenges to the Current Internet r TCP/UDP/IP suite provides best-effort, no guarantees on expectation or variance of packet delay r Streaming applications delay of 5 to 10 seconds is typical and has been acceptable, but performance deteriorate if links are congested (transoceanic) r 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) r Most router implementations use only First-Come- First-Serve (FCFS) packet processing and transmission scheduling r To mitigate impact of “best-effort” protocols, we can: m m m 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 r Reliable delivery not needed for multimedia r Timely delivery more important than in-order delivery. r Late packet can be thrown away r TCP’s reliability gets in the way.

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

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

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

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

Packet-pair

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

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

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