[Q3] Queueing of UDP Traffic

New Concepts: VOQ rate, egress link rate, threshold, iperf/UDP bandwidth
Review:
• The basic queueing principle
• XXXXX
Configuration File: The same configuration file used in [Q1]; i.e., cfg-queue-1nsp-loop.exp.
Description:
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 are 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 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.
The details of the regulator are unimportant for this problem. But what is important is to note that a link rate that has been set to 100 Mbps allows 12.5 MBps (Megabytes per second) of IP packet bytes. But since a UDP packet is encapsulated inside an IP packet, the effective rate of UDP packets is less than 100 Mbps. Instructions:
• Modify the link rate for VOQ(6,3) from 200 Mbps to 100 Mbps: by
  • Select port 6 => Queue Tables
  • Change the 200.0 Mbps entry for queue id 3 to 100
  • Select 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 1, 2 and 3.
• Open up another window to $n1p2 and continuously ping the n1p3 host:

  	          ping 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 4, 5 and 6.
Questions:
1. Let Q (Mbits) be the queue length of a VOQ, and let P be the size of the payload in a UDP packet (i.e., excludes the header). Derive an expression for Q (Mbits) when iperf is used to send UDP packets of length P bytes at a rate of w Mbps. What is Q when w = 100 Mbps?
2. 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.
3. 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.
4. What are the first 10 RTT values reported by ping after the iperf traffic starts?
5. Explain why the RTT values are consistent with your explanation in Questions 3-5.
6. Change the rate of VOQ(2,3) so that the queueing behavior seen at VOQ(6,3) now appears at VOQ(2,3). Submit screen shots that demonstrate this queueing behavior and explain why the plots and iperf reports support your claim.