Tests in the LAN
The objective of these tests is twofold:

• to tune buffer sizes and configurations of policers for proper EF support;
• to compare two different EF PHB implementations: the policing, buffer management and SCWFQ scheduling on the IBM platforms, and CAR and CB-WFQ on CISCO platforms.

One-Way Delay measurement
The SmartBits is a useful tool for delay and delay variation measurement. In particular, SmartApplication can measure latency between remote SmartBits by means of GPS synchronization. Latency is measured such that for each test of t secs only one packet with timestamp is sent out at time t/2. Traffic is sourced and sunk by a single SmartBits from/to different data ports. With this type of traffic no GPS clock is deployed, since the tx and the rx are the same.

Delay variation measurement
SmartApplication does not compute delay variation, but SmartWindows can be deployed for that. Unlike SmartApplications, SmarWindows can only connect to one SmartBits, so traffic has to be generated by one data interface and sinked to another data interface of the SmartBits.
Another possible methodology consists of the deployment of NTP and mgen. Unfortunately in our local test layout clock offset is not constant and given the small average packet delay, NTP is not able to achieve a sufficiently precise synchronization between the clocks of the transmitter and of the receiver. This issue is for further study.

Parameters

1. scheduler parameters (IBM):
   • Premium Buffer Size (default value: 5500 bytes)
2. scheduler parameters and/or buffering parameters (CISCO):
   • CB-WFQ queuelimit (per class, in packets)
   • PA-A3 tx-ring-limit (in particles)
3. traffic parameters:
   • variable MTU size
   • variable background traffic (TCP and/or UDP)

Network Configuration
An example of network configuration for IBM testing is illustrated in figure 1. Premium traffic can be sent at a constant given rate, for example 300 Kbps (15 % of the bandwidth) or a different bandwidth value can be chosen. A background traffic rate such that at least the whole PPP link capacity is deployed has to be chosen. The presence of background traffic is important in order to force the premium queue to build up because of competition between packets in physical queues.
Figure 1: LAN layout for one-way delay and one-way delay variation testing on IBM platforms. Full-duplex fastethernet or two different ethernet physical media for subnet 192.168.74.0 and .75.0 are recommended. A similar configuration can be deployed for testing on CISCO platforms. The IBM 2212 can be replaced by a CISCO C7200 or C7500, the PPP connection can be replaced by an ATM PVC at a bandwidth such that the application throughput is comparable to the one achieved on the PPP interface of the previous scenario. The network layout is illustrated in figure 2.
Figure 2: LAN layout for one-way delay and one-way delay variation testing on CISCO platforms.

Tests in the WAN
The objective of latency and latency variation measurement in the WAN is to estimate the effect of premium traffic aggregation and of buffering in a chain of routers on that to parameters. This is fundamental for the implementation of the Virtual Leased Line service.

Test Methodology

One-Way Delay Measurement
The SmartApplications is deployed for one-way latency measurement between two SmartBits which are remotely located. The GPS synchronization is deployed. In order to test latency in a chain the SmartBits at INFN and Utrecht can be deployed and static routing can be modified such that instead of deploying the direct ATM connection, traffic goes through CERN and GRNET as illustrated in figure 3.
Figure 3: one-way delay measurement with traffic going through a chain of multiple routers.

One-Way Delay Variation Measurement
Two methodologies can be deployed.

• Method 1: Loop SmartWindows can be deployed but traffic has to be looped back to it. In order to achive that two ATM PVC (have to be terminated into two different local routers, like in figure 4.
  Figure 4: deployment of SmartWindows in the WAN
• Method 2: Mgen without NTP
  Given a couple of hosts, the transmitter and the receiver, inter-leaving time between subsequent packets on both sites can be easily determined (a sniffer or the mgen log file can be deployed).
  The delay variation can be computed as the absolute value of the difference between the inter-leaving time of two subsequent packets at the sender (int₁) and the inter-arrival time of that two packets at the receiver (int₂): del_var = | int₂ - int₁| This approximation holds if both at the sender and at the receiver the time offset between two subsequent packets is constant, i.e. the frequency of both clocks is almost constant. (^)
  The demonstration is in figure 5.
  Figure 5: time diagram for one-way delay variation measurement

Parameters
Same as for testing in the LAN.