Side_1_360

given here – e.g. the very small jitter of 3 ms
does not mean that the users can detect jitters
so small, as jitter sensitive applications have
receiver buffers. It is based on observable dis-
tortion of the signal and applications with no
receiver buffering.

In general, the values given in Table 3 are not a
recommendation, but the examples of the values
achieved as a result of some tests.

4 Implementation of the

QUASI-model

The next step was to implement the QUASI-
model monitoring and control mechanisms.
Several techniques can be used to implement the
QUASI-model. The project focused on two tech-
niques: IETF’s DiffServ and IETF’s IntServ. We
did not consider MPLS – though it may be very
interesting – since it was investigated in other
EURESCOM projects. We also discarded some
more complicated QoS architectures (XRM,
HeiRat) as they were rather far from the basic
ideas of the QUASI-model, see [P906-3].

4.1 DiffServ Concerns

In this paper we will not describe the DiffServ
based implementation, but it is documented in
[P906-4]. It supports quality classes by setting
the Type of Service (TOS) field in the packets.
A user selects a desired service quality for his
application by subscribing to it in a WWW-page.
This information is inserted to access lists of all
edge routers. The edge router where the user’s
access network is connected marks the TOS-
field in the packets. The edge router gets the
mapping information from the access lists and
therefore the solution also supports the ability to

receive good quality, not only to send. QUASI-

model NPL classes are given different quality by

setting rate limiters, and setting limits as to how

much the rate can be exceeded without losses is

one way to obtain visibly different quality for

different NPL.

QoS monitoring is made using commercial test

traffic generating measurement tools, CISCO

SAA and some tools to collect measurement

data (FireHunter or NetSys). The accuracy is

good for delay and jitter, but very small loss

probabilities are difficult to measure accurately.

Test traffic and user traffic may not be treated

equally, e.g. if the user data flow is routed differ-

ently. The traffic management part of the Diff-

Serv implementation, notably updating the

access lists and rate limiters and their tolerances,

needs further elaboration.

The problem of the DiffServ in the QUASI-

model was basically a requirement that a sub-

scriber of better quality class should also receive

better quality, for instance for videotelephony.

One way this could be solved is to extend the

application protocols, like SIP, so that they keep

knowledge of current connections and insert into

access lists all parties of a connection. Such a

solution is outside the QUASI-model as it

requires improved application protocols. The

way this problem was solved in the DiffServ

implementation of the QUASI-model was to

have all users of quality classes better than best

effort in access lists of all edge routers. This

solution is not easily scalable. Another scalabil-

ity problem is the selected way of making class

differentiation by carefully adjusting rate lim-

iters to drop more packets from classes with Figure 3 Laboratory test bed

HUB

Linux PC

Sun

Workstation

HUB

Sun

Workstation

Linux PC

Cisco 3620

Router

Cisco 3620

Router A Router

(Linux PC)

RSVP

capable

Linux PC

Router,

RSVP

capable

Router B

(Linux PC)

RSVP

capable

Management

Server

User ́s

network

Provider ́s

network

Monitoring and

Management

System Domain

MRP A MRP B