15441 Computer Networking

1
15-441 Computer Networking

• Multimedia

2
Outline

• Multimedia requirements
• Streaming
• Phone over IP
• Recovering from Jitter and Loss
• RTP
• QoS Requirements
• Introduction to Scheduling Policies

3
Application Classes

• Typically sensitive to delay, but can tolerate
  packet loss (would cause minor glitches that can
  be concealed)
• Data contains audio and video content
  (continuous media), three classes of
  applications
• Streaming
• Unidirectional Real-Time
• Interactive Real-Time

4
Application Classes (more)

• 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

5
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

6
Challenges

• 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 (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
Solution Approaches in IP Networks

• Just add more bandwidth and enhance caching
  capabilities (over-provisioning)!
• Need major change of the protocols
• Incorporate resource reservation (bandwidth,
  processing, buffering), and new scheduling
  policies
• Set up service level agreements with
  applications, monitor and enforce the agreements,
  charge accordingly
• Need moderate changes (Differentiated
  Services)
• Use two traffic classes for all packets and
  differentiate service accordingly
• Charge based on class of packets
• Network capacity is provided to ensure first
  class packets incur no significant delay at
  routers

9
Outline

• Multimedia requirements
• Streaming
• Phone over IP
• Recovering from Jitter and Loss
• RTP
• QoS Requirements
• Introduction to Scheduling Policies

10
Streaming

• Important and growing application due to
  reduction of storage costs, increase in high
  speed net access from homes, enhancements to
  caching and introduction of QoS in IP networks
• Audio/Video file is segmented and sent over
  either TCP or UDP, public segmentation protocol
  Real-Time Protocol (RTP)

11
Streaming

• User interactive control is provided, e.g. the
  public protocol Real Time Streaming Protocol
  (RTSP)
• Helper Application displays content, which is
  typically requested via a Web browser e.g.
  RealPlayer typical functions
• Decompression
• Jitter removal
• Error correction use redundant packets to be
  used for reconstruction of original stream
• GUI for user control

12
Streaming From Web Servers

• Audio in files sent as HTTP objects
• Video (interleaved audio and images in one file,
  or two separate files and client synchronizes the
  display) sent as HTTP object(s)
• A simple architecture is to have the Browser
  request the object(s) and after their reception
  pass them to the player for display
• - No pipelining

13
Streaming From Web Server (more)

• Alternative set up connection between server and
  player, then download
• Web browser requests and receives a Meta File (a
  file describing the object) instead of receiving
  the file itself
• Browser launches the appropriate Player and
  passes it the Meta File
• Player sets up a TCP connection with Web Server
  and downloads the file

14
Meta file requests
15
Using a Streaming Server

• This gets us around HTTP, allows a choice of UDP
  vs. TCP and the application layer protocol can be
  better tailored to Streaming many enhancements
  options are possible (see next slide)

16
Options When Using a Streaming Server

• Use UDP, and Server sends at a rate (Compression
  and Transmission) appropriate for client to
  reduce jitter, Player buffers initially for 2-5
  seconds, then starts display
• Use TCP, and sender sends at maximum possible
  rate under TCP retransmit when error is
  encountered Player uses a much large buffer to
  smooth delivery rate of TCP

17
Real Time Streaming Protocol (RTSP)

• For user to control display rewind, fast
  forward, pause, resume, etc
• Out-of-band protocol (uses two connections, one
  for control messages (Port 554) and one for media
  stream)
• RFC 2326 permits use of either TCP or UDP for the
  control messages connection, sometimes called the
  RTSP Channel
• As before, meta file is communicated to web
  browser which then launches the Player Player
  sets up an RTSP connection for control messages
  in addition to the connection for the streaming
  media

18
Meta File Example

• lttitlegtXena Warrior Princesslt/titlegt
• ltsessiongt
• ltgroup languageen lipsyncgt
• ltswitchgt
• lttrack typeaudio
• e"PCMU/8000/1"
• src
  "rtsp//audio.example.com/xena/audio.en/lofi"gt
• lttrack typeaudio
• e"DVI4/16000/2"
  pt"90 DVI4/8000/1"
• src"rtsp//audio.ex
  ample.com/xena/audio.en/hifi"gt
• lt/switchgt
• lttrack type"video/jpeg"
• src"rtsp//video.ex
  ample.com/twister/video"gt
• lt/groupgt
• lt/sessiongt

19
RTSP Operation
20
RTSP Exchange Example

• C SETUP rtsp//audio.example.com/xena/audio
  RTSP/1.0
• Transport rtp/udp compression
  port3056 modePLAY
• S RTSP/1.0 200 1 OK
• Session 4231
• C PLAY rtsp//audio.example.com/xena/audio.en
  /lofi RTSP/1.0
• Session 4231
• Range npt0- (npt normal play time)
• C PAUSE rtsp//audio.example.com/xena/audio.e
  n/lofi RTSP/1.0
• Session 4231
• Range npt37
• C TEARDOWN rtsp//audio.example.com/xena/audi
  o.en/lofi RTSP/1.0
• Session 4231
• S 200 3 OK

21
Outline

• Multimedia requirements
• Streaming
• Phone over IP
• Recovering from Jitter and Loss
• RTP
• QoS Requirements
• Introduction to Scheduling Policies

22
Real-Time (Phone) Over IPs Best-Effort

• Internet phone applications generate packets
  during talk spurts
• Bit rate is 8 KBytes, and every 20 msec, the
  sender forms a packet of 160 Bytes a header to
  be discussed below
• The coded voice information is encapsulated into
  a UDP packet and sent out some packets may be
  lost up to 20 loss is tolerable using TCP
  eliminates loss but at a considerable cost
  variance in delay FEC (forward error correction)
  is sometimes used to fix errors and make up
  losses

23
Real-Time (Phone) Over IPs Best-Effort

• End-to-end delays above 400 msec cannot be
  tolerated packets that are that delayed are
  ignored at the receiver
• Delay jitter is handled by using timestamps,
  sequence numbers, and delaying playout at
  receivers either a fixed or a variable amount
• With fixed playout delay, the delay should be as
  small as possible without missing too many
  packets delay cannot exceed 400 msec

24
Internet Phone with Fixed Playout Delay
25
Adaptive Playout Delay

• Objective is to use a value for p-r that tracks
  the network delay performance as it varies during
  a phone call
• The playout delay is computed for each talk spurt
  based on observed average delay and observed
  deviation from this average delay
• Estimated average delay and deviation of average
  delay are computed in a manner similar to
  estimates of RTT and deviation in TCP
• The beginning of a talk spurt is identified from
  examining the timestamps in successive and/or
  sequence numbers of chunks

26
Outline

• Multimedia requirements
• Streaming
• Phone over IP
• Recovering from Jitter and Loss
• RTP
• QoS Requirements
• Introduction to Scheduling Policies

27
Recovery From Packet Loss

• Loss is in a broader sense packet never arrives
  or arrives later than its scheduled playout time
• Since retransmission is inappropriate for Real
  Time applications, FEC or Interleaving are used
  to reduce loss impact.
• FEC is Forward Error Correction
• Simplest FEC scheme adds a redundant chunk made
  up of exclusive OR of a group of n chunks
  redundancy is 1/n can reconstruct if at most one
  lost chunk playout time schedule assumes a loss
  per group

28
Recovery From Packet Loss

• Mixed quality streams are used to include
  redundant duplicates of chunks upon loss playout
  available redundant chunk, albeit a lower quality
  one
• With one redundant low quality chunk per chunk,
  scheme can recover from single packet losses

29
Piggybacking Lower Quality Stream
30
Interleaving

• Has no redundancy, but can cause delay in playout
  beyond Real Time requirements
• Divide 20 msec of audio data into smaller units
  of 5 msec each and interleave
• Upon loss, have a set of partially filled chunks

31
Outline

• Multimedia requirements
• Streaming
• Phone over IP
• Recovering from Jitter and Loss
• RTP
• QoS Requirements
• Introduction to Scheduling Policies

32
Real-Time Protocol (RTP)

• Provides standard packet format for real-time
  application
• Typically runs over UDP
• Specifies header fields below
• Payload Type 7 bits, providing 128 possible
  different types of encoding eg PCM, MPEG2 video,
  etc.
• Sequence Number 16 bits used to detect packet
  loss

33
Real-Time Protocol (RTP)

• Timestamp 32 bytes gives the sampling instant
  of the first audio/video byte in the packet
  used to remove jitter introduced by the network
• Synchronization Source identifier (SSRC) 32
  bits an id for the source of a stream assigned
  randomly by the source

34
RTP Control Protocol (RTCP)

• Protocol specifies report packets exchanged
  between sources and destinations of multimedia
  information
• Three reports are defined Receiver reception,
  Sender, and Source description
• Reports contain statistics such as the number of
  packets sent, number of packets lost,
  inter-arrival jitter
• Used to modify sender transmission rates and
  for diagnostics purposes

35
RTCP Bandwidth Scaling

• If each receiver sends RTCP packets to all other
  receivers, the traffic load resulting can be
  large
• RTCP adjusts the interval between reports based
  on the number of participating receivers
• Typically, limit the RTCP bandwidth to 5 of the
  session bandwidth, divided between the sender
  reports (25) and the receivers reports (75)

36
Outline

• Multimedia requirements
• Streaming
• Phone over IP
• Recovering from Jitter and Loss
• RTP
• QoS Requirements
• Introduction to Scheduling Policies

37
Improving QoS in IP Networks

• IETF groups are working on proposals to provide
  better QoS control in IP networks, i.e., going
  beyond best effort to provide some assurance for
  QoS
• Work in Progress includes RSVP, Differentiated
  Services, and Integrated Services
• Simple model for sharing and congestion
  studies

38
Principles for QoS Guarantees

• Consider a phone application at 1Mbps and an FTP
  application sharing a 1.5 Mbps link.
• bursts of FTP can congest the router and cause
  audio packets to be dropped.
• want to give priority to audio over FTP
• PRINCIPLE 1 Marking of packets is needed for
  router to distinguish between different classes
  and new router policy to treat packets
  accordingly
• e.g. MPLS, Diffserv,RSVP

39
Principles for QoS Guarantees (more)

• Applications misbehave (audio sends packets at a
  rate higher than 1Mbps assumed above)
• PRINCIPLE 2 provide protection (isolation) for
  one class from other classes
• Require Policing Mechanisms to ensure sources
  adhere to bandwidth requirements Marking and
  Policing need to be done at the edges
• e.g. WFQ

40
Principles for QoS Guarantees (more)

• Alternative to Marking and Policing allocate a
  set portion of bandwidth to each application
  flow can lead to inefficient use of bandwidth if
  one of the flows does not use its allocation
• PRINCIPLE 3 While providing isolation, it is
  desirable to use resources as efficiently as
  possible

41
Principles for QoS Guarantees (more)

• Cannot support traffic beyond link capacity
• PRINCIPLE 4 Need a Call Admission Process
  application flow declares its needs, network may
  block call if it cannot satisfy the needs

42
Summary
43
Outline

• Multimedia requirements
• Streaming
• Phone over IP
• Recovering from Jitter and Loss
• RTP
• QoS Requirements
• Introduction to Scheduling Policies

44
Scheduling And Policing Mechanisms

• Scheduling choosing the next packet for
  transmission on a link can be done following a
  number of policies
• FIFO in order of arrival to the queue packets
  that arrive to a full buffer are either
  discarded, or a discard policy is used to
  determine which packet to discard among the
  arrival and those already queued

45
Scheduling Policies

• Priority Queuing classes have different
  priorities class may depend on explicit marking
  or other header info, eg IP source or
  destination, TCP Port numbers, etc.
• Transmit a packet from the highest priority class
  with a non-empty queue
• Preemptive and non-preemptive versions

46
Scheduling Policies (more)

• Round Robin scan class queues serving one from
  each class that has a non-empty queue

47
Scheduling Policies (more)

• Weighted Fair Queuing is a generalized Round
  Robin in which an attempt is made to provide a
  class with a differentiated amount of service
  over a given period of time

48
Policing Mechanisms

• Three criteria
• (Long term) Average Rate (100 packets per sec or
  6000 packets per min??), crucial aspect is the
  interval length
• Peak Rate e.g., 6000 p p minute Avg and 1500 p p
  sec Peak
• (Max.) Burst Size Max. number of packets sent
  consecutively, ie over a short period of time

49
Policing Mechanisms

• Token Bucket mechanism, provides a means for
  limiting input to specified Burst Size and
  Average Rate.

50
Policing Mechanisms (more)

• Bucket can hold b tokens token are generated at
  a rate of r token/sec unless bucket is full of
  tokens.
• Over an interval of length t, the number of
  packets that are admitted is less than or equal
  to (r t b).
• Token bucket and WFQ can be combined to
  provide upperbound on delay.