| 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 | {{{ |
| | 169 | sudo 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 | {{{ |
| | 173 | reactor.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 | {{{ |
| | 177 | sudo /sbin/tc qdisc add dev eth1 root handle 1:0 netem delay 20ms |
| | 178 | sudo /sbin/tc qdisc add dev eth1 parent 1:0 tbf rate 20mbit buffer 20000 limit 16000 |
| | 179 | }}} |
| | 180 | - 4. run the script by: |
| | 181 | {{{ |
| | 182 | python 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 | {{{ |
| | 186 | http://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 | {{{ |
| | 196 | sudo /sbin/tc qdisc add dev eth1 root handle 1:0 netem delay 20ms |
| | 197 | sudo /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 | {{{ |
| | 211 | left: 5302.5338056252 bytes, Q Depth: 20.5240502532964 packets |
| | 212 | right: 14193.5212452065 bytes, Q Depth: 27.3912943665466 packets |
| | 213 | so this new flow goes left. Total number of flows on left: 1 |
| | 214 | left: 30864.5415104438 bytes, Q Depth: 5.35704134958587 packets |
| | 215 | right: 499.390132742089 bytes, Q Depth: 0.963745492987305 packets |
| | 216 | so this new flow goes right. Total number of flows on right: 1 |
| | 217 | left: 34797.5504056022 bytes, Q Depth: 4.51942007138619 packets |
| | 218 | right: 119634.69213493 bytes, Q Depth: 9.33169180628916 packets |
| | 219 | so 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] |
