Side_1_360

delays of IP-packets of a given AC, QC from

MRP A to MRP B.

Jitter:Jitter is 2*standard deviation of the delay

over the time interval of 10 seconds of one-way

transfer delays of IP-packets of a given AC, QC

from MRP A to MRP B. Jitter is averaged over

several time slots of 10 seconds and reported

every 16 minutes.

Loss:Loss is the loss probability over the time

interval of 16 minutes of IP-packets of a given

AC, QC transmitted from MRP A to MRP B.

The choice of 16 minutes was made because we

wanted the measurements in the DiffServ imple-

mentation to be over the same interval as in the

QUASI-IntServ implementation for easier com-

parison. In the DiffServ implementation mea-

surements were done using CISCO SAA creat-

ing test traffic. The time between test traffic

packets could not be easily assigned an arbitrary

fractional value. We set 2 * 8 = 16 meaning

8 test bursts and 2 minutes between a burst.

Each test burst of SAA consisted of a sequence

of packets selected to measure the jitter over

10 seconds.

The time interval of 16 minutes may seem far

too long considering burstiness of Internet traf-

fic. However, better QoS flows are often

assumed to be less bursty, data produced by

measurements cannot be very large for storing

and processing reasons, and dynamic manage-

ment is not expected to follow fast changes in

traffic volumes but to adapt to longer time varia-

tions. In each 16 minute time slot the RSVP-

pipes are dimensioned to carry peak traffic and

there is admission control for connections and

shaping of packets by RED in the edge routers.

If the QUASI-IntServ were used in practice, the

time slot size could be set to 5, 15 or 30 minutes,

as customary in PSTN. The time slot size is not

intended to be in the range of seconds, though

traffic variations are very fast in the Internet.

The time slot should be on a time scale suitable

for QoS monitoring and charging. Congestion

control mechanisms resolve problems on smaller

time scales. We should note that the QUASI-

IntServ implementation is only a test implemen-

tation: several aspects, like security, manage-

ment and accounting should be added

or improved before it can be used.

There were different views concerning the mea-

surement of connection blocking – IP does not

have connections, but still there are flows for

each user – and of something similar to through-

put. Throughput for the QUASI-model is some-

thing the user requests, but if the user does not

get it, then we assume that we see some deterio-

ration in the NPL-parameters and do not need to

measure the achieved throughput. This may or

may not be true, and there is an optional NPL

parameter resembling achieved throughput

called the transfer rate.

The usual procedure to set quality requirements

to a network is to select the quality parameters,

select some reference connections or scenarios

and to set target values to the quality parameters.

The project did not follow this procedure, but

rather chose to run a number of experiments test-

ing users’ acceptability. A sample table of upper

bounds resulting from a set of tests was com-

piled (Table 3).

The table contains figures, which can be under-

stood completely after studying the tests as

described in [P906-1]. A brief explanation is

AC AC 1 AC 2 AC 3

Interactive Non Interactive Non Real-Time

QC 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 NPLs and guarantee
levels for the QUASI-model
(NP values to be considered as
upper bounds)