More SARA & EVL UDPmon Large Results and SNMP

• Description
• Loop-Back Test Results
• LSD 6509 Test Results
• SSR + LSD 6509 Test Results
• More Result Links:
  • Other UDPmon Large Results
  • Compact Overview UDPmon Results Diverse Configurations
  • Compact Overview UDPmon Results Back-to-back
  • TCP / UDP Measurements

UDP Experiments were performed with a modified version of the UDPmon package written by R.E. Hughes-Jones in the sense that from 5000 packets the sequence number and the arrival time in microsec. are specified. There was no wait time between two successive packets. Before and after these tests also the appropriate SNMP counters at the interfaces were read to check if packets lost did occur at these interfaces during the measurement. The tests were focused to the hosts located at SARA and EVL in various topologies. However, more general UDPmon Large results are available in this document.

Setup

In these tests hosts gwgsara4 and gwgsara5 were directly connected with the Cisco ONS and at the Chicago site a hardware loop has been used, according to the scheme listed below. Interfaces from which sensible counter values can be read out have been marked with "S".

		   +-+        +-+
+--------+       S | |        | |
|gwgsara4|---------|O|        |O| S
+--------+	   | |- .... -| |--+
		   |N|        |N|  | hardware loop
+--------+         | |- .... -| |--+
|gwgsara5|---------|S|        |S| S
+--------+       S | |        | |
                   +-+        +-+

       SARA                   Chicago

UDPmon Large

The tests were performed with packet sizes of 500, 1000, 1200, and 1460 bytes. The time differences with the first packet as function of the packet sequence number are displayed in the . In the bandwidth calculated from the sequence number from the last received packet without lost (Last_Recv_Seq_Nr), the packet size in bytes calculated with , the Last_Recv_Seq_Nr field, and the # packets lost have been specified as function of the packet size.

(Last_Recv_Seq_Nr * Packet_Size * 8) / Rel_Time

.I.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara5 using the loop-back interface. The packet size was 500 bytes.

.II.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara5 using the loop-back interface. The packet size was 1000 bytes.

.III.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara5 using the loop-back interface. The packet size was 1200 bytes.

.IV.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara5 using the loop-back interface. The packet size was 1460 bytes.

SNMP Counters

By using the appropriate incoming and outgoing octet counters, marked with "S" in the scheme, packet lost at the following route trajectories can be detected:

• From Amsterdam to Chicago over the Lambda
• Over the loop-back interface.
• From Chicago to Amsterdam over the Lambda.

When the appropriate incoming and outgoing octet counters for these route parts were compared before and after the UDPmon test, no packet lost have been found. Note that only the Gigabit interfaces are capable of delivering octet counters.

Conclusions

Because no packets were dropped according to the SNMP counters, all packets lost where probably host effects.

Setup

In these tests the LSD 6509 have been used in the place of the hardware loop, described in the previous section. The following scheme have been used, where again "S" is marking an interface from which the octet counters can be read with SNMP. At the LSD 6509 we had no authorisation to read SNMP counters.

		   +-+        +-+         +-+
+--------+       S | |        | |         | |
|gwgsara2|---------|O|        |O| S       |6|
+--------+	   | |- .... -| |---------|5|
		   |N|        |N|         |0|
+--------+         | |- .... -| |---------|9|
|gwgsara4|---------|S|        |S| S       | |
+--------+       S | |        | |         | |
                   +-+        +-+         +-+

       SARA                       Chicago

The path followed in this test was: gwgsara2  =>  Amsterdam ONS  =>  Chicago ONS  =>  6509  =>  Chicago ONS  =>  Amsterdam ONS  =>  gwgsara4.

UDPmon Large

The tests were performed with packet sizes of 500, 1000, 1200 and 1460 bytes. The relative time differences as function of the packet sequence number are displayed in the In the bandwidth and packets lost data have been given as function of the packet size.

.I.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the 6509. The packet size was 500 bytes.

.II.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the 6509. The packet size was 1000 bytes.

.III.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the 6509. The packet size was 1200 bytes.

.IV.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the 6509. The packet size was 1460 bytes.

SNMP Counters

By using the appropriate incoming and outgoing octet counters, marked with "S" in the scheme, packet lost at the following route trajectories can be detected:

• From Amsterdam to Chicago over the Lambda
• Over the LSD 6509.
• From Chicago to Amsterdam over the Lambda.

When the appropriate incoming and outgoing octet counters for these route parts were compared before and after the UDPmon test, no packet lost have been found. Note that only the Gigabit interfaces are capable of delivering octet counters and we were not authorised to read the LSD 6509 counters.

Conclusions

Because no packets were dropped according to the SNMP counters, all packets lost where probably host effects.

For these tests host gwgsara2 is connected to the Cisco ONS via the SSR 8000. Also at the EVL host prusin has been connected to the Chicago ONS. The setup from section "LSD 6509 Test Results" has been developed to the following scheme, were again the octet counter capable interfaces have been marked with "S".

		+-+      +-+        +-+      +-+
+--------+    S |S| S  S | |        | |      | |
|gwgsara2|------|S|------|O|        |O| S    |6|
+--------+	|R|      | |- .... -| |------|5|      +------+
		+-+      |N|        |N|      |0|------|prusin|
+--------+               | |- .... -| |------|9|      +------+
|gwgsara4|---------------|S|        |S| S    | |
+--------+             S | |        | |      | |
                         +-+        +-+      +-+

           SARA                            Chicago

In this setup the following paths have been tested:

1. gwgsara2  =>  SSR  =>  Amsterdam ONS  =>  Chicago ONS  =>  6509  =>  Chicago ONS  =>  Amsterdam ONS  =>  gwgsara4
2. gwgsara2  =>  SSR  =>  Amsterdam ONS  =>  Chicago ONS  =>  6509  =>  prusin
3. gwgsara4  =>  Amsterdam ONS  =>  Chicago ONS  =>  6509  =>  Chicago ONS  =>  Amsterdam ONS  =>  SSR  =>  gwgsara2
4. prusin  =>  6509  =>  Chicago ONS  =>  Amsterdam ONS  =>  SSR  =>  gwgsara2

UDPmon Large

Also here the tests were performed with packet sizes of 500, 1000, 1200 and 1460 bytes. Below the relative time differences are presented for the paths mentioned in the "Setup" subsection as follows:

• Path gwgsara2  =>  gwgsara4 in .
• Path gwgsara2  =>  prusin in .
• Path gwgsara4  =>  gwgsara2 in .
• Path prusin  =>  gwgsara2 in .

.I.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the SSR + 6509. The packet size was 500 bytes.

.II.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the SSR + 6509. The packet size was 1000 bytes.

.III.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the SSR + 6509. The packet size was 1200 bytes.

.IV.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => gwgsara4 using the SSR + 6509. The packet size was 1460 bytes.

.I.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => prusin using the SSR + 6509. The packet size was 500 bytes.

.II.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => prusin using the SSR + 6509. The packet size was 1000 bytes.

.III.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => prusin using the SSR + 6509. The packet size was 1200 bytes.

.IV.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara2 => prusin using the SSR + 6509. The packet size was 1460 bytes.

.I.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara2 using the SSR + 6509. The packet size was 500 bytes.

.II.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara2 using the SSR + 6509. The packet size was 1000 bytes.

.III.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara2 using the SSR + 6509. The packet size was 1200 bytes.

.IV.

The relative receiving time as funtion of the packet sequence number for the UDP stream gwgsara4 => gwgsara2 using the SSR + 6509. The packet size was 1460 bytes.

.I.

The relative receiving time as funtion of the packet sequence number for the UDP stream prusin => gwgsara2 using the SSR + 6509. The packet size was 500 bytes.

.II.

The relative receiving time as funtion of the packet sequence number for the UDP stream prusin => gwgsara2 using the SSR + 6509. The packet size was 1000 bytes.

.III.

The relative receiving time as funtion of the packet sequence number for the UDP stream prusin => gwgsara2 using the SSR + 6509. The packet size was 1200 bytes.

.IV.

The relative receiving time as funtion of the packet sequence number for the UDP stream prusin => gwgsara2 using the SSR + 6509. The packet size was 1460 bytes.

SNMP Counters

By using the appropriate incoming and outgoing octet counters, marked with "S" in the scheme, packet lost at the route trajectories, described below, can be detected. There is also marked which paths are passing these trajectories.

• In Amsterdam over the SSR (paths 1, ..., 4).
• From Amsterdam to Chicago over the Lambda (paths 1, ..., 4).
• Over the LSD 6509 (paths 1 and 3).
• From Chicago to Amsterdam over the Lambda (paths 1, 3 and 4).

During these tests were only packets lost at the SSR. In the packages lost have been listed that were found at the SSR for the corresponding paths and packet sizes. The table header "SNMP" -> "Packets lost" is the loosely conversion of the SNMP octets lost to SNMP packets lost by division by the packet size.

Conclusions

The SNMP counters show that some of the packets lost can be related with incoming traffic at the SSR to host gwgsara2. For those losses there is a good correspondence with the UDPmon results. However, most losses are again due to host effects.