This exercise covers traffic monitoring and UDP traffic generation using the iperf traffic generator and will explore the idea of a bottleneck link. In preparation for the experiments in this section, you should read the Tutorial section titled Generating Traffic With Iperf. You can find it by selecting Tutorial => Filters, Queues and Bandwidth => Generating Traffic With Iperf or going to this link. Also, read over the exercise before attempting it so that you are familiar with its general outline.

UDP Traffic Generation

You must have a reservation for one cluster (no extra hosts) to do this experiment.

Follow the instructions below:

Instructions:

• Start the RLI, and open the cfg1-1.exp configuration file from Exercise 1-1.
• You will need atleast two command windows to do this exercise: one for the iperf server and one for the iperf client.
  • In one window, SSH into the host corresponding to n1p2.
  • Repeat for n1p3 in the other window.
  REMINDER: You should SSH into the ethernet interface, not the ATM one.
• In the n1p2 window, ping the n1p3 interface just to make sure that you have connectivity.
• In the n1p3 window, start a UDP iperf server by running the following command:

            iperf -s -u
  

• In the n1p2 window, send UDP traffic for 10 seconds at 10 Mbps by running the UDP iperf client like this:

            iperf -c n1p3 -b 10m -t 10
  

  Answer Question 1.
• Again in the n1p2 window, send UDP traffic for 10 seconds but now at 400 Mbps:

            iperf -c n1p3 -b 400m -t 10
  

  Answer Question 2.

Questions:

1. Explain why the plots and iperf reports are consistent with the 10 Mbps UDP traffic from n1p2 to n1p3.
2. Submit screen shots of the following windows:
   • traffic,
   • queue length,
   • perf client, and
   • perf server.
   Explain why the plots and iperf reports are consistent with the 400 Mbps UDP traffic from n1p2 to n1p3.

Traffic Queueing

A traffic backlog forms when the input rate to a link exceeds the capacity of the link and the system allows the excess traffic to be held in buffers or queues (sometimes we say a queue forms). The same principles are demonstrated when we pour water into a bucket with an outlet pipe at the bottom. The pipe has a capacity which when exceeded causes the water level in the bucket to rise until the input rate falls sufficiently to allow the pipe to drain the bucket.

The link rates inside an NSP that are adjustable by the user are implemented by traffic regulators (token buckets or leaky buckets to be precise). In front of each regulator is one or more finite size queues. A user can change the default rates and queue sizes of these regulators. Two such rate locations are the link rate at an egress port and VOQ rates at an ingress port.

The queue length plot in the cfg1-1.exp configuration plot shows the length of the queue associated with VOQ(6,3). All traffic coming into port 6 and going across the switch fabric to output port 3 are handled by this regulator. This exercise focusses on the behavior of this queue.

Some details about iperf UDP traffic generation and ONL traffic regulators are important to the precise details of the queueing:

• An iperf client will report that it is sending 1470-byte datagrams. The 1470 bytes is actually the UDP packet payload and does not include the 8-byte UDP header nor the 20-byte IP header.
• ONL traffic regulators regulate IP packets. So, when you set a link rate or VOQ rate to say 200 Mbps, you are saying that you want the regulator to allow no more than 200 Mbps (of bits in IP packet) to be sent.

We say that a link is a bottleneck if it has the smallest transmission capacity along the path of a flow; that is, it is a choke point and will determine the flow rate downstream. A regulator can also be a bottleneck. At a bottleneck that has capacity R, the output rate will never exceed R. If the input rate to a bottleneck is less than the capacity R, the output rate will be equal to the input rate if the bottleneck is work conserving (i.e., it is never idle when there is something to transmit).

Follow the instructions below:

Instructions:

• Modify the link rate for VOQ(6,3) from 600 Mbps to 100 Mbps by selecting port 6 => Queue Tables and changing the 600.0 Mbps entry for queue id 3 to 100, and selecting File => Commit.
• In the n1p2 window, send UDP traffic for 10 seconds at 100 Mbps by running the UDP iperf client like this:

            iperf -c n1p3 -b 100m -t 10
  

  Answer Questions 3, 4, 5 and 6.
• Open up another window to n1p2 and continuously ping the n1p3 host (NOTE: There is no -c flag, but there is a -U flag):

            ping -U n1p3
  

• While the ping command is running, send UDP traffic at 100 Mbps by running the UDP iperf client like this:

            iperf -c n1p3 -b 100m -t 10
  

  Answer Questions 7 and 8.

Questions:

3. Let r (Mbps) be the output rate of a VOQ. (Note that r measures the bits in an IP packet.) Derive an expression for u (Mbps), the output rate of the VOQ when only the bits from the 1470 bytes of UDP payload are counted? What is u when r = 100 Mbps?
4. Let R (Mbps) be the maximum output rate (transmission capacity) of a VOQ. Derive an expression for VOQ queue length Q as a function of u and R. Note that the function will be piecewise linear.
5. Submit screen shots of the following windows: traffic, queue length, iperf client, and iperf server. Explain why the plots and iperf reports are consistent with the 100 Mbps UDP traffic.
6. What is the slope of the left side of the queue length plot? Explain why the slope is consistent with our bottleneck and iperf traffic discussion at the beginning of this section and the expressions derived earlier. The explanation should include a numeric computation for the expected slope of the queue length curve.
7. What are the first 10 RTT values reported by ping after the iperf traffic starts?
8. Explain why the RTT values are consistent with your explanation in Questions 3-5.