k ¼ Xt=Yc
ð19:4Þ
The biggest difference between real-time traffic packages and regular is that for
the first ones the timing is strict: a package must be delivered within allocated
period of time and before the predefined moment of time;
It is also clear that within this category of real-time packages the importance of
them might differ as well.
Thus, for video or audio messaging the loss of some packages (if they are not
clustered) might be almost invisible, while for control of an unmanned aircraft, a
health-monitoring system or nuclear reactor control system, military or financial
messages cannot be lost in principle. Desperation and real-time-ness should be
analyzed along the DCS traffic as a whole.
There are two views to think about real time traffic:
– global and
– local
Global assumes that we know not only time for package within which it should be
delivered but delays which each router and line along the package path contributes.
Assuming “a global view” we are capable to estimate all delays and having this
information can make decision “globally”.
Thus, “globally” speaking, when our packages are highly unlikely are able to
reach a destination before deadline we should be discarding them well before the
real moment of deadline comes. It saves a lot of space and time for others and
“smooth” traffic as a whole for the whole DCS or Internet. Or,—especially for
real-time messaging we should make all our efforts to accelerate packages along the
paths available.
Our approach assumes a creation of a “weighted” contribution for each segment
of a package path and estimate it according the whole journey;
Let’s say a segment j share of total delay is a division of time spent within this
segment divided by total time allowed for messaging from the source to destination:
j-th share ¼
t jth
P n
1 t i
ð19:5Þ
Then we are able to analyze the situations such as: “are we really late even if we
are late at this one, particular, but maybe insignificant segment?” It is interesting,
there is no doubt, but requires some global knowledge, awareness about updated
traffic information involved.
Also, probably we should consider all agents involved. Sender with its computer
drivers involved, as well as all along routers with their programs, including in and
output drivers and policies of reservation and making pull decisions.
272
19 Distributed Systems: Resilience, Desperation
ð19:4Þ
The biggest difference between real-time traffic packages and regular is that for
the first ones the timing is strict: a package must be delivered within allocated
period of time and before the predefined moment of time;
It is also clear that within this category of real-time packages the importance of
them might differ as well.
Thus, for video or audio messaging the loss of some packages (if they are not
clustered) might be almost invisible, while for control of an unmanned aircraft, a
health-monitoring system or nuclear reactor control system, military or financial
messages cannot be lost in principle. Desperation and real-time-ness should be
analyzed along the DCS traffic as a whole.
There are two views to think about real time traffic:
– global and
– local
Global assumes that we know not only time for package within which it should be
delivered but delays which each router and line along the package path contributes.
Assuming “a global view” we are capable to estimate all delays and having this
information can make decision “globally”.
Thus, “globally” speaking, when our packages are highly unlikely are able to
reach a destination before deadline we should be discarding them well before the
real moment of deadline comes. It saves a lot of space and time for others and
“smooth” traffic as a whole for the whole DCS or Internet. Or,—especially for
real-time messaging we should make all our efforts to accelerate packages along the
paths available.
Our approach assumes a creation of a “weighted” contribution for each segment
of a package path and estimate it according the whole journey;
Let’s say a segment j share of total delay is a division of time spent within this
segment divided by total time allowed for messaging from the source to destination:
j-th share ¼
t jth
P n
1 t i
ð19:5Þ
Then we are able to analyze the situations such as: “are we really late even if we
are late at this one, particular, but maybe insignificant segment?” It is interesting,
there is no doubt, but requires some global knowledge, awareness about updated
traffic information involved.
Also, probably we should consider all agents involved. Sender with its computer
drivers involved, as well as all along routers with their programs, including in and
output drivers and policies of reservation and making pull decisions.
272
19 Distributed Systems: Resilience, Desperation