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

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

3. 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

4. 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

5. 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

6. 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?...

7. 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

8. 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.

9. 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

10. 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.

11. 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

12. 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

13. Packet-pair

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

15. 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

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