URLs for DiffServ

Download Report

Transcript URLs for DiffServ

Quality of Service (QoS)
• One definition:
– Network capability to provide a non-default
service to a subset of the aggregate traffic
(could be better than default, could be worse
than default)
– Dominant service class in use today:
• “best effort”
• Use of QoS to deal with network congestion
issues
• Can’t you just increase the bandwidth and
eliminate need for QoS?
• Adding bandwidth doesn’t resolve jitter or
provide traffic prioritization
• Major paper in 1992 SIGCOMM
Proceedings: first serious description of
service classes – describes two mechanisms:
– Token bucket filter: enforcing treatment for a
particular flow
– Weighted fair queuing: devices bandwidth
across queues of traffic based on weights,
ensuring that each traffic flow gets a fair share
Layer 2 Class of Service (CoS)
• IEEE 802.1p standard for prioritization
(“Traffic Class Expediting”)
• Use of 3-bit “user priority field within the
802.1Q tag
• 802.1p capable NICs, switches or routers
can tag packets; transit switches or routers
implement the priority through prioritized
queuing
802.1Q tag frame format
• TPID = 8100 When a frame has EtherType
code of 8100, we know there’s an 802.1Q tag
• Priority: 3 bits for priority as per 802.1p
• CFI: Ethernet or Token Ring (0 for Ethernet)
• VID: VLAN ID – 12 bits: 4094 VLANs (0 and
4095 reserved)
802.1p Service Classes
• The 8 classes/levels of priority available from the
3 bits are assigned as follows:
–
–
–
–
–
–
–
–
000 (0) - Routine
001 (1) - Priority
010 (2) - Immediate
011 (3) - Flash
100 (4) - Flash Override
101 (5) - Critical
110 (6) - Internetwork Control
111 (7) - Network Control
• Some switches have four queues per port; some have eight
• Weighted Round Robin usually used to service queues
(alternative: strict queuing)
Layer 3 CoS/ToS: IP Precedence
• Type of Service field in IP header
• When used, IP Precedence has traditionally
used first three bits of TOS field for 8
possible value
• Guess how the 8 possible precedence values
have been defined?
Limitations of IP Precedence
• IP-Precedence scheme allows only specification of relative
priority of a packet; no provisions to specify different drop
precedence for packets of a certain priority. Example: you
may want to specify both HTTP and Telnet as highpriority. However, if congestion occurs, you want Telnet
packets to be dropped, before HTTP (or vice versa).
• 3 bits restrict the number of possible priority classes to
eight. The Network Control and Internetwork Control
classes are usually reserved for router-generated packets,
necessary for the health of the network. This cuts down
usable classes for production traffic to 6.
• IP-Precedence is not always implemented consistently by
network vendors today.
Internet/IETF QoS Efforts
• 1994 – IETF began work on an Integrated
Services (IntServ) architecture:
– Flow = stream of packets with common Source
Address, Destination Address and port number
– Requires router to maintain state information on
each flow; router determines what flows get
what resources based on available capacity
IntServ components
• Traffic classes
– best effort
– controlled load (‘best-effort like’ w/o congestion)
– guaranteed service (real-time with delay bounds)
• Traffic control
– admission control
– packet classifier
– packet scheduler
IntServ components (cont.)
• Setup protocol: RSVP
• “Path” msg from source to destination collects information
along the path; the destination gauges what the network
can support, then generates a “Resv” msg
• If routers along the path have sufficient capacity, then
resources back to the receiver are reserved for that flow;
otherwise, RSVP error messages are generated and
returned to the receiver
• Reservation state is maintained until the RSVP “Path” and
“Resv” messages stop coming
IntServ/RSVP problems
• Scalability (processing of every individual
flow on core Internet routers)
• Lack of policy control mechanisms
What is the service?
There are two camps:
“Better best effort” — ISPs want finer control of relative
bandwidth allocation, particularly under heavy load
(Implementation in terms of drop- preference or
weighted- round- robin).
“Virtual leased line” — Users want an end- to- end absolute
bandwidth allocation, independent of other traffic
(Implementation in terms of priority queuing and strict policing).
The IETF is more vocal on the former but there is demand for
both.
What are the target applications?
• Bad question. In 1978, the answer was
remote job entry. In 1988, email/ ftp. In
1999, web. This too will change.
• IP/ TCP/ UDP/ IGMP/ OSPF/ BGP work
for any application.
• Differentiated services must too.
• What are the requirements of today’s
applications?
Scaling
A differentiated services mechanism must work at the
scale of the Internet (e. g., millions of networks) and at
the full range of speeds of the Internet (e. g., Gb/ s
links). The Internet is growing at 20% per month. To
get that kind of scaling the design must:
•push all the state to the edges, and
•force all per- conversation work (e. g., shaping,
policing) to the edges.
Scaling (cont.)
• Edge- only state suggests that special/
normal service indication must be carried in
the packet.
• Administrative diversity and high speed
forwarding both argue for very simple
semantics on that indication. E. g., a few bits
of special/ normal.
• No state in center means it sees only
aggregates (potential fairness problems).
Differentiated Services
(DiffServ)
• See http://www.ietf.org/html.charters/diffservcharter.html
• Instead of maintaining individual flows on all
routers, flows are aggregated into an aggregate
flow that receives “treatment” (per class or per
service state)
• Service classes are identified, packet is marked as
belonging to a particular service, sent on its way;
routers in path examine header to determine
treatment
Necessary DiffServ functions
• Admission control: ability of network to refuse
customers when demand exceeds capacity
• Packet scheduling: method for treating different
customers’ data differently as needed
• Traffic classification: ability to sort streams into
“substreams” that receive different treatments
• Policies and rules for allocating the network’s
resources
DiffServ from the router’s
perspective
• define packet treatment classes
• allocate an adquate amount of resources for
each class
• sort all incoming packets into their
corresponding classes
DiffServ components
• DS-field: uses 6 bits in the TOS field in
IPv4/traffic class field in IPv6; denotes service the
packet should receive (6 bits referred to as the
DSCP: DiffServ Code Point)
• PHB (per-hop behavior): defines the service at
each hop; may be relative (compared to other
PHBs) or absolute (in bandwidth or delay terms)
• BA (behavior aggregate): group of packets with
the same DSCP (PHB is applied to each BA)
Note error in above: 101-Immediate should be 010-Immediate
Proposed DiffServ services
• Expedited Forwarding - “virtual leased
line”; low delay, loss and jitter; provides a
peak rate/ceiling (DSCP: 101110)
• Assured Forwarding - emulates a lightly
loaded network (“drop me last”); provides a
“floor” rate
• Default - usual “best effort” service (DSCP:
000000)
DiffServ AF Codepoint Table
Drop
Probability
Class #1
Class #2
Class #3
Class #4
Low Drop
Probability
(AF11)
001010
(AF21)
010010
(AF31)
011010
(AF41)
100010
Med Drop
Probability
(AF12)
001100
(AF22)
010100
(AF32)
011100
(AF42)
100100
High Drop
Probability
(AF13)
001110
(AF23)
010110
(AF33)
011110
(AF43)
100110
Possible DiffServ Class Provisioning
Traffic
Class
DSCP
IP Routing
CS6
Interactive Voice
EF
Interactive Video
AF41
Streaming Video
CS4
Telephony Signaling
CS3
Transactional/Interactive
AF21
Network Management
CS2
Bulk Data
AF11
Scavenger
CS1
Best Effort
0
Fun Issues and Questions
• How will 802.1p, DiffServ and RSVP
interoperate?
• Not enough to just identify “audio/video” packets
(relative to others) and let them thru first. May
have more “audio/video” packets than bandwidth
available (LOTS of people running audio/video
apps). Who decides WHOSE audio/video
packets?
• How do we manage user expectations? How do
users view QoS? How do they invoke it? How do
they know that they have it?
Fun Issues and Questions (cont.)
• What to do with incoming traffic? What do
we do with flows currently in progress
when a higher priority flow requests access?
Do we allow preemption?
• What about the problem of multiple sources
sending data to a single destination, which
then ends up oversubscribed?
Fun Issues and Questions (cont.)
• How do we prevent starvation of “besteffort” traffic?
• How do you manage QoS policies?
– How do we decide who gets what? Are
DiffServ PHBs like a hall pass in school to go
to the bathroom?
– If so, who decides who has to go the worst?
– Does it come back to pricing?
Qbone
• Testbed work:
– http://qbone.internet2.edu
• Two models:
– Premium: the goal of offering as close to a virtual leased line
service model as is possible over IP
– Scavenger: allows for marking traffic for potentially degraded
treatment at congested downstream interfaces
• Note: “Due to a medium-large set of intractable deployment problems,
the Internet2 QBone Premium Service initiative has been suspended
indefinitely. Internet2 QoS design and deployment efforts are now
focused on ‘non-elevated’ forms of QoS like QBone Scavenger
Service that require no policing, no reservations, and no admission
control.”