Lecture 15: Routers and QoS - Home | Computer Science and … · Lecture 15 Overview" Router Basics Buffer Management Traffic Policing/Scheduling Quality of service basics CSE 123

CSE 123: Computer Networks Alex C. Snoeren

Lecture 15:Routers and QoS"

HW 4 due next Tuesday!

Lecture 15 Overview"  Router Basics

  Buffer Management

  Traffic Policing/Scheduling

  Quality of service basics

2 CSE 123 – Lecture 15: Routers and QoS

  Physical components ◆  One or more input interfaces that receive packets ◆  One or more output interfaces that transmit packets ◆  A chassis (box + power) to hold it all

  Functions ◆  Forward packets ◆  Drop packets (congestion, security, QoS) ◆  Delay packets (QoS) ◆  Transform packets? (Encapsulation, Tunneling)

Whatʼs in a Router?"

CSE 123 – Lecture 15: Routers and QoS 3

Reservation/ Admission Control

Routing Protocols

Routing Table

Classification Rules

Firewall

Packet Classification Switching

Forwarding Table

Output Scheduling

Control Plane •  Complex •  Per-control action •  May be slow

Data plane •  Simple •  Per-packet •  Must be fast

Router Architecture"

4

  Buffer management: which packet to drop when? ◆  We only have finite-length queues

  Scheduling: which packet to transmit next?

1

2

Scheduler

flow 1

flow 2

flow n

Classifier

Buffer management

Key Router Challenges"


  FIFO + drop-tail ◆  Simplest choice ◆  Used widely in the Internet

  FIFO (first-in-first-out) ◆  Implies single class of traffic

  Drop-tail ◆  Arriving packets get dropped when queue is full regardless of

flow or importance

  Important distinction: ◆  FIFO: scheduling discipline ◆  Drop-tail: drop policy


Basic Buffer Management"

  Leaves responsibility of congestion control completely to the edges (e.g., TCP)

  Does not separate between different flows

  No policing: send more packets à get more service

  Synchronization: end hosts react to same events

FIFO/Drop-Tail Problems"


  Design active router queue management to aid congestion control

  Why? ◆  Router has unified view of queuing behavior ◆  Routers see actual queue occupancy (distinguish queue

delay and propagation delay) ◆  Routers can decide on transient congestion, based on

workload

Active Queue Management"


  Keep throughput high and delay low ◆  High power (throughput/delay)

  Accommodate bursts

  Queue size should reflect ability to accept bursts rather than steady-state queuing

  Improve TCP performance with minimal hardware changes

Design Objectives"


  Detect incipient congestion

  Assume hosts respond to lost packets

  Avoid window synchronization ◆  Randomly mark packets

  Avoid bias against bursty traffic

Random Early Detection"


  Maintain running average of queue length

  If avg < minth do nothing ◆  Low queuing, send packets through

  If avg > maxth, drop packet ◆  Protection from misbehaving sources

  Else drop/mark packet in a manner proportional to queue length

◆  Notify sources of incipient congestion

RED Algorithm"


Min thresh Max thresh

Average Queue Length

minth maxth

maxP

1.0

Avg queue length

P(drop)

RED Operation"


Bottleneck link (10 Mbps)

1 UDP (10 Mbps) and 31 TCPs sharing a 10 Mbps line

UDP (#1) - 10 Mbps

TCP (#2)

TCP (#32)

. . .

UDP (#1)

TCP (#2)

TCP (#32)

. . .

Non-responsive Senders"


UDP vs. TCP"


  Parameters ◆  r – average rate, i.e., rate at which tokens fill the bucket ◆  b – bucket depth ◆  R – maximum link capacity or peak rate (optional parameter)

  A bit is transmitted only when there is an available token

r bps

b bits

<= R bps time

bits

b*R/(R-r)

slope R

slope r

Maximum # of bits sent

Token Bucket Basics"


  Drop packets that don’t meet user profile   Output limited to average of r bps and bursts of b

Test if token

token

No token, drop

Packet input

Packet output

r bps

b bits User Profile (token bucket)

Traffic Policing"


  Shape packets according to user profile   Output limited to average of r bps and bursts of b

Wait for token

Packet input

Packet output

Queue, Drop on overflow

r bps


Traffic Shaping"


  r = 100 Kbps; b = 3 Kb; R = 500 Kbps

3Kb

T = 0 : 1Kb packet arrives

(a)

2.2Kb

T = 2ms : packet transmitted b = 3Kb – 1Kb + 2ms*100Kbps = 2.2Kb

(b)

2.4Kb

T = 4ms : 3Kb packet arrives

(c)

3Kb

T = 10ms :

(d)

0.6Kb

T = 16ms : packet transmitted

(e)

Shaping Example"


  Mark packets according to user profile   During congestion, drop unmarked pkts first

Test if token

Mark packet

token

No token

Packet input

Packet output

r bps


Buffer Management"


  So far, we have assumed all traffic is equal and provided best effort delivery ◆  Perhaps with enforcement to throttle non-responsive senders

  Not always best model. Why? ◆  Application demands

»  I want low-delay low-loss for phone service ◆  Market differentiation

»  I want to sell better service for more money ◆  Bandwidth management

»  Don’t let BitTorrent eat up all UCSD bandwidth

Quality of Service (QoS)"


  Basic idea ◆  Sample signal, packetize, transmit ◆  Repeat in reverse at receiver

  Network Requirements (@ given load) ◆  Delay ◆  Jitter (variation in delay) ◆  Packet loss ◆  Exact parameters a function of interactivity demands, buffer

capacity, retransmission time and loss tolerance ◆  However… as a rule they want more

Multimedia Applications"


Util

ity

Delay-adaptive

Bandwidth

Util

ity Hard real-time

Bandwidth

Bandwidth

Elastic

Util

ity

Different Demands"


  Want to treat some traffic better/worse than others ◆  How to identify the more important traffic? ◆  How much better do we want to treat it? ◆  How do we actually treat it better?

  Router classifies based on packet header ◆  Aggregates

»  From particular network (IP src address) »  For particular protocol (e.g., port 80 traffic)

◆  Individual network flows »  5-tuple (src, dst, src port, dst port, protocol)

◆  Special header field that indicates traffic “type”

Packet Classification"


  Best-effort ◆  Vanilla IP

  Differentiated services ◆  Bronze, Silver, Gold, etc… (effectively priorities,

up to some amount of bandwidth per time) ◆  E.g., best service up to 10Mbps, then best effort

  Predicted service (soft real-time) ◆  Network guarantees good performance on average ◆  Application promises only send as fast as negotiated

  Guaranteed service (hard real-time) ◆  Network guarantees good performance always ◆  Application promises only send as fast as negotiated

Service Classes"


  Kind of service (service class)   Specify “flowspec” for data flow limits

◆  Tspec: describes the flow’s traffic characteristics »  Average bandwidth + burstiness (contract with ISP)

◆  Rspec: describes the service requested from the network (e.g., delay target)

  Interface can be interactive (ask network) or via business interface (ask salesman) ◆  Can say no ◆  If yes, then use scheduling mechanisms in routers (not FIFO

anymore) to deliver

How to Specify?"


Admission Control?

Data In Data Out

Co

ntr

ol P

lan

e

Dat

a P

lan

e

Scheduler

Routing Routing Messages

QoS Control messages

Classifier

Signaling

Dest Lookup

Forwarding Table Per Flow QoS Table

More Complicated Routers"


  So far we’ve done flow-based traffic policing ◆  Limit the rate of one flow regardless the load in the network

  In general, need scheduling ◆  Dynamically allocate resources when multiple flows compete ◆  Give each “flow” (or traffic class) own queue (at least

theoretically)

  Weighted fair queuing ◆  Proportional share scheduling ◆  Schedule round-robins among queues in proportion to some

weight parameter

Scheduling"


TCP vs. UDP w/Fair Queuing"


Flow 1

Flow 2

Flow n

I/P O/P

(Weighted) Fair Queuing"


  Maintain a queue for each flow ◆  What is a flow?

  Implements max-min fairness: each flow receives min(ri, f) , where

◆  ri – flow arrival rate ◆  f – link fair rate (see next slide)

  Weighted Fair Queuing (WFQ) – associate a weight with each flow

Fair Queuing"


  If link congested, compute f such that

8 6 2

4 4

2

f = 4: min(8, 4) = 4 min(6, 4) = 4 min(2, 4) = 2

10

Fair Rate Computation"


  Associate a weight wi with each flow i   If link congested, compute f such that

8 6 2

4 4

2

f = 2: min(8, 2*3) = 6 min(6, 2*1) = 2 min(2, 2*1) = 2

10 (w1 = 3) (w2 = 1) (w3 = 1)

If Σk wk <= C, flow i is guaranteed to be allocated a rate >= wi

Flow i is guaranteed to be allocated a rate >= wi*C/(Σk wk)

Another Example"


  Flows can be served one bit at a time

  WFQ can be implemented using bit-by-bit weighted round robin

◆  During each round from each flow that has data to send, send a number of bits equal to the flow’s weight

Fluid Flow"


0 15 2 10 4 6 8

5 1 1 1 1 1

  Orange flow has packets backlogged between time 0 and 10

  Other flows have packets continuously backlogged

  All packets have the same size

flows

link

weights

Fluid Flow Example"


  Packet (Real) system: packet transmission cannot be preempted. Why?

  Solution: serve packets in the order in which they would have finished being transmitted in the fluid flow system

Packet-Based Implementation"


0 2 10 4 6 8

0 2 10 4 6 8

  Select the first packet that finishes in the fluid flow system

Service in fluid flow

system

Packet system

Packet-Based Example"


Summary"


  Routers manage their own resources ◆  Buffer management may entail marking/dropping ◆  Scheduling discipline determines outgoing packet order

  Token bucket and RED ◆  Mechanisms to control traffic flowing through routers

For next time…"   Read Ch. 2.8,.4.4 in P&D

  Good luck on HW 4

  Have a great Thanksgiving!

38 CSE 123 – Lecture 15: Routers and QoS

Documents

Lecture 15: Routers and QoS - Home | Computer Science and … · Lecture 15 Overview" Router Basics Buffer Management Traffic Policing/Scheduling Quality of service basics CSE 123