CSE679: Multimedia and Networking

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 lt 150 msec acceptable
• Audio lt 150 msec good, lt400 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
• TCPs 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
• Dont 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 shouldnt 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
• Dont 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
• Streaming
• Unidirectional real-time applications
• Interactive real-time applications
• Multimedia requirements
• Challenges
• TCP and UCP limitations
• Rate adaptation