QoS by xiaocuisanmin


									Quality of
             QoS   #1
            QOS in IP Networks
q IETF groups are working on proposals to provide
  QOS control in IP networks, i.e., going beyond
  best effort to provide some assurance for QOS
q Work in Progress includes RSVP, Differentiated
  Services, and Integrated Services
q Simple model
  for sharing and

                                                    QoS   #2
        Principles for QOS Guarantees

q   Consider a phone application at 1Mbps and an FTP
    application sharing a 1.5 Mbps link.
    m   bursts of FTP can congest the router and cause audio packets
        to be dropped.
    m   want to give priority to audio over FTP
q   PRINCIPLE 1: Marking of packets is needed for
    router to distinguish between different classes; and
    new router policy to treat packets accordingly

                                                             QoS   #3
 Principles for QOS Guarantees (more)

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

                                                           QoS   #4
 Principles for QOS Guarantees (more)

q 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
q PRINCIPLE 3: While providing isolation, it is
  desirable to use resources as efficiently as

                                                   QoS   #5
Principles for QOS Guarantees (more)

q   Cannot support traffic beyond link capacity
    m   Two phone calls each requests 1 Mbps
q   PRINCIPLE 4: Need a Call Admission Process;
    application flow declares its needs, network may
    block call if it cannot satisfy the needs

                                                  QoS   #6
QoS   #7
              Building blocks

q Scheduling
  m Active Buffer Management

q Traffic Shaping
  m Leaky Bucket
  m Token Bucket

q Modeling
  m The (σ,ρ) Model
  m WFQ and delay guarantee

q Admission Control
  m QoS Routing

                                QoS   #8
    Scheduling: How Can Routers Help

q Scheduling: choosing the next packet for
   m FIFO/Priority Queue
   m Round Robin/ DRR
   m Weighted Fair Queuing
   m We had a lecture on that!

q Packet dropping:
   m not drop-tail
   m not only when buffer is full
       • Active Queue Management

q Congestion signaling
   m Explicit Congestion Notification (ECN)
                                              QoS   #9
                     Buffer Size

q Why not use infinite    buffers?
   m no packet drops!

q Small buffers:
   m often drop packets due to bursts
   m but have small delays

q Large buffers:
   m reduce number of packet drops (due to bursts)
   m but increase delays

q Can   we have the best of both worlds?
                                                     QoS   #10
       Random Early Detection (RED)

q Basic premise:
   m router should signal congestion when the queue first
     starts building up (by dropping a packet)
   m but router should give flows time to reduce their sending
     rates before dropping more packets
   m Note: when RED is coupled with ECN, the router can
     simply mark a packet instead of dropping it

q Therefore, packet drops should be:
   m early: don’t wait for queue to overflow
   m random: don’t drop all packets in burst, but space them

                                                               QoS   #11

q FIFO scheduling
q Buffer management:
    m   Probabilistically discard packets
    m   Probability is computed as a function of average queue
        length (why average?)
               Discard Probability


                           min_th     max_th queue_len Average
                                                      Queue Length

                                                                     QoS   #12
                 RED (cont’d)

Discard Probability (P)


                     min_th max_th queue_len Average
                                            Queue Length


                                                           QoS   #13
                         RED (cont’d)

q Setting the discard probability P:

              Discard Probability

         max_P   1

                          min_th         max_th queue_len Average
                                                         Queue Length

                                                                        QoS   #14
Average vs Instantaneous Queue

                                 QoS   #15
                       RED and TCP

q   Sequence of actions (Early drop)
    m   Duplicate Acks
    m   Fast retransmit
         • Session recovers
    m   Lower source rate

q   Fairness in drops
    m   Bursty versus non-Bursy
    m   Probability of drop depends on rate.

q   Disadvantages
    m   Many additional parameters
    m   Increasing the loss

                                               QoS   #16
                        RED Summary

q Basic idea is sound, but does not always work well
   m   Basically, dropping packets, early or late is a bad thing

q High network utilization with low delays when flows are long lived

q Average queue length small, but capable of absorbing large bursts

q Many refinements to basic algorithm make it more adaptive
   m   requires less tuning

q Does not work well for short lived flows (like Web traffic)
   m   Dropping packets in an already short lived flow is devastating

q Better to mark ECN instead of dropping packets
   m   ECN not widely supported

                                                                        QoS   #17
            Traffic Shaping

q Traffic shaping controls the    rate at which
  packets are sent (not just how many).
  m   Used in ATM and Integrated Services
q At connection set-up time, the sender and
  carrier negotiate a traffic pattern (shape).
q Two traffic shaping algorithms are:
  m   Leaky Bucket
  m   Token Bucket

                                             QoS   #18
         The Leaky Bucket Algorithm

q The Leaky Bucket Algorithm
  m used to control rate in a network.
  m It is implemented as a single-server queue
        • with constant service time.
   m   If the bucket (buffer) overflows then packets
       are discarded.
q Leaky Bucket (parameters r and B):
   m Every r time units: send a packet.
   m For an arriving packet
        • If queue not full (less than B) then enqueue
q Note that the output is a “perfect”
  constant rate.
                                                         QoS   #19
               The Leaky Bucket Algorithm

(a) A leaky bucket with water. (b) a leaky bucket with packets.

                                                             QoS   #20
                 Token Bucket Algorithm

q   Highlights:                 q   Token Bucket
    m   The bucket holds            (r, MaxTokens):
    m   To transmit a packet,       m   Generate a token every r
        we “use” one token.             time units
                                         • If number of tokens more
q   Allows the output rate                 than MaxToken, reset to
    to vary,                               MaxTokens.
    m   depending on the size       m   For an arriving packet:
        of the burst.
    m   In contrast to the
        Leaky Bucket                m   While buffer not empty
                                        and there are tokens:
q   Granularity                          • send a packet and discard
    m   Packets (or bits)                  a token

                                                              QoS      #21
The Token Bucket Algorithm


(a) Before.    (b) After.
                             QoS   #22
              Token bucket example
arrival queue   Token     sent
p1 (5)   -      0         -
                                  1/r=3 (=3 token/time)
p2 (2)   p1     3         -

p3 (1)   p2     6-5=1     p1

                4-2-1=1   p3,p2



                                               QoS   #23
        Leaky Bucket vs Token Bucket

Leaky Bucket                  Token Bucket
q Discard:                    q Discard:
   m   Packets                   m   Tokens
                                 m   Packet management
q Rate:                       q Rate:
   m   fixed rate (perfect)      m   Average rate
                                 m   Bursts allowed
q Arriving Burst:             q Arriving Burst:
   m   Waits in bucket           m   Can be sent immediately

                                                           QoS   #24
                     The (σ,ρ) Model
q   Parameters:
    m   The average rate is ρ.
    m   The maximum burst is σ.
q   (σ,ρ) Model:
    m   Over an interval of length t,
    m   the number of packets/bits that are admitted
    m   is less than or equal to (σ+ρt).
    m   Composing flows (σ1,ρ1) & (σ2,ρ2)
         • Resulting flow (σ1+ σ2,ρ1+ρ2)
q Token Bucket Algorithm:
   m σ = MaxTokens & ρ=1/r per time unit
q Leaky Bucket Algorithm
   m σ = 0 & ρ= =1/r per time unit
                                                       QoS   #25
Using (σ,ρ) Model for admission Control
q What does a router need to support
 streams: (σ1,ρ1) … (σk,ρk)
  m Buffer size B > Σ σi
  m Rate R > Σ ρi

q Admission Control (at the router)
  m Can support (σk,ρk) if
  m Enough buffers and bandwidth
    • R > Σ ρi and B > Σ σi

                                       QoS   #26
                  Delay Bounds: WFQ

q   Recall: workS(i, a,b)
    m   # bits transmitted for flow i in time [a,b] by policy S.

q   Theorem (Parekh-Gallager: Single link):
    m   Assume maximum packet size Lmax
    m   Then for any time t:
    workGPS(i,1,t) - workWFQ(i, 1,t) ≤ Lmax

q Corollary:
   m For any packet p and link rate R
         • Let Time(p,S) be its completion time in policy S
         • Then Time(p,WFQ)-Time(p,GPS) ≤ Lmax/R
                                                                   QoS   #27
         Parekh-Gallagher theorem
Suppose a given connection is (s,r) constrained,
  has maximal packet size L, and passes
  through K WFQ schedulers, such that in the
  ith scheduler
   m   there is total rate r(i)
   m   from which the connection gets g(i).
Let g be the minimum over all g(i), and suppose
  all packets are at most Lmax bits long. Then

                                                   QoS   #28
           P-G theorem: Interpretation

Delay of last packet of
a burst. Only in
bottleneck node
GPS term
            store&forward             WFQ lag behind
            penalty                   GPS: each node

                          GPS to WFQ correction
                                                  QoS   #29

q WFQ can provide end-to-end delay bounds
q So WFQ provides both fairness and
  performance guarantees
q Bound holds regardless of cross traffic
q Can be generalized for networks where
  schedulers are variants of WFQ, and the
  link service rate changes over time

                                            QoS   #30
                        Fine Points

q   To get a delay bound, need to pick g
    m   the lower the delay bound, the larger g needs to be
    m   large g means exclusion of more competitors from link
q   Sources must be leaky-bucket regulated
    m   but choosing leaky-bucket parameters is problematic
q   WFQ couples delay and bandwidth allocations
    m   low delay requires allocating more bandwidth
    m   wastes bandwidth for low-bandwidth low-delay sources

                                                                QoS   #31
               Approaches to QoS

Integrated Services        Differentiated Services
q   Network wide control   q Router based control
                               m   Per hop behavior
q   Admission Control      q   Resolves contentions
                               m   Hot spots
q Absolute guarantees      q Relative guarantees
q Traffic Shaping          q Traffic policing
q Reservations                 m   At entry to network
    m   RSVP

                                                         QoS   #32
IETF Integrated Services

q architecture for providing QOS guarantees in IP
  networks for individual application sessions
q resource reservation: routers maintain state info
  (a la VC) of allocated resources, QoS req’s
q 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?

                                                 QoS   #33
Intserv: QoS guarantee scenario
                   q   Resource reservation
                       m   call setup, signaling (RSVP)
                       m   traffic, QoS declaration
                       m   per-element admission control


             m    QoS-sensitive
                 scheduling (e.g.,

                                                      QoS   #34
                 Call Admission

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

                                                  QoS   #35
          RSVP request (T-Spec)

q   A token bucket specification
    m   bucket size, b
    m   token rate, r
    m   the packet is transmitted onward only if the number of
        tokens in the bucket is at least as large as the packet
q   peak rate, p
    m   p>r
q maximum packet size, M
q minimum policed unit, m
    m   All packets less than m bytes are considered to be m bytes
    m   Reduces the overhead to process each packet
    m   Bound the bandwidth overhead of link-level headers

                                                         QoS   #36
               RSVP request (R-spec)

q   An indication of the QoS control service
    m   Controlled-load service and Guaranteed service
q   For Controlled-load service
    m   Simply a Tspec
q   For Guaranteed service
    m   A Rate (R) term, the bandwidth required
         • R ³ r, extra bandwidth will reduce queuing delays
    m   A Slack (S) term
         • The difference between the desired delay and the delay
           that would be achieved if rate R were used
         • With a zero slack term, each router along the path must
           reserve R bandwidth
         • A nonzero slack term offers the individual routers greater
           flexibility in making their local reservation
         • Number decreased by routers on the path.
                                                                   QoS   #37
QoS Routing: Multiple constraints

q   A request specifies the desired QoS requirements
    m   e.g., BW, Delay, Jitter, packet loss, path reliability etc
q   Three (main) type of constraints:
    m   Additive: e.g., delay
    m   Multiplicative: e.g., loss rate
    m   Maximum (or Minimum): e.g., Bandwidth
q   Task
    m   Find a (min cost) path which satisfies the constraints
    m   if no feasible path found, reject the connection
    m   Generally, multiple constraints is HARD computationally.
q   Simple case:
    m   BW and delay

                                                               QoS   #38
                                                      Example of QoS Routing

                                         5                                    D=
                                   =5                                              10, B
                         4,   BW                                                        W=


                              D                                                                              B

                                       W                                  0                D = 14, BW = 40
   5, B

                                                           5,   BW


                                                                                                                W = 90
                                                                                                             D = 7, B

                                                                                     D = 10, BW = 90

                                               = 3, B


Constraints: Delay (D) < 25, Available Bandwidth (BW) > 30
                                                                                                                         QoS   #39
IETF Differentiated Services
Concerns with Intserv:
q Scalability: signaling, maintaining per-flow router
  state difficult with large number of flows
q Flexible Service Models: Intserv has only two
  classes. Also want “qualitative” service classes
   m   “behaves like a wire”
   m   relative service distinction: Platinum, Gold, Silver

Diffserv approach:
q simple functions in network core, relatively
  complex functions at edge routers (or hosts)
q Don’t define service classes, provide functional
  components to build service classes
                                                              QoS   #40
Diffserv Architecture

Edge router:
- per-flow traffic management          r marking
- marks packets as in-profile
and out-profile                    b         .
Core router:
- per class traffic management
- buffering and scheduling
based on marking at edge
- preference given to in-profile

                                                 QoS   #41
     Edge-router Packet Marking
q profile: pre-negotiated rate A, and token bucket size B
q packet marking at edge based on per-flow profile

                                    Rate A


                    User packets

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

                                                                   QoS   #42
      Classification and Conditioning

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

                                                 QoS   #43
        Classification and Conditioning

q   It may be desirable to limit traffic injection rate
    of some class; user declares traffic profile (eg,
    rate and burst size); traffic is metered and
    shaped if non-conforming

                                                      QoS   #44
                   Forwarding (PHB)

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

                                                              QoS   #45
                    Forwarding (PHB)

PHBs being developed:
q   Expedited Forwarding: pkt departure rate of a
    class equals or exceeds specified rate
    m   logical link with a minimum guaranteed rate
         • Premium service
    m   DSCP = 101110 (46)
q   Assured Forwarding: 4 classes of traffic
    m   each guaranteed minimum amount of bandwidth
    m   each with three drop preference partitions
         • Gold, silver, bronze

                                                      QoS   #46
                 DiffServ Routers

           Classifier   Marker       Meter       Policer

DiffServ                    PHB
           Select PHB        PHB           Local
Core                          PHB
                               PHB       conditions
                  Extract              Packet
                  DSCP               treatment

                                                           QoS   #47
          IntServ vs. DiffServ


"Call blocking"        "Prioritization"
approach               approach
                                          QoS   #48
Comparison of Intserv & Diffserv

                                   QoS   #49
Comparison of Intserv & Diffserv

                                   QoS   #50

To top