I am simulating a multihop broadcast protocol based on flooding using OMNeT++-4.6, Veins-4a2, SUMO-0.21.0 and Inet-3.3.0. I am collecting statistics for different parameters, as depicted in image below.Statistics collected for node[41]
However, I want to calculate some additional statistics such as end-to-end delay, total packet loss and total packets received successfully.
Any help in this regard is highly appreciated.
Thank you all!
Related
I'm trying to write my first script in Zeek which would allow to make statistics out of TLS packet segments sent and received by client in local network (quantity of packets with same size, list of dest ip by packets sent). Unfortunately, I'm unable to find proper Event or guide which would help me to find a solution for this. May I get an advise of this one?
Zeek has a few packet-level events that might get you started:
https://docs.zeek.org/en/current/scripts/base/bif/event.bif.zeek.html#id-new_packet
https://docs.zeek.org/en/current/scripts/base/bif/event.bif.zeek.html#id-raw_packet
https://docs.zeek.org/en/current/scripts/base/bif/event.bif.zeek.html#id-packet_contents
Note the warning that comes with these events: they incur high per-event overhead since they'll be generated for every packet, so they're most likely not suitable for deployment on live traffic.
How to get Throughput in OpenFlow Networks
We use OpenFlow 1.3 and Ryu Controller.
For Ryu Controller using OpenFlow, you may need to calculate based on statistics data received in OFPPortStats as part of OPFPortStatsReply for which you may need to use OFPPortStatsRequest message, to request port statistics info. Similarly, you can parse the OFPFlowStats of OPFFlowStatsReply message for flow based statistics calculation which shall be received as response for the request message OFPFlowStatsRequest.
OFPFlowStatsRequest can be used to get statistical information related to flow entry with switch. The requested target flow entry can be identified by conditions such as table ID, output port, cookie value and match but here all entries are made subject to the request.
OFPPortStatsRequest can be used to get port-related statistical information with switch. It is possible to specify the desired port number to acquire information from and OFPP_ANY can be specified to request information from all ports.
You may need to ceate an event handler that receives the PortStatsReply message. OPFPortStatsReply class’s attribute body is the list of OFPPortStats. The OFPPortStats has statistical information such as port numbers, send/receive packet count, respectively, byte count, drop count, error count, frame error count, overrun count, CRC error count, and collision count.
You may need to define a stats thread that send above requests messages and parse reply messages periodically. Once the statistics data it available, iterate/parse through the statistics information and compute bandwidth usage .
There are many other kind of requests you can perform and operate on the responses for which you can refer to http://osrg.github.io/ryu-book/en/html/traffic_monitor.html.
Calculating throughput on mininet will just give you a simulated answer which may not be true. However, check out the iPerf tool and see how you can integrate it with mininet.
I want to create a packet with additional data and then sending it using an on/off application in ns-3. I saw that I can only precise the size of packets and the rate. Can you please tell me how can I send a particular packet?
Thank you in advance.
I am using ryu controller (3.22) to monitor switches (Open vSwitch 2.0.2, supporting Open Flow 1.3), which are a part of virtual network created using mininet (2.1.0). It is a tree topology with depth = 2, and fanout = 5. I am using switch_monitor.py
With the help of controller, I can get port statistics using the EventOFPPortStatsReply decorator. I can get values of rx_packets, rx_bytes, rx_errors, tx_packets, tx_bytes, tx_errors, rx_dropped, tx_dropped etc.
But the values of rx_dropped, tx_dropped come out to be zero always, even when the switches are actually dropping packets, as reported by qdisc (linux command).
How to get packet loss statistics from an Open Flow switch?
a. How to get a non zero value?
b. Is there any alternate way?
qdisc reports what the kernel is dropping, not what the network is dropping. You're getting zero's because the switch isn't dropping frames.
(I don't know if your virtual network system supports simulating frame drops.)
I believe that dropped only cares about packets that are dropped due to actual drop rules or due to buffer overflows.
Another way to calculate packet loss is to compare the packet counts for the two switches on the edge of a link. Suppose you have A <--> B and want to calculate the packet loss rate from A to B. Then you take:
plr(A,B) = (tx_packets(A) - rx_packets(B)) / tx_packets(A))
Beware though that sometimes the counters are reset leading to rx_packets being higher that tx_packets. I am facing this behavior in my SDN software and tend to invalidate the results, if there are strange combinations.
I am using several XBee Zigbee with some Arduino modules (or microcontrollers, Arduino is not mandatory). I configured my XBees in AT/transparent mode.
I need to broadcast information: when one module is touched, every other module must react at the same time and immediately.
Unfortunately, if I have good speed results in unicast mode, there are lots of latencies in broadcast mode. It is something known and documented, see XBee ZigBee Addressing.
No data is lost, but they are sometimes buffered for a few seconds by an XBee before being sent again or delivered to my Arduino.
It seems it is not a configuration problem, it is the way the broadcast protocol work. Any idea on how I could speed-up the process?
The only one I have would be to use the API mode, to make each Arduino keep a list of the XBee addresses, and unicast information to the list of these addresses... but I lose the comfort of the broadcasting method, and I cannot easily add a new module without updating every Arduino.
Transmitting data using broadcast addressing with XBee ZB modules will generally give you much, much less performance than transmitting an individual unicast to each node you want to talk to. This is because broadcasting works very differently on the XBee ZB modules than with the XBee 802.15.4 modules.
When you send a broadcast with the XBee 802.15.4 modules, a single 802.15.4 frame is transmitted to the network and all the nodes that can hear the transmission pick it up and send the information out of their serial UARTs. The 802.15.4 network is a simple star network and no implicit repeating of the broadcast is performed by any of the nodes on the network. With XBee ZB, this is different. The XBee ZB modules are acting in a mesh topology and need to repeat the information to the other nodes that are out of range of the original transmission.
When you send a broadcast with the XBee ZB modules, each node that receives the broadcast will re-broadcast it 3 times, causing a lot of data to be transmitted between nodes. Additionally, there can only be a certain number of broadcasts which are "live" on a network at any given time. This often surprises people into thinking that the network is dropping their data when in fact the XBee is rejecting the transmission request.
Unless you are sending data very infrequently--perhaps a broadcast once per minute or more slowly--it is often better to follow this procedure:
Built a list of all nodes by performing a network discovery or collecting route record packets by enabling the AR feature
Send a unicast to each node you wish to transmit to
If you're sending information to a nodes on a large ZB network (i.e. greater than 30 notes) you may want to read this article: Large Networks and Source Routing
I don't think you can optimize it much more, unless only some of the modules need to receive the message. In this case you could use a multicast (might only be available with Xbee 2) instead of a broadcast, which would bring some very minor improvement on the overall speed of your network when it grows big enough (greater than 16 nodes, i.e. the basic routing table).
Have you tried a comparison between unicast, multicast and broadcast? It may be that making a dozen unicasts is on average faster or at least more reliable, especially if you have many hops in your specific network (ex: a 12-node network with 8 hops).
With unicast you can get a confirmation or ack so you know the overall time and success of the operation, and whether you need to retry or not.