Data Communications 2 Lecture 7
ISA
Best effort style has generally worked well
Historically IP based internets have been able to provide simple best-effort delivery service to all applications they carry. Best effort treats all packets equally, with no service levels, requirements, reservations, or guarantees. Although the IPV4 header is equipped with fields that can specify precedence and type of service, this information has generally been ignored by routers, both in the selection of routes and the treatment of individual packets.
But changes in traffic demands require variety of quality of service Internet phone, multimedia, multicast
New functionality required in routers
New means of requesting QoS
What is ISA? Internet Services Architecture
RFC 1633
Internet Traffic can be broadly classified as elastic or inelastic: Elastic
Can cope with wide changes in delay and/or throughput
FTP sensitive to throughput E-Mail insensitive to delay
Network Management sensitive to delay in times of heavy congestion Web sensitive to delay
Inelastic
Does not easily adapt to variations –e.g. real time traffic
By considering the requirements of these two traffic types we see the need for an enhanced internet architecture – i.e. one that takes into consideration QoS
Requirements for Inelastic Traffic
Requirements for Inelastic Traffic
Inelastic traffic introduces a new set of requirements for quality of service.
Throughput - a minimum value for throughput will most likely be required; below that level the particular application may not function accurately
Delay - Stock trading is an example of an application that would have a strong requirement to minimize delay.
Jitter - The magnitude of delay variation e.g. real time interactive applications will require an upper bound; the longer the real delay the greater the size of buffers that will be required at the receivers
Two major requirements for a system supporting inelastic traffic:
Require mechanism for giving preferential treatment to applications with more demanding requirements. Applications need to be able to state their requirements either:
Ahead of time in some sort of service request manner or
On the fly, by means of fields in the IP header
Preference to the former approach, since it provides flexibility; e.g. a service level may be denied, based on current agreements and load.
Elastic traffic must still be supported. In other words we must still cater for traffic needing nothing more than best effort service. Also such traffic must not be crowded out by inelastic traffic, with QoS requirements.
The above discussions point to the need for a reservation protocol e.g. RSVP, which we will discuss later
ISA Approach ISA Approach
Without ISA, congestion controlled by
–Routing algorithms – deals with minimizing delay –Packet discard – deals with buffer overload
The ISA approach:
–Associate each packet with a flow
–This is different from a TCP connection in that it is Unidirectional (may also be multicast)
Functions used by ISA to manage congestion and to provide QoS transport:
–Admission Control – a flow may or may not be admitted (RSVP used to make decision) –Routing Algorithm – Routing decision may be made based on a variety of QoS
considerations as well as with the aim of providing minimum delay
–Queuing discipline – effective queuing policy that takes into consideration different flows
ISA Components
Below thick black line are forwarding functions of the router; These are executed for each packet and therefore must be highly optimized. The remaining functions, above the line, are background functions that create data structures used by the forwarding
functions.
Defining some ISA components Reservation Protocol
–Used b/w routers and between end-systems and routers.
–Responsible for maintaining flow-specific state information at end systems and routers along the path of the flow
–Updates the traffic control database, which is used by the packet scheduler to determine the service provided for packets of each flow
Admission Control: are there sufficient resources available to admit the flow at the required QoS level requested
Management Agent
–Modify the traffic control database
–Direct the admission control module in order to set admission control policies
Routing protocol
– is responsible for maintaining a routing database that gives the next hop to be taken for each destination address and each flow
Two main components that handle forwarding: Classifier and route selection
–Packets must each be classified for appropriate treatment.
–Based on the packets class and destination IP address, the next hop address is determined
Packet Scheduler
–Manages one or more queues for each output port. Determines the order in which queued packets are selected and the selection of packets for discard if this is necessary. –Policing – has a flow exceeded the limits of the contract
Token Bucket Traffic Specification Token Bucket Traffic Specification
We want to look at ISA service categories but we must have a good understanding of the token bucket specification, which is a way of characterizing traffic. It has three
advantages in the context of ISA:
–Many traffic sources can easily and accurately be defined by a token bucket scheme
–The token bucket scheme provides a concise description of the load to be imposed by a flow, enabling the service to determine easily the resource requirement
–The token bucket scheme provides the input parameters to a policing function The scheme is defined by:
Token replenishment rate R
– Continually sustainable data rate Bucket size B
– Amount that data rate can exceed R for short period
– During time period T amount of data sent can not exceed RT + B
Token Bucket Scheme Token Bucket Scheme
ISA Services ISA Services
A number of general categories of service are provided, each of which provides a certain general type of service guarantees.
Within each category, the service for a particular flow is specified by the values of certain parameters; together, these values are referred to as a traffic
specification (TSpec). Currently three categories of service are defined:
Guaranteed
– Assured data rate
– Upper bound on queuing delay
– No queuing loss
– Real time playback
Controlled load
– Approximates behavior to best efforts on unloaded network – No specific upper bound on queuing delay
– Very high delivery success
Best Effort
Queuing Discipline Queuing Discipline
Traditionally FIFO
– No special treatment for high priority flow packets – Large packet can hold up smaller packets
– Greedy connection can crowd out less greedy connection
Fair queuing
– Queue maintained at each output port – Packet placed in queue for its flow
– Round robin servicing
– Skip empty queues
– Can have weighted fair queuing (WFQ)
