6.2 Open Issues Related to
QoS Architecture
As the best effort service is the most commonly
seen in most IP-based networks, a wider range
of service levels is also sought. The service lev-
els can be widened in two respects; to provide
a service level improved from best effort, and
to provide a service level which is more pre-
dictable.
Basically, a few features have to be in place in
order to allow for differentiating service levels.
Firstly, the application has to convey the infor-
mation to the network of which service level it
wants (naturally, this may also be done manu-
ally). Then, resources in the network have to
be available to provide the service level agreed.
In order to ensure that resources are available,
some load control and resource usage/configura-
tion schemes have to be applied. If an applica-
tion request the service level for a certain traffic
flow, it also has to mark the flow in a way for
the network to recognise it. Commonly, there
are also some constraints attached on the traffic
to be transferred. An alternative to handling
individual flows is to have the network look at
aggregates. In such a case, the IP packets have to
be marked in order to assign them to the proper
aggregate. Then, it may not be needed for the
application to signal its request to the network in
advance; it could simply start sending packets.
Thus, it would not be up to the network to report
explicitly to the application if a service request
cannot be met, it simply has to be detected by
the application itself (e.g. as lost packets). This
resembles DiffServ. The former approach resem-
bles IntServ, allowing for a finer and closer fol-
lowing up of the network for each application
and traffic flow initiated.
In order to enhance the support of differentiated
service levels some issues are mentioned in
[RFC2990]:
- Aware applications. In case the application is
capable of giving estimates of its requests to
the network, the network may check its state
to see if the requests can be met. This can then
be returned to the application. This requires
that the application can give relative precise
description of its traffic profile (and policing
may then be applied). Then, the application
may be made aware of which service level
that is provided, e.g. in case different charging
applies. Another factor is that making aware
applications could allow for end-to-end views
between applications at the two endpoints,
ensuring that the receiver is prepared to re-
ceive the information to be transmitted. How-
ever, it can always be discussed which should
be the first to be upgraded: the network or the
applications. Preferably these should go hand-
in-hand.- Scalable and accurate service environment. As
noted, IntServ allows fine granularity follow-
ing traffic flows, resource allocation, and con-
veying information to the other end-point. The
so-called scalability, however, may be a prob-
lem. On the other hand, DiffServ scales well,
while not supporting signalling. Some effort
is undertaken to enhance DiffServ with capa-
bilities for signalling and reservation of
resources. - Service query and discovery. Prior to using a
service, an application may need to decide if
the service can be supported by the network.
This could likely be used for initiating a nego-
tiation between the application and the net-
work. - Service levels on resource handling and rout-
ing. Considering service levels when deciding
upon routing and configuring resources re-
quires that additional attributes are introduced.
These attributes would describe the service
levels, or characteristics of the resources, and
have to be correlated with corresponding attri-
butes on the service requests. In addition, fea-
tures like load distribution could be achieved. - Relations with TCP. Recognising that TCP
is one of the most used transport protocols,
having efficient means for controlling the
TCP flow rate is essential. TCP relies on ACK
messages in order to adjust its rate as part of
the load control. When introducing different
service levels, the TCP should get the proper
feedback on the forward direction as this is
the one to be controlled. Thus, effects in the
backward direction should not have too much
influence on the TCP estimates of required
flow rate. - Granularity of flow identification. As dis-
cussed earlier, IntServ and DiffServ apply dif-
ferent levels of granularity. IntServ may
recognise individual flows given by the 5
tuple (IP source address, IP destination
address, source port, destination port and
protocol). At the border of a DiffServ domain
a similar 5 tuple can be applied to map the
flow into a class/aggregate. Use of various
tunnelling, e.g. IPSec and fragmentation of
transport packets into multiple IP packets may
imply that this information is not present/
detectable in every IP packet of the flow. - Classes of service levels. In principle, a large
number of service levels could be present.
For instance, even DiffServ has 64 classes as
options, then these may even be implemented