Subject: Re: RSVP and ATM

From: Roch Guerin <[email-masked]>
Date: Thu, 15 Aug 1996 11:40:19 -0400

Tim,

While I certainly agree with your distinction between hard and soft
real-time requirements, I cannot fully agree with the statement below
on what is achievable with store-and-forward technology.  

>Please note that for real-time requirements, their are 'hard'
>real-time requirements and 'soft' real-time requirements.
>RSVP is not designed for 'hard' real-time requirements, and
>as a matter of fact, there is no store-and-forward technology
>that works for 'hard' real-time requirements because in theory,
>the cummulative wire-speed delays are the limiting factor.
>(see http://www.silkroad.com/papers/ for a draft on hard vs.
>soft real time requirements in packet switched networks).

Btw, because this discussion is more of an Int-Serv one than an RSVP
one, I'm copying this message to the Int-Serv list.

Specifically, Int-Serv defines a service, Guaranteed Service, that
essentially provides hard real-time guarantees over store-and-forward
networks (granted not all, but the broader discussion of how this is
done over different link/network technologies is currently addressed
in the context of the ISSLL working group, and I'll defer to the
several drafts that have been generated in that group for more
details). 

So, the basic point I want to make is that you can provide hard
real-time guarantees over store-and-forward technology and the
Int-Serv Guaranteed Service defines one approach to do so.  When
combined with RSVP, it will let you provide such guarantees.

Roch

---

From: Tim Bass (Underground) <[email-masked]>
Date: Thu, 15 Aug 1996 12:38:56 -0400 (EDT)

Hi Roch!

> on what is achievable with store-and-forward technology.  

Great!  I don't think that I have ever been in a situation where
anyone fully agreed, especially in the internetworking world :-)

....

From my experience a few months ago, the distinction between a 'hard'
and a 'soft' real time requirement was well documented in the
literature.  The references are at the back on the little draft
on real-time at http://www.silkroad.com/papers/ (I'm not trying
to promote the little draft, BTW, it just summarizes some very
simple concepts and gives references to others work in the field
and I can't remember the references off hand)

Basically, there are pre-defined terms for what constitutes a
'hard real-time' system.  And, in a nut-shell (but the
references explain much better and I refer the readership to the
references at the back of the draft) a hard real-time system is
one that is --so critical-- that data is delivered that if the data
is not delivered then there is a possibility of 'loss of life'
and the lifetime of the data from source to sink is normally
a few milliseconds. (this is defined in a chart, BTW)

Hence, voice, video, etc. are *not* hard real time requirements
as defined in the literature.

A hard real time requirement (again, I did not make up this def'
out of thin cyberair) would be (like) a real time navigational system
or sensor system that requires a hard fast guarentee of real time
data.  Sense, transmit, process, react.... in milliseconds.

Clearly, this is not optimal in a store-and-forward network which
has more than a few nodes or has multiple nodes with 'unlimited'
mega-bandwidth (then we have other latency issues, avoided here :-)
let's only consider the non-GIGABIT cases)

Given a simple network:

H---I----I----I----I----H  (where H are hosts and I are intermediate systems)

for a store and forward network, the absolute minimal delay from H to H
is the sum of the wire speed of the links (if we drive queuing, processing,
and backplane delays to zero).

Most practical real-time applications do not enjoy unlimited, mega-bandwidth
for each and every link, Host to Host, and to build a routed store-and-forward
network that is optimal for hard-real time data is like trying to build
an ocean going ship out of concrete and make it float (sorry for the
metaphor!).....

Sure, it is humanly possible to design and build store-and-forward packet
switched networks that *could* be used for hard real-time requirements,
but then it would not be a 'store-and-forward' network (in practical terms)
because the most optimal way to deliver high reliable data between any
two points is to have the most simple, fastest, reliable data link
possible.  Store and forward networks are WONDERFUL!  But to try to
extrapolate the store-and-forward paradigm to enjoy the reliability
and robustness of a dedicated circuit is more of an 'academic science
project' thing than practical engineering.

If your families lives depended on a network that required reliable millisecond
(less than 5 ms for sake of writing) I am sure that most engineers would
design a designated point-to-point circuit to manage the data.  To try
to do so with a packet switched network is not practical engineering
and there are more important 'fish to fry', IMO.

Please, however, do not confuse nor obfuscate the fact that RSVP or any
packet based resource reservation protocol (of the future) that operates
on a store-and-forward network (waiting for the entire packet to arrive
in the queue and do the 'checksum thing' :-) must sum to individual
wire-speed delays even if the routers and processors are transparent.

( I am an advocate for RSVP, BTW, for 'soft real-time' applications,
  again, 'soft real-time' has been clearly defined in the literature)

For priority surfing, priority mail, priority file transfer, video or
voice.... a few packets dropping here or there or a little delay here
or there, ..... no one's life depends on consistant ms response time.

I refer the reader to the references, which describe much more
elegantly the uniqueness of 'hard real time data'...  You are certainly
free to disagree with the 'community at large' and their symantics;
but based on my understanding, hard-real time requirements are not for
store-and-forward nets, soft real time requirements are, however; and
engineers get paid 'the big bucks' to determine what network systems
have hard and soft requirements (but only when the customer wants
the 'correct answer' and not the politically sexy and correct one :-)

(of course, we can change the defs' and constraints of what constitutes
 hard real time and then make it fit the program... sounds like a plan :-)

Regards,

Tim

---

From: Roch Guerin <[email-masked]>
Date: Thu, 15 Aug 1996 15:35:35 -0400

>anyone fully agreed, especially in the internetworking world :-)

Do I get something for that?  ;-)

>is not delivered then there is a possibility of 'loss of life'

And let met do it again, i.e., fully agree with the above.

>a few milliseconds. (this is defined in a chart, BTW)

Coming now to the above definition of "normality", let me point out
first that the Guaranteed Service will support this kind of
requirements, i.e., no losses (except for those due to physical
errors) and a guaranteed/hard/cast-in-concrete delay bound by which
packets will be delivered to the intended receiver(s).  This being
said, let me also point out that Guaranteed Service will only attempt
to control what can be controlled, i.e., the variable part of the
delay due to the queueing or contention that arises naturally in a
store-and-forward network, and obviously not the propagation delay.
Furthermore, while it is clearly possible to request very low
(queueing) delays, the amount of resources the network will need
to allocate to the flow in order to satisfy such stringent
requirements will increase quite rapidly.  Potentially to the point
where if may become more "expensive" (although still doable) than
providing a dedicated "circuit".  The question then is more in terms
of how stringent (close to propagation delay) the requirements are,
what percentage of applications will have such stringent requirements,
and the economy scale that can be achieved by having those connections
share overall network resources with others (which will obviously be
treated at a "lower priority" but can then use the remaining resources
more efficiently).

So overall, Guaranteed Service can support hard (and soft) delay
requirements, and experimenting with it in combination with other
services should help us find out where the right operating point is.
I wish ;) 

Roch