Resource Control and Reservation October 30, 2001 RSVP 2 Resource - - PowerPoint PPT Presentation

▶
resource control and reservation
SMART_READER_LITE
LIVE PREVIEW

Resource Control and Reservation October 30, 2001 RSVP 2 Resource - - PowerPoint PPT Presentation

Dec 02, 2023 39 likes •393 views

RSVP 1 Resource Control and Reservation October 30, 2001 RSVP 2 Resource Control and Reservation policing: hold sources to committed resources scheduling: isolate flows, guarantees resource reservation: establish flows October 30,

slide-1
SLIDE 1

RSVP 1

Resource Control and Reservation

October 30, 2001

slide-2
SLIDE 2

RSVP 2

Resource Control and Reservation

  • policing: hold sources to committed resources
  • scheduling: isolate flows, guarantees
  • resource reservation: establish flows

October 30, 2001

slide-3
SLIDE 3

RSVP 3

Usage parameter control: leaky bucket algorithm

  • constrain what host can inject into the network
  • single server queue with fixed service time
  • finite-size bucket ➠ either throttle source or loose packets
  • no burstiness allowed

October 30, 2001

slide-4
SLIDE 4

RSVP 4

Leaky bucket algorithm

Faucet Leaky bucket Water drips out of the hole at a constant rate Host computer Packet The bucket holds packets Unregulated flow Regulated flow Network Interface containing a leaky bucket Water (b) (a)

October 30, 2001

slide-5
SLIDE 5

RSVP 5

Token bucket

  • tokens allow bursts into the network
  • tokens generated at constant rate up to maximum burst size
  • if no token, either quench source or drop packet
  • implementation: token counter, incremented periodically

October 30, 2001

slide-6
SLIDE 6

RSVP 6

Generic Cell Rate Algorithm (GCRA)

Mechanism used by UNI 3.1 to police either peak or mean cell rate. PCR: peak cell rate SCR: sustainable cell rate = mean cell rate CDVT: cell delay variation tolerance τs: burst tolerance peak rate mean rate T 1/PCR 1/SCR L CDVT τs

October 30, 2001

slide-7
SLIDE 7

RSVP 7

GCRA

  • cell i can arrive at ti > ti−1 + T − L; but: arrival time set to

ti = ti−1 + T

  • can’t save up late arrivals
  • can’t accumulate L

October 30, 2001

slide-8
SLIDE 8

RSVP 8

GCRA flow chart

YES NO NO YES arrival of cell k a at time t (k) TAT = TAT + T conforming cell TAT = t (k) a TAT? cell non-conforming t (k) + L < a a t (k) > TAT?

TAT = theoretical arrival time

October 30, 2001

slide-9
SLIDE 9

RSVP 9

GCRA

T-ε T-ε T-ε T-ε T-ε T 2T 3T 4T 5T 1 2 3 4 5 6 Non- conforming cell Time ε 2ε 3ε (a) (b) 4ε 5ε T Fluid level Bucket limit

October 30, 2001

slide-10
SLIDE 10

RSVP 10

Packet scheduling

work conserving: never delay a packet if line is idle ➠ no lower bound

  • n jitter

non-work-conserving: minimum residency time ➠ jitter bound Isolation: one misbehaving source can’t monopolize resources

October 30, 2001

slide-11
SLIDE 11

RSVP 11

FIFO+ and HL

For packets with real-time constraints (deadlines) ➠ give priority to those about to miss their deadline hop-laxity: priority = hops to go time left drop packets that have exceeded their deadline or are too close FIFO+: give priority to packets if travel time > average for class

  • both require accumulating delays
  • performance better than FIFO
  • but: no guarantees, scheduling overhead

October 30, 2001

slide-12
SLIDE 12

RSVP 12

Weighted Fair Queueing (WFQ)

  • fair queueing: separate queues for each input stream, round-robin ➠

favors long packets, wait for n other queues if a bit too late

  • ➠ WFQ: order transmissions by when last bit would have been sent

under bit-by-bit round robin

  • need ordered queue of size q: O(log q) ➠ expensive
  • divide bandwidth into m-bit cycles and distribute unequally

October 30, 2001

slide-13
SLIDE 13

RSVP 13

Weighted Fair Queueing

Delay Di of flow i if token bucket at edge: Di = βi gi + (hi − 1)li gi +

hi

  • m=1

l⋆ rm where β: bucket size; gi: fraction; li: maximum packet length for i; l⋆: maximum packet length in network; hi: number of hops; rm: outbound bandwidth

October 30, 2001

slide-14
SLIDE 14

RSVP 14

Reservations

First approach: everybody is the same ➠ best effort ➠

  • enough bandwidth for everybody (telephone network)
  • “human backoff” if unusable
  • TCP for data applications (but: also minimum usable bandwidth)
  • adjust audio or video coding to best possible ➠ application control

(later)

  • pick least congested route: telephone system, but Internet too large

October 30, 2001

slide-15
SLIDE 15

RSVP 15

Reservations

Some are more equal than others ➠

  • incumbency protection
  • priorities (general over PFC)
  • bulk service vs. priority delivery ➠ cost

October 30, 2001

slide-16
SLIDE 16

RSVP 16

Reservations

$/kb/s may be dynamic ➠

  • reservation may change during the lifetime of an application
  • networks may not be homogeneous ➠ different multicast groups for

different layers or versions

October 30, 2001

slide-17
SLIDE 17

RSVP 17

RSVP

Receiver-oriented, out-of-band reservation protocol standardized by IETF:

  • not a routing protocol, but interacts with routing
  • may need QOS routing to pick appropriate path
  • transports opaque QOS and policy parameters for sessions
  • flow: group of packets being treated the same ➠ same multicast

group or destination, IPv6 flow id, . . .

  • simplex ➠ setup for unidirectional data flows

October 30, 2001

slide-18
SLIDE 18

RSVP 18

RSVP, cont’d.

  • does not prescribe admission or policy control
  • sets up packet classifier, but does not handle packets
  • independent sessions (can’t tie video and audio session)
  • multicast (and unicast)
  • either own protocol type or UDP encapsulated

October 30, 2001

slide-19
SLIDE 19

RSVP 19

RSVP Objects

Flow descriptor = Flowspec:

  • service class
  • Rspec ➠ desired QoS
  • Tspec ➠ describes traffic characteristics

Filterspec: which packets get this treatment ➠ sender IP address/port, protocol, other fields ➠ complex (regular expressions? IP options!) ➠ currently, sender IP address and UDP/TCP port ➠ no fragmentation

October 30, 2001

slide-20
SLIDE 20

RSVP 20

Reservation Styles

sender reservations selection distinct for each sender shared explicit fixed filter (FF) shared-explicit (SE) wildcard (all) – wildcard filter (WF) ➠ mutually incompatible explicit: list senders by address wildcard: any sender with a specific port (e.g.) shared: only one active data source ➠ e.g., reserve for twice needed for audio distinct: video

October 30, 2001

slide-21
SLIDE 21

RSVP 21

RSVP: basic operation

Data (multicast) PATH RESV S R R R D D data sender receivers network of routers

  • receiver joins group via IGMP
  • source sends PATH messages to receivers ➠ same path as data:

previous hop to source, Tspec ↔ RESV one path, data another

  • receivers send RESV messages back to senders

October 30, 2001

slide-22
SLIDE 22

RSVP 22

RSVP: basic operation

  • reservations may be lowered
  • reservations are merged at each node for same sender: max.

flowspec

  • merge point or data sender may send confirmation (if requested)
  • reservations may get merged between senders (audio!)
  • one-pass ➠ receiver doesn’t know final QoS ➠ One Pass With

Advertising

  • application should explicitly tear down reservations

October 30, 2001

slide-23
SLIDE 23

RSVP 23

Killer Reservations

  • 1. small reservation in place; another receiver larger reservation ➠

failure? ➠ keep old

  • 2. large reservation fails again and again ➠ blocks new, smaller one

receiver source receiver 100 kb/s 200 kb/s data loss! reservation capacity: 150kb/s merged: 200 kb/s

October 30, 2001

slide-24
SLIDE 24

RSVP 24

RSVP service classes

guaranteed: no loss, upper bound on delay controlled load: “few” losses, “like unloaded network” ➠ delay-adaptive applications best effort: no guarantees; current IP service model ➠ delay + bandwidth adaptive services

  • thers: research

October 30, 2001

slide-25
SLIDE 25

RSVP 25

RSVP vs. ATM resource reservation

IP, RSVP ATM multicast tree, reservation sequential same time

  • rigin

receiver sender (root) ➠ UNI4.0 change reservations yes no routing changes time-out re-establish VC routing IP routing PNNI (QOS) flow merging (audio) yes no (separate VCs) receiver diversity not yet no state soft hard

October 30, 2001

slide-26
SLIDE 26

RSVP 26

The recurring costs of reservations

Signaling: processing and state maintenance, APIs Routing: QoS path selection, state distribution Policy: who gets what (and who doesn’t) Charging, billing, accounting, service contracts: right party pays for usage, ensure QoS is delivered as promised

October 30, 2001

slide-27
SLIDE 27

RSVP 27

RSVP implementation

  • scheduling: about 10% cost overhead
  • low-end 68040: 0.73 ms for PATH, 0.37 ms for RESV
  • ➠ approximately 1,000 flow setups/s
  • processing of PATH (RESV) refresh: 0.33 ms (0.29 ms)
  • ➠ approximate capacity is 1,600 flows
  • about 500 bytes/flow
  • refresh bandwidth ≈ 100 kb/s for 1000 flows (30 s refresh)
  • PATH: 208 bytes, RESV: 148 bytes

October 30, 2001

slide-28
SLIDE 28

RSVP 28

Resource reservation: general comments

  • doesn’t help if network capacity ≪ demand
  • modes:

receiver-oriented: RSVP sender-oriented: YESSIR

  • scaling issues: a reservation for every phone call ↔ datagram idea,

routing aggregation

October 30, 2001

slide-29
SLIDE 29

RSVP 29

RSVP problems

  • if reservation/tear down request lost, no immediate feedback
  • can increase reservation latency or “phone off hook”
  • large number of refreshes ➠ scaling problems

➠ hop-by-hop confirmation (→ extend refresh interval)

October 30, 2001

slide-30
SLIDE 30

RSVP 30

RSVP scaling

Scaling issues:

  • number of flow states ➠ refresh, memory, time-outs
  • large number of packet queues

Alternatives:

  • “tunnels” = encapsulation IP-in-IP ➠ overhead
  • aggregation for sender reservation ➠ flow classes
  • drop and delay preferences

October 30, 2001

slide-31
SLIDE 31

RSVP 31

YESSIR: Yet another Sender Session Internet Reservation

  • RSVP: separate daemon, API
  • ➠ integrate into application that needs it (embedded systems!)
  • in-band ➠ easier firewall
  • router alert option
  • soft-state + RTCP BYE
  • partial reservations: add links as session ages ↔ fragmentation

October 30, 2001

slide-32
SLIDE 32

RSVP 32

YESSIR

plain RTCP SRs or additional information:

YESSIR message:

  • reservation command: active/passive
  • reservation style, refresh interval
  • reservation flow specification
  • link resource collection
  • reservation failure report

IP Header with Router-Alert Option UDP Header RTCP message: Sender Report:

  • sender information
  • detailed report for each source

Profile-specific extensions

end-to-end refresh (vs. hop-by-hop)

October 30, 2001

slide-33
SLIDE 33

RSVP 33

YESSIR

  • measurement mode
  • IntServ flow specs
  • PT-based for well-known PTs
  • TOS-based: value
  • killer reservations ➠ SR reservation failure
  • OPWA: hop count, propagation delay, aggregated bandwidth, delay

bounds ➠ updated at router

  • cost: 360 µs

October 30, 2001

slide-34
SLIDE 34

RSVP 34

SRP: Scalable Reservation Protocol

  • sender-oriented, out-of-band
  • data packets marked as REQUEST ➠ learn reservation level
  • router aggregates requests, downgrades to best effort
  • receiver reports rate of successful REQUESTS
  • ➠ sender adjusts rate RESERVED data packets
  • aggregation by estimation:
  • max(observed traffic over several intervals)
  • effective bandwidth e = sup
  • ni

tj−ti+D

October 30, 2001

slide-35
SLIDE 35

RSVP 35

SRP packet processing

best effort class ? be schedule in the Can the packet Reserved Request Reserved No Best effort Reserved Request Yes Best effort No No Yes Discard Can the packet class ? reserved service be schedule in the Yes Request

estimated bandwidth Is an update of the estimated bandwidth acceptable ?

Best effort

Packet scheduler

Update the

SRP estimator

October 30, 2001