Hi,
so I decided to go with a statsmanager component that measures delay and
packet loss for every link found by the discovery component.
To measure delay, I will send ICMP echo requests and measure the RTT for
the links to the switches and then send a packet from the controller to
switchA to switchB back to the controller. As a first approach this
should be fine.
The first problem I have is: How do I get the IPs of the switches to
send the ICMP echo requests to? NOX talks to these switches via the
control channel and I want to simply send an ICMP echo request to this
IP. Is there any way to get this piece of information? The stats reply
that I get from a datapath_join event doesn't contain it and I could not
find anything else that might give me the needed information.
Your help is very much appreciated.
Best regards
Bernd Wittefeld
On 12.01.2012 15:34, Bernd Wittefeld wrote:
Hi Kyriakos,
yes I know of the propagation delays of the control channels. I
thought of measuring these by simple ICMP Echo Requests and extracting
the RTT from that. Assuming that we have symmetric channels, I can get
an estimate of these delays and use them in the delay calculation.
The processing time on the switches should be a part of the overall
delay in my opinion, as the packets travelling through the network
must also take this time to be processed.
The question now is: which way is the best to implement this: patching
the discovery module, as the infrastructure for periodical packets on
every link is already there, or writing an own component which can be
rather complex as there are some details that cannot be solved easily
in my opinion.
The LLDP packets are filtered out and processed. A similar concept
would be needed in this component. Then is the question: what type of
packets would be used and how would they be sent through the network?
Maybe creating a simple packet with the dst IP of the controller and
an action on the dst switch to forward the whole packet to the
controller would work as long as the flows being installed do not
interfere with the "normal" switch processing.
Best regards
Bernd
On 11.01.2012 23:42, Kyriakos Zarifis wrote:
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
<mailto: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 <mailto:nox-dev@noxrepo.org>
http://noxrepo.org/mailman/listinfo/nox-dev
_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev
_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev