I am trying to do multipath routing using per packet in openflow. I do not know how are multipaths used to deliver data on per packet basis. Is flow table updated everytime or group table does per packet delivery?
Each flow entry may have an idle timeout and or a hard timeout associated with it.
The idle timeout and a hard timeout control the removal of a flow entry from the OpenFlow table. If either value is non-zero, the switch must note the flow entry's arrival time, as it may need to evict the entry later. A non-zero idle_timeout entry field causes the flow entry to be removed after the given number of seconds, if no packet has been matched by the flow. A non-zero hard_timeout field causes the flow entry to be removed after the given number of seconds, regardless of how many packets it has matched.
Hard timeout: The absolute timeout after which the flow is removed from the device.
Idle timeout: The absolute timeout in which if there are no packets hitting the flow for the duration, then flow is removed from the device.
Related
Command response pair
I couldn't find a clear specification about the period between two consecutive Command/Response Pair (T in the diagram).
for example, If I had sent a command to the card and received a response, What is the maximum period I can wait before the communication is not valid anymore? I need this because I'm willing to make use of this period to give me some flexibility in my design.
This is the block waiting time (which can be computed from the BWI part of TB3 in the ATR). If the card needs more time, it has to send a Waiting Time Extension (abbreviated WTX), before this elapses, which has to be acknowledged by the other side (typically the reader). If the acknowledge is not given both sides assume a communication error.
Note, that FWI and BWI from TA1 as well as the clock supplied to the card influence the time.
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.
In my understanding, the flow rules stay present. My issue is with rules that direct the packet to the controller. If a new flow comes in, for example, and the controller is down, will this new packet simply be dropped?
will this new packet simply be dropped?
Exactly!
Its up to the configuration whether the flows will present or not. Here is the explanation from Openflow 1.3 documentation:
Flow entries are removed from flow tables in two ways, either at the
request of the controller or via the switch flow expiry mechanism. The
switch flow expiry mechanism that is run by the switch independantly
of the controller and is based on the state and configuration of flow
entries. Each flow entry has an idle_timeout and a hard_timeout
associated with it. If either value is non-zero, the switch must note
the flow entry's arrival time, as it may need to evict the entry
later. A non-zero hard_timeout field causes the flow entry to be
removed after the given number of seconds, regardless of how many
packets it has matched. A non-zero idle_timeout field causes the flow
entry to be removed when it has matched no packets in the given number
of seconds. The switch must implement flow expiry and remove flow
entries from the flow table when one of their timeout is exceeded.
If both idle_timeout and hard_timeout are zero, the entry is considered permanent and will never time out:
If the idle_timeout is set and the hard_timeout is zero, the entry
must expire after idle_timeout seconds with no received trafic. If the
idle_timeout is zero and the hard_timeout is set, the entry must
expire in hard_timeout seconds regardless of whether or not packets
are hitting the entry. If both idle_timeout and hard_timeout are set,
the flow entry will timeout after idle_timeout seconds with no
trafic, or hard_timeout seconds, whichever comes first. If both
idle_timeout and hard_timeout are zero, the entry is considered
permanent and will never time out. It can still be removed with a
flow_mod message of type OFPFC_DELETE.
If a consumer of a RabbitMQ crashes, with no graceful disconnection, will a subsequent declare-ok request fired several milliseconds later report a diminished consumer-count? Or is there an amount of time that needs to pass before the reported number will change?
declare-ok count all known consumers regardless their actual state.
See, in fact, some time after connection get dangled it still marked as alive (exact time depends on OS settings and whether do you use heartbeats and whether there are any network operation over that connection). In RabbitMQ management panel you may see connection and it channels with consumer tags listed some time after connection died.
I am using NSB 4.4.2
I want to have something like heartbeats on my saga to show processing statistics.
When i request a timeout it sends to sagas input queue.
In case of many messages prior to this timeout message, IHandleTimeouts may not be fired at specific time.
Is it a bug? Or how can i use separate queue for timeout messages?
Thanks
You are correct - when a timeout is ready to be dispatched, it is sent to the incoming queue of the endpoint, and if there are already many other messages in there, it will have to wait its turn to be processed.
Another thing you might want to consider, is that the endpoint may be down at that time.
If you want to guarantee that your saga code will be invoked at (or very close to) the time of the timeout, you'll need to set up a high availability deployment first. Then, you should look at setting the SLA required of that endpoint - how quickly messages should be processed, and then monitor the time to breach SLA performance counter.
See here for more information: http://docs.particular.net/nservicebus/monitoring-nservicebus-endpoints
You should be prepared to scale out your endpoint as needed to guarantee enough processing power to keep up with the load coming in.
NOTE: The reason we use the same incoming queue for processing these timeouts is by design. A timeout message is almost always the same priority or lower than the other business messages being processed by a saga. As such, it doesn't make sense to have them cut ahead of other messages in line.
Timeouts are sent to the [endpointname].timeouts