Schedule of Class Meeng

Mul$media  Networking  

  #10  QoS   Semester  Ganjil  2012   PTIIK  Universitas  Brawijaya  

  

Schedule  of  Class  Mee$ng  

1.

    Introduc$on     2.

  14. Summary  

  13. Discussion  

   

   

    CDN:  Case  Studies   11.

    CDN:  Solu$ons   10.

    Overlay  Mul$cast   9.

  IP  Mul$cast  (cont’d)     8.

   

    RTP   6.   IP  Mul$cast   7.

  5.

    Coding  and   Compression  

    Requirements  of  MN   4.

    Applica$ons  of  MN   3.

QoS  on  the  Internet:   Constraints   12

QoS  on  the  Internet:   Solu5ons  

  

Today’s  Outline  

• Network  support  for  mul$media  
• –  General  QoS  
• –  Differen$ated  QoS  
• –  Per-­‐Connec$on  Flow  QoS  

  

Network  support  for  mul$media  

Approach   Granularity   Guarantee   Mechanism   Complex?   Deployed?   all  traffic   applica$on-­‐layer   Making  best-­‐ treated   support  (CDNs  &   none,  or  so`   minimal   everywhere   effort  service   equally   overlays)   packet  marking,   Differen$ated   per  class  of   none,  or  so`   policing,   medium   some   service   traffic   scheduling   packet  marking,  

  Per-­‐ per  source-­‐ so`  or  hard,   policing,   connec$on   des$na$on   once  is   high   licle   scheduling;  call  

  QoS   flow   admiced   admission  

  Dimensioning best effort networks

• approach:   deploy  enough  link  capacity  so  that  

  conges$on  doesn’t  occur,  mul$media  traffic  flows   without  delay  or  loss  

• –  low  complexity  of  network  mechanisms  (use  current   “best  effort”  network)  
• –  high  bandwidth  costs  
• challenges:  

  how  much  bandwidth  is   “enough?”  

• –   network  dimensioning:  

  needed  to   determine  how  much  bandwidth  is  “enough”  (for  that   much  traffic)  

• –   es3ma3ng  network  traffic  demand:  

Providing  mul$ple  classes  of  service  

• thus  far:  making  the  best  of  best  effort  service  
• –  one-­‐size  fits  all  service  model  
• alterna$ve:  mul$ple  classes  of  service  
• –  par$$on  traffic  into  classes  
• –  network  treats  different  classes  of  traffic  differently   (analogy:  VIP  service  versus  regular  service)   ₀₁₁₁

  granularity:  differen$al      service  among  mul$ple   classes ,  not  among   individual  connec$ons   history:  ToS  bits  

    

Mul$ple  classes  of  service:  scenario  

  H3 H1 R1 R2 H4 R1 output

  1.5 Mbps link H2 interface queue Scenario  1:  mixed  HTTP  and  VoIP  

• •  example:    1Mbps  VoIP,  HTTP  share  1.5  Mbps  link.    

• –  HTTP  bursts  can  congest  router,  cause  audio  loss  
• –  want  to  give  priority  to  audio  over  HTTP  

  R1 R2

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  applica$ons  misbehave  (VoIP  sends  higher   than  declared  rate)  
• –  policing:  force  source  adherence  to  bandwidth  alloca$ons  

    provide  protec$on  (isola$on)  for  one  class  from  others

• marking ,   policing  at  network  edge

     Principle  2  

  R1 R2

  1 Mbps phone packet marking and policing

• alloca$ng  fixed  (non-­‐sharable)  bandwidth  to   flow:  inefficient  use  of  bandwidth  if  flows   doesn ’t  use  its  alloca$on  

  

while  providing  isola$on,  it  is  desirable  to  use    

resources  as  efficiently  as  possible   Principle  3  

  R1 R2

  1 Mbps phone

  

Principles  for  QOS  guarantees  (more)   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  

• –  real-­‐world  example?  

  if  packet  arrives  to  full  queue:  who  to   discard?  

• –   discard  policy:  

  drop  arriving  packet  

• tail  drop:  

  drop/remove  on  priority  basis  

• priority:  

  drop/remove  randomly   queue (waiting area) packet arrivals packet departures link

• random:  

  (server) Scheduling  policies:  priority   high priority queue (waiting area) priority  scheduling:   send  highest   arrivals departures priority  queued   packet     classify link (server) low priority queue

• mul$ple  classes,  

  (waiting area) with  different  

  2 priori$es  

  5

  4

  1

  3 arrivals

• –  class  may  depend   on  marking  or  other  

  packet in 1 3 2 4

  5 header  info,  e.g.  IP   service source/dest,  port   departures numbers,  etc.  

  1

  3

  4

  2

  5

• –  real  world  example?    

Scheduling  policies:  s$ll  more   Round  Robin  (RR)  scheduling:  

• mul$ple  classes  
• cyclically  scan  class  queues,  sending  one   complete  packet  from  each  class  (if  available)  
• real  world  example?  

  2

  5

  1

  4

  3 arrivals packet in

  1

  3

  2

  4

  5 service departures

  1 3 3 4

  5 Scheduling  policies:  s$ll  more  

Weighted  Fair  Queuing  (WFQ):    

• generalized  Round  Robin  
• each  class  gets  weighted  amount  of  service  in   each  cycle  
• real-­‐world  example?  

  Policing  mechanisms  

goal:   limit  traffic  to  not  exceed  declared  parameters  

Three  common-­‐used  criteria:    

•   how  many  pkts  can  be  

    (long  term)  average  rate: sent  per  unit  $me  (in  the  long  run)  

• –  crucial  ques$on:  what  is  the  interval  length:  100   packets  per  sec  or  6000  packets  per  min  have  same   average!  
•  e.g.,  6000  pkts  per  min  (ppm)  avg.;  

    peak  rate: 1500  ppm  peak  rate  

•  max  number  of  pkts  sent  

    (max.)  burst  size: consecu$vely  (with  no  intervening  idle)  

  

Policing  mechanisms:  implementa$on  

token  bucket:   limit  input  to  specified   burst  size   and   average  rate    

           

• bucket  can  hold  b  tokens  

• •  tokens  generated  at  rate  r  token/sec  unless  bucket  full  

• over  interval  of  length  t:  number  of  packets  admiHed  

    less  than  or  equal  to    (r  t  +  b)  

  guarantee!   WFQ token rate, r bucket size, b per-flow rate, R

  Policing  and  QoS  guarantees  

• token  bucket,  WFQ  combine  to  provide  

  guaranteed  upper  bound  on  delay,  i.e.,   QoS  

  D = b/R max arriving traffic arriving traffic Differen$ated  services  

• want  “qualita$ve”  service  classes  
• –  “behaves  like  a  wire”  
• –  rela$ve  service  dis$nc$on:  Pla$num,  Gold,  Silver  

  scalability:   simple  func$ons  in  network  core,    

• rela$vely  complex  func$ons  at  edge  routers  (or  

  hosts)  
• –  signaling,  maintaining  per-­‐flow  router  state    difficult   with  large  number  of  flows    
• don’t  define  define  service  classes,  provide  

  func$onal  components  to  build  service  classes  

    DiffServ  architecture edge router: per-flow traffic management

     marks packets as in-profile and

     out-profile core router: per class traffic management

     buffering and scheduling based on

     marking at edge preference given to in-profile

     packets over out-of-profile packets

    DiffServ  architecture marking r edge router: b per-flow traffic management

     marks packets as in-profile and

     out-profile core router: per class traffic management

     buffering and scheduling based on

     marking at edge preference given to in-profile

     packets over out-of-profile packets

    DiffServ  architecture edge router: scheduling per-flow traffic management

     marks packets as in-profile and

     out-profile .

  . . core router: per class traffic management

     buffering and scheduling based on

     marking at edge preference given to in-profile

     packets over out-of-profile packets

  Edge-­‐router  packet  marking     profile:   pre-­‐nego$ated   rate  r,  bucket  size  b  

    

packet  marking  at  edge  based  on   per-­‐flow  profile  

     rate r b user packets

  :   possible  use  of  marking

class-­‐based  marking:  packets  of  different  classes  marked  

     differently  

intra-­‐class  marking:  conforming  por$on  of  flow  marked  

     differently  than  non-­‐conforming  one  

  DSCP unused Classifica$on,  condi$oning   may  be  desirable  to  limit  traffic  injec$on  rate   of  some  class:  

  Diffserv  packet  marking:  details  

• packet  is  marked  in  the  Type  of  Service  (TOS)   in  IPv4,  and  Traffic  Class  in  IPv6  
• 6  bits  used  for  Differen$ated  Service  Code   Point  (DSCP)  
• –  determine  PHB  that  the  packet  will  receive  
• –  2  bits  currently  unused  

• user  declares  traffic  profile  (e.g.,  rate,  burst   size)  
• traffic  metered,  shaped  if  non-­‐conforming    

  Forwarding  Per-­‐hop  Behavior  (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   $me  intervals  of  a  specified  length  
• –  class  A  packets  leave  first  before  packets  from   class  B  

  

Forwarding  PHB  

PHBs  proposed:  

• expedited  forwarding:   pkt  departure  rate  of  a  

  class  equals  or  exceeds  specified  rate    

• –  logical  link  with  a  minimum  guaranteed  rate  
• assured  forwarding:   4  classes  of  traffic  
>–  each  guaranteed  minimum  amount  of  bandwidth  
• –  each  with  three  drop  preference  par$$ons  

Per-­‐connec$on  QOS  guarantees    

• basic  fact  of  life:   can  not  support  traffic  

  demands  beyond  link  capacity   call  admission:   flow  declares  its  needs,  network  may    

block  call  (e.g.,  busy  signal)  if  it  cannot  meet  needs  

  Principle  4   R1 R2

  1 Mbps phone

  1 Mbps phone

  QoS  guarantee  scenario     resource  reserva3on  

• –  call  setup,  signaling  (RSVP)  
• –  traffic,  QoS  declara$on  

   

• –  per-­‐element  admission  control

QoS  guarantee  scenario     resource  reserva3on  

• –  call  setup,  signaling  (RSVP)  
• –  traffic,  QoS  declara$on  

   

• –  per-­‐element  admission  control QoS-sensitive scheduling

     (e.g., WFQ)

  QoS  guarantee  scenario     resource  reserva3on  

• –  call  setup,  signaling  (RSVP)  
• –  traffic,  QoS  declara$on  

   

• –  per-­‐element  admission  control

  request/ reply QoS-sensitive scheduling

     (e.g., WFQ)