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
