Technical Information
QUASIMODO - QUAlity of ServIce MethODOlogies
and solutions within the service framework: Measuring,
managing and charging QoS
Summary of QUASIMODO Findings on QoS
Authors:
Baolo Bostica (editor), Telecom Italia S.p.A.
Magnus Krampell, EURESCOM GmbH
Abstract
This document describes how the QUASI-model was implemented and documents the main findings
of the tests, which were conducted. The report is useful for anybody considering implementing QoS
to IP networks. It is especially relevant if QoS is implemented according to the QUASI-model of the
QUASIMODO project, the two implemented versions show how to implement the QUASI-model
using IEFT’s DiffServ and IntServ approaches. Of the main approaches for building QoS to IP
networks only MPLS is not tried in this project. Even if QoS is not implemented according to the
QUASI-model, this report contains useful observations of problems and solutions to QoS
measurement and management issues.
QoS in IP networks can be implemented by modifying and elaborating these implementation
examples. They can also serve as investigated alternatives to other implementation possibilities. A
useful result from this report is also identification of a number of possible technical problems to be
faced if QoS is offered. From one of the two implementations there is source code for Linux
available for trial and further development.
Another interesting point, here developed, is related to the QOS charging for the QUASImodel,
investigating two different architectural solutions, centralised and distributed, applied to both the
IntServ and DiffServ approaches.
EDIN 0088-0906
Project P906
For full publication
January 2001
Disclaimer
This document contains material, which is the copyright of certain EURESCOM PARTICIPANTS,
and may not be reproduced or copied without permission.
All PARTICIPANTS have agreed to full publication of this document.
The commercial use of any information contained in this document may require a license from the
proprietor of that information.
Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the report
is capable of use, or that use of the information is free from risk, and accept no liability for loss or
damage suffered by any person using this information.
EURESCOM Technical Information page 3 (30)
Table of contents
ABBREVIATIONS .......................................................................................................................................... 4
1. INTRODUCTION ....................................................................................................................................... 5
2. THE QUASIMODEL .................................................................................................................................. 7
2.1 THE QUASI-MODEL SCENARIO ................................................................................................................ 7
2.2 THE QUASI-MODEL CHARACTERISATION METHODOLOGY ................................................................. 8
2.3 THE NPL CHARACTERISATION ............................................................................................................ 9
2.4 USING THE QUASI-MODEL TO CREATE A USER SERVICE OFFER....................................................... 10
3. QUASIMODEL IMPLEMENTATIONS ................................................................................................ 11
3.1 DIFFSERV-BASED IMPLEMENTATION ................................................................................................ 11
3.1.1 Mapping user requests to network classes ............................................................................... 11
3.1.2 QUASImodel service management ........................................................................................... 12
3.2 QUASI-INTSERV IMPLEMENTATION ................................................................................................ 13
3.2.1 Mapping User Requests to Network Classes............................................................................ 13
3.2.2 QUASImodel Service Management .......................................................................................... 14
3.3 TESTING OF QUASIMODEL IMPLEMENTATIONS................................................................................ 15
4. CHARGING POLICIES FOR QUASIMODEL ..................................................................................... 16
3.1 QUASIMODEL CHARGING SCHEMES ................................................................................................ 16
3.1 QUASIMODEL CHARGING IMPLEMENTATIONS ................................................................................. 17
4.2.1 Centralised architecture (DT) .................................................................................................. 18
4.2.2 Distributed architecture (BT) ................................................................................................... 19
4.3 QUASIMODEL CONFORMANCE OF CHARGING IMPLEMENTATIONS ................................................... 21
4.3.1 Centralised charging approach ............................................................................................... 21
4.3.2 Distributed charging approach ................................................................................................ 22
5. CONCLUSIONS COMING FROM QUASIMODEL IMPLEMENTATION AND
EXPERIMENTAL TESTS ........................................................................................................................... 24
5.1 QUASIMODEL QOS MANAGEMENT AND MEASUREMENT ................................................................. 24
5.2 QUASIMODEL QOS CHARGING ........................................................................................................ 26
5.3 FINAL COMMENTS ............................................................................................................................. 26
5.4 THE USEFULNESS OF QUASIMODEL ................................................................................................ 28
REFERENCES .............................................................................................................................................. 29
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 4 (30) EURESCOM Technical Information
Abbreviations
AAA Authentication, Authorisation and Accounting
AC Application Categories
ADIF Accounting Data Interchange Format
AMP Accounting and Meter Policies
API Application Programmers Interface
BPF BSD packet filter
CID Class ID
DAC Dynamic Accounting Managers
ECA Event-Condition-Action
GUI Graphical User Interface
IETF Internet Engineering Task Force
IP Internet Protocol
LAN Local Area Network
MIB Management Information Base
MOS Mean Opinion Score
MPLS Multi Protocol Label Switching
MRP Measurement Reference Point
MRPD MRP Daemon
MS Management System
NEP Network Accounting Record (NAR) Exchange Protocol
NP Network Performance
NPL Network Performance Level
PIP-NAR Premium IP Network Accounting Record
PNO Public Network Operator
QC Quality Class
QCS Quality Class Specification
QoS Quality of Service
RTFM Real Time Flow Measurement
RSVP Resource ReSerVation Protocol
RTP Real Time Protocol
SNMP Simple Network Management Protocol
SLA Service Level Agreement
TCA Traffic Conditioning Agreement
TCP Transmission Control Protocol
TFL Tariff Formula Language
TOS Type of Service
UA User Agent
UDP User Datagram Protocol
VoIP Voice over IP
WAN Wide Area Network
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 5 (30)
1. Introduction
IP networks and in particular the Internet are becoming ever more widespread. Many
services/applications with different requirements use these networks, but presently there are no
global methodologies and tools for managing their Quality of Service (QoS) and charging.
In the on-going animated discussions related to providing differentiated levels of quality for
services provided over IP networks, the proposed solutions often assumes users who are very
literate in the technologies used in the network. When services including differentiated levels of
quality are provided to a mass market, this assumption will not hold any more.
Some mechanisms exist for controlling performance in IP networks (e.g., IETF DiffServ and
IntServ) but it is not clear how these mechanisms can be used in order to provide end-to-end
quality, i.e., a quality that can be perceived by the end user. Moreover, it is not clear which QoS
parameters to use for expressing QoS at the user level and how to correlate them to network
performance parameters. Finally, services/applications in these networks (including the Internet)
are not presently charged on the basis of user QoS requirements and QoS offered by
service/network providers.
The EURESCOM Project P906 QUASIMODO (QUAlity of ServIce MethODOlogies and solutions
within the service framework: Measuring, Managing and charging QoS) has been investigating a
proposal for how this problem can be overcome, namely by creating a (small) set of well known
Quality Classes. “Normal” people will be able to recognise these Classes and can choose the Class
that suits their needs (and budget!).
Relevant aspects of this idea has been investigated by the Project, including Management and
Charging and the main results are described here. However, the marketing departments of the
Telecommunications Operators will be the ultimate judge of the applicability of the idea.
To reach the aims of offering Quality Classes to the end-user and to provide the mechanisms and
tools for QoS control, measurement and charging, the QUASIMODO Project has carried out the
following activities:
creation of a QoS model (called QUASImodel) characterised by a set of Application
Categories (ACs) classifying the potential or presently used applications depending on their
performance requirements, and by a number of Quality Classes (QC) among which the user
can choose the quality level suitable to his/her requirements. The QCs are created such that a
user will always perceive a difference in quality level between one class and another. A set of
Network Parameters (NP) and the related Levels (NPL) are to be managed in order to provide
the user with the desired Quality Class for the used application (belonging to a certain
Application Category).
execution of tests with some meaningful reference services/applications in order to find the
correlation between Quality Classes and Network Performance Levels;
implementation of the QUASImodel (two different approaches were chosen) through
development of methodologies and tools for QoS management and measurement and
experimental testing to verify the practical feasibility, potential problems and performance
actually obtainable;
development of methodologies, policies and tools, within the framework of the QUASImodel,
for QoS charging;
experimental testing of the two different charging models proposed.
This document describes how the QUASI-model was implemented and documents the main
findings of the tests, which were conducted. The report is useful for anybody considering
implementing QoS to IP networks. It is especially relevant if QoS is implemented according to the
QUASI-model of the QUASIMODO project, the two implemented versions show how to
implement the QUASI-model using IEFT’s DiffServ and IntServ approaches. Of the main
approaches for building QoS to IP networks only MPLS is not tried in this project. Even if QoS is
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 6 (30) EURESCOM Technical Information
not implemented according to the QUASI-model, this report contains useful observations of
problems and solutions to QoS measurement and management issues.
QoS in IP networks can be implemented by modifying and elaborating these implementation
examples. They can also serve as investigated alternatives to other implementation possibilities. A
useful result from this report is also identification of a number of possible technical problems to be
faced if QoS is offered. From one of the two implementations there is source code for Linux
available for trial and further development.
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 7 (30)
2. The QUASImodel
Because an investigation on all the existing QoS models [1] has demonstrated that none of them fill
satisfactory with the QUASImodel requirements and characterisation, a new model has been
created.
2.1 The QUASI-model scenario
The simplified logical (business) and physical scenarios for the model are schematically
represented in Figure 1 and in Figure 2
The user’s perception is influenced by all of the systems involved in the service provisioning. It is
therefore possible to limit the control of performance to the edges of the provider’s network if and
only if the performance of the resources and applications used by the user are known as being
sufficient for the required service. In fact, in order to provide end-to-end quality to the user, the
user’s domain (LANs, terminals, applications) must also be taken into account in the end-to-end
transmission chain because it plays an important role in the quality that will be actually perceived
by the user. Consequently, a characterisation of the user resources should be performed, providing
the user with a description of the minimum requirements on their network to obtain a satisfactory
end-to-end service. Therefore in the scenario illustrated in Figure 2, we can assume that the
provider will offer a service in terms of control of the network performance levels at the edges of
its network (B and C points in Figure 2). Moreover the provider will characterise the user’s domain
(e.g., LANs, terminals, applications) in terms of minimum system characteristics and performance
requirements.
Business Relation
Service
Physical Connection
Provider
Retail Wholesale
Network
User Operator
B/C
points
Figure 1 Logical (business) scenario.
End system A End system B
A D
B C
User Operator(s) User
Network Network Network
Characterized Provided Characterized
Figure 2 Physical scenario
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 8 (30) EURESCOM Technical Information
In this scenario, a provider will offer some guaranteed network performance levels at the edges of
its network (B and C points in Figure 1). Moreover, it will characterise the user’s domain
(composed by his end system and the local network) in terms of a minimal number of
characteristics and performance levels. It should be noted that, in the case of a multi-provider
environment, the points B and C of Figure 2 would indicate the edges of all the providers’ networks
involved in the data transmission between the two user domains. Clearly, in this case, agreements
(SLAs/SQAs) must be signed between providers in order to provide the requested end-to-end
network performance levels.
The user requires a certain Quality Class (QC) for the application/service used (belonging to a
specific Application Category (AC)) from the Service Provider. The Service Provider maps the
user requirements in Network Performance Levels (NPLs) and will ask the Network Operator to
provide at the network edges the performance values specified into the NPLs for the traffic of all
the users who have made similar requests. The Network Operator maps the NPLs to network
quality classes and applies proper quality of service control mechanisms in order to provide the
requested performance levels.
Although the user domain is directly connected to the operator network (B/C points in Figure 2),
the Service Provider will nevertheless play the central role of mapping the specific requirements of
a single user in network requirements of a group of users (who have similar requirements).
Moreover, it buys wholesale services from the Network Operator and sells retail services to an
individual user. Figure 2 show these relations.
2.2 The QUASI-model characterisation methodology
Given the above scenario, the main characteristics of the QUASI-model can be summarised as
follows:
A set of Application Categories (ACs) is identified, composed by a number of application
types characterised by significantly different NP requirements. Each AC groups user
applications having similar performance requirements. This makes the model application
aware.
Users can choose one of the offered Quality Classes (QC) (depending on his/her quality
requirements). Also the number of QC is limited in order to be manageable and to guarantee a
significant difference in perception between one class and another.
A set of NP parameters with related level and guarantees (NPL) is to be managed in order to
provide the user with the desired Quality Class for a certain Application Category.
Since Quality Classes and Application Categories are unrelated we can represent their relationship
in a table (Table 1).
AC1 AC2 …. ACn
QC1 NPL11 NPL12 ... NPL1n
QC2 NPL21 NPL22 ... NPL2n
… ... ... ... ...
QCm NPLm1 NPLm2 ... NPLmn
Table 1 The general QUASImodel
Each combination (QC, AC) corresponds to a Network Performance Level (NPL). A NPL is a
(small) set of network performance parameters (e.g., delay, jitter and loss), each with a value range
and a guarantee that each parameter value will stay inside the range. This represents the target for
the network in order to provide the desired Quality Class when an application from a certain
Application Category is used. Each NPL can be seen as a data ‘flow’ within the network and must
be treated accordingly.
As basic AC three reference categories has been selected, namely interactive real time, non-
interactive real time and non real time, while for NP parameters delay, jitter and loss has been
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 9 (30)
chosen. Once the NP parameters have been identified it is necessary to define value domains,
which provide an acceptable quality level for each of the ACs selected.
So a Network Performance Level (NPL) is basically defined in terms of delay, jitter and loss
parameters, upper bounds on the values of those parameters and related guarantees (e.g., % of time
the parameter value is below the threshold).
To limit the efforts in the experimental phase, we use a QUASI-model which contains two Quality
Classes, Premium and Basic and three Application Categories relative to applications characterised
by significantly different performance requirements, e.g., non real-time, non-interactive real time,
interactive real-time. The combination of the two QCs with three ACs results at most in six
possible data flows to be treated differently in the network in order to preserve the performance
requirements of the relative services/applications (Table 2). The Premium class of each Application
category would be treated better than the relative Basic class. All the remaining traffic not
belonging to these two subscribed quality classes or exceeding the agreed traffic profile or the total
bandwidth available, is treated as Best Effort (no NPL values are given for BE).
Application Categories
AC1 AC2 AC3
Quality Premium NPL11 NPL12 NPL13
Classes
Basic NPL21 NPL22 NPL23
Best Effort - - -
Table 2 The practical QUASImodel
2.3 The NPL characterisation
Some lab tests (with experts) and acceptability tests (with real users) have been carried out on some
meaningful applications belonging to different Application Categories (namely VoIP for interactive
real-time, Streaming video for non-interactive real time, and Web E-commerce for non real-time
applications). These tests were performed in order to find the correlation between Quality Classes
and Network Performance Levels. While for end systems and user network a real environment has
been used, a huge set of network impairments has been emulated through NISTNET SW [11].
Extensive and detailed results of experimental testing activities are available in [1] and especially
in [2]. The essential results are concisely summarised in Table 3. They show that for each
Application Category two Quality Classes can be created (based on different MOS (Mean Opinion
Score) levels obtained) so that they have quite different NP values and are differently perceived by
the user.
AC 1 AC 2 AC 3
Interactive Non-Interactive Non-Real Time
Real Time Real Time
Premium Delay 150 msec 300 msec 100 msec
Jitter 3 msec 50 msec best effort
Loss 2% 1% 2.5%
Guarantee 99% 99% 98%
Basic Delay 800 msec 600 msec 300 msec
Jitter 3 msec 100 msec best effort
Loss 4% 5% 15%
Guarantee 95% 95% 92%
Table 3 Example NPLs for the QUASImodel (NP values to be considered as upper bound)
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 10 (30) EURESCOM Technical Information
The values in the table are presented only as an example of possible target reference values, based
on the limited but significant tests conducted. The actual values to be used should be based on more
careful considerations, derived from the experimental part of the QUASImodel implementation and
from operational experience on the network considered.
In the Deliverable 1 [1] of the QUASIMODO project the QUASImodel, basically developed by
CSELT, Telecom Ireland and Norwegian Telecom, is fully described, together with the
experimental tests, made by Telia, Hungarian Telecom and CSELT, and the related detailed results.
2.4 Using the QUASI-model to create a user Service Offer
A typical Service Offer Specification, besides specifying the NPL corresponding to the QC and AC
chosen by the user, will contain the description of the user traffic that can be injected in the
network, the characterisation of the user domain (as discussed above) and the cost of that Service
Offer to the user. This Service Offer can be part of a Service Level Agreement (SLA) to be agreed
between the user and the provider (Figure 3).
Service Offer Specification
NPL(QC/AC)
Network Parameters e.g., delay, jitter, loss
Network Performance Limits e.g., delay = 90%
Traffic Profile e.g., bandwidth, burstiness
Characterization of user domain e.g., CPU type, LAN speed
Other parameters e.g. blocking, availability, reliability,
uni/bi-directionality, dynamic/static
Pricing Information
Figure 3 Sample Service Offer Specification
A traffic profile (e.g., average bandwidth, burstiness) will be determined for each user, i.e., the
acceptable characteristics and consequently the limitations on the traffic that can be injected in the
network by the user. The network should implement appropriate management mechanisms to
admit, shape, police and route the traffic in order to guarantee the expected NPL and prevent
congestion.
Other quality aspects of a service (for example availability/reliability) can be specified as part of
the Service Offer in terms of levels and related guarantees, but they are not directly part of a NPL
or of a QC. The directionality of the data flow will also be included here. The user will choose
whether the parameters apply to a uni-directional or a bi-directional connection. In addition, it may
be possible for the user to dynamically configure this Service Offer, rather than the provider
statically configuring it.
A Service Offer will have an overall price. This will be made up of three components:
– the cost of a NPL (depending on the couple QC/AC);
– the cost related to the traffic profile;
– the cost of the performance levels of the other offered parameters (e.g., availability).
Careful evaluation needs to be made on the combination and relative weights of the three
components.
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 11 (30)
3. QUASImodel implementations
An extensive investigation on methodologies and tools for QoS measurement and management [3]
has been carried out with the aim to find the proper ones to be implemented in the QUASImodel.
Because it was discovered that no one of them fit appropriately with the QUASImodel requisites
needed for NPL measurement and management, new implementations have been made.
In the QUASI-model architecture users have LAN access and the LANs are connected to the WAN
operator’s network via edge routers, which are so called MRPs (Measurement Reference Points)
for the QUASI-model. The users make an agreement with a service provider, who has an
agreement with a network operator. The service provider maps AC/QC to NPL and the operator
network has to differentiate traffic flows based on NPL. (Figure 1)
The QUASImodel has been implemented using two different technologies for traffic flow
differentiation: DiffServ and IntServ.
The main features of the two implementation proposed, described in detail in [5], are briefly
summarised here.
3.1 DiffServ-based Implementation
Two implementations of the QUASI-model based on the IETF DiffServ Architecture [12], have
been made, one by CSELT and another by Broadcom. They differ basically by the measurement
systems used, namely Firehunter [12] and Netsys [13].
3.1.1 Mapping user requests to network classes
The implementation of the QUASI-model allows Users/Customers to select a QC/AC for their
applications. The Customer asks the Service Provider to provide a certain Quality Class for one or
more Application Categories
The user interacts with the Service Provider through a Web-based GUI (shown in Figure 4)
allowing the user to select the preferred Quality Class for each Application Category.
Figure 4 User Interface for Quality Class selection.
When the user submits the form, the Service Provider stores the data of the request in a database
table together with its IP address. An authentication phase allows associating the IP address (whose
traffic will be treated accordingly) to the user. A sample table of the registered data is shown in
Table 4.
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 12 (30) EURESCOM Technical Information
IP address RT new request Non RT new request
163.162.28.18 Best Effort PREMIUM
163.162.28.35 PREMIUM BASIC
Table 4 Stored user selection of Quality Classes
The Service Provider map the users’ requests into their corresponding NPLs/resource requests.
Then the input interface of edge routers classify, mark and shape the input packets according to the
Application Category and Quality Class that these packets belong to. The marker function is
performed to give the flow the correct code and treatment to reflect their requests in terms of NPLs
parameters.
The Service Provider has to scan user requests recorded into the table periodically and update
access lists in the Cisco routers (MRPs) in order to accommodate those requests.
Access lists are rules to match packets based on the following information:
Protocol information in IPv4 header ( 8 bits );
Source address (with wildcards);
Destination address (with wildcards);
Precedence bits (3 most significant bits of the TOS field );
The complete TOS byte.
Through access lists it is possible to permit or deny access to packets matching ad hoc criteria. The
Cisco routers are configured so that they present an access list for each NPL. The NPL flow can be
identified by access list based on 5-tuple values. A default access list, matching all traffic but the
QC-related traffic, is used for Best Effort packets.
In the core network , network operators only perform packet differentiation based on some values
in packets, for example, TOS values and Precedence values. The DSCP [15] is an IETF term for
the combination of TOS and Precedence. The values applied to the DSCP byte is specified based
on the chosen AC/QC couple. It is worth to note that more than one NPL could share the same Per
Hop Behaviour, and therefore the same CodePoint.
The necessity to identify traffic belonging to different Application Categories is not a trivial task.
One possibility is to use the knowledge of ports and the 4th layer protocol. In the special case of two
Application Categories, we can simply use the 4th layer protocol thus making the following
assignment:
AC1 = Non Real Time. All TCP traffic can be assigned to this category. The classifier at the
edge of the network domain will then catch packets coming from TCP ports and assign them a
NPL code according to the user selection of the Quality Class.
AC2 = Real Time. All UDP traffic can be assigned to this category. The classifier at the edge
of the network domain will then catch traffic from UDP ports and assign it the NPL-code
according to the user selection of the Quality Class.
If three Application Categories are used, we also need to distinguish between Interactive and Non
Interactive Real Time traffic by using two separated codes. Classification based on the port values
of UDP traffic could do this. Here is just the case to remember that a 3rd layer router might not have
access to this information located in the transport protocol header. A more complex routing
element is then necessary. The Cisco routers can accomplish this task through Extended Access
Lists, which however are more computationally expensive.
3.1.2 QUASImodel service management
The QUASImodel implementation guarantees that once a Customer has subscribed to one or more
Quality Classes for his applications (belonging to one or more Application Categories), the Service
Provider translates each (AC,QC) request in the proper NPL. Then The Network Operator assigns
each NPL to the proper network traffic class (Expedited Forwarding or Assured Forwarding) and to
the most suitable differentiated network flow.
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 13 (30)
A DiffServ-enabled network provider dictates the rules traffic flows should respect and then it
polices the traffic entering its network in order to avoid congestion situation for a particular NPL.
Edge routers are configured so that traffic directed to the Customer, coming from any source host
in the network, is “intercepted”, correctly marked, and transported to its final destination according
to its requirements. A request from a user entails changes in all network edge routers responsible of
intercepting and marking traffic. Aggregating traffics belonging to the same AC/QC (having
similar performance requirements) allows reaching a more scalable architecture while not
compromising performance as perceived by the user. In fact the DiffServ implementation does not
consider singular flows as in the IntServ architecture and permits higher scalability and lower
costs, giving also some guarantees for the aggregated traffic. However, the DiffServ solution does
not allow reservation of network resources such as buffer space, CPU processing or bandwidth.
To check if agreed performance parameters for each NPL are respected within the network domain
according to the definition of the QUASI-model, the NPL parameters are to be measured as close
as possible to the boundaries of the network domain. So the performance measurements are done in
edge routers (MRPs). An edge router will send artificial traffic to each other edge routers in the
network and evaluate round trip times and other requested measures for each NPL. The
implementation has a centralised collection station whose task is to configure and inquire edge
routers in order to retrieve the results of the performed measurements and to check if agreed
performance parameters for each NPL are respected within the network domain.
Measurement methodologies for NPL basic parameters, namely delay, jitter and loss are defined in
[5], [6] and [10] Measurement can be done using different techniques and tools. We could add
timestamps into real traffic to obtain the useful timing information or we could inject artificial
traffic through which it is possible to estimate many performance parameters. The first one is called
the non-intrusive approach whereas the latter solution is referred to as the intrusive approach. For
data collection the two implementation made use respectively the Firehunter product by Agilent
and the Netsys for CISCO. These measurement products are responsible for collecting
measurement tests performed by the edge routers, averaging and watching over exceeded threshold.
The same PC that acts as Service provider, by receiving the requests from the users and translating
them into requests for the network, can be used as monitoring system.
3.2 QUASI-IntServ Implementation
The implementation consists of new software in MRPs and in a Management Server basically
developed by Finnet Group.
3.2.1 Mapping User Requests to Network Classes
User’s application is sending IP-packets, which enter an Access Node that is an MRP (see Figure
5). These IP-packets are not marked with QUASI-model Classes. The QoS Software takes the
packets, processes them and then forwards to the outgoing connection Before the packet is
forwarded, it is decoded to the transport protocol level and the protocol and the destination port
number are identified. Based on this information a lookup is made to a table (Table of Services)
mapping these parameters to QUASI-model Classes (QC, AC). The QoS Software converts the
QUASI-model Class to network class or ClassID (CID). The IP-packet is marked by setting the
CID and the packet is sent forward. If the (protocol, port)-pair is not in the table, no marking is
done.
There is a thread for making RSVP-reservations for given ClassIDs. A simple solution, used in the
implementation, is to have the reservations for all ClassIDs already made, and then by setting the
ClassID in an IP-packet to a given value, the packet will be treated with reserved QoS. If such
reservation were not made, the reservation can be made dynamically according to user’s requests.
The user can change the QC on-the-fly by selecting a new QC for the given AC using the “QoS
window” (Figure 5).
The user can select the application from the list of allowed applications using the QoS window.
The applications, have to use well-known destination port numbers and peer-to-peer
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 14 (30) EURESCOM Technical Information
communications. (This mapping has some limitations: e.g. Mbone with IP-over-IP is not covered
and there are other special cases).
ACCESS NODE Linux PC
(MRP)
Intserv mapping
Table of Services
Protocol Port Number ClassID
TCP ftp_port QCx, ACx QoS
TCP www_port QCy, ACy Software
IP packets with
UDP rtp_port QCz, ACz (Netfilter)
CID and
RSVP-daemon
TimeStamp
Logical connection IP packets marked
End system Physical connection
QoS Window Router,
User’s Firewall,
Network Proxies
QC/AC Selection
Figure 5 Access node (MRP) Architecture.
3.2.2 QUASImodel Service Management
The QUASI-model software implementation is a distributed system with an architecture as shown
in Figure 6.
Management
server
user agent
processes
MRP A daemon MRP B daemon
process process
user network A user network B
provider network
Figure 6 Architecture of QUASI-model implementation.
It is a hierarchical distributed system consisting of three levels:
1. User Agent (UA), a software component that allows user to register with a service provider and
subscribe/unsubscribe to the network services through a negotiation with a Management Server
(MS) using a predefined protocol,
2. MRP Daemon (MRPD), a software component that performs user registration, admission
control, statistics gathering (per class). Obtained statistics is transferred to the MS,
3. Management Server (MS), a software component, which performs task of gathering traffic
statistics from each MRPD and (possibly) serves as centralised user registry. Statistics are
aggregated and represented in a usable form.
The measurement software is running on MRPs A and B. The management software is running on
the Management Server.
The QUASI-IntServ software performs the following tasks:
measures NPL-parameters per AC/QC-pair and per MRP-pair,
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 15 (30)
maps of AC/QC to NPLs,
manages QoS so, that the requirements for each AC/QC-pair are satisfied, this is done by
having RSVP-reservations between MRP-pairs and admitting user connections to the reserved
flows by admission control,
dynamically changes bandwidth allocations between MRP pairs based on NPL-measurements.
The following capabilities are needed at MRPs:
At MRP A, register user packet and timestamp it. At MRP B, register the packet, read the
timestamp and clear it from the packet and perform calculation of NPL-parameters Delay and
Jitter.
To accomplish this task, the QoS software is architecturally located between the Datalink and IP
protocols layers in TCP/IP protocol stack (Figure 7). For IP traffic accounting and measurement
this is the best place, since it is possible to intercept in packet processing before or after it is gone
through the whole protocol stack.
Application
Transport
Network
Measurement
and Management
Datalink software
Figure 7 Architectural location of QoS software.
The following aspects must be considered when implementing time stamping:
The time for packet manipulation should be minimised in order to keep the additional delay
small. This means, that the software should be extremely effective. The implemented solution is
based on the Linux OS, which is relatively efficient.
The information added to the packets and used for measurement should not introduce a heavy
data overhead.
To obtain useful traffic timings the time at both MRPs, A and B should be synchronised
The QoS software running at each MRP calculates the NPL-parameters continuously over certain
time intervals and stores the results in the local MRP memory. The calculation of the average delay
and the average loss rate are made once in 16 minutes, while the calculation of the average jitter is
done once in 10 sec, and then the average jitter is calculated for 16 min interval (we are interested
in short range jitter). The average QoS parameters are then sent through a TCP-socket interface to
the MS from each registered MRP once in 16 min. The MS itself collects the data coming from
different MRPs and stores them to its local memory, and then it calculates the average QoS
parameters of the whole system.
The MS stores the average values of QoS parameters per each MRP pair and the average values of
QoS parameters of the whole system to file in a readable form. The charging system can have
access to this file using a defined interface and read the required values of QoS parameters. These
values can be used to charge the users according to the QoS achieved.
3.3 Testing of QUASImodel implementations
Extensive tests aimed to analyse the critical aspects of QUASImodel implementations and their
performances has been carried out by CSELT, Broadcom, Finnet Group and Portugal Telecom. The
detailed results, used to derive the conclusions of this document, are reported in [6] and commented
in [3].
Note: Extended references for literature works taken into account or implemented in the
QUASImodel can be found in [1],[2],[3],[4],[5].
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 16 (30) EURESCOM Technical Information
4. Charging policies for QUASImodel
The QoS related charging activities started with overviews and surveys, defining a charging
framework, model, schemes, proceeded with requirements analysis mainly coming from network
providers, economic perspective on the QoS charging and its role in the new service model for the
multi-service Internet. These results, together with an extensive survey conducted among the
project participants and other shareholders/TLC operators are reported in [8] and were used to
develop two independent charging evaluation approaches (by BT Labs in collaboration with UCL
(University College London) and by Deutsche Telekom T-Nova in collaboration with GMD
FOKUS). The implemented solutions has then been analysed through experimental tests.
The objective of both efforts was to design, specify, prototype and evaluate QoS charging solutions
which meet the following major conformance requirements:
the QUASIMODO QoS provisioning model (see [1]);
PNO requirements;
emerging industry standards found in best current products and IETF standardisation efforts.
While the BT Labs approach analyses an innovative distributed QoS charging system, the DT
solution concentrates on a centralised system.
The major results of this work are:
a complete and systematic QoS charging system design, specification and experimental
evaluation;
identification of system components which have standardisation potential.
3.1 QUASImodel Charging Schemes
A charging scheme is an algorithm for calculating the charge for some network service 1. The
reference QUASImodel charging scheme, basically developed by OTE, is briefly described here.
A QUASImodel customer's charge for network services can be basically expressed as follows:
Charge Access_charge Usage_charge i (Eq. 1)
i
where Usage_chargei is the charge related to a user generating bursty traffic. It can depend on the
user's traffic profile, the statistical characteristics of the user's traffic and to the NPL guaranteed by
the network related to the x couple (AC/QC) selected by the user and using the connection i. These
parameters are included in the SLA between the user and the service provider. It is desirable to map
all these quantities into a scalar that reflects the relative amount of resources used by the user.
In a QUASImodel environment a customer expects to be charged according to the agreed price
only when the network provides the NPL guarantees specified in the QCS. When the service
offered by the provider does not adhere to the NPL guarantees defined in the QCS, compensation
schemes could be applied.
In the simple case where the usage charge is linear in measurements of duration (time) and volume,
the usage charge can be written as:
Standard_usage_charge + Reduced_usage_charge =
pc + pTTi + pVVi + pT,reducedTvgi + pV,reducedVvgi . (Eq. 2)
where the quantities introduced are defined below:
1 In this section, the term "network service" is used to refer to either end-user service or network
transport service.
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 17 (30)
Charging scheme parameters:
Access_charge: part of the total charge for network services that can contain a one-time site connection fee
and monthly rental
Usage_charge: part of the total charge for network services that is associated with resource reservation and
consumption
xi: In the case of transport services, includes the Network Performance Level (NPL) and traffic
profile contained in the Quality Class Specification (QCS) for service i. In the case of end
services, includes the service (application) and quality class.
pT(xi): charge per unit of time (e.g. ECUs per minutes) of the resource reserved
pV(xi): charge per unit of volume (e.g. ECUs per Mbyte) of the resources used
pc(xi): per connection charge (applies only to connection oriented services)
Ti: duration of service or connection i
i
V: transferred volume during service or connection i
Compensation scheme parameters:
pT,reduced: reduction per unit of time charge, when the corresponding NPL is violated
pV,reduced: reduction per unit of volume charge, when the corresponding NPL is violated
Tvgi: duration of period in which NPL is violated for service i
Vvgi: volume transferred during period in which NPL was violated for service i. This variable can
either be measured directly by the QoS monitoring system, or estimated from other
measurements.
Vvg: volume (of all flows corresponding to a given NPL) transferred during an NPL violation
period.
3.1 QUASImodel charging implementations
The accounting architecture is based on the charging and accounting reference model [8]. The
general five layers Charging and Accounting Reference Model used in the project are shown in
Figure 8. The figure illustrates the basic functions that a generic billing system goes through from
capturing the usage to creating a bill to be sent to a customer.
Billing Configuration
Billing Policy Billing Layer
(e.g. bill template)
User/Service specific
requirements Charged data
Charging Configuration
Charging Policy Charging Layer
(e.g. charging formula)
Charging specific
requirements Accounting data
Accounting Configuration
Accounting Policy Accounting Layer
(e.g. collector address)
Accounting
requirements Collected data
Collecting Configuration
Collecting Policy Collecting Layer
(e.g. meter address/
placement) DI
Collecting
requirements Metered data
PI
Meter Configuration
Metering Policy Metering Layer
(e.g. metering intervals) CI
PI = policy interface; CI = configuration interface; DI = data interface
Figure 8 Charging and Accounting Reference Model
There are two basic different architectural approaches for implementing the QUASImodel. One is
the standard centralised architecture, developed for example by DT, while the other is a distributed
architecture currently under development by BT. The BT and DT Charging Architectures
description, found in [9], was used to determine which of the functions are implemented by these
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 18 (30) EURESCOM Technical Information
architectures. In particular BT introduces a sixth layer, dealing with payment policy and process, to
cover some specific feature of this implementations.
4.2.1 Centralised architecture (DT)
Figure 9 shows the DT centralised accounting architecture.
Billing
Billing and Billing
Charging Policy
Policy Charging
Server Policy Charging
(TFL)
Policy Accounting
Gateway Data Gateway
Accounting
Accounting Accounting
Policy PIP-NAR
PIP-NAR
& Metering
Collecting
Policy Server Collecting Collecting
Policy
Meter Policy
M
Metering M M M M M M
Provider Domain A Provider Domain B
Figure 9 Centralised accounting architecture
The architecture uses metering conformant to the IETF Real Time Flow Measurement Architecture
(RTFM) [28]). Collecting entities at each domain collect data from the meters.
In the architecture the configurable metering tool NetTraMet (Network Traffic Meter RFC2123,
[29]) is used for monitoring the resource usage. The NetTraMet meter is a stand-alone SNMP agent
that stores the measured data in a meter MIB defined in RFC2720 [30]. NeTraMet uses rulesets as
instructions for the classification process. Rulesets are downloaded by a management application to
the meter and also stored in the MIB. A Simple Ruleset Language (SRL) has been developed to
simplify the creation of rulesets (RFC2723, [31]).. The DiffServ Codepoint Information can be
used as an attribute and a NeTraMet extension for support of capturing RSVP flowspec information
in addition to the flows has been proposed in [18]. NeTraMet is open source and runs on
Sun/Solaris, Linux, freeBSD and DOS. The used version was 4.4b6.
A data structure has been specified, referred to as PIP-NAR (Premium IP Network Accounting
Record) for the transportation of accounting data. This data structure allows to transport usage
information within one provider domain and also to exchange usage information in a multi-
provider scenario. The data structure contains reserved and used resources for an IP flow. It
contains a measurement point identifier and a record description to support different styles of PIP-
NARs (uni-directional/bi-directional, DiffServ/IntServ style, and others). For unique identification
of the flow, a flow description is used. The structure of the PIP-NAR and the protocol for the
transportation of PIP NARs are presented below.
Meter configuration is done via policies that are translated into the appropriate configuration
information for the meter and data collection process. For the metering NeTraMet rulesets are
derived from this policies. With this the meter can be instructed to meter only the required flows
and store only the relevant flow attributes. Furthermore the collection intervals can be configured.
Meter Records was encoded in Accounting Data Interchange Format (ADIF) proposed by the AAA
IETF working group [19]. The ADIF is a human readable accounting record format, which is based
on MIME. The NAR Exchange Protocol (NEP) is a small protocol for transferring ADIF records
over an IP-based network. The protocol is strongly based on the DIAMETER protocol [20]
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 19 (30)
4.2.2 Distributed architecture (BT)
In the BT implementation, metering and accounting processes are performed in the customer
machines. This helps scalability, opens up customer control and improves responsiveness to price.
The BT solution mapped on the reference model is depicted in Figure 10.
Customer Provider
Payment Layer Payment Layer
Billing Layer (optional) Billing Layer (optional)
Charging Layer Charging Layer
Accounting Layer Accounting Layer
Aggregating Accounting data Collecting
Metering Layer Metering Layer
= external interface
Figure 10 Charging Model: Distributed BT accounting system
BT’s metering and accounting architecture conforms to the IETF RTFM (Real Time Flow
Measurements), which is described in RFC2722. However, BT has tailored it to their
requirements..
The meter is configured using a control file called RuleSet. It is a set of specific rules written for a
Pattern Matching Machine-PME (RFC2722 [32]). The configuration is performed by the Manager.
Usually, it uploads a ruleset into the meter. After, the meter starts matching information within
packet headers against the rules.
Finally, the data stored in the Meter needs to be collected. The Reader component provides such
collection mechanisms. Currently, the RTFM MIB (RFC2720 [30]) supports only Pull Mode. The
Manager tells the Reader which data should be collected. Then, the Reader using a request/reply
protocol (e.g. SNMP) polls the Meter in order to supply the Manager with metered data.
The scenario illustrated by Figure 11 briefly describes distributed metering interfaces. A provider
multicasts tariff objects to all Dynamic Accounting Managers (DAC) (1). Once a customer’s DAC
has received a tariff, it loads dynamically a module called Tariff Translator (TT) in order to
perform a translation to appropriate Accounting and Meter Policies (AMP) (2,3). Thus, the AMP is
a set of ECA (Event-Condition-Action) generic policies derived from the tariff. It specifies
explicitly/implicitly accounting/metering requirements. After that, the AMP is transformed to
Meter specific control and uploaded into a Meter (4). For the RTFM architecture, the meter control
is a rule set as described in RFC2722 [32]. On the other hand, for Cisco NetFlow meters, control is
appropriate Cisco Flow Collector rules [21]. Therefore, this proposal aims to be generic, thus
providing mechanisms for metering and accounting independently of the low-level meter in place.
It might be a combination of BT’s modified RTFM Meter implementation, or a Cisco Netflow with
Flow Collectors or Linux routers with some packet filter enabled (e.g. BPF, Netfilter).
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 20 (30) EURESCOM Technical Information
RTFM Meter Arch
5.Data 4.Control
(Pull Mode) (Ruleset)
2. Tariff
DAC
6.Data
(unicast)
3. AMP Set
1. Tariff Multicast Channels
Provider
3. AMP Set
2. Tariff
Tariff
DAC Translator
5.Data 4.Control
(Push Mode) (Flow Collector rules)
Cisco NetFlow Arch
Figure 11 Accounting/Metering
The Provider/Customer collect the accounting data from Meters using one of the following modes
(5):
Pull Mode or Proactive: a Reader polls the meter periodically in order to gather metered data,
usually through a request/reply mechanism.
Push Mode or Reactive: a Meter pushes out data to a set of Readers/Collectors registered as
listeners when a pre-defined event occurs. BT has identified so far some categories of events as
follows:
Packet-related (e.g. set of packets arrival),
Temporal (e.g. clock timeout),
Protocol-related (specific TCP stream)…
The translation performed in steps (2,3) has derived the accounting requirements. Therefore, the
collected data from the meters is one form of input to calculate the usage charge. In Figure 11, only
the accounting and metering processes are shown.
Each customer DAC makes use of a generic interface GMAI (Generic Metering and Accounting
Interfaces) in order to cope with configuration and data collection. All the logic of those both
processes is encapsulated by the implementation of two partial interfaces, which composes such an
API: one for control and another for data.
The interface defines an abstract model for different metering/accounting architectures (IETF
RTFM, Cisco Netflow), which hides several details such as the communication protocol.
The accounting system deals with the gathering and storage of network usage records. It is
sometimes termed a mediation system. In the distributed charging solution (see for example [22]) it
can reside in the customer machine.
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 21 (30)
The BT solution allows tariffs to be multicasted to both the accounting systems. The accounting
system tunes in and listens for any tariff announcement from the multicast channel. Charges are
then calculated by combining network usage records to tariff.
To provide security for the provider if the customer has agreed to do their own accounting, the
architecture incorporates a “traffic warden” feature. This performs random security sweeps,
sampling the established customer base trying to locate inconsistencies in the accounting data that
are being transferred between the client and the provider system.
4.3 QUASImodel conformance of charging implementations
In this section we address the issue of QUASImodel charging. That means we show how our
approach can be used to charge directly for Quality Classes. We assume that QUASIMODO
quality classes are directly presented to an end-user according the QUASImodel implementation
described in Chapter 3. All material related to QUASImodel charging issue and its implementations
can be found in [7],[8],[9].
4.3.1 Centralised charging approach
In the first place, if there is some signalling between end-system and edge router by which a
microflow produced/consumed by a particular application is tagged directly or indirectly by a QCS
value, then we conclude that some accounting entity is to be embedded in the edge router or the
end-system. The above accounting we suggest to dub direct QCS (Quality Class Specification)
accounting. This embedded accounting entity is then responsible for setting up parameters of the
metering system.
Second, when providing direct accounting for QUASIMODO classes it has to be considered
additionally how the QoS is enforced at the network (IP) level. This is important for the selection
of appropriate charging schemes. We consider two cases: IntServ capable and DiffServ capable
networks.
In the case of IntServ, the Quasi-matrix can contain the Rspec parameters for the different classes
(Table 5). The charging scheme will be based on these reservation parameters. It might also
contain a usage based part. In general the charging formula will look similar for all QC/AC
combinations. That means that the tariff variables used in the formula like reservation parameters
and actual used resources (like volume) will be the same for all QC/AC but the tariff coefficients
(e.g. price per unit volume or price per reserved rate) will differ. That means all the tariffs can be
derived from a common formula. For the basic service with nrt (non-real-time) requirements it
might be that a pure best effort service without reservation is used. Here still the common formula
can be used by simply setting the tariff coefficient for the reservation part to zero. For the other
classes it is more likely that it is always charged for the reserved resources and the addition of a
usage based part is optional.
SC1 (nrt) SC2 (rt)
Premium Rspec11 Rspec12
Basic Rspec23 Rspec24
Table 5 IntServ Classes
In the case of DiffServ (Table 6), have to consider different PHB groups for the different QC/AC
combinations (e.g. AF for (nrt, premium) and for (rt, basic), and EF for (rt, premium), leaving best
effort for (nrt, basic)). Here different formulas might be used to charge for the different service. It
is important for instance how traffic is handled that exceeds the negotiated thresholds and what
kind of drop preferences are applied (e.g. dropping vs. degradation to a lower class)
SC1 (nrt) SC2 (rt)
Premium AF EF
Basic BE AF
Table 6 DiffServ Classes
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 22 (30) EURESCOM Technical Information
The policy rules which are used to configure the IP meters are constructed by considering a desired
charging policy or more precise a tariff structure. A tariff structure can be expressed in the Tariff
Formula Language (TFL). This tariff formula can be used as input to the charging architecture. A
tariff formula generally includes different parameters that describe a network service usage.
Important dimensions that describe a network service usage are the volume and the time.
Volume can be measured in bytes or in packets. In bytes it reflects the consumed bandwidth on
links; in packets the header-processing work that has to be performed at each router along a
packet's path, and not properly the bandwidth consumption, since the IP packet length is variable
For a volume-based charging policy it is not only relevant how much bytes or packets traverse a
metering point, but also the direction of the data flow might be considered. Charging policies might
be desirable which consider either only the volume received by a customer or the total (bi-
directional) volume sent/received by a customer.
Besides the volume the time is an important dimension which can be considered within a usage-
based tariff structure. To measure the volume and the duration of a single flow allows to determine
the mean rate of the flow. A tariff structure can also consider the time-of-day. The time-of-day in a
tariff is applied to smooth out the demand for network services by charging a higher price during
busy hours. The TFL is capable to express different charging policies, which use any combination
of the described usage parameters. Suitable policy rules for IP meters can then be constructed with
the TFL expressions as an input factor.
For Integrated and Differentiated Services a charging policy or tariff structure that considers only
volume or time is not sufficient. The QoS that is granted to a flow has to be considered in some
way in the tariff structure.
4.3.2 Distributed charging approach
Implementation and experimental tests performed by BT show that distributed charging
architecture can easily be adapted to suit the “practical QUASI-model”.
An SLA (Service Level Agreement) was created for each class of service per QC/AC (Quality
Class/Application Class) and selected directly by customer (Table 7).
Application Categories
AC1 AC2 AC3
Premium SLA 1P SLA 2P SLA 3P
Quality
Classes
Basic SLA 1B SLA 2B SLA 3B
Table 7 An illustration of SLA to QC/AC mapping
The transformation of Quality Class was into NPL (Network Performance Level) was carried out
by the users’ system. The meter measures the network resource request generated by the customer.
The measurement record is then collected by the accounting system. Charge is then calculated with
the charging policy (tariff) per network resource requested (Figure 12).
Figure 12 A screenshot of a charge per RSVP 64KB resource request tariff
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 23 (30)
BT’s architecture recognises that it is very costly to measure delivered quality, but much easier to
measure requests for quality. Therefore, the general scheme is to measure admitted requests as the
only input to the charging system, and delegate responsibility to network mechanisms for ensuring
that admitted requests result in the requested service.
In the case of IntServ, the relevant network mechanism is reservation admission control, and the
relevant requests to measure are the RSVP PATH & RESV messages, plus potentially the volume
of traffic under a reservation.
In the case of DiffServ, the relevant mechanism is ingress per packet policing of traffic conditioning
agreements, and the relevant requests to measure are the TCA (Traffic Conditioning Agreement)
set-up requests, and possibly the volume of traffic presented to each class of service.
The customer machine self-polices the TCA on a per flow basis, marking conformant traffic as
appropriate, leading to conformance with the TCA for the whole machine (per IP address). Then
the traditional DiffServ architecture is adopted on a per IP address basis from the network edge
onwards. The important point maintained by the distributed architecture is that the DiffServ pattern
of reliance on aggregation as each organisational boundary is crossed is correct, but it stops too
early. Per flow handling should be dealt with on the host, with aggregation so that only per address
handling is necessary once the network edge is reached.
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 24 (30) EURESCOM Technical Information
5. Conclusions coming from QUASImodel implementation and
experimental tests
5.1 QUASImodel QoS management and measurement
In this section we return to the questions the project wanted to answer.
What are the possible approaches for QoS measurement and management?
There are basically three main approaches for QoS management: DiffServ, IntServ and MPLS that
could be used to implement a QoS architecture such as the QUASI-model. There are other QoS
architectures, but they are not useful in this context. The IntServ solution is relatively far from the
needs of the QUASI-model, therefore we created the QUASI-IntServ model. There are a number of
methodologies and tools for QoS measurement. The methodologies of IETF IPPM and ITU-T I.380
do not correspond accurately to the needs of the QUASI-model, therefore the NPL-parameters were
defined in the project. Existing tools can be used for QoS-monitoring. Existing tools can be used
for QoS-monitoring. It is feasible to implement own measurement methods and to measure the
NPL-parameters more precisely and according to the NPL definitions.
Are the QUASImodel NPL-parameters correct and are they independent?
The NPL-parameters delay, jitter and loss seem like a good choice of NPL-parameters. They are
also selected by other parts of the industry. There is a need for admission control in the QUASI-
IntServ implementation, which means that connection blocking is needed. Admission control is
most probably necessary also in the DiffServ based implementation for guaranteeing sufficiently
low losses, though it is not currently implemented.
Can the QUASI-model be implemented?
The QUASI-model is quite flexible and can be implemented in several ways. However, neither
DiffServ nor IntServ are as such ideal for the QUASI-model.
How can the user application be mapped to AC/QC pairs?
The proposed way is to use a WWW-page, as in the DiffServ implementation, for user selection of
the AC/QC. Mapping applications to AC/QC is not an easy matter. We have mapped applications
using the port number and the IP-address of packets coming to the MRP. There are special cases
that have not been treated: Mbone is IP-on-IP. It is currently not supported. Separating RTP traffic
from other UDP traffic, such as DNS, is not treated. The problem is, that RTP does not have a
protocol number, nor a well-known port number. It may be best to separate some UDP traffic (e.g.
DNS requests) and treat the remaining part as RTP traffic and give it good quality.
How can the NPL-parameter measurements be offered to a charging system?
The NPL-measurements are collected every 16 minutes and the data is available for a charging
application in a central point, a data gathering system. We have not investigated whether 16 min is
a suitable time interval, but it can be changed easily. (5, 15, 30, 60 min are natural values.)
How can QoS be managed?
Both DiffServ and QUASI-IntServ are working solutions for QoS management. They are described
in Chapter 3.
How to implement NPL-measurements?
DiffServ implementations. Measures of delay (using Cisco SAA) are precise enough for the
purposes of our architecture, but only if values to be measured are not dramatically low; jitter is
evaluated with good precision too. Losses are not well evaluated; this is due to the fact that too
few samples are used. Using more samples presents the drawback of increasing measurement
traffic to unsustainable levels. Measuring small loss probabilities, say 10 6 would not be
possible with test traffic Measurement instruments should generate test traffic having the same
characteristics of the real traffic crossing the network.. Moreover, traffic traversing the network
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 25 (30)
is itself really heterogeneous, thus increasing the difficulty of parameter setting. With regards
to jitter measurement, it is very difficult to establish its statistical stability because its measure
is based on inter-packet delay variation instead of the delay variance.
IntServ implementations. The overhead of time stamping in delay and jitter measurements is
relatively low. The values are more precise, especially for jitter. Defining jitter as short time
delay variation is a more constant figure than measuring maximum jitter in a read-out period.
Advantages of using maximum jitter could be discussed. Measuring loss by counting discarded
packets is precise and has the advantage of protecting the core network. This measurement
method can be scaled to arbitrarily low loss probabilities Measuring connection blocking is
straightforward if admission control is used. There are no special problems implementing
NPL-measurements in the QUASI-IntServ model.
Are the values for the NPL-parameters correct in Table 3?
Because the test were basically laboratory tests and they have not been performed in different real
network environments final conclusions for recommended target NPL values have not been
reached. However, taking into account as reference the sample values of Tab. 3, a more precise
tuning of them can be performed by a service/network provider through the direct operational
experience gained in his specific network environment and the cost needed to offer and to
guarantee them. Note that in complex network environments also the basic target values proposed
could not be easily achieved and guaranteed at reasonable costs. In fact the first question is of delay
bounds 150 msec, 300 msec and 200 msec. These upper bounds have been set by usability tests in
the project, here the question is if the values can be achieved. Delay is composed of queuing
delays, processing delays and propagation delays. Propagation delay is 1 msec in 200 km, so the
sum of propagation delays is usually less than 20 msec. Number of hops is usually less than 30.
Queuing and processing delay in one router is (from Test 6) typically 1-2 msec and the overhead
for time stamping is 4 msec. This sums to 20+60+4=84 msec. The values in the tables can be
reached. However, it does not seem, that delays in the end systems have been correctly accounted
with. In reality, the delay bounds in IP for telephony are quite hard for the network due to the end
system delay. Base on the tests we cannot give any values for the Basic class, only theoretical
minima for the Premium class.
The motivation in Table 3 for the very low jitter requirement is that the waveform of speech is
distorted if the jitter is higher than 3 msec. However, it is still not possible for a human ear to hear
it. From some recent (unpublished) tests of IP telephony there are results indicating that in the
present Internet the median of the jitter is about 20 msec and about 97% of packets have jitter
below 40 msec. These results cannot be taken as general results, they only give the rough
quantitude of jitter we can expect. Setting jitter requirements below 40 msec should be considered
only if there is real reason for it.
With loss we can say that test traffic measurements can measure accurately up to 1% but not below.
It is possible, that in the future much lower loss probabilities are needed if several classes are
offered. For classes offered to TCP sources we should select the loss probability so, that the sources
can control their sending speed but also stay in the congestion avoidance stage. If the acceptable
loss probability is too low, sources cannot control their sending speed. If the acceptable loss
probability is too high, new sources can stay in slow start. Then we cannot measure only using
delay, jitter and loss as the transfer rate can be too small even though loss is acceptable, as the
source has slowed down transfer speed because of the losses.
With the guarantees, the guarantee should be given for each 16 minutes time slot, not as the
average over longer time when there are low traffic times to decrease the average.
Does the QUASI-model work?
Yes, both implementations work well in the laboratory tests. However, appropriate further
activities should be planned to investigate the possibility to test the implementations in:
A heterogeneous ISP domain with a large number of nodes and where the routers are using
different packet scheduling policies.
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 26 (30) EURESCOM Technical Information
A multi-domain environment where the routers of the different domains must co-operate to
assure an appropriate class differentiation as well as the final edge router to perform the
measurements of the NPLs and the related guaranties.
Furthermore, especially for bandwidth allocation between the various traffic flows (related to
NPLs) and queue length assignment, more precise strategies, traffic and queuing theory based,
should be developed, helping the service and network provider in setting up and tuning
appropriately the critical parameters of the network.
Do the users see the difference between the classes?
From testing results we can draw the following conclusions:
For the DiffServ based model:
- DiffServ is sufficient enough for QUASI-model implementation, users can see the difference in
the service quality they receive when they move from Premium class service to Basic class
service in any network load including the worst case.
- Tolerance of each Quality class is network configuration-dependent. In order to conform to the
definition of QUASI-model we have implemented QUASI-model by using DiffServ in the way
the Premium class always has better tolerance for excess traffics than Basic class application.
So DiffServ is flexible enough to give different tolerance on excess traffic to different
application classes.
For the QUASI-IntServ model:
- RSVP reservations guarantee the bandwidth allocations for each AC/QC. The admission
control is sufficient in the laboratory tests. Users see the different bandwidths; they do not
actually see the difference in the service quality they receive when they move from Premium
class service to Basic class service
The laboratory tests performed clearly indicate the real possibility for an ISP to differentiate and to
manage quality classes in an IP network domain. The quality classes are obtained through different
edge to edge NPLs resulting in differently perceivable qualities for the user.
5.2 QUASImodel QoS charging
Despite the fact that some vendors are already offering on commercial basis QoS charging
products, it becomes clear from this document that these products are covering only parts of the
system a provider would need to be able to charge efficiently for QoS enabled IP services. So the
QUASImodel charging implementations and the experimental tests conducted was needed as a
basis for an operational complete charging system. Extensive experimental evaluations have been
carried out by DT and BT in order to prove the “chargeability” of the QUASImodel, to find the
most efficient metering implementation and to assess the metering and accounting performance.
The obtained results are reported in [9].
The results show that when the number of variables introduced in the formula algorithm for
accounting quadruples, the accounting time doubles. This implies for example that passing from a
Best Effort to IntServ the accounting time increases of the 50%.
Experimental results show that both a centralised and a distributed charging system does conform
to the QUASIMODO specification. They can be tailored to charge customer per QUASI-quality
class. Nevertheless while for Integrated Services approach solutions are already available, for
Differentiated Services further standardisation and implementation activities are needed.
5.3 Final comments
The report demonstrates that the QUASI-model can be implemented in several ways; NPL-
measurements can be realised and IP-networks dimensioned to support the NPL classes. At least
for IntServ based solutions it may be useful to use blocking. The Best Effort class is worse than
NPL-classes since the NPL-parameters are not guaranteed. NPL-classes all have good NPL-
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 27 (30)
parameter values and are not differentiated by them. Connection blocking is lower for Premium
than for basic and it makes the class differentiation.
Note that some aspects in the implementations made could be further elaborated:
For the DiffServ implementation currently dynamic management is missing. We have potential
scalability problems if all users of better quality classes must be put to access lists of all edge
routers. Furthermore, reaching effective quality level differentiation between the quality classes
and accurate measurement of the current NPL values achieved needs a fine tuning of the edge
routers parameters (bandwidth assignment for rate limiters between the NPL flows, choice of
queues lengths, setting priority and tolerances to management mechanisms, define correctly
frequency and packet length for testing traffic, etc.), especially when not all the routers are
homogeneous as operating system and management mechanisms implemented.
For the QUASI-IntServ implementation, admission control is currently rough. Dynamic
management of QoS could be done with some optimisation algorithms. Mapping of user
requests to AC/QC is not a complete solution.
The QUASI-model does not treat multi-provider networks, nor different access networks.
Also QUASImodel charging can be implemented in different ways:
The classical centralised architecture, where the metering is performed at edge router of the
provider’s network, seems more stable and reliable but with some problems of scalability,
computational time and costs. In this case the system uses policy based QoS charging, treating
policy mechanism as the core configuration mean.
The distributed architecture, where the metering is performed at the user’s terminals, seems
more open and flexible to suit to technological network changes, services evolution (multicast,
multimedia..) and personalised real time billing (dynamic pricing, active tariff, self-billing etc.)
even if its reliability, customer acceptance and compensation processes in case of meter
discrepancies between customer and provider should be further investigated and improved.
The innovation throughout distributed charging system architecture leads to a very flexible
solution. It allows network businesses (providers and customers) to tailor the system to suit their
needs. By optionally moving processes to customer machines, it relaxes the demand on the
provider for a huge server pool thus reducing operational costs, and enabling infinite scalability.
Service perfection doesn’t depend on the processing power of machines, it is good management
and policing which count.
Further, by the introduction of dynamic pricing mechanism, which are enabled as one option in this
architecture, the network can be managed by competition of demand. Quality of Service can then
be guaranteed through market forces. Tariff multicasting mechanism “makes” dynamic pricing a
practical proposition.
A policy based control system allows each component of the system to be reconfigured on the fly.
Because of the flexibility of the distributed charging system, tailoring the system to suit different
requirement specification for instance QUASIMODO is an easy possibility. For an e-business
changing dynamically, a distributed charging architecture could be a good solution.
The final issue to resolve is: "What about failure to deliver the specified service?" his issue divides
into two further issues:
Can it be proved that there was a NPL violation?
Which provider(s) in a multi-provider chain were to blame?
The former is a difficult problem. A solution is given in [26], but involves the use of smart cards.
The latter is also a difficult problem, because with an end-to-end service, it can be very costly to
apportion blame when things go awry. If the customer has paid for reliability, who should give the
refund if a packet is dropped? If latency is guaranteed, who gives the refund if some network has
used too much of the delay budget? However, Briscoe [27] proposes a pragmatic principle for these
circumstances. If a customer disputes payment and their local provider accepts their case (or can
not be bothered to argue) all providers on the end-to-end path share the same fate, losing the
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 28 (30) EURESCOM Technical Information
associated revenue, or at least not bothering to account for the refund between themselves. This is
akin to peering between ISPs today, but need only be applied to the exceptional cases of failure.
Hence this is termed “exception peering”. Just as with peering, occasional audit would be
necessary to ensure gains and losses were within acceptable tolerance of each other.
5.4 The Usefulness of QUASImodel
As can be deduced from this document, the QUASImodel is a realistic concept, and can be
implemented using state-of-the-art mechanisms.
However, there is one part, which can become a bottle neck. That is the classification of
applications into ACs. Since there is a need to keep the number of ACs low, the grouping may be
too ‘course’, meaning very different applications may be put in the same AC. This could lead to
difficulties to provide perceived different Quality for users of these applications.
We feel that further research is needed on this issue. We remain convinced though, that the concept
of Quality Classes is correct.
EDIN 0088-0906 2001 EURESCOM Participants in Project P906
EURESCOM Technical Information page 29 (30)
References
[1] P906 Deliverable 1 – “Offering Quality Classes to end users Vol. 1: Main Report,
EURESCOM 1999.
[2] P906 Deliverable 1 – “Offering Quality Classes to end users Vol. 2: Annexes,
EURESCOM 1999.
[3] Project Report – “Methodologies and tools for QoS measurement and management”
EURESCOM 2001, EDIN 0055-0906
[4] Technical Information – “Survey of existing methodologies and tools for QoS
measurement and management” EURESCOM 2001, EDIN 0056-0906
[5] Technical Information – “QUASImodel implementation” EURESCOM 2001, EDIN 0057-
0906
[6] Technical Information – “Experimental evaluation of QoS measurement and management”
EURESCOM 2001, EDIN 0058-0906
[7] Project Report – “Methodologies and Policies forQoS charging” EURESCOM 2001, EDIN
0059-0906
[8] Technical Information – “Key QoS charging issues” EURESCOM 2001, EDIN 0060-0906
[9] Technical Information – “Experimental evaluation of QoS charging” EURESCOM 2001,
EDIN 0061-0906
[10] Jormakka J., Heikkinen K., ”QoS/GOS parameter definitions and measurement in IP/ATM
networks” QofIS2000 workshop.
[11] NistNet HomePage http://www.antd.nist.gov/nistnet/index.html
[12] Carlson M., Weiss W., Blake S., Wang Z., Black D., and Davies E., “An architecture for
Differentiated Services”,RFC 2475, December 1998. http://www.ietf.org/rfc/rfc2475.txt
[13] FireHunter HomePage http://www.firehunter.com
[14] Netsys HomePage http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/netsys/
[15] Nichols, K., Blake, S., Baker, F. and Black D., "Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
http://www.ietf.org/rfc/rfc2474.html
[16] N. Brownlee: Reference Manual NeTraMet & NeMaC Version 4.1, Information
Technology Systems & Services, The University of Auckland, New Zealand, November
1997 (http://www.auckland.ac.nz/net/Accounting/ntm.Release.note.html)
[17] N. Brownlee: srl Compiler and Language User's Guide Version 4.2, Information
Technology Systems & Services, The University of Auckland, New Zealand, August 1998
(http://www.auckland.ac.nz/net/Accounting/ntm.Release.note.html)
[18] Massimiliano Canosa, Martino De Marco, Alessandro Maiocchi: „Traffic accounting
mechanism for Internet Integrated Services“, CEFRIEL, Politecnico di Milano (1998)
[19] B. Aboba, D. Lidyard: The Accounting Data Interchange Format (ADIF), Work in
Progress, IETF Internet Draft , August 1999
[20] P.R. Calhoun and A.C. Rubens. DIAMETER Base Protocol. IETF Internet Draft , Oct. 1999.
[21] Cisco Systems. NetFlow Services and Applications.
[23] M. Karsten, J. Schmitt, L. Wolf, R. Steinmetz: An Embedded Charging Approach form
RSVP, International Workshop on Quality of Service ‘98, Napa, California, 18. - 20. Mai,
1998
[24] K. Nichols, V. Jacobsen, L. Zhang: A Two-bit Differentiated Services architecture for the
Internet, 1997
[25] K. Kilkki: Simple Integrated Media Access (SIMA), Internet Draft, Work in Progress,
, Nokia Research Center, June 1997
[26] B. Briscoe, I. Fairman: Nark: Receiver-based Multicast Non-repudiation and Key
Management, in Proc. ACM conference on Electronic Commerce (EC’99) Nov 1999
2001 EURESCOM Participants in Project P906 EDIN 0088-0906
page 30 (30) EURESCOM Technical Information
[27] Bob Briscoe (BT), "The Direction of Value Flow in Connectionless Networks", in Proc
International Conference on Telecommunicatons and E-Commerce (ICTEC’99), Oct 1999,
[28] N. Brownlee, C. Mills, G. Ruth, "Traffic Flow Measurement: Architecture" IETF RFC
2063, Jan 1997,
[29] N. Brownlee: „Traffic Flow Measurement: Experiences with NeTraMet”, RFC2123, March
1997
[30] Nevil Brownlee, “Traffic Flow Measurement: MIB”, IETF RFC 2720, October 1999.
[31] N. Brownlee: SRL: A Language for Describing Traffic Flows and Specifying Actions for
Flow Groups, RFC 2723, October 1999
[32] N. Brownlee, C. Mills, and G. Ruth, “Traffic Flow Measurement: Architecture”, IETF RFC
2722, October 1999.
EDIN 0088-0906 2001 EURESCOM Participants in Project P906