Changes between Version 59 and Version 60 of Internal/OpenFlow/Controllers/MultiCtl

Timestamp:

Apr 27, 2013, 5:27:25 PM (11 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl

@@ -3 +3 @@
 
 This "logging" method is based on a relatively effective method developed during a GSoC 2012 project. 
+
+These notes will eventually be turned into documentation suitable for human eyes.  
 
 == Quick Links. ==
@@ -14 +16 @@
  || [#w4 week4] || [#w10 week10] || [#w19 week19] || [#w29 week29] ||
  || [#w5 week5] || [#w11 week11] || [#w20 week20] || [#w30 week30] ||
- || [#w6 week6] || [#w12 week12] || [#w23 week23] || ||
+ || [#w6 week6] || [#w12 week12] || [#w23 week23] || [#w31 week31] ||
 [[BR]]
  
@@ -641 +643 @@
 Processing conflicts will arise if forwarding functions are executed before authentication. This type of conflict cannot be resolved by simply juggling around tiers, since tier 1 will still receive both forwarding table rules from the respective services. So we assign a higher priority to authentication so that it is checked first.  
 
+==== w/o 4/21-4/27 ==== #w31
+A mild hiatus from usual work. Worked out a base set of slides potentially useful as part of my defense. 
+
+However, some insightful points, possibly:
+ * Check out threading and delegation of threads in Floodlight per switch. There may be a bottleneck in regards to scaling, according to an ONOS dev (Pankaj). 
+ * Time measurements - If using !PacketIns and !PacketOuts, throw the timestamp into the payload right after packet construction, to bypass the overhead from the packet e.g. lingering in the network stack buffers, allowing better measurement of message processing overhead. 
+ * A very good (big) concern that needs to be addresses is that of switch abstraction in higher tiers. As of now, we count on services being delegated in a way such that the higher tiers do not need any information about the topology. This may not always be the case if we eventually want tiering in terms of scope of network view. 
+
+For the last concern, we may be able to abuse the Topology objects supported in Floodlight. More code reading may be necessary to determine if this is true. 
+
+Switch performance testing is difficult. There is OVS, which may be possible to hack up a bit so we can pull times from it, but for anything else, this is not really feasible. 
+
 ----
 [#home Home.]