search

kvetak / RINA

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

Changes in score counting in QoSCubes when less is better #22

Closed kaleal closed 7 years ago

kaleal commented 7 years ago

I suggest some changes in ScoreComparer FA policy. Basically, this affect the score counting for that cases where less is better. In the original code greater is always better, but in fact, this is not the truth.

Example: (requirements.getUndetectedBitErr() >= cube.getUndetectedBitErr()) ? score++ : score--; Here, the QoSCube should provide a undetected bit error rate inferior than that acceptable by the application to met their requirements. Less undetected bit error is better.

The same explanation for: requirements.getPduDropProbability() >= cube.getPduDropProbability() requirements.getMaxAllowGap() >= cube.getMaxAllowGap() requirements.getDelay() >= cube.getDelay() requirements.getJitter() >= cube.getJitter() requirements.getCostTime() >= cube.getCostTime() requirements.getCostBits() >= cube.getCostBits()

Kleber

gaixas1 commented 7 years ago

Just those are ok like that. E.g. (requirements.getUndetectedBitErr() >= cube.getUndetectedBitErr()) ? score++ : score--; this means that the score is possitive if the request allows equal or more lost undetected errors than the underlaying QoS, so it supports it.

Same with delay or jitter for example, the flow may require at most 5 so if the qos says 5 or less is good, otherwise -1

2017-01-25 22:29 GMT+01:00 Kleber Leal notifications@github.com:

I suggest some changes in ScoreComparer FA policy. Basically, this affect the score counting for that cases where less is better. In the original code greater is always better, but in fact, this is not the truth.

Example: (requirements.getUndetectedBitErr() >= cube.getUndetectedBitErr()) ? score++ : score--; Here, the QoSCube should provide a undetected bit error rate inferior than that acceptable by the application to met their requirements. Less undetected bit error is better.

The same explanation for: requirements.getPduDropProbability() >= cube.getPduDropProbability() requirements.getMaxAllowGap() >= cube.getMaxAllowGap() requirements.getDelay() >= cube.getDelay() requirements.getJitter() >= cube.getJitter() requirements.getCostTime() >= cube.getCostTime() requirements.getCostBits() >= cube.getCostBits()

Kleber

You can view, comment on, or merge this pull request online at:

https://github.com/kvetak/RINA/pull/22 Commit Summary

  • Turn Window-based congestion control on
  • Fixed the TCP_Tahoe_CWND signal to type double
  • Fixed NewFlowResquest policy ScoreComparer attibutes where less is better

File Changes

Patch Links:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kvetak/RINA/pull/22, or mute the thread https://github.com/notifications/unsubscribe-auth/ABY86DGbLWRbYr_9pQNz7KMDc_s5glRKks5rV760gaJpZM4LuBQn .

kaleal commented 7 years ago

I did the same check for MinComparer policy.

In the MinComparer, the validation must return false if the application requirement is not met. The QoSCube is rejected if at least one of the requirements fail in validation.

For: requirements.getMaxAllowGap() < cube.getMaxAllowGap() If the MaxAllowGap provided by the QoSCube is greater than the required by requester, the validation must fail.

requirements.getJitter() < cube.getJitter() The same for Jitter. If that one provided by the QoSCube is greater than the requester application requirement, the requirement is not met and the validation must fail.

I just made the changes and pushed them into my fork.

kvetak commented 7 years ago

Fair enough. Justification makes sense.