Specifications

CHAPTER 3. SYSTEM ARCHITECTURE 14
3.3 Generating IP packets
We have modified the firmware on the network cards in order to be able to generate IP
packets instead of just simple Ethernet frames. The traffic descriptor table that is loaded
into the card before a test contains all the fields in the IP header, including the IP Type of
Service.
The TCP and UDP were not implemented due to the increased overhead associated with
these protocols. UDP requires the computation of a control sum on the data being transmit-
ted and this would be too time consuming for the proces sor on-board the NIC to generate
packets at line speed. TCP requires the maintaining of a full history (within the sliding win-
dow) of packets being transmitted and rec eived and the on-board memory is limited to 1MB
by the type of chips used by the manufacturer. Also, TCP would be too computationally
intensive to achieve Gigabit speeds on the current on-board processors.
Our traffic generator produces streaming traffic at the raw IP level. The content of the
packets can be considered as being random. The packe t loss is calculated by using a
sequence number embedded in the packets.
3.4 The global clock system
The standard way of making network delay (latency) measurements is to calculate the
round-trip time and divide by two in order to obtain the one-way travel time. This method
has the advantage that the same clock is used for both of the send and receive timestamps
and the only important issue is how accurate this clock can be read. However, such a
calculation is only valid when the packet returns on the same route (which is not guaranteed
for an Internet environment).
Computing the one-way network latency provides an accurate estimate of the network’s
behavior under any traffic pattern, especially over long haul networks. In order to make
this calculation, the two timestamps have to be applied by two clocks that are very well
synchronized. Synchronizing two clocks with a sub-microsecond precision is not an easy
task, even when the two clocks are located in the same room. The problem is even more
difficult when a distance of a few hundreds kilometers separates the two clocks. Applying
the timestamps to every packets being sent and received at Gigabit speeds adds a further
degree of difficulty to the problem.
The synchronized clock of our LAN m eas urement system is based on custom-built boards
and electrical connections between a master and slave boards installed in all the computers
being part of the testbed. The accuracy of the clock board combined with the time-stamping
by the Alteon card when a packet is being sent and received is about 300 ns [2].
The approach of physically connecting the master and slave clock boards is no longer valid
when two parts of the testbed are geographically separated. To overcome this limitation
we are using the Global Positioning System (GPS) to provide a time reference. The GPS
signal is freely available everywhere on Earth and a receiver unit that has enough satellites
in view it is able to give the Universal Time with accuracy in the order of 100 ns [6]. We
are using off-the-shelf GPS receivers connected on the PCI bus of the computer. Only
one computer at each location of the testbed needs to be equipped with such a card and
connected to the special antenna. The GPS card replaces the master clock card from the