Open Source Projects Europe

I'll will add this to implementation of the other tickets and merge my branch in a few days.

ad PD: currently, the monitoring policy is invoked only on PDU arrival (according to specs); should we invoke it on PDU departure as well, then?

PDD: actually, the monitor policy is called before that, so it doesn't matter:

https://github.com/kvetak/RINA/blob/ade995cf258d8d44fc9e93d1b4f1f3a3fb47751a/src/DIF/RMT/RMT.cc#L72

RE:PD: Yes, in departure should be also called, as if there are no new inputs then variables used by the scheduler on outputs wouldn't be updated (for example the counters described latter).

RE:PDD: But then, in case that a PDUis dropped, the monitor never knows that nor update its variables....
Now, we are grouping some QoS classes in the same queue, each QoS with its threshold (the minimum of those will be also that of the RTMQueue) and the MaxQPolicy has to decide if accept or not new PDUs depending on things like the length of the queue and also the number of PDUs with that QoS on it.
Our idea was that the observer would increment/decrement those counters on input/output so either the observer is called when the push is "complete" (PDU not dropped) or not called if it's aborted (PDU dropped).
But well, if the current order is required, the MaxQPolicy can also notify the Monitor of the dropped PDU.

Actually, there isn't really any strict requirement about the order (that I know of). Any feedback from the actual policy writers is appreciated.

One of the first RinaSim requirements addressed a need of having some sort of Internet dropping policy in place so there would be a common base for comparison. I chose the RED algorithm and split it into a monitoring policy and a dropping policy. However, since the values used for RED dropping decision are recomputed before the actual drop is made (https://upload.wikimedia.org/wikipedia/commons/f/fd/Random_Early_Detection_algorithm_en.svg), the monitoring policy had to be invoked before the dropping policy.

How about extending the monitor policy class with an optional hook handler that would be triggered by a PDU drop? Something like monitoringpolicy::onPDUDrop().

(Or, rather than adding another method, we would invoke the same function but the call would include an additional parameter indicating the event type.)

Yes, that was more or less the other option that I was saying.
In that case, the best solution would be for the dropped pdu to be also passed as a parameter (or the header) as our policy needs the qos class of that pdu, but other policies (pseudo-connections with shared queues for example could require other parameters of the dropped pdu on monitoring).
The other option is for the monitoring policy to store itself the information needed and manage that itself, then a simply onPDUDrop(queue) without parameters should work.
I can work with both options.

PD. Passing the affected RTMQueue as a parameter is a must for onPDUDrop.

PDD. If the monitor is called also when PDUs are pop from the queues, then the values used for RED dropping decision could not be simply recomputed after the output and have the two policies swapping orders?

Okay, I think I'll go with the first option (or make the queue hold the "dropped" PDU in an acessible temporary buffer until all policies are done processing, then drop it).

ad PDD: I thought about that, but it wouldn't work. The formula used for computing average queue length in RED uses a timestamp of PDU arrival as a variable (because it takes into account the time interval for which the queue has been idle). Also, I don't think we can rule out the possibility of some other future policy requiring the pre-drop invocation.

Ok, perfect.

In the current stable version, the PDU attributes can be accessed via "black-box" methods:

unsigned int getFirstPDUPayloadLength()
unsigned int getLastPDUPayloadLength()
unsigned short getFirstPDUQoSID()
unsigned short getLastPDUQoSID()

To deal with message drop monitoring, the monitoring policy base class now contains a new hook method onMessageDrop(queue, pdu).

• status: open --> closed