search

kvetak / RINA

RINA Simulator
https://rinasim.omnetpp.org/
Other
29 stars 11 forks source link

DTP error, scheduling to the past #6

Closed gaixas1 closed 9 years ago

gaixas1 commented 9 years ago

There is an error at DTP::schedule, when QoS ATime is left as undefined (-1). In that case, as this function takes this value directly, it considers -1 as a valid time and then can try to schedule messages to past times.

I propose to compute MPL, R and A before the scheduling (checking that there is no invalid value) and then on the switch make it clearer. E.g. scheduleAt(simTime() + 3 * (MPL+R+A) , timer); //3(MPL+R+A)

screw commented 9 years ago

Could you point me to the branch, scenario, config, where I could test it? I believe this error is due to misconfigured QoSCube. .xml config has to include tag. I've updated all config.xml files in master branch when adding support for ATimer. DTP expect valid value. Check on that value should be in QoSCube, not in DTP.

gaixas1 commented 9 years ago

Un any escenario, removing atime from qos cube should do the trick. There are no uploaded examples with that problem working, as only i have uses qos with undefined parameter and have not this error on muy branch. El 01/05/2015 00:01, "screw" notifications@github.com escribió:

Could you point me to the branch, scenario, config, where I could test it?

— Reply to this email directly or view it on GitHub https://github.com/kvetak/RINA/issues/6#issuecomment-97983427.

screw commented 9 years ago

Well then there you have it. You cannot remove ATimer from QoSCube.

gaixas1 commented 9 years ago

Then make that parameter def value 0 and not -1, at least for qos cubes. -1 for ae. El 01/05/2015 00:06, "screw" notifications@github.com escribió:

Well then there you have it. You cannot remove ATimer from QoSCube.

— Reply to this email directly or view it on GitHub https://github.com/kvetak/RINA/issues/6#issuecomment-97984598.

screw commented 9 years ago

There are two problems mixed into one. There is requirements QoSCube and there is QoSCube supported by the DIF. We chose to use one class for both at the beginning. And that's why you cannot have default value that satisfy both cases. We chose using default values for the requirements QoSCube as there is reasonable expectation that AE specify only some parameters and others are represented as don't care (-1). On the other hand QoSCube supported by the DIF is expected to be fully specified as there is no default value for (all or at least many of) parameters. I'll suggest to V splitting QoSCube class into two.

gaixas1 commented 9 years ago

I support the spliting, but having some qos cube parameters as undefined may be also good, if are really parametets that we don't care or simply don't know/cannot ensure. E.g. qll qos differ only in delay or we have only a best effort qos. Also, mapping qos n to n-1 should be consideres at some point. El 01/05/2015 18:36, "screw" notifications@github.com escribió:

There are two problems mixed into one. There is requirements QoSCube and there is QoSCube supported by the DIF. We chose to use one class for both at the beginning. And that's why you cannot have default value that satisfy both cases. We chose using default values for the requirements QoSCube as there is reasonable expectation that AE specify only some parameters and others are represented as don't care (-1). On the other hand QoSCube supported by the DIF is expected to be fully specified as there is no default value for (all or at least many of) parameters. I'll suggest to V splitting QoSCube class into two.

— Reply to this email directly or view it on GitHub https://github.com/kvetak/RINA/issues/6#issuecomment-98173962.

screw commented 9 years ago

If you are referring to what i have described as "QoSCube supported by the DIF", then no, having some parameters as undefined is unacceptable (until somebody proves me otherwise). The DIF knows what it can and cannot support. If you are talking about requirements QoSCube, then undefined value is do-not-care value, and that is already in.

gaixas1 commented 9 years ago

Well the problemas here is that we have 3 things expresed in the same way. App requirements, what an app needs to work well. Qos cube, internal qos clases of each DIF used to distingish flows. Flow "qos", what an n-1 flow really provides.

A DIF must know what n-1 flows provide un order to use them, but to distingish its own flows, only need the qos páramos that really afect how those flows are treated. So if we have for example a DIF that only gives us best effort flows with or without retransmission, only the parapeters that decide that are needed un the qos cubes (as that is something only used within the dif and unknown to upper/lower layers.

Pd. Requests on n-1 flows on n flow allocation should be treated un the same way as request from apps. But simplifiying, a qos cube should have its supported params + required n-1 qos (e.g. we ensure delay <1ms, but require delay <0.1 ms on n-1 flows in order to ensure our delay). El 01/05/2015 19:04, "screw" notifications@github.com escribió:

If you are referring to what i have described as "QoSCube supported by the DIF", then no, having some parameters as undefined is unacceptable (until somebody proves me otherwise). The DIF knows what it can and cannot support. If you are talking about requirements QoSCube, then undefined value is do-not-care value, and that is already in.

— Reply to this email directly or view it on GitHub https://github.com/kvetak/RINA/issues/6#issuecomment-98178519.

screw commented 9 years ago

Closing this bug as it is not a bug. Moving the discussion to skype.