Providing QoS in IP Networks Future: next generation Internet with QoS guarantees m Differentiated...
Embed Size (px)
Transcript of Providing QoS in IP Networks Future: next generation Internet with QoS guarantees m Differentiated...
- Slide 1
Providing QoS in IP Networks Future: next generation Internet with QoS guarantees m Differentiated Services: differential guarantees m Integrated Services: firm guarantees r simple model for sharing and congestion studies: Slide 2 Principles for QoS Guarantees r Example: 1Mbps IP phone, FTP share 1.5 Mbps link. m bursts of FTP can congest router, cause audio packets to be excessively delayed or lost m want to give priority to audio over FTP packet marking needed for router to distinguish among packets belonging to different classes of traffic; new router policy needed to treat packets accordingly Principle 1 Slide 3 Principles for QoS Guarantees what if applications misbehave (e.g. audio sends higher than declared rate)? r policing: force source adherence to certain criteria (drop or delay packets, e.g., leaky bucket) r Packet classification/marking and policing done at network edge (in the host or at an edge router) provide protection (isolation) for one class from others Principle 2 Slide 4 Principles for QoS Guarantees r Allocating fixed (non-sharable) bandwidth to each flow: inefficient use of bandwidth if flows doesnt use its allocation While providing isolation among flows, it is desirable to use resources as efficiently as possible Principle 3 Slide 5 Principles for QoS Guarantees r Basic fact of life: can not support traffic demands beyond link capacity Call Admission: flow declares its QoS requirement, network either accepts the flow or blocks the flow (if it cannot provide the required QoS). Principle 4 Slide 6 Scheduling Mechanisms r scheduling: choose next packet to send on link r FIFO (first in first out) scheduling: send in order of arrival to queue r Drawbacks of FIFO scheduling m No special treatment is given to packets from flows that are of higher priority or are more delay sensitive m Flows of larger packets get better service m A greedy flow will adversely affect other flows Slide 7 Scheduling Mechanisms Priority scheduling: r Multiple priority classes, each has its own queue r A packets priority class may depend on an explicit marking or other header info, e.g. source/dest IP address, source/dest port number, etc. r Transmit a packet from the highest priority class that has a nonempty queue Slide 8 Scheduling Mechanisms Round Robin scheduling: r multiple classes, each has own queue r cyclically scan class queues, serving one packet from each class (if available) m No advantage in being greedy r Work-conserving queuing discipline: never allow the link to remain idle whenever there are packets queued for transmission Slide 9 Scheduling Mechanisms Weighted Fair Queuing (WFQ): approximate fluid fair queuing (FFQ) r FFQ: m A separate FIFO queue for each connection sharing the same link. m During any time interval when there are N nonempty queues, the server serves the N packets at the head of the queues simultaneously m At any time t, the service rate for a nonempty queue i is where w i is the weight associated with queue i, B(t) is the set of nonempty queues, and C is the link speed. m FFQ allows different connections to have different service shares. Slide 10 WFQ r FFQ is impractical because m Only one connection can receive service at a time m An entire packet must be served before another packet can be served r WFQ: When the server is ready to transmit the next packet at time t, it picks the first packet that would complete service in the corresponding FFQ system if no additional packets were to arrive after time t Slide 11 Policing Mechanisms Goal: regulate the rate at which a flow is allowed to inject packets into the network Three policing criteria: r (Long term) Average Rate: how many packets can be sent per time interval m crucial question: what is the interval length? r Peak Rate: max. number of packets that can be sent over a short period of time. r Burst Size: max. number of packets that can be sent consecutively (with no intervening idle) Slide 12 Policing Mechanisms Token Bucket: limit input to specified Burst Size and Average Rate. r bucket can hold b tokens r tokens generated at rate r token/sec m Token added to bucket if bucket not full, ignored otherwise r A packet must remove a token from the token bucket before it is transmitted into the network Slide 13 Policing Mechanisms (more) For a leaky-bucket-policed flow: r The max. burst size is b packets r Over interval of length t: max. number of packets admitted is (r t + b) r limit the long term average rate r Leaky bucket + WFQ = guaranteed upper bound on end-to-end delay and delay jitter, i.e., QoS guarantee! m A connections guaranteed rate must be greater than or equal to the connections average rate Slide 14 IETF Integrated Services (RFC1633) r Architecture for providing QoS guarantees to individual application sessions r Call setup: A session requiring QoS guarantees must first reserve sufficient resources at each router on its path before transmitting data r Arriving session must: m declare its QoS requirement using R-spec m characterize traffic it will send into network using T-spec r A signaling protocol is needed to carry R-spec and T-spec to routers m RSVP r Router must determine whether or not it can admit the call r Router must maintain per-flow state (allocated resources, QoS requests) Slide 15 Router components Classifier: perform a Multi-Field (MF) classification and put the packet in a specific queue based on the classification result. Packet scheduler: schedule the packet accordingly to meet its QoS requirements. Slide 16 RSVP r RSVP: a signaling protocol for applications to reserve resources (link bandwidth and buffer space) m Provide reservations for bandwidth in multicast trees m Receiver-oriented m Can reserve resources for heterogeneous receivers r Sender sends a PATH message to the receiver specifying the characteristic of the traffic and QoS requirement r Receiver responds with a RESV message to request resources for the flow m An intermediate router can reject or accept the request of the RESV message m A router may merge the reservation messages arriving from downstream Slide 17 Intserv Service Models Guaranteed service: r Provide firm bounds on end-to- end datagram queuing delays. r Provide bandwidth guarantee r Leaky-bucket-policed source + WFQ WFQ token rate, r bucket size, b per-flow rate, R D = b/R max arriving traffic Controlled load service: r Provide a quality of service closely approximating the QoS that the same flow would receive from an unloaded network element. m A very high percentage of transmitted packets will be successfully delivered to the destination. m A very high percentage of transmitted packets will experience a queuing delay close to 0. Slide 18 IETF Differentiated Services Concerns with Intserv: r Scalability: router need to process resource reservations and maintaining state for each flow. r Flexible Service Models: Intserv has only two classes. Also want qualitative service classes Diffserv approach: r Goal: provide the ability to handle different classes of traffic in different ways r Scalable: simple functions in network core, relatively complex functions at network edge r Flexible: dont define specific service classes, provide functional components to build service classes Slide 19 Diffserv Architecture Edge router: -Packets are marked -The mark of a packet identifies the class of traffic to which the packet belongs Core router: -Packet forwarded to the next hop according to the per-hop behavior (PHB) associated with that packets class -PHB determines buffering and scheduling at the routers - Routers neednt maintain states for individual flows Slide 20 Edge-Router Packet Marking r Class-based marking: packets classified based on packet header fields, packets of different classes marked differently r Intra-class marking: packet marking based on per-flow profile, conforming portion of flow marked differently than non-conforming one m Traffic profile: pre-negotiated rate A, bucket size B r Out-of-profile packets might be shaped (i.e. delayed) or dropped Slide 21 Packet Marking r Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6 r 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive r 2 bits are currently unused r DS field of the packets can be marked by end hosts or leaf router Slide 22 Forwarding (PHB) r PHB is defined as a description of externally observable forwarding behavior of a Diffserv node applied to a particular Diffserv behavior aggregate. m A PHB can result in different classes of traffic receiving different performance. m A PHB does not specify what mechanisms to use to ensure required performance behaviors m Differences in performance must be observable and hence measurable r Examples: m Class A gets x% of outgoing link bandwidth over time intervals of a specified length m Class A packets leave first before packets from class B Slide 23 Service Level Agreements r A customer must have a Service Level Agreement (SLA) with its ISP. A SLA specifies the service classes supported and the amount of traffic allowed in each class. m Static SLA: negotiated on a regular basis (e.g. monthly and yearly) m Dynamic SLA: customers must use a signaling protocol (e.g. RSVP) to request for services on demand r The classification, policing and shaping rules at the ingress routers are derived from the SLAs. r The amount of buffering space needed for these operations is also derived from the SLAs. r When a packet enters one domain from another domain, its DS field may be re-marked, as determined by the SLA between the two domains. Slide 24 Example Diffserv Services r Premium Service: for applications requiring low delay and low jitter service; r Assured Service: for applications requiring better reliability than Best Effort Service r Olympic Service: provide three tiers of services: Gold, Silver and Bronze, with decreasing quality. Slide 25 An