known in advance. However, the SP can have
empirical measurements of past sessions,
hence can determine the average transport
level requirements of one session. Further-
more, the estimates of transport level require-
ments can be refined with time.In the above service examples, the SP might
choose to charge based on duration only. For
other services, however, the SP may select to
charge also based on the transferred volume, if it
sees that providing users the incentive to control
the total volume they transfer is important. One
example of such a service is Internet access over
ADSL. In this example, if the SP does not pro-
vide incentives for users to limit their transferred
volume, then congestion in some part of the
access network can arise.
7.5 Compensation Schemes
By agreeing the SLA, both the customer and the
provider define the behaviour, duties and rights
of each of the parties. Therefore, in case some
of the statements in the SLA are not fulfilled,
a reaction pattern can be applied. Note that the
reaction pattern is described in the SLA as well.
One reaction is related to the compensation
schemes. Such schemes imply the compensation
the provider offers to the user after not fulfilling
the conditions given in the SLA (and under con-
dition that the user’s traffic was conformant with
the agreed traffic pattern).
In a QUASIMODO scope, a user should be
charged as agreed in the SLA, but only if the
agreed NPL is delivered as well. In case the
provider failed to deliver the NPL with the guar-
antees stated in the SLA, some compensation
may be invoiced. Note that the compensation is
not restricted only to the direct money flow, but
can impose “service credit”, i.e. service usage
free of charge for a certain (defined) period.
When constructing compensation schemes,
the NPL violations are necessary information.
Hence, measurements related to this dictate the
granularity a compensation scheme can be de-
veloped with. Depending on the type of mea-
surement/monitoring methods and tools, the
detection of the violation of a certain QoS para-
meter will differ, and hence affect the compensa-
tion scheme structure. For example, whether
detection of NPL violations is for individual
flows or for aggregate flows, whether the spe-
cific NPL parameters that are violated are de-
tected, whether the duration of NPL violations
and the traffic transferred during these violations
is measured.4)
More details on the compensation schemes dis-
cussed in the QUASIMODO project can be
found in [P906-7], [P906-8]8 Open Issues and
Concluding Remarks
The question of scalability of the QUASI-model
deserves further attention. One particular prob-
lem is scalability of a central management sys-
tem for one operator’s network. If NPL measure-
ments are made with test traffic so that traffic is
sent from one MRP, loops back from another
MRP, and the measure for the NPL-parameters
is derived as an average from the two-way de-
lays and losses, then one MPR can do its mea-
surements alone. This was applied in the QUASI-
model DiffServ implementations. In the QUASI-
IntServ implementation delays are measured
one-way and clock synchronisation is needed,
but no correlation of traces of measured times of
packet arrivals in two MRPs is needed, as the
delay is calculated from a time stamp. In both
implementations measurements from MRPs are
collected to a central point, either continuously
or if measured values are unnecessarily good or
too bad. The same or another central point also
manages dynamically the MRPs in the QUASI-
IntServ implementation. A central point may be
considered a poorly scalable solution. It is possi-
ble to divide the network to subnetworks and set
target values to each subnetwork and to have a
hierarchical management system where a central
manager manages subnetwork managers, in the
same way as in distributed network management
of SNMPv2/3. The QUASI IntServ implementa-
tion uses a simple unsecured socket connection
between the managing node and the MRPs. A
suitable de-facto standard, like SNMP or GSMP
(General Switch Management Protocol) would
be an improvement, but the protocol should be
secured as changing bandwidths of the RSVP
flows between MRPs make the network vulnera-
ble to denial of service attacks.An important issue is security. If security is pro-
vided with IPSec (or IPv6 security), then IPSec
restricts the use of NAT in the QUASI-IntServ
and if EPS with data encryption is used, IPSec
prevents reading the port and the protocol, also
AH prevents NAT. Though the TOS field can be
updated, transport mode IPSec with EPS and
encryption conflicts with the use of DiffServ
also. A working solution is to use IPSec in the
tunneling mode and terminate tunnels to MPRs
and continue from there with another tunnel. If
the network is divided into subnetworks because
of more scalable management, it could induce
long delays to terminate IPSec tunnels to each4)An issue we do not discuss here is which system (accounting or QoS monitoring) is responsible for
collecting such measurements.