It should be noted that the session term is seen
with varying interpretations, like an FTP session,
HTTP session, and so forth. Usually, the admis-
sion control acts on the flow level, not taking
into account effects on the session level. An
argument may be that an application, in case a
flow is not accepted, may retry the transfer and
then leave that operation to the end-system/
application. Hence, the network would not need
to be enhanced with capabilities enabling group-
ing of flows into sessions. For some services and
users, however, the service portfolio (and the
conditions stated in the Service Level Agree-
ment, SLA) may refer to phenomena on the ses-
sion level. This is not covered here as any corre-
lation between those levels might be estimated
by monitoring/measuring, e.g. for verifying the
SLA conditions.
2.4.1 Rationale for Admission Control
The following reasoning is excerpted from
[ID_acaf]:
There is a growing feeling that the basic Diff-
Serv architectural model lacks the capability
of providing service accuracy.Quoting [RFC2990]: both the Integrated Ser-
vices architecture and the Differentiated Ser-
vices architecture have some critical elements
in terms of their current definition which
appear to be acting as deterrents to wide-
spread deployment. There appears to be no
single comprehensive service environment
that possesses both service accuracy and scal-
ing properties.Also, in [RFC2998], it is
pointed out that: further refinement of the QoS
architecture is required to integrate DiffServ
network services into an end-to-end service
delivery model with the associated task of
resource reservation.To this purpose,
[RFC2990] recommends to define an admis-
sion control function which can determine
whether to admit a service differentiated flow
along the nominated network path.In fact,
without per flow admission control, preven-
tion of overload in a given service class, e.g.
by means of pure inter-domain Service Level
Agreements, does not appear to be an easy
task. Upon overload in a given service class,
all flows in that class suffer a potentially harsh
degradation of service.Another track of reasoning behind the introduc-
tion of admission control is that similar capabili-
ties have been present in most telecommunica-
tion networks, in particular those based on cir-
cuit-switched principles. Hence there is a certain
experience of how such mechanisms can be
utilised, combining high utilisation and ensured
service levels. In addition, admission control
may also be seen together with the need for
authorisation, implying that the means for con-
veying admission requests can also be applied
for authorisation.2.4.2 Overall Objectives of
Admission Control
The overall objectives of having admission con-
trol are to:- Ensure that the existing traffic flows still
receive adequate service levels when addi-
tional traffic flows are introduced; - Provide appropriate feedback/advise to a user/
application when initiating a session that the
session (or traffic flow) may well receive a too
low service performance; - Enable differentiation between traffic flows,
including applications and users in accordance
with policy and subscription/user profile; - Balancing ensured service provision (with
effective guarantees on performance levels)
and efficient utilisation of network resources.
These objectives will not be equally weighed
independent of the scope of discussion. For
instance, from a user perspective, less interest
could be placed on the network utilisation issue.In broad terms, traffic flows can be characterised
as elastic or streaming (inelastic), meaning the
latter has stronger requirements on delay and
delay variations. Commonly, TCP is used for
the former, while UDP is used for the inelastic
flows. Even though the elastic traffic flows adapt
to the network conditions (to a certain extent),
the effective throughput would decrease when
congestion appears. Hence, packets may experi-
ence time-out, being retransmitted and the dura-
tion of the session prolonged. The ultimate fac-
tor then limiting the traffic demand is the user
impatience (as it takes too long to complete the
operation). It is discussed in [Robe01] that intro-
ducing some form of admission control for elas-
tic flows may give a more effective overload
control compared to relying on user impatience.
A criterion for the admission decision would be
to reject a new flow when the resulting band-
width is below a specified threshold. This
implies that the available bandwidth has to be
followed by measurements and that the band-
width requirement of a new flow has to be esti-
mated/predicted.Considering elastic traffic, the TCP flow control
algorithm, applying a closed loop approach, will
restrict the throughput. Naturally, this will also
be influenced by the access rate and duration of
the flows. An approximate expression of the
effective throughput as a function of the round-