IP Qo S issues From Int Serv to

IP Qo. S issues From Int. Serv to Diff. Serv to Adaptive Qo. S Mangement File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 1

Agenda • • Qo. S and IP networks Int. Serv Diff. Serv Adaptive Qo. S Management File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 2

Qo. S enabling a Network • Goals – Improve network service perceived by applications – Give the network administrator control over network resource usage – These are really the same • If there were infinite network resources, Qo. S would not be necessary – but - there are congestion points – Qo. S is about deciding what traffic gets access to resources at these points File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 3

How can this be achieved? • Correlate packets with traffic sources – sending user, receiving user, application – classify according to common fields in packet headers • Give certain traffic preferential access to resources at congestion points – reserve adequate capacity on transmit interfaces – bypass queues on transmit interfaces – extra buffer space in network elements File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 4

Specifying traffic: Tspec IDEA: call must describe traffic that it will inject into net leaky bucket proposal: traffic entering net filtered by leaky bucket regulator: • B: maximum burst size • r: average rate • amount traffic entering over any interval of length t, less than b + rt File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 5

Token Bucket Possible token bucket uses: – shaping, policing, marking • delay pkts from entering net (shaping) • drop pkts that arrive without tokens (policing function) • let all pkts pass through, mark pkts: those with tokens, those without • network drops pkts without tokens in time of congestion (marking) File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 6

Traffic classes • Networks should match offered service to source requirements (corresponds to utility functions) • Example: telnet requires low bandwidth and low delay – utility increases with decrease in delay – network should provide a low-delay service – or, telnet belongs to the low-delay traffic class • Traffic classes encompass both user requirements and network service offerings File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 7

Traffic classes - details • A basic division: guaranteed service and best effort – like flying with reservation or standby • Guaranteed-service – utility is zero unless app gets a minimum level of service quality • bandwidth, delay, loss – open-loop flow control with admission control – e. g. telephony, remote sensing, interactive multiplayer games • Best-effort – send and pray – closed-loop flow control – e. g. email, net news File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 8

GS vs. BE (cont. ) • Degree of synchrony – time scale at which peer endpoints interact – GS are typically synchronous or interactive • interact on the timescale of a round trip time • e. g. telephone conversation or telnet – BE are typically asynchronous or non-interactive • interact on longer time scales • e. g. Email • Sensitivity to time and delay – GS apps are real-time • performance depends on wall clock – BE apps are typically indifferent to real time • automatically scale back during overload File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 9

Traffic subclasses (roadmap) • ATM Forum – based on sensitivity to bandwidth – GS • CBR, VBR – BE • ABR, UBR • IETF – based on sensitivity to delay – GS • intolerant • tolerant – BE • interactive burst • interactive bulk • asynchronous bulk File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 10

ATM Forum GS subclasses • Constant Bit Rate (CBR) – – constant, cell-smooth traffic mean and peak rate are the same e. g. telephone call evenly sampled and uncompressed constant bandwidth, variable quality • Variable Bit Rate (VBR) – – long term average with occasional bursts try to minimize delay can tolerate loss and higher delays than CBR e. g. compressed video or audio with constant quality, variable bandwidth File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 11

ATM Forum BE subclasses • Available Bit Rate (ABR) – users get whatever is available – zero loss if network signals (in RM cells) are obeyed – no guarantee on delay or bandwidth • Unspecified Bit Rate (UBR) – like ABR, but no feedback – no guarantee on loss – presumably cheaper File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 12

IETF GS subclasses • Tolerant GS – nominal mean delay, but can tolerate “occasional” variation – not specified what this means exactly – uses controlled-load service • controlled load: "a Qo. S closely approximating the Qo. S that same flow would receive from an unloaded network element, but uses admission control to assure that this service is received even when the network element is overloaded. " even at “high loads”, admission control assures a source that its service “does not suffer” – it really is this imprecise! • Intolerant GS – need a worst case delay bound – equivalent to CBR+VBR in ATM Forum model File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 13

IETF BE subclasses • Interactive burst – bounded asynchronous service, where bound is qualitative, but pretty tight • e. g. paging, messaging, email • Interactive bulk – bulk, but a human is waiting for the result – e. g. FTP • Asynchronous bulk – junk traffic – e. g netnews File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 14

Some points to ponder • The only thing out there is CBR and asynchronous bulk! • These are application requirements. There also organizational requirements (link sharing) • Users needs Qo. S for other things too! – billing – privacy – reliability and availability File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 15

Time scales • Some actions are taken once per call – tell network about traffic characterization and request resources – in ATM networks, finding a path from source to destination • Other actions are taken during the call, every few round trip times – feedback flow control • Still others are taken very rapidly, during the data transfer – scheduling – policing and regulation • Traffic management mechanisms must deal with a range of traffic classes at a range of time scales File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 16

Summary of mechanisms at each time scale • Less than one round-trip-time (cell-level) – Scheduling and buffer management – Regulation and policing – Policy routing (datagram networks) • One or more round-trip-times (burst-level) – Feedback flow control – Retransmission – Renegotiation File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 17

Summary (cont. ) • Session (call-level) – – Signaling Admission control Service pricing Routing (connection-oriented networks) • Day – Peak load pricing • Weeks or months – Capacity planning File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 18

Renegotiation • An option for guaranteed-service traffic • Static descriptors don’t make sense for many real traffic sources – interactive video • Multiple-time-scale traffic – burst size B that lasts for time T – for zero loss, descriptors (P, 0), (A, B) • P = peak rate, A = average – T large => serving even slightly below P leads to large buffering requirements – one-shot descriptor is inadequate File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 19

Renegotiation (cont. ) • Renegotiation matches service rate to traffic • Renegotiating service rate about once every ten seconds is sufficient to reduce bandwidth requirement nearly to average rate – works well in conjunction with optimal smoothing • Fast buffer reservation is similar – each burst of data preceded by a reservation • Renegotiation is not free – signaling overhead – call admission ? • perhaps measurement-based admission control File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 20

Signaling • How a source tells the network its utility function • Two parts – how to carry the message (transport) – how to interpret it (semantics) • Useful to separate these mechanisms • call setup protocol needed – to perform call admission – to reserve resources at each router on end-end path File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 21

Signaling semantics • • • Classic scheme: sender initiated SETUP, SETUP_ACK, SETUP_RESPONSE Admission control Tentative resource reservation and confirmation Simplex and duplex setup Doesn’t work for multicast File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 22

Resource translation • Application asks for end-to-end quality • How to translate to per-hop requirements? – E. g. end-to-delay bound of 100 ms – What should be bound at each hop? • Two-pass – forward: maximize (denial!) – reverse: relax – open problem! File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 23

Resource Control • Tasks – Admission Control Tests at connection setup – Reservation of resources at connection setup – Scheduling of resources during runtime Rest Bandbreite • enough capacity for new connection • all existing connections should keep their Qo. S maximale Netzkapazität Verb 2 Verb 1 Zeit • similar to processor scheduling – Release of resources File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 24

Link Layer: critical Qo. S component Buffering and bandwidth: the scare resources • cause of loss and delay • Scheduler as example for resource controller – packet scheduling discipline, buffer management will determine loss, delay seen by a call – Scheduling disciplines: • FCFS • Fair Queuing (FQ) • Weighted Fair Queueing (WFQ) incoming links Link level packet scheduling Outgoing link router File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 25

Scheduling: FCFS • FCFS (First Come First Served) oder FIFO – packets are processed according to their arrival time – buffer overflow-> packets are lost • congestion control at the endpoints of the network necessary – in todays internet IP routers. TCP deals with congestion control – Advantage: simple to implement – Disadvantage: No Qo. S guarantees, because it does not distinguish between packet priorities • FCFS and Priorities – – several queues with different priorities within each queue: FCFS highest priority queue served first no guarantees within each priority class File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 26

Scheduling: Fair Queueing • Idea: Fairness. Each flow gets same amount of bandwidth Per Flow packet Queues • Advantages: Flow 1 pkts – misbehaving source does not influence other flows • Problems: Outgoing link Flow N pkts Round-robin service: • assume fixed length pkts, N session • session i gets to send 1 pkt each "tu service • if session i has no pkt, i+1 gets chan – many queues – Insufficient algorithm: rate depends on packet size • Guarantees minimal throughput File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 27

Scheduling: WFQ • Variant of Fair Queueing: – share per bandwidth varies between flows; negotiated at set-up – Possible implementation: (virtual clock) • Time. Stamp: each packet is associated with a timestamp that determines planed sending time – first packet: connection setup time – other packets: increment timestamp by time difference that matches the average negotiated bandwidth of the flow (act_Packetsize/bandwidth) • what packets are sent first? – Inspect timestamps. Sent packets with minimum time first – Advantage: individual bandwidth share per flow – Disadvantage: Overhead due to scheduling – WFQ guarantees minimal throughput and miximal delay File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 28

IP v 4 Header Prio Delay TP Rel CU CU – Described by TOS-Byte 4 -bit hdr 8 -bit type of serv. version length (TOS) 8 -bit time to live (TTL) 16 -bit total length (in bytes) 3 -bit flags 16 -bit identification • Qo. S in IP-Datagrams 8 -bit protocol 13 -bit fragment offset 16 -bit header checksum 32 -bit source IP address 32 -bit destination IP address Options (if any) • • Priority Delay Throughput Reliability – RFC 791: do not use TOS – IPv 4 can not provide Qo. S data File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 29

IPv 6 DS field (Diff. Serv) Changes to Ipv 4: • • • 128 bit addresses (so we don't run out of IP addresses) header simplification (faster processing) more support for type of service – – • priorities flow identifier: identifiy packets in a connection security Notes: • no fragmentation in network – packet too big generates ICMP error to source – source fragmentation via extension header • no checksum (already done at transport and data link layer) File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 30

Agenda • • Qo. S and IP networks Int. Serv Diff. Serv Adaptive Qo. S Management File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 31

Integrated Services Model 3 Working Groups RSVP Int. Serv Layer 3 ISSLL Layer 2 File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 32

Int. Serv Architecture • RSVP (Resource Reservation Protocol) – Generic Mechanisms – Dynamic, per flow – p-2 -p and multicast • Int. Serv (Integrated Services) – Layer 3 in each entity – classes of service for each flow • Guaranteed • Controlled Load • Best Effort File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 33

Int. Serv Architecture • ISSLL (Integrated Services over a Specific Link Layer) – ISSLOW (Slow Links) • Header Compression • Priority Packets – IS 802 • uses 802. 1 p tagging – ISATM • ATM Qo. S – If no Definition for link layer • Layer 3 packet scheduling File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 34

Int. Serv Architecture • What Int. Serv does NOT: – provide packet forwarding or format specification • still IPv 4, IPv 6 – routing • no Qo. S routing – Admission control in the network • if not enough resources, use best effort class File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 35

Internet signaling transport: RSVP • Main motivation is to efficiently support multipoint multicast with resource reservations – large numbers of heterogeneous receivers – heterogeneity in available bandwidth to receiver – heterogeneity in receiver Qo. S demands (differing delay requirements) • Progression – – – Unicast Naive multicast Intelligent multicast Naive multipoint multicast RSVP File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 36

RSVP in short • Host-network-host Signaling Protocol – – who am I? (user ID, application ID) how can you recognize my packets? what do I want? (service type, quantity) what part of the network will I impact? • Useful for any persistent traffic flows – quantitative (Intserv) – qualitative • Admission control and topology awareness enable stricter guarantees • Unifies other Qo. S mechanisms File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 37

RSVP • When no reservation is needed, no change to internet • Receiver initiated – scalability – heterogeneity, each receiver chooses Int. Serv class • Reservation state per group, instead of per connection • PATH and RESV messages • PATH sets up next hop towards source(s) – no reservations at this point • RESV makes reservation • Travel as far back up as necessary – how does receiver know of success? • DSBM: Designated Subnet Bandwidth Manager for 802 type networks File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 38

Filters and Soft State • Filters – Allow receivers to separate reservations – Fixed filter • receive from exactly one source – Dynamic filter • dynamically choose which source is allowed to use reservation • Soft State – State in switch controllers (routers) is periodically refreshed – On a link failure, automatically find another route – will go away if not "refreshed" by receivers File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 39

Call Setup in RSVP Sender sends Tspec out on multicast tree in PATH message Receiver sends RESV message back up tree: • contains senders Tspec and receiver Qo. S requirement (Rspec) • routers along reverse path reserve resources needed to satisfy receiver's Qo. S File name: IP_Qo. S_01 Originator: A. Kassler Sender Path R 1 R 5 R 2 R 3 R 4 RESV Receiver 1 Status: Lecture Page 40

RSVP: Multicast Multiple receivers: • may have different Qo. S requirements • resource reservations merged as RESV travels upstream • resources must be allocated to satisfy strictest demands of downstream receivers – e. g. : receiver 1 first reserves resources for 100 ms max delay – if receiver 2 Qo. S is 200 ms max delay, no new resources at R 2, R 1 – if receiver 2 Qo. S is 50 ms, more resources needed at R 2, R 1 File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 41

Multiple Receivers Sender R 1 RESV R 5 (merged) R 2 R 3 RESV R 4 RESV Receiver 1 File name: IP_Qo. S_01 Originator: A. Kassler Receiver 2 Status: Lecture Page 42

Multiple Senders Can handle multiple senders as well: – different "styles" of resource reservation • e. g. , reserve enough resources in case all senders simultaneous • resource enough resources for two simultaneous senders • can dynamically determine which of N streams is forwarded downstream (switching within the network) File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 43

Example Data Handling & RSVP Signaling End-to-end RSVP signaling Sender Receiver Switched Network (in-house) File name: IP_Qo. S_01 Originator: A. Kassler Small Routed Networ k (ISP) Large Routed Network (Core) ATM Network Status: Lecture Page 44

RSVP Drawbacks • Qo. S guarantees – every router has to use RSVP and Resource Reservation • Scalability – Context per flow in each router, even if no reservation is requested • the RESV message must follow the same path than the PATH message • Internet Routing is asymetrical – per packet classification in router File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 45

Renegotiation problems • Static descriptors don’t make sense for interactive sources or multiple-time scale traffic • Renegotiation matches service rate to traffic • Renegotiation is not free- incurs a signaling overhead • Open questions – – when to renegotiate? how much to ask for? admission control? what to do on renegotiation failure? File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 46

Agenda • • Qo. S and IP networks Int. Serv Diff. Serv Adaptive Qo. S Management File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 47

Differentiated Services Model Receiver Sender • establishes TOS • can control bitrate to assure QOS Edge Router (Egress) Edge Router (Ingress) • verify conformance (shape/tag/drop) • assigns label to packet • • Diff. Ser v Cloud Better than Best Effort In-Band Signalling (Packet Header) Complexity shifted towards Edge Router Simple Charging (Service Level Agreement) File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 48

Diff. Serv in short • Aggregate traffic handling mechanism • Defines a small number of per-hop behaviours (PHBs) supported in routers – invoked by per-packet marking • Concatenation of ‘hops’, with admission control, can provide useful services across the Diff. Serv cloud • Very scaleable – no inherent signaling – little state required File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 49

Class-based Qo. S • Internet model requires per session state at each router – 1000 s - 1000000 s of flows • reluctance on part of network admins to accept • Differentiated service model: 3+ classes – Premium service: • high scheduling priority - aggregate peak rate allocation - low delay – Assured service: • high buffer priority => lower loss – Best effort service: • the usual File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 50

Diff. Serv classes RFC 2597, 2598 Bronze Silver Gold Higher Drop Precedence dropped first File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 51

DSCP Filed DSCP DS field CU IP Precedence • • DS field = ex-Tos Field for IPv 4 (rfc 791) Traffic Class octet for IPv 6 • --> DS field both in IPv 4 and IPv 6 header • • DSCP : Differentiated Service Code Point = 6 bits CU: Currently Unused = 2 bits File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 52

Differentiated Services DSCP Simple Tasks Data Traffic Classification, Policing, Shaping File name: IP_Qo. S_01 Originator: A. Kassler EDGE Complex Tasks EDGE CORE PHB: Per Hop Behavior • Congestion-Mgmt • Queuing+Scheduling > RED, WFQ, . . . Status: Lecture Page 53

Diff. Serv Architecture (simplified) IP packets classifier Backbone Conditioner Marker • Classifier – Behavior Aggregate (BA): only DSCP (index into PHB table). Policy dictates configuration of PHB – Multifield (MF), other header info (Port, Protocol, DA, SA) • Marker – add DSCP if empty – add DSCP as mapped from RSVP-Params – map DSCP <-> IP-TOS – change DSCP according to local policy – can apply traffic shaping File name: IP_Qo. S_01 Originator: A. Kassler Edge Meter • – statistics Conditioner – – – applies PHB queue selection and treatment policing packet dropping authentication for Admission Control Status: Lecture Page 54

Service Level Agreement (SLA) • SLA – – between border networks defines traffic profile establishes policy criteria traffic will be policed and smoothed at egress points according to the SLA – “out of profile” traffic at ingress point have no guarantees File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 55

Trade. Off • Qo. S mechanisms range in complexity – processing overhead – state overhead – not referring to complexity of usage here • Generally, at a given level of complexity, the network administrator can tradeoff: – efficiency with which network resources are used – strictness (tightness) of Qo. S guarantees File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 56

Agenda • • Qo. S and IP networks Int. Serv Diff. Serv Adaptive Qo. S Management File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 57

Motivation • Stream Tailoring as Qo. S enforcement mechanism – to match different receivers Qo. S req. Temporal Filtering • processing power • network connection properties – match different receivers vis. req. • • • temporal domain spatial domain frequency domain combinations/transcoders error resilience (seg. /re-assembly) – influences Bandwidth – influences Qo. S – Different Scenarios • Vo. D File name: IP_Qo. S_01 • Realtime Conferences Originator: A. Kassler Spatial Filtering Frequency Filtering Combi Filtering Status: Lecture Page 58

Qo. S related Tasks • Support – quality enhanced multimedia communication using a Qo. SFramework – Multicast scenarios – Mobility (Session-Mobility) – Adaptivity (Transparent vs. Adaptive) – Heterogenity (end hosts, network characteristics – Fairness-Policies (IETF Policy Framework) – simple, yet powerful API (Qo. S-API) – different media qualities (Videoconference vs. S-VHS) • Use networkspezific QOS Mechanisms • media stream adaptation in network and end hosts • user friendly interface for Qo. S specification File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 59

Adaptive Qo. S Middleware User Qo. S Requirement Application Protocol Layers Network Subsystem Distributed Qo. S Architecture • Mobility • Adaptivity • Heterogenity Qo. S Monitoring Qo. S Mechanisms/ Negotiation Adaptive Endsystem Active Netwerk, Adaptive Services provides Qo. S (Int. Serv, Diff. Serv, . . . ) and Adaptation File name: IP_Qo. S_01 Originator: A. Kassler Qo. S-Management Media Processors Qo. S-Management Qo. S Specification Media Processors Protocol Layers Network Subsystem Adaptive Endsystem Adaptive Services Status: Lecture Page 60

Qo. S in mobile networks + Filtering Main goal: support adaptive media streaming given soft end-to-end Qo. S requirements adaptive media filtering, media scaling and media transcoding at the end-systems and inside the net under given Qo. S requirements to serve heterogeneous and moving receivers Filters bridge Heterogenity Gap inherent to Wireless Communication Objectives: ü FAST (real-time streaming) ü Scalable System (support several users simultaneously) ü Scalable Bandwidth Adaptation (wireless + wired users) ü Support for broad range of adaptation mechanisms (different Qo. S wishes) ü Configurable (for different receivers and scenarios) ü Chainable (Filterchain) ü Robust (protect wireless transmission if desired) File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 61

Usage Scenario 1. 436 mbps full quality Q Q Core-Net F Q Policy Server 78 kbps F Q Q Vo. D Server 1. 436 mbps full quality Router Q Q 1. 182 mbps lower Quality Q 78 kbps Q F Wireless Proxy Server Admission Control Q QQ F F 78 kbps F 36 kbps 25. 2 kbps Q Qo. S Framework F Media Filter Mobile Subnet with Wireless Proxy Server • Multimedia Adaptation Services Base Station 78 kbps 32. 2 kbps FQ FQ • Error Control (local re-transmit) • Policy-Control File name: IP_Qo. S_01 Originator: A. Kassler Status: Lecture Page 62