Hi Bernd, this sounds like an interesting idea to me, and something that could be proven useful. One concern is that in the trip from the controller to switch A, switch B and back to the controller, you have the propagation delay of the control channels, the propagation delay between A<->B, but also the processing delay on the switches. So some caution should be taken there in order to make sure that the processing delay on the switches is minimized, in order to get the best possible estimate of the delay of the link A<->B. Also I would imagine that, say, if there was no other traffic, buffers were all empty etc, even then different switches would perform a bit differently, so that's another factor that would influence the estimation, though it's probably negligible.
On Wed, Jan 11, 2012 at 7:33 AM, Bernd Wittefeld < s9bew...@stud.uni-saarland.de> wrote: > Hi, > I am currently working on a component that needs a lot of statistical > information about the current network state. > In fact, I need the packet lLoss rate and the delay of single links > between OpenFlow-switches. > The PLR can be computed quite easily from the statistics that the switch > gives me (tx_packets and rx_packets of switches that are connected via a > link), but the delay turns out to be a problem. > I have the following idea: > > I might use the discovery module and install an organizationally specific > TLV that simply carries a timestamp and with every received LLDP packet, I > can measure the time it takes for a packet to travel from controller to > switchA to switchB and back to the controller. The links from the > controller to the switches can be measured easily, so I can get a rough > estimate of the Delay on the link (we don't talk about accuracy in the > first place here :)) > The discovery module can then deliver the delay for a specific link via an > API function. > > What do you think? Is this feasible? Is this way ok or do I abuse the LLDP > protocol? > > If it's ok, the implementation might be relatively straight forward, > adding a class to nox.lib.packet.lldp for my tlv and add a parser, then > modify the discovery module and I should be fine?! > > If yes, do you have any other suggestions on how to implement this? I also > thought about a custom component that builds a packet containing a > timestamp and sends it out every switch port that is connected to another > switch and install an Action on the target switch to forward that packet > back to the controller. I don't know if this is feasible and would work in > the first place (addressing and type of the packet carrying the timestamp > for example would be a problem). > > Or am I completely wrong here? Is there anything that gives me this > information? > > What do you think? I'm open for suggestions :) > > Thanks in advance! > > Bernd > ______________________________**_________________ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/**listinfo/nox-dev<http://noxrepo.org/mailman/listinfo/nox-dev> >
_______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
