since the NPL-parameters are not guaranteed.
NPL-classes all have good NPL-parameter val-
ues and are not differentiated by them. Connec-
tion blocking is lower for Premium than for
basic and it makes the class differentiation.
In the DiffServ implementation rate limiters are
tuned so that more IP-packets are dropped for
worse classes even if the total load is low. This
method works, but to some extent it is an artifi-
cial way to create service differentiation. One
should clarify what is the goal of service differ-
entiation and if it might not be better to do it
with connection blocking.
5 Measuring Methods
A main motivation for time stamping user traffic
instead of measuring with test traffic was to see
if time stamping actually is such a performance
bottleneck as it has been called. A starting point
was a firewall: A firewall is a component you
normally would put in places like a router con-
necting an operator’s network to a user’s subnet-
work. A packet level firewall adds processing
load but is normally not considered impossible
for this reason. For time stamping we use a
rewritten firewall code contained in the Linux
OS since the version 2.3x. There is a Netfilter
interface by which one can access IP-packets,
get them out of the router’s queues, modify them
and put them back into the queue. In the protocol
stack the Netfilter interface is placed between
the datalink and network levels in the TCP/IP
protocol stack.
Netfilter is basically a set of hooks to packet
filtering in the Linux kernel. For IPv4 there
are five hooks in different places of routing the
packet. One can register to any of the hooks and
wait for packets of a given protocol to come,
take it for processing and put back. Normally,
Netfilter moves the packets to the user space,
but if the software is a kernel module, then the
packet processing will take place in the kernel,
which gives a huge performance advantage over
processing in the user space. As we have tried to
run the code in the user space and it limited a
router’s bandwidth considerably, we would rec-
ommend writing this kind of modifications as
kernel modules, which in our case removed the
performance problems. As for time stamping
itself, if must get the time in some way. Usually,
calling the system clock is slow but fast if the
process is a kernel module. One should also note
that as the desired time accuracy is only 10 ms, a
sufficiently accurate time for a process working
at a much higher speed to be made a variable in
memory, updated once in 10 ms by a separate
process.
5.1 Delay and Jitter Measurement
Measurement of delay and loss are made by
inserting time stamps to the padding field of user
data packets at the edge routers. This method
does not compromise performance and it does
not conflict with the use of IPSec or optimisation
with MPLS inside the network. It conflicts with
fragmentation inside the operator’s network and
requires less than maximal size packets. It
should be possible to avoid these problems as
we are talking about one operator’s network.
Providing quality will have some cost. We use
the padding field because that way we can store
a time stamp in 16 bits for a resolution of 1 ms
to values of up to 65,536 milliseconds. Had we
used the IPv4 options field, the time stamp
would take 4 bytes and core routers look at this
option field as spending time. One bit of the IP
header is used to indicate if the padding field
contains our data. Currently, we time stamp all
packets but only a sample would suffice if per-
formance becomes critical. The sending MRP
sets the time stamp using time from the system
clock, and the receiving MRP looks at the time
stamp and calculates the delay as a difference of
the value and the value given by the system
clock. Jitter is calculated as a standard deviation
over 10 seconds and delay as a longer time aver-
age for each time slot in a jumping window
manner. Every 16 minutes the MRP daemon
writes the values for each AC/QC to a TCP
socket, which is read by the Management server.Tests were made to evaluate both the accuracy
and the performance overhead of the delay and
jitter measurements. The performance is quite
good provided that the code is made a kernel
module. Accuracy is very good, the errors are
caused by time synchronisation between the
clocks and processing time of the time stamping
software. The latter was about 4 ms in the tests.
It is a value for load, which is not creating a
queue. In general, putting some additional pro-
cessing to a router will give a processing time
dependent on the load because of queuing delay,
but here the situation is that the software is suffi-
ciently fast to avoid queues and the additional
processing time is constant. Tests of jitter showed
one interesting thing: we could measure jitter
caused by spacing, but test traffic by CISCO
SAA between MRPs in the DiffServ implemen-
tation would probably not measure this jitter.
One should be careful measuring jitter with test
traffic; there may be mechanisms which are not
affecting test traffic while they affect user traffic.5.2 Loss Measurement
In the QUASI-IntServ implementation loss is
measured by intentionally discarding packets by
RED for each ClassID in the MRPs and counting
the discarded packets. This rather strange way of
loss measurement protects the core and therefore