Upload
presta
View
42
Download
0
Embed Size (px)
DESCRIPTION
IETF Integrated Services Model: Architecture and Scheduling. Cheryl Pope Department of Computer Science University of Adelaide. Integrated Services - motivation. Many applications are sensitive to the effects of delay, jitter and packet loss. - PowerPoint PPT Presentation
Citation preview
IETF Integrated Services Model: Architecture and Scheduling
Cheryl PopeDepartment of Computer Science
University of Adelaide
IRC Department of Computer Science 2
Integrated Services - motivation
• Many applications are sensitive to the effects of delay, jitter and packet loss.
• The existing Internet architecture provides a best effort service.
• All traffic is treated equally (FIFO queuing). Currently there is no mechanism for distinguishing between delay sensitive and best effort traffic.– IPv4 TOS is not widely implemented.
• Aim of IntServ WG: to specify the enhanced services needed in the Internet service model to support the integration of real-time and “classical” data traffic.
IRC Department of Computer Science 3
Integrated Services Architecture
• Integrated Services (IntServ) expands congestion control to include reservation of resources– Signalling through Resource Reservation Protocol
(RSVP)• Specification of traffic characteristics and QoS
– Admission control– Policing and shaping of traffic– Scheduling of flow packets
IRC Department of Computer Science 4
Integrated Service ArchitectureIntegrated Service Architecture
Tx
Rx
1) Tspec (sender traffic spec) ADSpec (services, possibly modified by routers)
2) Tspec (reservation traffic spec) RSpec (reservation service request) Service class
IRC Department of Computer Science 5
Traffic Specification
• To date, one general traffic specification parameter has been defined (RFC 2215): TOKEN_BUCKET_TSPEC
• Consists of:– float r token rate (bytes/sec)– float b bucket depth (bytes)– float p peak rate (bytes/sec)– unsigned m minimum policed unit (bytes)– unsigned M maximum packet size (bytes)
• RSPEC consists of: R requested rate (bytes/sec) S delay slack (microseconds)
IRC Department of Computer Science 6
Service Categories• Guaranteed
– Mathematically provable upper bound on queuing delay, assured data rate, no loss
– Hard real-time applications• Controlled Load
– Approximates best-effort service under unloaded conditions
– Adaptive real-time applications• Best effort
IRC Department of Computer Science 7
Traffic distortion
• Traffic policing monitors that traffic at the source adheres to its Tspec.
• Traffic that is well behaved at the network edges can still become distorted within the network.
• Reshaping is typically used to correct this distortion.• Ensure that: data sent <= M+min[pT, rT+b-M] : for all times T
IRC Department of Computer Science 8
Guaranteed ServiceGuaranteed Service
Tx
Rx
policerreshaper
Fluid model scheduling
reshaper
Fluid model scheduling
IRC Department of Computer Science 9
Fluid Model Scheduling
• If an element approximates the “fluid model” then the service received will be the same as a wire with bandwidth equal to the service rate.
• Aim is to isolate traffic flows from each other. D=b/R
Fluid model scheduler with service rate, R.
Tx Rx
RxTxwire with bandwidth R
IRC Department of Computer Science 10
Relationship between service, traffic, loss and delay bounds
bits
time
traffic service
traffic arrival
busy period
backlog
IRC Department of Computer Science 11
EDD(Ferrari, 1990)
• Based on EDF scheduling from real-time systems.• Deadline, D, based on guaranteed delay bound, d and
expected arrival time of packet.
• Packets placed in priority queue sorted by D• Requires that both link and scheduler are not saturated.
– Consider 2 flows: flow 1 {r=5, M=5, d=1} flow 2 {r=3, M=6, d=1} out link of r=10
EDD scheduling jth packet, D=(M/r)*j+d
Tx Rx
IRC Department of Computer Science 12
Virtual Clock(L. Zhang, 1991)
• Scheduling of packets based on when packets would have been sent if TDM were used.
• Timers VC (flow monitoring) and auxVC (packet scheduling)
• On packet arrival both timers are advanced to next packet eligibility time.
• After a set number of packets (AI*AR), VC is compared to a real-time clock (RTC). – If VC > RTC restrict flow– If VC < RTC, VC=RTC (prevent higher rate in subsequent
interval)• VC updates are packet based. AuxVC avoids saving
“credits”
IRC Department of Computer Science 13
Packet by packet generalised processor sharing (PGPS)
(Parekh, 1994)
• Based on weighted fair queuing (weight proportional to R)
• Priority queue (similar to EDD and VC) ordered by time the packet would have been scheduled had bit by bit fair queuing been used.
IRC Department of Computer Science 14
Guaranteed Service Bounds
• For fluid scheduling, an upper bound on delay is given by:
(b-M)/R * (p-R)/(p-r) + (M+Ctot)/R + Dtot for R<p
(M+Ctot)/R+Dtot for p<=R
• C - rate dependent error term
• D - rate independent error term
• From ADSPEC: M (path mtu, or service specific), C, D
IRC Department of Computer Science 15
Limitations
• Guaranteed service only bounds the maximum queuing delay.
• None of the proposed schedulers provide bounded jitter.• All are work conserving models so a minimum queuing
delay of 0 is possible.• Actual delays are likely to be significantly less than the
worst case maximum, so nominal jitter can be large.• Scheduling algorithms exist that do control jitter (jitter-
EDD, Stop and Go)
IRC Department of Computer Science 16
Controlled Load
• Aim: Behaviour similar to best effort on an unloaded network, regardless of actual network load (in Tspec traffic)
• No specific delay bounds• Tspecs can exceed network element resources• Out of Tspec traffic becomes best effort (separate from
elastic traffic!)• Possible implementations
– Fluid models (isolation of traffic in traffic classes)– Measurement based– Probabilistic
IRC Department of Computer Science 17
Routing
• Integrated Services (CL & GS) requires fixed routing.• Possibly handled by
– Pre-configuration– Source based routing– (Multi-protocol Label Switching) MPLS
• Recovery of IntServ flows from element/link failures is not well studied, yet.
IRC Department of Computer Science 18
Differentiated Service
• Integrated service provides QoS; but it has problems– It doesn’t scale. The routers would have to maintain
state on every flow passing through them.– Heterogeneous networks may not provide particular
QoS controls or even RSVP.• Differentiated service (DiffServ) aims to offer QoS to
aggregated flows.
IRC Department of Computer Science 19
Combining IntServ & DiffServ
• IntServ provides fine grain control and handles dynamic allocation of resources to flows.
• DiffServ provides course grain control of flows through their aggregates.
• The two together can be combined to provide scalable end to end Integrated service, using a DiffServ region as a single element.
• Controlled Load can be implemented over Assured Forwarding PHB
• Guaranteed can be implemented over Expedited Forwarding PHB
IRC Department of Computer Science 20
Summary
• Integrated Service provides applications with guaranteed delay bounds or performance similar to an unloaded link.– Several scheduling algorithms exist.
• RSVP can be used to support signalling of traffic and service requirements for admission control
• MPLS can support fixed path routing (more likely at aggregate than per flow)
• Differentiated Service provides scalable service across network regions– Research is still needed on bridging the gap between
session based flows and aggregated flows.
IRC Department of Computer Science 21
Current State
• RSVP and the queuing mechanisms to support IntServ are available in IPv6 distributions.
• IPv6 is implemented in Solaris, Windows 2K, Linux, *BSD.
• DiffServ projects are currently being run under Internet2 and CAnet2.
IRC Department of Computer Science 22
Open Issues• Existing proposals for Intserv/Diffserv control latency but
not jitter. Delays are pessimistic so predicted jitter can be large.
• Flows are one-way. No symmetric architecture exists yet.• Multicast causes problems for both Intserv & Diffserv,
which base expected internal loads on ingress/egress pairs of traffic.
• Fault-tolerance and recovery of flows hasn’t been touched on.
• Flow resource requirements are pessimistic. Aggregation of Tspecs is also pessimistic leading to even more pessimistic resource allocations. Probabilistic mechanisms need more study.
IRC Department of Computer Science 23
Open Issues
• Allocation of Diffserv resources.• Admission control algorithms for Diffserv.• How can we bridge the “islands” of IntServ/DiffServ.
IRC Department of Computer Science 24
Differentiated Service
• DiffServ defines Differentiated Service Code Points (DSCP) - IPv4 TOS, IPv6 Traffic Class
• All traffic in one DSCP is treated the same.• Per hop behaviour (PHB) is determined by DSCP of
packet.• Service Level Agreements are with customers (possibly
other diffserv clouds) not flows.
IRC Department of Computer Science 25
Differentiated Service Architecture
classifier
Rx
TxDiffserv region
marker
meter
Shaper/dropper
To interiornodes
PHB
IRC Department of Computer Science 26
Differentiated Service
• Resource allocation– Bandwidth broker: global view of resources.– Static provisioning: may give poor service to flows.– Signalling: use of RSVP to allocate resources.
• Defined Per Hop Behaviours– Expedited Forwarding: near constant
delay/throughput• Virtual Wire aggregate
– Assured Forwarding: provides low loss probability for compliant traffic. Guarantees ordering of packets in a given AF class.
IRC Department of Computer Science 27
Multicasting
• Multicasting is both a main argument for reservations and one of the main problems for IntServ/DiffServ
• Muticast can generate a large amount of potentially unnecessary traffic.
• Number and QoS requirements of receivers can change dynamically, without changing incoming traffic. – Provision based on all possible routers that could be
part of a multicast?• Receivers may have different QoS requirements. How
does DiffServ manage this with a single PHB at the boundary?