Quality of Service -Guaranteed bandwidth }__ allocate circuit -Guaranteed delay/jitter } -Average bandwidth over time What we're guaranteeing: (table showing different options) connect | delay | bw | avg bw | bw change Int serv { absolute | | | | { predicted | | | | Diff serv{better than best | | | | { best effort | | | | Today: -circuits -paris metro pricing -price determines class of service -premium for high quality connectivity -over-provision! How much to pay for quality? (2x ?) Various types of quality/service: -fixed(f)/variable(v) rate -tolerant(t)/intolerant(i) of loss/delay -adaptive(a)/non-adaptive(na) rate/delay Applications: -robot surgery (f, i, na) -teleconferencing (v, t, a) -video on demand -online gaming (v, i, a) (latency/jitter matters) -internet radio/TV broadcast (delay ok, bw matters) -online shopping -web surfing Mechanism/Cost: -lightweight circuit provisioning Is delay adaptation a long term solution? Ok to shift jitter between users? con: synchronization of bursts pro: if well behaved, then better statistical multiplexing Do we need any special hardware support for QoS? -different customers will demand different quality Over-provisioning along is not enough; must distinguish between users: -synchronized bursts can cause problems -large flows Mechanism (5 parts): -service model (guaranteed, predicted, ...) -flow specification -admission control -reservation protocol -scheduling Flow Specification: -fixed bandwidth, leaky bucket (bandwidth + buffer for bursts), tolerance for loss/delay, latency target Admission Control: -strict guarantee - flow spec is met at every hop, rate < capacity -predicted service (if behavior of others is stable) -rate < measured capacity -delay (measured delay/jitter of higher priority traffic) -priorities (in spec/out spec) -Over-provisioning for high priority Reservation Protocol: -RSVP, circuits -check for reserved bandwidth along path; out of luck if path changes