Changes between Version 4 and Version 5 of GENIEducation/SampleAssignments/OpenFlowAssignment/ForInstructors


Ignore:
Timestamp:
05/23/13 10:43:32 (11 years ago)
Author:
shuang@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIEducation/SampleAssignments/OpenFlowAssignment/ForInstructors

    v4 v5  
    55== Exercise materials ==
    66Anything that the instructor might need, e.g.:
    7  * Instructions can be found [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/openflow-geni.pdf Here]
     7 * Instructions can be found [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/forInstructors/of-instructor.pdf Here]
    88
    99
     
    160160  The first word on the line is the “direction” of the interface — toward the inside or outside of the network diagram. The second is the interface name as found in ''/proc/net/dev''. [[BR]]
    161161  You are free to communicate these network statistics from the traffic shaping nodes to your OpenFlow controller in any fashion you like. You may want to use a web service, or transfer the data via an external daemon and query a statistics file from the controller. Keep in mind that flow creation decisions need to be made rather quickly, to prevent retransmissions on the connecting host. [[BR]]
    162 
    163   '''Hints''' [[BR]]
    164   -
    165     - Remember that the TCP control loop is rathers low — on the order of several round trip times for the TCP connection. This means your load balancing control loop should be slow.
    166     - You may wish to review control theory, as well as TCP congestion control and avoidance principles.
    167     - Without rebalancing, “correcting” a severe imbalance may be difficult or impossible. For testing purposes, add flows to the path slowly and wait for things to stabilize.
    168     - Some thoughts on reducing the flow count when load balancing via Open- Flow can be found in [http://dl.acm.org/citation.cfm?id=1972438 Wang et al.] You are not required to implement these techniques, but may find them helpful.
    169     - Remember that the default OpenFlow policy for your switch or Open vSwitch instance will likely be to send any packets that do not match a flow spec to the controller, so you will have to handle or discard these packets.
    170     - You will want your load balancer to communicate with the traffic shaping nodes via their administrative IP address, available in the slice manifest.
    171     - If packet processing on the OpenFlow controller blocks for communication with the traffic shaping nodes, TCP performance may suffer. Use require ’threads’, Thread, and Mutex to fetch load information in a separate thread.
    172     - The OpenFlow debugging hints from Section 3.1 remain relevant for this exercise.
    173 
    174  * Answers can be found [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/ Here]
     162 
     163  '''Questions'''[[BR]]
     164  To help user to fetch the information about the amount of traffic as well as the queue depth (measured in number of packets) on both left and right node, we provide a script that the user can download and run on both left and right node [[BR]]
     165  You can download the script from [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/netinfo.py netinfo.py] (If you have already downloaded it, ignore this). Then do the following to start monitoring network usage: [[BR]]
     166 -
     167  - 1. install Twisted Web package for Python on both left and right node:
     168{{{
     169sudo yum install python-twisted-web
     170}}}
     171  - 2. upload netinfo.py onto left and right node, then change the listening IP address in netinfo.py to the public IP address of left and right node respectively. i.e., replacing the following 0.0.0.0 in your netinfo.py file to the public IP address of the left/right node.
     172{{{
     173reactor.listenTCP(8000, factory, interface = '0.0.0.0')
     174}}}
     175  - 3. apply qdisc on interface eth1 of both left and right node by executing (you may further change the parameters by using ''tc qdisc change''):
     176{{{
     177sudo /sbin/tc qdisc add dev eth1 root handle 1:0 netem delay 20ms
     178sudo /sbin/tc qdisc add dev eth1 parent 1:0 tbf rate 20mbit buffer 20000 limit 16000
     179}}}
     180  - 4. run the script by:
     181{{{
     182python netinfo.py
     183}}}
     184  - 5. verify it is working by opening a web browser and typing the following URL ('''replacing 155.98.36.69 with your left or right node's public IP address'''):
     185{{{
     186http://155.98.36.69:8000/qinfo/0
     187}}}
     188  For more information about netinfo.py, please look at the comments in the file. [[BR]]
     189  '''Question: Implement your load-balancer.rb, run it on ''switch'', and display the number of bytes and queue length on both left and right node when a decision is made'''[[BR]]
     190  '''Solution: The source code for load-balancer.rb can be found at [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/forInstructors/lb-solution.rb lb-solution.rb] [[BR]]'''
     191  '''Steps to verify that it works: '''
     192 -
     193  - 1. Download the code lb-solution.rb, upload to node ''switch'', open the source code, change ''$leftip'' and ''$rightip'' to the corresponding public IP address of the left and right node
     194  - 2. Have both left and right node configured with (you can change the parameters but it has to be on dev eth1):
     195{{{
     196sudo /sbin/tc qdisc add dev eth1 root handle 1:0 netem delay 20ms
     197sudo /sbin/tc qdisc add dev eth1 parent 1:0 tbf rate 20mbit buffer 20000 limit 16000
     198}}}
     199  - 3. On both left and right node, running ''netinfo.py''. On node ''switch'', run ''sudo /opt/trema-trema-8e97343/trema run lb-solution.rb'' to run the OpenFlow controller.
     200  - 4. Run multiple TCP flows from ''outside'' node to ''inside'' node: on ''inside'', run:
     201{{{
     202/usr/local/etc/emulab/emulab-iperf -s
     203}}}
     204    On ''outside'' run the following multiple times, with about 6 seconds interval between each run:
     205{{{
     206/usr/local/etc/emulab/emulab-iperf -c 10.10.10.2 -t 100 &
     207}}}
     208    This will give the ''netinfo.py'' enough time to collect network usage statistics from both left and right node so that the load-balancer can make the right decision.
     209  - 5. Pay attention to the output from the load balancer every time a new TCP flow is generated from ''outside''. Sample output should be similar to the following:
     210{{{
     211left:  5302.5338056252 bytes, Q Depth: 20.5240502532964 packets
     212right: 14193.5212452065 bytes, Q Depth: 27.3912943665466 packets
     213so this new flow goes left. Total number of flows on left: 1
     214left:  30864.5415104438 bytes, Q Depth: 5.35704134958587 packets
     215right: 499.390132742089 bytes, Q Depth: 0.963745492987305 packets
     216so this new flow goes right. Total number of flows on right: 1
     217left:  34797.5504056022 bytes, Q Depth: 4.51942007138619 packets
     218right: 119634.69213493 bytes, Q Depth: 9.33169180628916 packets
     219so this new flow goes left. Total number of flows on left: 2
     220}}}
     221    Generally speaking, the decision is made as follows, when the available queue length seen on one node is drastically more than the other, then the new flow goes to the that node/path, otherwise the new flow goes to which-ever node/path with less number of bytes seen. [[BR]]
     222    The experimenters can further try to change the ''tc'' token bucket filter parameters to test their load balancer.
     223
     224
     225 * Answers can be found [http://www.gpolab.bbn.com/experiment-support/OpenFlowExampleExperiment/forInstructors/ Here]