These brief description of basic router duties highlights that a package inside
might be reorganized, delayed, queued at the input and at the output with absolutely
different reasons.
19.10.1 Router Level—Inside Job
Every package awaiting processing inside a router can be described by states 1, 2,
3… n, Fig. 19.8a. The number of “states” allowed depends on a type of a package.
For example:
• Packages with emails might wait, two hundred milliseconds of delay for this
type of messaging is not critical;
• Real-time messaging requires “smooth delivery”, when some packages might be
even dropped but the rest should be delivered in the strict time slot (video- and
audio messaging);
• Safety-critical messaging and related packages (when the Internet is applied in
real-time applications) vary in the level of restrictions and urgency.
Thus we can consider forced us to think about handling of “states” allowed for each
type of package. Changing of states for a package might depend on time this
package queued in the router. Clear that various type of packages can be given
different number of states per package. Instinctively we simply must keep the delay
for a package with high demand as short as possible and process package that is
reaching its critical limit ASAP. Processing here means:
• receiving
• routing
• pulling out from incoming queue
• pushing in allocated output queue
This kind of monitoring in terms “who sits here long enough” introduces a policy to
handle queues accordingly “the level of desperation”, for each and every package.
For a hard real time we simply must have the shortest queuing and fastest service
from input to output, when priority is high, but not really real-time type of traffic,
the queueing might be a little bit longer, and finally when a package is standard the
waiting time might be much longer, Fig. 19.8a illustrates qualitatively behavior of
router in terms of different type packages.
What kind of support the principle of desperation control requires from a router?
It is fairly simple:
A priority within a class or even across different classes of packages should be
considered and treated as variables.
This changing should depend on time of package presence within a queue and
“history of the package”. Thus, “High priority” package in any queue should be
288
19 Distributed Systems: Resilience, Desperation
might be reorganized, delayed, queued at the input and at the output with absolutely
different reasons.
19.10.1 Router Level—Inside Job
Every package awaiting processing inside a router can be described by states 1, 2,
3… n, Fig. 19.8a. The number of “states” allowed depends on a type of a package.
For example:
• Packages with emails might wait, two hundred milliseconds of delay for this
type of messaging is not critical;
• Real-time messaging requires “smooth delivery”, when some packages might be
even dropped but the rest should be delivered in the strict time slot (video- and
audio messaging);
• Safety-critical messaging and related packages (when the Internet is applied in
real-time applications) vary in the level of restrictions and urgency.
Thus we can consider forced us to think about handling of “states” allowed for each
type of package. Changing of states for a package might depend on time this
package queued in the router. Clear that various type of packages can be given
different number of states per package. Instinctively we simply must keep the delay
for a package with high demand as short as possible and process package that is
reaching its critical limit ASAP. Processing here means:
• receiving
• routing
• pulling out from incoming queue
• pushing in allocated output queue
This kind of monitoring in terms “who sits here long enough” introduces a policy to
handle queues accordingly “the level of desperation”, for each and every package.
For a hard real time we simply must have the shortest queuing and fastest service
from input to output, when priority is high, but not really real-time type of traffic,
the queueing might be a little bit longer, and finally when a package is standard the
waiting time might be much longer, Fig. 19.8a illustrates qualitatively behavior of
router in terms of different type packages.
What kind of support the principle of desperation control requires from a router?
It is fairly simple:
A priority within a class or even across different classes of packages should be
considered and treated as variables.
This changing should depend on time of package presence within a queue and
“history of the package”. Thus, “High priority” package in any queue should be
288
19 Distributed Systems: Resilience, Desperation