GEC3 DRAGON demonstration movie

We did not have enough time on the morning of October 29, 2008 to present this movie at the GENI Engineering Conference #3. It was expected to be shown at the end of our presentation.

Click here to watch the movie.

Overview:

This movie demonstrates the setup of 2 dynamic, high-bandwidth circuits across the DRAGON metro-area network, provisioned using tagged Ethernet VLANs.

The first circuit uses a web-based provisioning approach, while the second circuit uses a command-line Java client that makes use of a Web Services (SOAP/XML) API.

Please note that the video demo was originally about 40 minutes long. It has been shortened to under 5 minutes for presentation purposes by removing sections that take awhile to complete (such as the performance verification testing).

First Circuit:

The creation of the first circuit starts out by visiting the "create reservation" tab of our web-based user interface.

The following parameters are entered into the form:

• source: max-es1.dragon.maxgigapop.net
• destination: urn:ogf:network:domain=dragon.maxgigapop.net:node=HOPI-WASH:port=0-2-1:link=*
• bandwidth: 500Mbps
• description: GEC3 demo circuit 1
• end time: approximately 15 minutes in the future
• VLAN tag: left blank for any available VLAN

The source and destination specify 2 endpoint interfaces -- one in a human-friendly DNS-style format, the other using URN syntax. Once this form is submited, the user waits for the circuit to become active.

We can see that this circuit was setup on VLAN ID 3000. The endpoint interfaces are expecting tagged (802.1Q) MAC frames.

Now we must configure the end hosts with IP addresses and 802.1Q logical subinterfaces so that they will pass tagged frames to the ingress/egress interfaces.

We run the following commands on the first host:

• vconfig add eth1 3000
• ifconfig eth1.3000 inet 10.10.10.1 netmask 255.255.255.0

And then run the following commands on the second host:

• vconfig add eth1 3000
• ifconfig eth1.3000 inet 10.10.10.2 netmask 255.255.255.0
• ping -s 8000 -M do -c 3 10.10.10.1

Note that the round-trip time is approximately 1.8ms.

Next, we run a UDP test at 550M. Since we are sending more data than the circuit allows, we expect to see some loss. Note that loss only appears after the policer's burst buffer fills up, which takes approximately 6 seconds. The command used to initiate the 550M UDP flow for 30 seconds is:

• ./nuttcp -i3 -T30 -R550M -u -r 10.10.10.1

To run a TCP test, we calculate the bandwidth delay product (BDP) given the 1.8ms RTT using bc.

The TCP test is executed with a 112kb window size for 30 seconds using the following command:

• ./nuttcp -w112k -i3 -T30 -r 10.10.10.1

TCP attempts to run as fast as it can. Since the circuit is provisioned as sub-rate (500Mbps is smaller that the GigE^? interfaces on the hosts), TCP does encounter some retransmissions. However, over 30 seconds it averages out to 499.7Mbps.

Next, we run a rate-limited TCP. This is a much more CPU intensive process as it puts the performance testing application into a tight timing loop. We run a long TCP test (8 minutes or 480 seconds) using this command:

• ./nuttcp -w112k -i60 -T480 -R500M -r 10.10.10.1

We still see TCP retransmissions because we are too close to the circuit's upper limit. We will see in the second circuit what happens if we stay within 95% of the size of the provisioned circuit.

The video then shows a cricket (similar to MRTG, uses RRDtool) which is monitoring the packet counters on one of the switch interfaces used by this circuit. The graph clearly shows the traffic levels averaging out to 500Mbps over the past 8 minutes.

We are going to let the circuit be torn down automatically, without any user intervention. We start a ping using the following command:

• ping -s 8000 -M do 10.10.10.1

Now we let the scheduler automatically tear down the circuit at the appropriate time (4:10pm in our example). The pings continue until the circuit is automatically torn down, at which point the status changes to "FINISHED" in the web-based user interface.

Second Circuit:

The second circuit uses a command-line Java client that makes use of a Web Services (SOAP/XML) API.

A text file is created using emacs, and then the filename of this text file is passed as a command-line parameter to a Java circuit setup application.

This Java application contacts the domain controller (network brokering agent) by sending a cryptographically signed SOAP/XML message (using Web Services) with the details of the reservation request.

Create the file 'gec3.ckt.properties' using emacs. Provide the following parameters -- note that we pick a specific VLAN ID this time (3001) instead of requesting a VLAN to be picked for us:

 interactive=0
 url1=https://idc.dragon.maxgigapop.net:8443/axis2/services/OSCARS/
 layer=2
 sourceEndpoint=max-es1.dragon.maxgigapop.net
 destEndpoint=ncsa-es1.dragon.maxgigapop.net
 vtag=3001
 bandwidth=900
 description=GEC3 demo circuit 2
 pathSetupMode=timer-automatic
 duration=0.5

We are requesting a 900Mbps circuit over VLAN 3001 for 0.5 hours, between the hosts max-es1 and ncsa-es1.

The Java client is executed using the following command in the shell to submit the reservation for this circuit:

• ./createRes.sh -pf gec3.ckt.properties

Next, we login to the web-based user interface, we observe that the circuit has appeared and the status is currently "ACTIVE".

We can also use the Java API to show the status of this reservation using the following command in the shell:

• ./listRes.sh

Similar to the first circuit, we must login to the end hosts, assign IP addresses and create logical subinterfaces. We setup the first host as follows:

• vconfig add eth1 3001
• ifconfig eth1.3001 inet 10.10.20.1 netmask 255.255.255.0

The second host is setup as follows:

• vconfig add eth1 3001
• ifconfig eth1.3001 inet 10.10.20.2 netmask 255.255.255.0
• ping -s 8000 -M do -c 3 10.10.20.1

We observe that the ping time across this circuit is approximately 2.2ms.

If we run a UDP test at 925Mbps, we expect loss because we are oversubscribing the circuit:

• ./nuttcp -i3 -T30 -R925M -u -r 10.10.20.1

We then calculate the BDP for a TCP test and find the window size should be 248k for 900Mbps at 2.2ms. A TCP test is initiated using the following command:

• ./nuttcp -w248k -i3 -T30 -r 10.10.20.1

If we rate-limit TCP to approximately 95% of the size of the provisioned circuit, we observe that TCP encounters no retransmissions in a long (8 minute) test:

• ./nuttcp -w248k -i60 -T480 -R875M -r 10.10.20.1

The cricket graph shows the traffic on the switch interface averaging out a little below 900Mbps, as we expect.

Now we will start another ping across the circuit:

• ping -s 8000 -M do 10.10.20.1

And tear down the circuit (before its normal ending time) using the Java API with the following command:

• ./cancelRes.sh

Once the circuit has been torn down, we observe that the pings subside. The web-based user interface shows the circuit status as "CANCELLED" since we ended it prematurely.

More Information:

For more information, please refer to http://dragon.maxgigapop.net. The software suite used in this demonstration is freely available and may be found at the following URL: https://wiki.internet2.edu/confluence/display/DCNSS/Home