intermediate MRP. This is fortunately not
needed as the IP-packets are already marked for
the desired NPL and it is sufficient to read the
outer IP-header. In this way the QUASI-model
can be used with decentralised management and
IPSec. Offering VoIP with IPSec tunnels may
cause problems because of header overhead and
set-up delays connected with IKE, but these
problems are not specific to the use of IPSec in
the QUASI-model.
Currently the implementations for measurement
and management do not have security mecha-
nisms in the user access. A full AAA-protocol
(Authentication, Authorisation, Accounting)
could be used. The present AAA protocols, like
COPS, RADIUS or Diameter, are not ideal for
the QUASI-IntServ. The implementations for
charging the use of AAA, see [P906-6].
Another scalability issue is the usage of access
lists in the DiffServ implementation. The prob-
lem appears because a user can select different
quality classes for an application in the QUASI-
model. In conversational services, like VoIP, a
subscriber to better quality should receive better
quality in a conversation with a user of worse
quality. This is solved in the DiffServ implemen-
tation by putting all subscribers to better quality
to access lists of all MRPs. Then the MRP
knows to mark the TOS field of IP packets des-
tined to a subscriber to better quality, but the
solution is not scalable. One way could be to
upgrade SIP or H.323 so that the applications
negotiate the used quality. This solution may be
difficult to enforce as SIP and H.323 compliant
implementations exist and the standards do not
yet include quality negotiation, and requiring
upgrading applications to support the QUASI-
model before the QUASI-model can be used
hinders its usage. In the QUASI IntServ the
problem is solved by MRPs keeping the state of
existing connections and exchanging the infor-
mation of AC/QC in both MRPs of a connection.
A similar solution might be the easiest way to
scale the DiffServ implementation.
The QUASI-model does not restrict the use of
MPLS inside the network, but it should be noted
that in the QUASI-model an application can be
assigned a different quality. In many label switch-
ing methods traffic flows are classified by their
traffic pattern and the classifier decides what is
the required quality of the flow. This approach
fails in the QUASI-model as the traffic pattern
does not indicate what the desired quality is.
Mobility via Mobile IP (or IPv6 mobility) has
not been considered in the QUASI-model. It is
likely to require changes to the QUASI-model.
In Mobile IP traffic is sent to the home agent and
then forwarded to the visiting agent. In order to
support the same quality in both connections, it
seems that the MRPs should have signalling to
inform the MRP on the route to the visiting
agent what is the selected AC/QC.The scalability problems of the DiffServ imple-
mentation can be solved with additional proto-
cols and enhancements of the model. They add
some complexity but also they add some func-
tionality. Service differentiation is basically a
philosophical matter: should one worsen existing
quality simply to provide service differentiation?
Does it mean provisioning guaranteed bad ser-
vice? The solution we proposed to be used in
QUASI-IntServ is connection blocking, but this
implies some kind of connection oriented view
to a traditionally connectionless IP-network. In
general, is QUASI-IntServ a poor version of
ATM and why not to use the real ATM? Any-
thing based on IntServ and in conformance with
the QUASI-model is likely to be similar to
QUASI-IntServ.There are proposals to use charging schemes
where the operator increases the prices when
the network is heavily loaded and the users are
expected to respond with reduced traffic de-
mand. In the situation when the users are con-
nected to a single operator and they respond to
prices, these methods work as feedback methods
and the only stability issue is the control loop
delay. In the QUASI-model there is an interme-
diate role – the retailer – and the retailer can be
connected to several operators, some of which
may use congestion pricing. The retailer, let us
call it the ISP, may try to shift traffic to an oper-
ator offering lower prices instead of reflecting
the increased prices to end users as long as there
are cheap operators available. Then the users
do not respond to the change or prices, as their
prices do not change, and the total traffic
demand is not reduced. In the QUASI-model
traffic control is on the IP layer and connection-
less, therefore existing connections can be
shifted on-the-fly to another operator providing
sufficient NPL. In this situation the response to
congestion prices is On/Off, i.e. the ISP min-
imising costs for each charging time slot will
shift traffic abruptly from a more expensive
operator to a cheaper one. It is possible to use
more complicated operator pricing schemes, like
carry the first N-bytes in a charging time slot
with come cost per byte, and the remaining traf-
fic on the time slot is more expensive. Then the
operator will get the response it desires in con-
gestion pricing schemes. This shows that the role
of the retailer is useful: the pricing scheme of the
operator is unfair as prices depend on the arrival
times of IP packets with respect to charging time
slots, but the ISP can offer users fair and more
constant prices.