250 likes | 360 Views
Differentiated Services. Service Differentiation in the Internet. • Different applications have varying bandwidth, delay, and reliability requirements • How can the network meet these requirements – No differentiation – treat all packets the same and design network to
E N D
Service Differentiationin the Internet • Different applications have varying bandwidth, delay, and reliability requirements • How can the network meet these requirements – No differentiation – treat all packets the same and design network to meet all requirements – Per-flow differentiation – each end-to-end connection requests resources. Network checks available resources and accepts or denies connection – Aggregate differentiation – combine traffic with similar requirements and treat the same way. Results in a limited number of different services
No Service Differentiation • Overprovision network so that there is never poor performance • Networks are designed to be operating below knee in performance curve • Advantages – Easy to implement – Supports all possible services • Disadvantages – Possibly expensive to meet low bandwidth and low delay requirements at the same time – Internet traffic is variable – there will always be some periods of congestion
Per-Flow Differentiation • Integrated Services (IntServ) [RFC2210, RFC2211, RFC2212, RFC2215, RFC2216] • Each flow uses RSVP to request resources from the network • Each router in the network checks available resources to determine if the flow should be accepted • Advantages – Each accepted flow is guaranteed to have good performance • Disadvantages – Network must maintain state about each individual flow – Routes may change – Application must know what resources to request
Aggregate Differentiation • Differentiated Services (DiffServ) [RFCs: 2474, 2475, 2597, 2598] • Packets are classified into one of several “behavior aggregates” (BAs) when they enter the network • A packet receives service according to its BA marking • Advantages – No per-flow state – Applications do not need to explicitly request resources • Issues – Provisioning is a difficult problem – How to aggregate traffic is an open problem – Each network can offer a different set of services
DiffServ • Identify the aggregate to which a packet belongs • At each hop, treat packets belonging to an aggregate so as to achieve a certain Per Hop Behavior, consistent with the requirements of this aggregate • Provision network to support traffic demands, or conversely only accept traffic which the network can support • Establish end-to-end service
Marking II: DS field • In DiffServ, each packet carries a marking indicating which behavior aggregate it belongs to. This marking determines the treatment the packet receives at each hop. • The field used to carry the marking is the former TOS field, renamed the DS field. • Only the 0-5 bits are currently used and called the DiffServ CodePoint or DSCP. Bits 6-7 are reserved for future use.
Per Hop Behavior • Each node maps DSCPs to PHBs • Per Hop Behavior (PHB), [RFC 2475]: – “the externally observable forwarding behavior applied at a node to a particular behavior aggregate” – “determines how much forwarding resources (transmission bandwidth and buffer) are allocated at each interior router for this behavior aggregate” • 2 standardized PHBs – Expedited Forwarding (EF), [RFC 2598] – Assured Forwarding (AF), [RFC 2597]
Example of a DiffServ Interior Node Each DiffServ node must allocate buffer and output bandwidth for the different PHBs
Buffer Management Mechanisms • Tail drop – traditional buffer management • Random Early Drop (RED) – probabilistically drop packets based on queue length • RIO – apply RED to each drop precedence level
Scheduling Mechanisms • Priority queuing – Minimizes queuing delay for high priority traffic – Could starve low priority classes if there is too much traffic • Weighted fair queuing – Round robin scheduling with weights – Partitions bandwidth among queues – Cannot have starvation between classes
Expedited Forwarding (EF) • RFC 2598 specification: – “the departure rate of the aggregate’s packets from any DS node MUST always equal or exceed a configured rate” – “it SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate”
• Possible implementations of EF PHB: – Priority queuing – Weighted Fair Queuing • Services based on EF: – Require control at the ingress: “conditioning the EF aggregate (via policing or shaping) so that the arrival rate at any node is always less than the configured minimum departure rate.” – Designed for applications that require low delay, low jitter, low loss, eg. IP telephony. – Eg. “Virtual Wire” emulates a dedicated line: users are restricted to transmit at a configured rate but their traffic receives very low delay.
Assured Forwarding (AF) • RFC 2597 specification: – “an AF compliant node MUST allocate some minimum resources to each AF class, sufficient to achieve at least the configured service bandwidth over large and small time scales.” – 4 independent AF classes and within each AF class traffic is further marked with one of 3 levels of drop precedence. – an AF compliant node MUST NOT reorder AF packets regardless of their drop precedence. – 4x3=12 allocated codepoints (see assignment of DSCPs). • Input rate is not strictly limited - how to handle excess traffic MAY be specified.
• Implementation: – no reordering requirement implies one queue per AF class – buffer management like RIO, but with 3 thresholds instead of one: one for each drop precedence:
• So far, we only presented – the packet marking (DS field) – the Per Hop Behaviors (PHBs) • The complete DiffServ architecture includes also the following elements: – Partitioning the network into separate DS domains; each domain is responsible for treating each aggregate internally – The boundary nodes of a domain (Ingress or Egress) have some additional functionality – Interaction between domains is specified by means of Service Level Agreements (SLAs).
Service Level Agreements (SLAs) • Agreement between network and user • Specifies – Service provided by the network – Traffic the user will inject into the network • May be static or dynamic
Service Metrics • Quantitative – specific delay, jitter, bandwidth and other metrics – e.g., 90% of the packets will receive 75 msec delay • Qualitiative – no quantifiable metrics – e.g., “low loss” service • Proportional – metric is specified relative to another class – e.g., AF1 will receive twice the bandwidth of AF2
Traffic Profiles • Specifies characteristics of incoming traffic – e.g., peak rate, token bucket, effective bandwidth – If traffic exceeds its negotiated profile it may be marked, dropped, or reshaped • Specifies the geographic scope – Destinations to which the user will transmit traffic – From source A to destination B – From sources A to destinations {B1,B2,B3} – From source A to all destinations
Border Nodes • Interior nodes are kept simple: classify packets and apply PHBs • Border nodes (Ingress or Egress) have additional functionality:
Network Provisioning • Buffer management and scheduling provide different service to each traffic class • Does not guarantee that the traffic will receive the end-to-end service it requires • Need to provision network to so that there are enough resources in the network to meet traffic demands • Need to know – Characteristics of traffic injected into the network – Available network resources
Open problems • What types of service differentiation can be provided with DiffServ mechanisms • How to specify SLAs – What service metrics are important to users – What are appropriate traffic profiles (e.g. token bucket) • How to compose end-to-end services – What are characteristics of aggregate traffic – What SLAs should networks negotiate between them – Networks may offer different services – What happens when traffic needs to be de-aggregated