Changes between Version 36 and Version 37 of GENIEducation/SampleAssignments/OpenFlowLoadBalancerTutorial/ExerciseLayout/Execute


Ignore:
Timestamp:
07/12/13 10:25:35 (11 years ago)
Author:
shuang@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • GENIEducation/SampleAssignments/OpenFlowLoadBalancerTutorial/ExerciseLayout/Execute

    v36 v37  
    113113  - On !LabWiki, drag and drop the "File" icon and re-do the experiment as described in section 2.3
    114114 - Some explanations about the different load balancers:
    115   - "load-balancer-random.rb" is the load balancer that picks path randomly: each path has 50% of the chance to get picked
    116   - "load-balancer-roundrobin.rb" is the load balancer that picks path in a round robin fashion: right path is picked first, then left path, etc.
    117   - Load balancers that begin with "load-balancer-bytes" picks path based on the total number of bytes sent out to each path: the one with fewer bytes sent out is picked
     115  - "load-balancer-random.rb" is the load balancer that picks path '''randomly''': each path has 50% of the chance to get picked
     116  - "load-balancer-roundrobin.rb" is the load balancer that picks path in a '''round robin''' fashion: right path is picked first, then left path, etc.
     117  - Load balancers that begin with "load-balancer-bytes" picks path based on the total number of bytes sent out to each path: the one with '''fewer bytes''' sent out is picked
    118118   - "load-balancer-bytes-thread.rb" sends out flow stats request in function "packet_in" upon the arrival of a new TCP flow and waits until flow stats reply is received in function "stats_reply" before a decision is made. As a result, this balancer gets '''the most up-to-date flow stats''' to make a decision. However, it needs to wait for at least the round-trip time from the controller to the switch (for the flow stats reply) before a decision can be made.
    119    - "load-balancer-bytes-auto-thread.rb" sends out flow stats request once every 5 seconds in a separate thread, and make path decisions based on the most recently received flow stats reply. As a result, this balancer makes path decisions based on some old statistics (up to 5 seconds) but reacts fast upon the arrival of a new TCP flow (i.e., no need to wait for flow stats reply)
    120   - Load balancers that begin with "load-balancer-flows" picks path based on the total number of flows sent out to each path: the one with fewer flows sent out is picked
     119   - "load-balancer-bytes-auto-thread.rb" sends out flow stats request once every 5 seconds in a separate thread, and makes path decisions based on the most recently received flow stats reply. As a result, this balancer makes path decisions based on some '''old statistics (up to 5 seconds)''' but reacts fast upon the arrival of a new TCP flow (i.e., no need to wait for flow stats reply)
     120  - Load balancers that begin with "load-balancer-flows" picks path based on the total number of flows sent out to each path: the one with '''fewer flows''' sent out is picked
    121121  - Load balancers that begin with "load-balancer-throughput" picks path based on the total throughput sent out to each path: the one with '''more throughput''' is picked
    122122
    … …  
    172172    - '''start''': is the function that will be called when the OpenFlow Controller is started. Here in our case, we read the file /tmp/portmap and figures out which OpenFlow port points to which path
    173173    - '''switch_ready''': is the function that will be called each time a switch connects to the OpenFlow Controller. Here in our case, we allow all non-TCP flows to pass (including ARP and ICMP packets) and ask new inbound TCP flow to go to the controller.
    174     - '''packet_in''': is the function that will be called each time a packet arrives at the controller. Here in our case, we send out a flow_stats_request to get the current statistics about each flow. Then waits for the latest TCP flow stats. Here we create another thread to wait for the stats reply so that the controller is not blocked. Based on the latest statistics, we make our path choices.
     174    - '''packet_in''': is the function that will be called each time a packet arrives at the controller. Here in our case, we send out a flow_stats_request to get the current statistics about each flow. Then waits for the latest TCP flow stats. Here we create another thread to wait for the stats reply so that the controller is not blocked. It calls "decide_path()" to get path decisions.
    175175    - '''stats_reply''': is the function that will be called when the OpenFlow Controller receives a flow_stats_reply message from the OpenFlow Switch. Here in our case, we update the flow statistics then signal the thread created in "packet_in" to continue.
    176176    - '''send_flow_mod_add()''': is the function that you should use to add a flow entry into an OpenFlow Switch.
     177    - '''decide_path()''': is the function that makes path decisions. It returns the path choices based on flow statistics.
    177178  - '''The Whole Process: ''' Upon the arrival of a new TCP flow, the OpenFlow controller sends out a "FlowStatsRequest" message to the OpenFlow switch. The OpenFlow switch will reply with statistics information about all flows in its flow table.
    178179  This flow statistics message will be fetched by the "stats_reply" function in the OpenFlow controller implemented by the user on node "Switch". Based on the statistics, experimenters can apply their own policy on which path to choose in different situations.