Date: 26th Aug, 2003
Lecture No. 12 (Integrated Services)
Scribe: Jugal Garg


Contents

Queuing Clarification
Integrated Services
	Properties
	Different types of Services
	Token-Bucket Filter
Scheduling for Guaranteed Services
Scheduling for Predicted Services
Priority Classes
Multi-hop - FIFO+
Unified Scheduling


Queuing Clarification

We have studied two types of queuing mechanisms, one is FCFS and the other one is 
Fair Queuing (FQ). FQ allows user to prevent from mis-behaving but it is costly
than FCFS. Each insertion takes O(logn) time per packet where n is the total number 
of active queues at that instant. So it is very costly to implement, so we have
Stochastic FQ (SFQ) which hashes the flows onto queues, but it can only be
implemented when the total number of active queues are less otherwise lot of
collisions will appear.

We have other methods also to overcome this problem, like Deficit Round-Robin
(DRR) based scheduling, in which every queue is alloted a fixed number of
quantum for each round, so when the packet size is less than the quantum, we
will store the deficit (quantum - packet size) for this queue and in the next
turn this queue is allowed to send (deficit + quantum) amount of data. So
here, the time taken is only O(1) because we have to see only deficit at each
queue to know how much data can be sent in this round which is of the constant
cost.

Other mechanism is Core-Stateless-Fair-Queuing (CSFQ) which does FQ in the
routers which do not have many flows like edge routers and they insert label
(contains the bandwidth used by this queue) in the packet so that when this
packet reaches to the core-router, there is no need for the implementation of
FQ, it only sees the label attached by edge-router in order to determine the
probability of dropping according to its uses of the band-width. Like if there
are 40 flows and the total bandwidth at the core-router is 100Mbps so each
queue should get 2.5Mbps of the bandwidth (fairness), so these core-router
sees what is that label, so if the label is 5Mbps than it calculates
probability of dropping which is, in this case is 50%. So the idea is there is
no need to implement FQ at core-routers which have a lot of flows.


Integrated Services

A variety of different types of services when provided by the same
network gives a lot of benefit like ubiquity and statistical multiplexing
benefits. Voice and data are different types of services. Voice service is
different from data with respect to delay. In the voice service, delay more 
than a threshold value is not acceptable whereas in data, any value of delay 
can be acceptable. 

Its architecture consists of:

1. Service commitments: The network should commit to the service 
2. traffic characterization
3. Implementation
4. Admission Control
5. Policing
6. Session setup protocol (Signaling Protocol)

The classification of applications are:
best-effort - does not worry about high delay for some time 
Real time, with play back point - Play back point is equal to the amount of
buffer at the receiver end because that much amount of delay is permissible.
If it is more than play-back point then the application will not be
interactive. Typical values for buffer are a few seconds, 15-30 seconds
which is different for different applications. 

Properties:

Low delay desired: For interactive applications, like in VoIP, delay should be
less than 700-800 msecs. In these applications, some packet loss can be
tolerated, there is no need for retransmission of the lost packet.

In Video application, there are different types of frames, some of them are
bursty in nature, like the ratio of peak bandwidth to mean bandwidth is of the
order 10 to 20. So, these types of applications can take advantage of
statistical multiplexing in which, the burst is reached to the receiver within
there play-back point.

Some real time applications (interactive) fix their play-back point regardless 
of the actual delay experienced. These are rigid applications. It usually
requires small play-back point, viz. these applications can not tolerate the 
delay more than a specified amount. For other applications, play-back point is not 
fixed, and vary according to the network delay experienced. These are adaptive 
applications. So, we can classify these applications into two classes:

1. rigid and intolerant
2. adaptive and tolerant

Different types of Services:

For these applications to perform well, network should provide service commitment, 
which will be different for different types of services.

1. Guaranteed Services: These services require assurance to the applications 
(rigid and intolerant) about the service they receive, i.e. the delay will 
not be more than the play-back point.

2. Predicted Services: These services include adaptive and intolerant
applications where the play-back point is set according to the state of the
network. So here, the past behavior is the guide to the future. So if there is
increased delays then the application will receive some spikes after that it will 
set its play-back point according to this large delay. Here, network tries to 
minimize the delay because in the Guaranteed service, it is set to the worst-case 
analysis of the network.

3. Best-effort: These services include other applications (datagram) those 
do not have requirement of delay bound. Non-interactive applications come in
this category.

For network to provide service commitment, the applications should also
provide the traffic commitment (if it has committed to x bandwidth, then it
should not send traffic of more than x bandwidth). So traffic must conform to
the characterization it has committed to the network. One form of traffic
characterization is a token-bucket filter. 

Token-Bucket Filter: It is characterized by two parameters, a rate r and size
b. Here one token is required to send one bit through network and r is the
token generation rate (average flow rate) and b is the maximum token credit 
(size of the burst). So algebraically, the equations are:

n(0) = b (At time=0, number of tokens = b)
n(i) = min[b, n(i-1) - p(i) + r*{t(i) - t(i-1)}] 

(Here, p(i) is the size of ith packet and n(i-1) is the number of tokens left at 
time=i-1)

So, if n(i) >= 0 => flow conforms to (r,b), because n(i) represent the number
of tokens left after ith packet leaves and it is positive means it is not
using more than b token credits.

We can specify b(r) for any r, for a given flow. It is non-increasing function
and set to the minimal value such that the process conforms to a (r, b(r))
filter. 


Scheduling for Guaranteed service

For Guaranteed service, network provides commitment to the applications so weighed 
fair Queuing (WFQ) can be implemented where weights are given to the queues.
So more weights are given to the queues which require higher commitment. 

Parekh and Gallager have shown the result that 
if a flow gets same clock rate at all routers, and the sum of rates of all flows at 
every router is no greater than its capacity then the delay in the network is 
bounded by b(r)/r for each flow. 

Here, r is the clock rate for this flow. So, if it is having the same clock
rate at all the routers then the delay, it would suffer only at the first
queue because rest of the queues of other routers will get the data at the
rate of r and the clock rate for this flow at these routers is also r. 
So the maximum delay it would suffer is bounded by b(r)/r.

In Guaranteed service, delay does not depend on the behavior of the other
flows because the scheduling scheme tries to isolate flows from each other.
The WFQ scheme isolates each source to others by providing it a specified share
of the bandwidth. 


Scheduling for Predicted Service

Here, the experiment considers that a single source is bursty at some instant. 
So in this scenario, if we implement WFQ then only this flow will see all excess
delay. So due to this excess delay, some packets may miss their dead-line. So
this is not appropriate for real-time applications. Earliest Deadline First
(EDF) is more appropriate because we have considered that a single source is
bursty at some instant, then it will be allowed to send more packets during
this time and others will also use the similar settings when they need to send
bursts. So everyone will get the sharing benefits. 

So, if all the flows of same service requirement, and all the packets have same
dead-line offset from arrival time, then EDF will behave like FIFO.

So, the result is that FIFO is good for sharing (for predicted services) and WFQ
(for guaranteed services) is good for isolation.


Priority Classes

Here, we have priority classes for different services according to their
service requirements. In this, one class acquires the jitter of higher
priority classes, which consequently get much lower jitter. It is a sharing
mechanism for the same classes but isolation between higher and lower priority
classes, i.e. lower priority traffic can never affect the performance of
higher priority one.


Multi-Hop - FIFO+

In FIFO+, we try to implement FIFO-style sharing at each hop so we assign
equal jitter for all flows of the same class at each hop. This is done as: 
For each hop, we measure the average delay seen by packets in each aggregate 
class at that switch. We then compute for each packet the difference between 
its particular delay and the class average. So according to this difference, 
we add (or subtract) this difference to the field in the header of the packet,
which then accumulates the total offset for this packet from the average of
its class. The switch then schedules the packet as if it arrived at this by
these expected arrival times rather than by the actual arrival times.


Unified Scheduling

For unified scheduling of all types of services under same network, we can 
implement one WFQ queue for each guaranteed service flow and one for predicted 
and best-effort services (multi class based on delay bounds). So essentially, 
we are providing isolation to guaranteed service flows and sharing among predicted 
service flows.