19.4 Researching Desperation
Some good research questions here are worth to consider:
– Probability of reaching the destination in terms of time remains, how it
changes?
– How an internal state of each router and its organization impact on performance of network for real-time routing?
– Is it right to have a decision to hold or pull based on the level of time left?
– Should be better service (priority higher) when the threshold gets closer?
– How about steepness of a curve of success reaching a destination in time?
Regretfully, this global view is over-optimistic, as delays due to traffic vary.
Additionally, hardware malfunctions and path restrictions also contribute in
uncertainty of delivery time. We consider this “global” view in a bit more details
further.
In turn, the “Local view”, or local approach is based on the interaction of
elements inside the router represented such routing tables, queues, operating system, memory, processing power as well as hardware interruption schemes.
Every router—it is worth to remind—has to deal with packages of various types,
i.e. mixed traffic of: normal, regular and real-time packages.
There are several potential questions that might have research interest:
– What we know at the level of router? (see examples above, extended)
– Do we know the distance covered and how much time left? (at least ruffled?)
– A distance covered?
– Time left?
– Time spent?
Answering these questions, we note: for real-time packages we have limitations that
we are aware of: time given time spent at each segment.
Sure, we have to create a policy of pulling out packages that are approaching
their deadline (of presence in the router we are talking about). The closer to the
threshold the more urgent pull actions should be exercised.
This is what exactly has been called by as level of desperation or desperation
policy.
Instinctively, an algorithm at the local (router) level to deal with real-time
packages is obvious, Fig. 19.2.
In combination with a parameter of the package known as TTL (time to live),
that describes maximum permitted either time (is milliseconds) or in numbers
(number of hops permitted) time, for each package we can create a simple formula
that combines three parameters:
– Resource available
– Resource used
– Resource required
19.4 Researching Desperation
273
Some good research questions here are worth to consider:
– Probability of reaching the destination in terms of time remains, how it
changes?
– How an internal state of each router and its organization impact on performance of network for real-time routing?
– Is it right to have a decision to hold or pull based on the level of time left?
– Should be better service (priority higher) when the threshold gets closer?
– How about steepness of a curve of success reaching a destination in time?
Regretfully, this global view is over-optimistic, as delays due to traffic vary.
Additionally, hardware malfunctions and path restrictions also contribute in
uncertainty of delivery time. We consider this “global” view in a bit more details
further.
In turn, the “Local view”, or local approach is based on the interaction of
elements inside the router represented such routing tables, queues, operating system, memory, processing power as well as hardware interruption schemes.
Every router—it is worth to remind—has to deal with packages of various types,
i.e. mixed traffic of: normal, regular and real-time packages.
There are several potential questions that might have research interest:
– What we know at the level of router? (see examples above, extended)
– Do we know the distance covered and how much time left? (at least ruffled?)
– A distance covered?
– Time left?
– Time spent?
Answering these questions, we note: for real-time packages we have limitations that
we are aware of: time given time spent at each segment.
Sure, we have to create a policy of pulling out packages that are approaching
their deadline (of presence in the router we are talking about). The closer to the
threshold the more urgent pull actions should be exercised.
This is what exactly has been called by as level of desperation or desperation
policy.
Instinctively, an algorithm at the local (router) level to deal with real-time
packages is obvious, Fig. 19.2.
In combination with a parameter of the package known as TTL (time to live),
that describes maximum permitted either time (is milliseconds) or in numbers
(number of hops permitted) time, for each package we can create a simple formula
that combines three parameters:
– Resource available
– Resource used
– Resource required
19.4 Researching Desperation
273