School of Computing Science
             Simon Fraser University

 CMPT 771/471: Internet Architecture and

Multimedia Networking and Quality of Service

     Instructor: Dr. Mohamed Hefeeda

Multimedia, Quality of Service: What is it?

                            Multimedia applications:
                            network audio and video
                            (“continuous media”)

network provides
application with level of
performance needed for
application to function.
Chapter 7: Goals

 Classify multimedia applications
 Identify the network services the apps need
 Making the best of best effort service
 Mechanisms for providing QoS
Protocols and Architectures
 Specific protocols for best-effort
 Architectures for QoS

MM Networking Applications

Classes of MM applications:    Fundamental
1) Streaming stored audio
   and video                    Typically delay sensitive
                                      end-to-end delay
2) Streaming live audio and
                                      delay jitter

                                But loss tolerant:
3) Real-time interactive
                                 infrequent losses cause
   audio and video
                                 minor glitches
                                In contrast to data,
                                 which are loss intolerant
   Jitter is the variability     but delay tolerant.
   of packet delays within
   the same packet stream
A few words about audio compression

 Analog signal sampled         Example: 8,000
  at constant rate               samples/sec, 256
      telephone: 8,000          quantized values -->
       samples/sec               64,000 bps
      CD music: 44,100         Receiver converts it
                                 back to analog signal:
 Each sample quantized,
                                     some quality reduction
  i.e., rounded
                               Example rates
      e.g., 28=256 possible
       quantized values         CD: 1.411 Mbps
 Each quantized value          MP3: 96, 128, 160 kbps
  represented by bits           Internet telephony:
      8 bits for 256 values     5.3 - 13 kbps
 A few words about video compression

 Video is sequence of        Examples:
  images displayed at          MPEG 1 (CD-ROM) 1.5
  constant rate                 Mbps
       e.g. 24 images/sec
                               MPEG2 (DVD) 3-6 Mbps
 Digital image is array of
                               MPEG4 (often used in
  pixels                        Internet, < 1 Mbps)
 Each pixel represented
  by bits
                               Layered (scalable) video
 Redundancy
                                    adapt layers to available
      spatial                       bandwidth
                               Fine-grain scalable (FGS)

                                    Adapt at bit level

Streaming Multimedia: UDP or TCP?
 server sends at rate appropriate for client (oblivious to
  network congestion !)
    often send rate = encoding rate = constant rate
    then, fill rate = constant rate - packet loss
 short playout delay (2-5 seconds) to compensate for network
  delay jitter
 error recover: time permitting
 send at maximum possible rate under TCP
 fill rate fluctuates due to TCP congestion control
 larger playout delay: smooth TCP delivery rate
 HTTP/TCP passes more easily through firewalls

User Control of Streaming Media: RTSP

HTTP                             What it doesn’t do:
 Does not target multimedia      does not define how
  content                          audio/video is encapsulated
 No commands for fast             for streaming over network
  forward, etc.                   does not restrict how
RTSP: RFC 2326                     streamed media is
 Client-server application
                                   transported; it can be
  layer protocol.                  transported over UDP or
 For user to control display:
                                  does not specify how the
  rewind, fast forward,
  pause, resume,                   media player buffers
  repositioning, etc…              audio/video
 RTSP is out-of-band
  protocol (similar to FTP)

RTSP Example

 metafile communicated to web browser
 browser launches player
 player sets up an RTSP control connection, data
    connection to streaming server
Real-time interactive applications

 PC-2-PC phone               Going to now look at
    instant messaging        a PC-2-PC Internet
     services are providing   phone example in
     this                     detail
 PC-2-phone
    Dialpad
    Net2phone
 videoconference with

Interactive Multimedia: Internet Phone
 speaker’s audio: alternating talk spurts, silent
      64 kbps during talk spurt
 pkts generated only during talk spurts
      20 msec chunks at 8 Kbytes/sec: 160 bytes data
 application-layer header added to each chunk
 Chunk+header encapsulated into UDP segment
 application sends UDP segment into socket every 20
  msec during talk spurt
 Need to handle packet losses and delay jitter

 Recovery from packet loss (1)
forward error correction        Playout delay needs to
  (FEC): simple scheme           be fixed to the time to
 for every group of n           receive all n+1 packets
  chunks create a               Tradeoff:
  redundant chunk by
                                   increase n, less
  exclusive OR-ing the n
                                    bandwidth waste
  original chunks
                                   increase n, longer
 send out n+1 chunks,
                                    playout delay
  increasing the bandwidth
                                   increase n, higher
  by factor 1/n.
                                    probability that 2 or
 can reconstruct the
                                    more chunks will be
  original n chunks if there
  is at most one lost chunk
  from the n+1 chunks
  Recovery from packet loss (2)
2nd FEC scheme
• “piggyback lower
quality stream”
• send lower resolution
audio stream as the
redundant information
• for example, nominal
stream PCM at 64 kbps
and redundant stream
GSM at 13 kbps.

              • Whenever there is non-consecutive loss, the
              receiver can conceal the loss.
              • Can also append (n-1)st and (n-2)nd low-bit rate

 Recovery from packet loss (3)

 chunks are broken              if packet is lost, still have
   up into smaller units          most of every chunk
 for example, four 5 msec       has no redundancy overhead
   units per chunk               but adds to playout delay
 Packet contains small units
   from different chunks
Handling Delay Jitter
 Receiver uses a playout buffer
    Fixed buffer
    Adaptive buffer: depends on network conditions


                  packets                    loss
                                                            playout schedule
                                                                  p' - r

                                                    playout schedule


                                 p          p'

  Adaptive Playout Buffer (1)
   Goal: minimize playout delay, keeping late loss rate low
   Approach: adaptive playout delay adjustment:
         Estimate network delay, adjust playout delay at beginning of
          each talk spurt.
         Silent periods compressed and elongated.
         Chunks still played out every 20 msec during talk spurt.

          t i  timestamp of the ith packet
          ri  the time packet i is received by receiver
          p i  the time packet i is played at receiver
          ri  t i  network delay for ith packet
          d i  estimate of average network delay after receiving ith packet
Dynamic estimate of average delay at receiver:

                         d i  (1  u )d i 1  u (ri  ti )
where u is a fixed constant (e.g., u = .01).                                   16
    Adaptive Playout Buffer (2)
Also useful to estimate the average deviation of the delay, vi :
                vi  (1  u )vi 1  u | ri  ti  d i |
The estimates di and vi are calculated for every received packet,
although they are only used at the beginning of a talk spurt.

For first packet in talk spurt, playout time is:

                         pi  ti  d i  Kvi
    where K is a positive constant.

    Remaining packets in talk spurt are played out periodically

Real-Time Protocol (RTP): FRC 1889
 RTP specifies packet structure
  audio and video data
      payload type identification
      packet sequence numbering
      time stamping
 RTP runs in the end systems
 RTP packets are encapsulated in
  UDP segments
 RTP does not provide any
  mechanism to ensure QoS
      RTP encapsulation is only seen
       at the end systems

   RTP Header

Payload Type (7 bits): Indicates type of encoding currently being
used: e.g.,
    •Payload type 0: PCM mu-law, 64 kbps
    •Payload type 33, MPEG2 video

Sequence Number (16 bits): Increments by one for each RTP packet
sent, and may be used to detect packet

Timestamp field (32 bytes long). Reflects the sampling instant of the
first byte in the RTP data packet.

SSRC field (32 bits long). Identifies the source of the RTP stream.
Each stream in a RTP session should have a distinct SSRC.

 Real-Time Control Protocol (RTCP)
 Works in conjunction with RTP

 Each participant in RTP session
  periodically transmits RTCP control
  packets to all other participants

 Each RTCP packet contains sender and/or
  receiver reports
      statistics, e.g., number of packets sent, number
       of packets lost, interarrival jitter, etc.
      used to control app performance
      Sender may modify its transmissions based on

RTCP Packets

Receiver report packets:   Source description
 fraction of packets        packets:
  lost, last sequence       e-mail address of
  number, average            sender, sender's name,
  interarrival jitter.       SSRC of associated
Sender report packets:       RTP stream.
 SSRC of the RTP           Provide mapping
  stream, the current        between the SSRC and
  time, the number of        the user/host name.
  packets sent, and the
  number of bytes sent.

RTCP: Synchronization of Streams

 RTCP can synchronize            Each RTCP sender-report
  different media streams          packet contains (for the
  within a RTP session.            most recently generated
 Consider videoconferencing       packet in the associated
  app for which each sender        RTP stream):
  generates one RTP stream             timestamp of the RTP
  for video and one for audio.          packet
 Timestamps in RTP packets            wall-clock time for when
                                        packet was created.
  tied to the video and audio
  sampling clocks                 Receivers can use this
                                   association to synchronize
    not tied to the wall-
                                   the playout of audio and
     clock time

Session Initiation Protocol (SIP)

 Comes from IETF
SIP long-term vision
 All telephone calls and video conference calls take
  place over the Internet
 People are identified by names or e-mail
  addresses, rather than by phone numbers
 You can reach the callee, no matter where the
  callee roams, no matter what IP device the callee
  is currently using.

 SIP Services

 Setting up a call                Determine current IP
    Provides mechanisms for        address of callee.
     caller to let callee know          Maps mnemonic
     she wants to establish a            identifier to current IP
     call                                address
    Provides mechanisms so
                                   Call management
     that caller and callee can
                                      Add new media streams
     agree on media type and
     encoding.                         during call
                                      Change encoding during
    Provides mechanisms to
     end call.                         call
                                      Invite others
                                      Transfer and hold calls

         Setting up a call to a known IP address
                                                                                             • Alice’s SIP invite
                                                                                             message indicates her
                                                                                             port number & IP address.                                    
                                                                                             Indicates encoding that
                                                                                             Alice prefers to receive
                     INVITE bob
                     c=IN IP4 16           10.89
                                                                                             (PCM ulaw)
                     m=audio 38
                                060 RTP/A
                                           VP 0
                                                               port 5060    Bob's
                                                                            terminal rings

                                                                                             • Bob’s 200 OK message
                                         200 OK
                                         c=IN IP4 193.64
                                                    753 RTP/AVP 3
                                                                                             indicates his port number,
                                         m=audio 48
                 port 5060

                                           ACK                                               IP address & preferred
                                                                                             encoding (GSM)
                                                               port 5060

                                              m Law audio
                port 38060
                                                                                             • SIP messages can be
                                                                                             sent over TCP or UDP;
                                                             port 48753                      here sent over RTP/UDP.

                                                                                             •Default SIP port number
              time                                                       time                is 5060.
Name translation and user location

 Caller wants to call          Result can be based on:
  callee, but only has             time of day (work, home)
  callee’s name or e-mail          caller (don’t want boss to
  address.                          call you at home)
                                   status of callee (calls sent
 Need to get IP
                                    to voicemail when callee is
  address of callee’s               already talking to
  current host:                     someone)
      user moves around       Service provided by SIP
      DHCP protocol             servers:
      user has different IP
       devices (PC, PDA, car    SIP registrar server
       device)                  SIP proxy server

SIP Registrar
 When Bob starts SIP client, client sends SIP
  REGISTER message to Bob’s registrar server
  (similar function needed by Instant Messaging)

Register Message:

Via: SIP/2.0/UDP
Expires: 3600

SIP Proxy

 Alice sends invite message to her proxy server
    contains address

 Proxy responsible for routing SIP messages to
      possibly through multiple proxies.
 Callee sends response back through the same set
  of proxies.
 Proxy returns SIP response message to Alice
      contains Bob’s IP address

 Note: proxy is analogous to local DNS server

Caller                                SIP registrar

with places a

call to                                             SIP
                                            2                       registrar
(1) Jim sends INVITE
                              SIP proxy
message to umass SIP
proxy. (2) Proxy forwards         1                       7                5
request to upenn                      8
registrar server.

(3) upenn server returns                                      9

redirect response,          SIP client
                                                                       SIP client
indicating that it should

(4) umass proxy sends INVITE to eurecom registrar. (5) eurecom
registrar forwards INVITE to, which is running keith’s SIP
client. (6-8) SIP response sent back (9) media sent directly
between clients.
Note: also a SIP ack message, which is not shown.
Comparison with H.323

 H.323 is another signaling     H.323 comes from the ITU
  protocol for real-time,         (telephony).
  interactive                    SIP comes from IETF:
 H.323 is a complete,            Borrows much of its
  vertically integrated suite     concepts from HTTP. SIP
  of protocols for multimedia     has a Web flavor, whereas
  conferencing: signaling,        H.323 has a telephony
  registration, admission         flavor.
  control, transport and         SIP uses the KISS
  codecs.                         principle: Keep it simple
 SIP is a single component.      stupid.
  Works with RTP, but does
  not mandate it. Can be
  combined with other
  protocols and services.

Improving QoS in IP Networks
Thus far: “making the best of best effort”
Future: next generation Internet with QoS guarantees
      What do we need to do to get QoS guarantees?

 simple model for sharing and congestion studies:

Principles for QoS Guarantees
 Example: 1Mbps IP phone, FTP share 1.5 Mbps link.
    bursts of FTP can congest router, cause audio loss
    want to give priority to audio over FTP

    Principle 1
    packet marking needed for router to distinguish
    between different classes; and new router policy
    to treat packets accordingly
Principles for QoS Guarantees (more)
 what if applications misbehave (audio sends higher
  than declared rate)
      policing: force source adherence to bandwidth allocations
 marking and policing at network edge:
   similar to ATM UNI (User Network Interface)

Principle 2
provide protection (isolation) for one class from others
 Principles for QoS Guarantees (more)

 Allocating fixed (non-sharable) bandwidth to flow:
  inefficient use of bandwidth if flows doesn’t use
  its allocation

       Principle 3
     While providing isolation, it is desirable to use
     resources as efficiently as possible
Principles for QoS Guarantees (more)

   Basic fact of life: can not support traffic demands
    beyond link capacity

     Principle 4
    Call Admission: flow declares its needs, network may
    block call (e.g., busy signal) if it cannot meet needs
Summary of QoS Principles

 Let’s next look at mechanisms for achieving this ….

Scheduling And Policing Mechanisms

 scheduling: choose next packet to send on link
 FIFO (first in first out) scheduling: send in order of
  arrival to queue
      discard policy: if packet arrives to full queue: who to discard?
        • Tail drop: drop arriving packet
        • priority: drop/remove on priority basis
        • random: drop/remove randomly

Scheduling Policies: more

Priority scheduling: transmit highest-priority queued
 multiple classes, with different priorities
      class may depend on marking or other header info, e.g. IP
       source/dest, port numbers, etc..

Scheduling Policies: still more
Weighted Fair Queuing:
 generalized Round Robin
 each class gets weighted amount of service in each

Policing Mechanisms

Goal: limit traffic to not exceed declared parameters
Three common-used criteria:
   (Long term) Average Rate: how many pkts can be sent
    per unit time (in the long run)
       crucial question: what is the interval length: 100 packets per
        sec and 6000 packets per min (ppm) have same average!
   Peak Rate: e.g.,
       Avg rate: 6000 ppm
       Peak rate: 1500 ppm
   (Max.) Burst Size: max. number of pkts sent
    consecutively (with no intervening idle)

Policing Mechanisms
Leaky Bucket: limit input to specified Burst Size and
  Average Rate.

 bucket can hold b tokens
 tokens generated at rate   r token/sec unless bucket
 over interval of length t: number of packets
  admitted less than or equal to (r t + b).
Policing Mechanisms (more)
 Leaky bucket + WFQ  provide guaranteed upper bound
  on delay, i.e., QoS guarantee! How?
      WFQ: guaranteed share of bandwidth
      Leaky bucket: limit max number of packets in queue (burst)

                                        Ri  R wi /  w j
                                        d   i
                                             m ax
                                                     bi / Ri

IETF Integrated Services (IntServ)

 architecture for providing QoS guarantees in IP
  networks for individual application sessions
 resource reservation: routers maintain state info
  of allocated resources, QoS req’s
 admit/deny new call setup requests:

  Question: can newly arriving flow be admitted
  with performance guarantees while not violated
  QoS guarantees made to already admitted flows?

IntServ: QoS guarantee scenario
                    Resource reservation
                       call setup, signaling (RSVP)
                       traffic, QoS declaration
                       per-element admission control


                 QoS-sensitive
                 scheduling (e.g.,

Call Admission

Arriving session must:
 declare its QoS requirement
    R-spec: defines the QoS being requested
 characterize traffic it will send into network
    T-spec: defines traffic characteristics
 signaling protocol: needed to carry R-spec and T-
  spec to routers (where reservation is required)
    RSVP

IntServ QoS: Service models [rfc2211, rfc 2212]

Guaranteed service:
 worst case traffic arrival: leaky-bucket-policed source
 simple (mathematically provable)     bound on delay [Parekh
  1993, Cruz 1988]

          arriving    token rate, r
                      bucket size, b
                                        rate, R

                            D = b/R
IETF Differentiated Services
Concerns with IntServ:
 Scalability: signaling, maintaining per-flow router
  state difficult with large number of flows
      Example: OC-48 (2.5 Gbps) link serving 64 Kbps audio
       streams  39,000 flows! Each require state maintenance.
 Flexible Service Models: Intserv has only two classes.
  Also want “qualitative” service classes
      relative service distinction: Platinum, Gold, Silver
DiffServ approach:
 simple functions in network core, relatively complex
  functions at edge routers (or hosts)
 Don’t define service classes, provide functional
  components to build service classes
 DiffServ Architecture

Edge router:
 per-flow traffic management           r marking
 Classifies (marks) pkts
                                    b         .
    different classes
    within a class: in-profile
   and out-profile

 Core router:
  per class traffic management
  buffering and scheduling based
   on marking at edge
  preference given to in-profile

Edge-router Packet Marking
 profile: pre-negotiated rate A, bucket size B
 packet marking at edge based on per-flow profile

                                 Rate A


                  User packets

Possible usage of marking:
  class-based marking: packets of different classes marked
  intra-class marking: conforming portion of flow marked
   differently than non-conforming one

Edge-router: Classification and Conditioning

 Packet is marked in the Type of Service (TOS) in
  IPv4, and Traffic Class in IPv6
 6 bits used for Differentiated Service Code Point
  (DSCP) and determine Per-Hop Behavior (PHB)
  that the packet will receive
 2 bits are currently unused

Edge-router: Classification and Conditioning

may be desirable to limit traffic injection rate of
  some class:
 user declares traffic profile (e.g., rate, burst size)
 traffic metered, shaped if non-conforming

Core-router: Forwarding (PHB)

 PHB result in a different observable (measurable)
  forwarding performance behavior
 PHB does not specify what mechanisms to use to
  ensure required PHB performance behavior
 Examples:
      Class A gets x% of outgoing link bandwidth over time
       intervals of a specified length
      Class A packets leave first before packets from class B

Core-router: Forwarding (PHB)

PHBs being developed:
 Expedited Forwarding (EF): pkt departure rate of a
  class equals or exceeds specified rate
      logical link with a minimum guaranteed rate
      May require edge routers to limit EF traffic rate
      Could be implemented using strict priority scheduling or
       WFQ with higher weight for EF traffic
 Assured Forwarding: multiple traffic classes,
  treated differently
      amount of bandwidth allocated, or drop priorities
      Can be implemented using WFQ+leaky bucket or RED
       (Random Early Detection) with different threshold values.
        • See Sections. 6.4.2 and 6.5.3 in [PD07]
Multimedia Networking: Summary
  multimedia applications and requirements
  making the best of today’s best effort
  scheduling and policing mechanisms
  next generation Internet: Intserv, RSVP,

Intserv and Diffserv: Discussion
 For over 20 years, many attempts failed to introduce
  QoS into packet-switched networks. Why?
 Both Intserv and Diffserv need collaboration between
  all ISPs, otherwise you can not provide guarantee 
 QoS needs accounting, extra processing (shaping,
  marking, policing,…)  complex and costly
  equipment/management  charge customers more
 Most of the time there would be no perceived
  difference between Best-effort and
  Intserv/Diffserv services, at moderate load
      So why would customers pay more??

 How should the Internet evolve to better
 support multimedia?
Integrated services philosophy:   Differentiated services
 Fundamental changes in             philosophy:
   Internet so that apps can       Fewer changes to Internet
   reserve end-to-end                infrastructure, yet provide
   bandwidth                         1st and 2nd class service.
 Requires new, complex
   software in hosts & routers
Laissez-faire (minimum
 no major changes
 more bandwidth when
 content distribution,
   application-layer multicast
      application layer            What’s your opinion?


Shared By: