Variety of lists for possible propagation of a problem and possible reasons are
based on a type of problem faced. For example, in case of leakage, water propagates
along the system almost everywhere, in case of fire as well, while in case of
shot-cut, due to energy discharge damage is limited by neighborhood nodes.
Thus graph model of a system was enriched by logic operators for each
incoming and outcoming link. In this work, instead of fault propagation we are
trying to apply the same principle for algorithms and methods of system description
(graph, graph logic model (GLM) [16] to monitor “a level of desperation” for
packages traveled across network.
Indeed, these days at router level various packages are handled differently, using
the content of routing tables. Group of various algorithms introduced for that in [8–
12] are applied sometimes even in combination to address the requirements of
different types of packages. This all has been known as Quality of Service (QoS).
Amount of reading about such algorithms exceeds (11.5 Million) and grows (see
again previous chapters); surprisingly all of them are based on either Dijkstra or A*
algorithms but scrutinized “to fit” QoS demanded by type of package.
Mentioned algorithms use routing tables. Routing tables, in turn, are using the
protocol of network management protocol (NMP), that updates distance each
200 ms.
Modern routing is based on adding-on analysis of possible traces, paths and
selection of the most relevant or suitable. Both Dijkstra’s and A* algorithms form a
basis for modern routing. Cisco [13] and other algorithms [12] does not have
sufficient difference with Dijkstra and A* to be mentioned or considered.
In these circumstances introducing a level of urgency for service (or level of
desperation as we call it) into routing of packages especially for real-time packages
instead of known routing algorithms might be useful. This is simply because:
“those who need the most should be treated first”
But before to dive into details we should clarify what a difference of desperation
in generic terms is with the one we are trying to be explicitly defined for the
purposes of package handling. It is clear that the less time left the more effective
service should be provided.
Sure, it is possible to think and introduce inside the router something like integer
semaphores amongst all arrived packages with claims to be served and accessing it
through critical section or we can call “service zone” instead of “waiting zone”. We
might, for example, provide for all queuing packages “a right to be served”, following the rules of P, V semaphores [17] or even fault tolerant semaphores and [7].
When package (or process) is required to be served it requests to get through
“critical section”—P, V semaphores (“NATO book” Jenui Ed., [17]. This solution
is universal and it works. But number of voters is varying and complexity of voting
scheme becomes too high at the router level and overall performance of it, therefore
will be unavoidably poor.
Naturally, to implement “level of desperation”-driven service we need to evaluate timing for each package through the whole journey. At the same time, at the
router level we do not know so far how many paths along the graph of network a
package should take to reach its destination.
278
19 Distributed Systems: Resilience, Desperation
based on a type of problem faced. For example, in case of leakage, water propagates
along the system almost everywhere, in case of fire as well, while in case of
shot-cut, due to energy discharge damage is limited by neighborhood nodes.
Thus graph model of a system was enriched by logic operators for each
incoming and outcoming link. In this work, instead of fault propagation we are
trying to apply the same principle for algorithms and methods of system description
(graph, graph logic model (GLM) [16] to monitor “a level of desperation” for
packages traveled across network.
Indeed, these days at router level various packages are handled differently, using
the content of routing tables. Group of various algorithms introduced for that in [8–
12] are applied sometimes even in combination to address the requirements of
different types of packages. This all has been known as Quality of Service (QoS).
Amount of reading about such algorithms exceeds (11.5 Million) and grows (see
again previous chapters); surprisingly all of them are based on either Dijkstra or A*
algorithms but scrutinized “to fit” QoS demanded by type of package.
Mentioned algorithms use routing tables. Routing tables, in turn, are using the
protocol of network management protocol (NMP), that updates distance each
200 ms.
Modern routing is based on adding-on analysis of possible traces, paths and
selection of the most relevant or suitable. Both Dijkstra’s and A* algorithms form a
basis for modern routing. Cisco [13] and other algorithms [12] does not have
sufficient difference with Dijkstra and A* to be mentioned or considered.
In these circumstances introducing a level of urgency for service (or level of
desperation as we call it) into routing of packages especially for real-time packages
instead of known routing algorithms might be useful. This is simply because:
“those who need the most should be treated first”
But before to dive into details we should clarify what a difference of desperation
in generic terms is with the one we are trying to be explicitly defined for the
purposes of package handling. It is clear that the less time left the more effective
service should be provided.
Sure, it is possible to think and introduce inside the router something like integer
semaphores amongst all arrived packages with claims to be served and accessing it
through critical section or we can call “service zone” instead of “waiting zone”. We
might, for example, provide for all queuing packages “a right to be served”, following the rules of P, V semaphores [17] or even fault tolerant semaphores and [7].
When package (or process) is required to be served it requests to get through
“critical section”—P, V semaphores (“NATO book” Jenui Ed., [17]. This solution
is universal and it works. But number of voters is varying and complexity of voting
scheme becomes too high at the router level and overall performance of it, therefore
will be unavoidably poor.
Naturally, to implement “level of desperation”-driven service we need to evaluate timing for each package through the whole journey. At the same time, at the
router level we do not know so far how many paths along the graph of network a
package should take to reach its destination.
278
19 Distributed Systems: Resilience, Desperation