As per Relevance of the word throughput, we have this rfc below:
Network Working Group D.
Request for Comments: 1193 UC
November 1990
CLIENT REQUIREMENTS FOR REAL-TIME COMMUNICATION
Status of this
This memo describes client requirements for real-time
services. This memo provides information for the Internet community
and requests discussion and suggestions for improvements. It
not specify any standard. Distribution of this memo is unlimited
A real-time communication service provides its clients with
ability to specify their performance requirements and to
guarantees about the satisfaction of those requirements. In
paper, we propose a set of performance specifications that
appropriate for such services; they include various types of
bounds, throughput bounds, and reliability bounds. We also
other requirements and desirable properties from a client'
viewpoint, and the ways in which each requirement is to be
to make it suitable for lower levels in the protocol hierarchy
Finally, we present some examples of requirements specification,
discuss some of the possible objections to our approach
This research has been supported in part by AT&T Bell Laboratories
the University of California under a MICRO grant, and
International Computer Science Institute. The views and
in this document are those of the author and should not
interpreted as representing official policies, either expressed
implied, of any of the sponsoring organizations
1.
We call real-time a computer communication service whose clients
allowed to specify their performance requirements and to
guarantees about the fulfillment of those requirements
Three terms in this definition need further discussion
clarification: clients, performance, and guarantees
Network architecture usually consists, at least from a
viewpoint, of a stack of protocol layers. In the context of such
architecture, the notions of client and server apply to a number
Ferrari [Page 1]
RFC 1193 Requirements for Real-Time Services November 1990
different pairs of entities: every layer (with the support of
underlying layers) provides a service to the layer immediately
it and is a client of its underlying layers. In this paper,
considerations generally apply to any client-server pair. However
most of them particularly refer to human clients (users, programmers
and to the ways in which such clients express their communication
processing needs to the system (e.g., interactive commands
application programs). This type of client is especially important
since client needs at lower layers can be regarded as translations
the needs expressed by human clients at the top of the hierarchy
When the client is human, the server consists of the
(distributed) system, including the hosts, their operating systems
and the networks interconnecting them
As for the generic term, performance, we will give it a fairly
meaning. It will include not only delay and throughput, the two
network performance indices, but also reliability of
delivery. Real-time communication is concerned with those aspects
quality of service that have to do with performance in this
sense
The term guarantee in this paper has a rather strong legal flavor
When a server guarantees a given level of performance for
communications of a client, it commits itself to providing
performance and to paying appropriate penalties if the
performance turns out to be insufficient. On the other hand,
client will have to obey certain rules, and will not be entitled
the requested performance guarantees unless those rules
scrupulously obeyed. In other words, client and server have to
into a contract specifying their respective rights and duties,
benefits that will accrue, the conditions under which those
will materialize, and the penalties they will incur for not
their mutual promises. We believe that a legal viewpoint is to
adopted if serious progress in the delivery of communication
(not only the real-time ones) is desired. Utility services, as
as other kinds of service, are provided under legally
contracts, and a mature computer communication utility cannot fail
do the same. In the field of real-time communication, such
contract will by definition include performance guarantees
Real-time services may be offered in any kind of network
internetwork. Some of their predictable applications are
(a) digital continuous-media (motion video, audio
communication: lower bounds on throughput and upper
on delay or delay variability or both are needed to
any desired level of output quality; in the interactive case
both the values of delay and delay variabilities have to
Ferrari [Page 2]
RFC 1193 Requirements for Real-Time Services November 1990
bounded; some limited message losses are often tolerable
the cases of video and voice (whenever very high quality
not required), but usually not in the case of sound
(b) transmission of urgent messages in real-time
systems: delay bounds are the important guarantees to
provided in these applications; losses should ideally
impossible
(c) urgent electronic-mail messages and, more in general
urgent datagrams: again, delay is the obvious index to
bounded in this case, but small probabilities of losses
often be tolerated
(d) transfers of large files: minimum throughput bounds
usually more important than delay bounds in
application; also, all pieces of a file must be
with probability 1;
(e) fast request-reply communication: e.g., data base queries
information retrieval requests, remote procedure calls;
is another case in which delay (more precisely, round-
delay) is the index of primary interest;
requirements are generally not very stringent
We conjecture that, when networks start offering well-designed
reasonably-priced real-time services, the use of such services
grow beyond the expectations of most observers. This will
primarily because new performance needs will be induced by
availability of guaranteed-performance options. As the history
transportation and communication has repeatedly shown,
services bring about major increases of the shipments that
perceived as urgent. The phenomenon will be more
whenever the quality of service provided to non-real-time
will deteriorate. It is clear from this comment that we assume
real-time services will coexist within the same networks
internetworks with non-real-time communications. Indeed,
a world in which the two types of service are segregated rather
integrated would be unrealistic, as it would go against the
trend towards the eventual integration of all information services
For the same reason, the traffic in the network is assumed to
heterogeneous, i.e., to consist of a variety of types of messages
representing a variety of information media and their combinations
with a wide spectrum of burstiness values (from
continuous fixed-rate streams to very short and erratic bursts
information).
This paper discusses the client requirements and characteristics of
Ferrari [Page 3]
RFC 1193 Requirements for Real-Time Services November 1990
real-time communication service. Server requirements and
principles will be the subject of a subsequent paper. Section 2
contains some considerations about the ways in which the
specify their requirements, and those in which a server should
to requests for real-time services. Performance requirements
presented in Section 3; other properties that clients may need
desire are described in Section 4. Section 5 deals with the
of translating the requirements of a human client or an
for the equivalent lower-level ones. In Section 6, we
present four examples of client requirement specifications, and
Section 7 we discuss some of the objections that can be
against our approach
2. Client Requests and Server
No real-time service can be provided if the client does not specify
together with the requirements, the characteristics of the
input traffic. Describing input traffic and all the
requirements entails much work on the part of a client.
the necessary information and inputting it may be very time
consuming. A well-designed real-time communication service
minimize the effort to be spent by a client
Sensible default values, the possibility of partial or
specifications (e.g., by editing preexisting specifications), and
number of standard descriptions should be provided.
descriptions will include characterizations of inputs (e.g., those
a video stream for multimedia conferencing, an HDTV stream, a hi-
audio stream, a file transfer stream, and so on) and standard sets
requirements. With these aids, it might be possible for a
client to specify his or her request by a short phrase,
followed by a few characters representing options or changes to
standard or default values
Since requests for real-time services may be denied because of
mismatch between the client's demands and the resources available
the server, the client will appreciate being informed about
reasons for any rejection, so that the request can be modified
resubmitted, or postponed, or cancelled altogether [Herr89].
information provided by the server to a human client should
meaningful, useful, and non-redundant. The reason for
should be understandable by the client (who should be assumed not
know any of the details of the operating system, of the protocols
of the network) and should be accompanied by data that will be
to the client in deciding what to do as well as how the request
to be modified to make it successful. If, for example, a
specified by the client cannot be guaranteed by the server under
current load, the information returned to the client should
Ferrari [Page 4]
RFC 1193 Requirements for Real-Time Services November 1990
the minimum or maximum value of the bound that the server
guarantee; the client will thus be able to decide whether that
would be acceptable (possibly with some other modifications as well
or not, and act accordingly
When the client is not a human being but an application or a process
the type of a server's replies should be very different from
just described [Herr89]; another standard interface, the one
an application and a real-time service, must therefore be defined
possibly in multiple, application-specific versions
Clients will also be interested in the pricing policies
by the server: these should be fair (or at least perceived to
fair) and easy to understand. The client should be able easily
estimate charges for given performance guarantees as a function
distance, time of day, and other variables, or to obtain
estimates from the server as a free off-line service
3. Performance
A client can specify a service requirement using the general
pred = TRUE
where some of the variables in predicate pred can be controlled
influenced by the server
A simple and popular form of performance requirement is
involving a bound. A deterministic bound can be specified
(var <= bound) = TRUE, or var <= bound
where variable var is server-controlled, while bound is client
specified. The bounds in these expressions are upper bounds; if <
is replaced by > , they become lower bounds
When the variable in the latter expression above is a probability,
have a statistical bound, and bound in that case is a
bound; if the predicate is a deterministic bound, we have
Prob (var <= bound) >= probability-bound
In this requirement, the variable has an upper bound, and
probability a lower bound. Note that deterministic bounds can
viewed as statistical bounds that are satisfied with probability 1.
A form of bound very similar to the statistical one is the
bound
Ferrari [Page 5]
RFC 1193 Requirements for Real-Time Services November 1990
Ca (var <= bound) >= b
where variable var has a value for each message in a stream, and
is a function that counts the number of times var satisfies the
for any a consecutive messages in the stream; this number Ca
satisfy bound b. Obviously, a fractional bound is realizable only
b <= a . Fractional bounds will not be explicitly mentioned in
sequel, but they can be used in lieu of statistical bounds, and
over these bounds the avantages of easy verifiability and
practical interest
In this section, we restrict our attention to those requirements
are likely to be the most useful to real-time clients
3.1 Delay
Depending on the application, clients may wish to specify their
requirements in different ways [Gait90]. The delays involved
usually be those of the application-oriented messages known to
client; for instance, the delay between the beginning of the client
level transmission of a video frame, file, or urgent datagram and
end of the client-level reception of the same frame, file, or
datagram. (In those cases, e.g., in some distributed real-
systems, where message deadlines are assigned instead of
delays, we can always compute the latter from knowledge of the
and of the sending times, thereby reducing ourselves again to a
bound requirement.) Also, they will be the delays of those
that are successfully delivered to the destination; the fraction
messages that are not, to which the delay bounds will not apply,
be bounded by reliability specifications. Note that clients
express delay bounds by making implicit reference to their
clocks; the design of a real-time service for a large network
have to consider the impact on bounds enforcement of non-
clocks [Verm90]. Some of the forms in which a delay requirement
be specified
(i) deterministic delay bound
Di <= Dmax for all i
the client is delivered to the destination client-level entity,
Dmax is the delay upper bound specified by the client. In
descriptions we assume, without loss of generality, that the
requesting a real-time service is the sending client, and that
destination (which could be a remote agent of the client or
user) is a third party with respect to the establishment of
particular communication being considered (In our descriptions
assume, without loss of generality, that the client requesting
Ferrari [Page 6]
RFC 1193 Requirements for Real-Time Services November 1990
real-time service is the sending client, and that the
(which could be a remote agent of the client or another user) is
third party with respect to the establishment of the
communication being considered.);
(ii) statistical delay bound
Prob ( Di <= Dmax ) >= Zmin
where Di and Dmax are defined as above, and Zmin is the
bound of the probability of successful and timely delivery
(iii) deterministic delay-jitter bound
Ji = | Di - D | <= Jmax for all i
where D is the ideal, or target delay, Ji is the delay jitter
the i-th message delivered to the destination, and Jmax is
upper jitter bound to be specified by the client together with D
note that an equivalent form of this requirement consists
assigning a deterministic upper bound D + Jmax and a
lower bound D - Jmax to the delays Di [Herr90];
(iv) statistical delay-jitter bound
Prob (Ji <= Jmax) >= Umin, for all i
where Umin is the lower bound of the probability that Ji
within its limits
Other forms of delay bound include bounds on average delay,
variance, and functions of the sequence number of each message,
example, Dmax(i) for the deterministic case. There may
applications in which one of these will be the preferred form, but
since we have not found any so far, we believe that the four types
bounds listed as (i)-(iv) above will cover the great majority of
practical cases
3.2 Throughput
The actual throughput of an information transfer from a source to
destination is bounded above by the rate at which the source
messages into the system. Throughput may be lower than this
because of the possibility of unsuccessful delivery or message loss
It is also bounded above by the maximum throughput, which is
function of, among other things, network load. As the
increases its input rate, the actual throughput will grow up to
limit and then stop. Clients concerned with the throughput of
Ferrari [Page 7]
RFC 1193 Requirements for Real-Time Services November 1990
transfers will want to make sure that saturation is never reached,
is reached only with a suitably small probability and for
short intervals. Also, if the bandwidth allocated to a transfer
not constant, but varies dynamically on demand to accommodate,
least to some extent, peak requests, clients will be interested
adding an average throughput requirement, which should
information about the length of the interval over which the
must be computed [Ferr89a].
Thus, reasonable forms for throughput requirements appear to be
following
(i) deterministic throughput bound
Ti >= Tmin, for all i
where Ti is the throughput actually provided by the server,
Tmin is the lower bound of throughput specified by the client
that is, the minimum throughput the server must offer to
client
(ii) statistical throughput bound
Prob (Ti >= Tmin) >= Vmin
where Ti and Tmin are defined as above, and Vmin is the
bound of the probability that the server will provide a
greater than the lower bound
(iii) average throughput bound
T >= Tave
where T is the average throughput provided by the server, Tave
its lower bound specified by the client, and both variables
averaged over an interval of duration I specified by the client
the above inequality must obviously hold for all intervals
duration I, i.e., even for that over which T is minimum
One clear difference between delay bounds and throughput bounds
that, while the server is responsible for delays, the
throughputs of a non-saturated system are dictated by the
rates, which are determined primarily by the clients (though they
be influenced by the server through flow-control mechanisms).
Ferrari [Page 8]
RFC 1193 Requirements for Real-Time Services November 1990
3.3 Reliability
The usefulness of error control via acknowledgments
retransmission in real-time applications is doubtful, especially
those environments where message losses are usually higher, i.e.,
wide-area networks: the additional delays caused by
and retransmission, and out-of-sequence delivery are likely to
intolerable in applications with stringent delay bounds, such
those having to do with continuous media. Fortunately, the loss
some of the messages (e.g., video frames, voice packets) is
tolerable in these applications, but that of sound packets
generally intolerable. In other cases, however, completeness
information delivery is essential (e.g., in file
applications), and traditional retransmission schemes will
have to be employed
A message may be incorrect when delivered or may be lost in
network, i.e., not delivered at all. Network unreliability (due,
example, to noise) is usually the cause of the former problem;
overflow (due to congestion) or node or link failure are those of
latter. The client is not interested in this distinction: for
client, the message is lost in both cases. Thus, the simplest
in which a reliability bound may be expressed and also, we believe
the one that will be most popular,
Prob (message is correctly delivered) >= Wmin
where Wmin is the lower bound of the probability of correct delivery
to be specified by the client. The probability of message loss
obviously be bounded above by 1 - Wmin. This is a statistical bound
but, as noted in Section 3, a deterministic reliability bound
if we set Wmin = 1.
In those applications in which any message delivered with a
greater than Dmax must be discarded, the fraction of messages
by the destination will be bounded below by Wmin Zmin. The
may actually specify the value of this product, and let the
decide the individual values of the two bounds, possibly subject to
client-assigned constraint, e.g., that the price of the service
the client be minimum
If the value of Wmin is greater than the system's reliability (
probability that a delivered message is correct), then there is
buffer space allocation in the hosts, interfaces, switches
routers or gateways that will allow the client-specified Wmin to
guaranteed. In this case, the server uses error correcting codes,
(if the application permits) retransmission, or duplicate messages
or (if the sequencing problem discussed in Section 4.1 can be
Ferrari [Page 9]
RFC 1193 Requirements for Real-Time Services November 1990
satisfactorily or is not a problem) multiple physical channels
the same logical channel, or has to refuse the request
4. Other Required or Desirable
In this section, we briefly describe client requirements that
be easily expressed as bounds on, but are related to,
performance. These include sequencing, absence of duplications
failure recovery, and service setup time. We are not concerned
with features that may be very important but have a
(e.g., multicast capabilities) or security (e.g.,
authentication) rather than a performance flavor. Requirements
these areas will generally have appreciable effects also
performance; we do not discuss them only because of
limitations
For a given application, some of these properties may be required
some others only desirable. Also, some may be best represented
Boolean variables (present or absent), some others as continuous
multi-valued discrete variables, others yet as partially
specifications
4.1
For applications involving message streams (rather than
datagrams), it may be necessary or desirable that messages
delivered in sequence, even though the sequence may not be complete
If the lower-level servers are not all capable of delivering
sequentially, a resequencing operation may have to be performed
some higher level in the hierarchy. In those cases in
reliability requirements make retransmission necessary,
may delay delivery of a large number of messages by relatively
times. An adequate amount of buffer space will have to be
for this purpose at the level of the resequencer in the
hierarchy
If sequencing is not guaranteed by all servers at all levels,
application may be able to tolerate out-of-sequence messages as
as their number is small, or if the delay bound is so large that
few out-of-sequence messages have to be discarded because they
too late. The client could be allowed to specify a bound on
probability that a message be delivered out of sequence, or to
out-of-sequence losses with the other types of message loss
by Wmin. The client would specify the value of Wmin (or Wmin Zmin),
and the server would have to decide how much probability to allow
buffer overflow, how much for network error, and how much
imperfect sequencing, taking into account the stringency of the
bounds
Ferrari [Page 10]
RFC 1193 Requirements for Real-Time Services November 1990
On the other hand, with fixed-route connections and
queueing and scheduling in the hosts and in the network, it is
not too hard to ensure sequenced delivery at the various layers
hence also at the top
4.2 Absence of
Most of the discussion of sequencing applies also to duplication
messages. It is, however, easier and faster to
duplications than to resequence, as long as some layer keeps track
the sequence numbers of the messages already received.
specification of a bound may be needed only if duplications
very frequent, but this would be a symptom of serious
malfunction, and should not be dealt with in the same way as
handle delays or message losses. These observations do not apply,
course, to the case of intentional duplication for
reliability
4.3 Failure
The contract between client and server of a real-time service
have to specify what will happen in the event of a server failure
Ideally, from the client's viewpoint, failures should be
masked, and service should be completely fault-tolerant. As we
already mentioned, however, it is usually unrealistic to expect
performance guarantees can be honored even in presence of failures
A little less unrealistic is to assume that service can resume
short time after a failure has disrupted it. In general, clients
not only wish to know what will happen if a failure occurs, but
have a guaranteed upper bound on the likelihood of such
occurrence
Prob (failure) <= Fmax
Different applications have different failure recovery requirements
Urgent datagrams or urgent message streams in most real-
distributed systems will probably not benefit much from recovery
unless it can be made so fast that hard deadlines may still
satisfied, at least in some cases. In the case of video or
transmission, timely resumption of service will normally be
useful or even necessary; thus, clients may need to be
guarantees about the upper bounds of mean or maximum time to repair
this may also be the case of other applications in which
deadlines are not so stringent, or where the main emphasis is
throughput and/or reliability rather than on delay
In communications over multi-node routes and/or long distances,
network itself may contain several messages for each source
Ferrari [Page 11]
RFC 1193 Requirements for Real-Time Services November 1990
destination pair at the time a failure occurs. The recovery
will have to solve the problems of failure notification (to all
system's components involved, and possibly also to the clients)
disposition of messages in transit. The solutions adopted may
duplicate elimination necessary even in contexts in which
duplicates are ever created in the absence of failures
4.4 Service setup
Real-time services must be requested before they can be used
communicate [Ferr89b]. Some clients may be interested in long-
arrangements which are set up soon after the signing of a
and are kept in existence for long times (days, months, years).
Others, typically for economical reasons, may wish to be allowed
request services dynamically and to avoid paying for them even
not in use. The extreme case of short-term service is that in
the client wants to send one urgent datagram, but this is
best handled by a service broker ("the datagraph office") using
permanent setup shared by many (or all) urgent datagrams. In
other cases, a request for a short-term or medium-term service
be processed by the server before the client is allowed to
that service (i.e., to send messages). Certain applications
need the setup time to be short or, in any case, bounded: the
time the client will have to wait for a (positive or negative)
to a request may have to be guaranteed by the server in the contract
5. Translating
Performance specifications and other requirements are assigned at
top level, that of the human client or application, either
or implicitly (see Section 2). To be satisfied, these
need the support of all the underlying layers: we believe that
real-time service cannot be implemented on top of a server at
level that is unable to guarantee performance. (Some of the
requirements can be satisfied even without this condition:
example, reliable delivery (when retransmission is acceptable)
sequencing.) Upper-level requirements must be translated
lower-level ones, so that the implementation of the former will
adequately supported. How should this be done
5.1 Delay
The method for translating delay bounds macroscopically depends
the type of bound to be translated. All methods have to deal
two problems: the effects of delays in the individual layers, and
effects of message fragmentation on the requirements
(i) Deterministic delay bound. A deterministic bound on the
Ferrari [Page 12]
RFC 1193 Requirements for Real-Time Services November 1990
encountered by a message in each layer (or group of layers)
the hosts will have to be estimated and enforced
The delay bound for a server at a given level will be
by subtracting the delay bounds of the layers above it in
the sending and the receiving host from the original
bound
Dmax' = Dmax - SUMi {d(max,i)}.
Message fragmentation can be handled by recalling that delay
defined as the difference between the instant of completion of
reception of a message and the instant when its shipment began
If x is the interfragment time (assumed constant for
here) and f is the number of fragments in a message, we
Dmax' = Dmax - x(f-1),
where Dmax' is the fragment delay bound corresponding to
message delay bound Dmax, i.e., the delay of the first fragment
(ii) Statistical delay bound. The statistical case is
complicated. If the bounds on the delay in each
(or group of layers) are statistical, we may approach
problem of the messages delayed beyond the
pessimistically, in which case we shall
Zmin' = Zmin / (PRODi {z(min,i)}),
where the index i spans the layers (or group of layers) above
given lower-level server, Zmin' is the probability bound to
enforced by that lower-level server, and d(max,i) and z(min,i)
the bounds for layer i. (A layer has a sender side and a
side at the same level in the hierarchy.) The expression
Zmin' is pessimistic because it assumes that a message
beyond its bound in a layer will not be able to meet the
bound Dmax. (The expression above and the next one assume
the delays of a message in the layers are
independent of each other. This assumption is usually not valid
but, in the light of the observations that follow the
expression, the error should be tolerable.)
At the other extreme, we have the optimistic approach,
assumes that a message will not satisfy the global bound only
it is delayed beyond its local bound in each layer
Zmin' = 1 - (1 - Zmin)/(PRODi {1 - z(min,i)}).
Ferrari [Page 13]
RFC 1193 Requirements for Real-Time Services November 1990
The correct assumption will be somewhere in between
pessimistic and the optimistic ones. However, in order to be
to guarantee the global bound, the system will have to choose
pessimistic approach, unless a better approximation to reality
be found. An alternative that may turn out to be more
is the one of considering the bounds in the layers
deterministic, in which case Zmin' will equal Zmin, and the
bound will be statistical only because the network will
a statistical bound
When estimating the effects of message fragmentation, the
bounds must refer to the fragment stream as though its
were independent of each other. Assuming sequential delivery
fragments, a message is delayed beyond its bound if its
fragment is delayed beyond the fragment bound. Our goal can
achieved by imposing the same probability bound on fragments as
messages [Verm90]. Thus
Zmin' = Zmin
Note that both expressions for D prime sub max given in (i)
apply to the statistical delay bound case as well
(iii) Deterministic delay-jitter bound. For the case of layer
layer translation, the discussion above yields
Jmax' = Jmax - SUMi {j(max,i)} ,
where j(max,i) is the deterministic jitter bound of the i-th
above the given lower-level server. When messages are fragmented
the delay jitter bound can be left unchanged
Jmax' = Jmax .
There would be reasons to reduce it in the case of
fragmentation only if the underlying server did not
sequenced delivery, and if no resequencing of fragments
provided by the corresponding reassembly layer on the
side
(iv) Statistical delay-jitter bound. The interested reader
be able with little effort to derive the translation
for this case from the definition in Section 3.1 (iv
and from the discussion in (ii) and (iii) above
Ferrari [Page 14]
RFC 1193 Requirements for Real-Time Services November 1990
5.2 Throughput
Since all layers are in cascade, the throughput bounds would be
same for all of them if headers and sometimes trailers were not
at each layer for encapsulation or fragmentation. Thus,
bounds have to be increased as the request travels downward
the protocol hierarchy, and the server at each layer knows by
much, since it is responsible for these additions
5.3 Reliability
If we assume, quite realistically, that the probability of
loss in a host is extremely small, then we do not have to change
value of Wmin when we change layers
The effects of message fragmentation are similar to those
statistical delay bounds, but in a given application a message may
lost even if only one of its fragments is lost. Thus, we
Wmin' = 1 - (1 - Wmin)/f ,
where Wmin' is the lower bound of the correct delivery
for the fragment stream, and f is the number of fragments
message. The optimistic viewpoint, which is the one we adopted
Section 5.1 (ii), yields Wmin' = Wmin, and the observations made
that section about the true bound and about providing
apply
5.4 Other
Of the requirements and desiderata discussed in Section 4, those
are specified as a Boolean value or a qualitative attribute do
have to be modified for lower-level servers unless they are
in some layer above those servers (e.g., no sequencing is to
required below the level where a resequencer operates). When
are represented by a bound (e.g., one on the setup time, as
in Section 4.4), then bounds for the layers above a lower-
server will have to be chosen to calculate the corresponding
for that server. The above discussions of the translation
performance requirements will, in most cases, provide the
techniques for doing these calculations
The requirement that the server give clear and useful replies
client requests (see Section 2) raises the interesting problem
reverse translation, that from lower-level to upper-
specifications. However, at least in most cases, this does not
to be a difficult problem: all the translation formulas we
written above are very easily invertible (in other words, it
Ferrari [Page 15]
RFC 1193 Requirements for Real-Time Services November 1990
straightforward to express Dmax as a function of Dmax', Zmin as
function of Zmin', and so on).
6.
In this section we describe some examples of client requirements
real-time services. Simplifying assumptions are introduced
decrease the amount of detail and increase clarity. Our intent is
determine the usefulness of the set of requirements proposed above
and to investigate some of the problems that may arise in
cases. An assumption underlying all examples is that the network'
transmission rate is 45 Mbits/s, and that the hosts can keep up
this rate when processing messages
6.1 Interactive
Let us assume that human clients are to specify the requirements
voice that is already digitized (at a 64 kbits/s rate) and
(packet size: 48 bytes, coinciding with the size of an ATM cell
packet transmission time: 8.53 microseconds ; packet
time: 6 ms). Since the communication is interactive,
(and statistical) delay bounds play a very important role. Jitter
also important, but does not dominate the other requirements as
non-interactive audio or video communication (see Section 6.2).
minimum throughput offered by the system must correspond to
maximum input rate, i.e., 64 kbits/s; in fact, because of
overhead (5 control bytes for every 48 data bytes), total
throughput should be greater than 70.66 kbits/s, i.e., 8,834 bytes/s
(Since the client may not know the overhead introduced by the system
the system may have to compute this value from the one given by
client, which in this case would be 8 kbytes/s.) The minimum
throughput over an interval as long as 100 s is 44% of Tmin, due
the silence periods [Brad64].
Voice transmission can tolerate limited packet losses without
the speech unintelligible at the receiving end. We assume that
maximum loss of two packets out of 100 (each packet corresponding
6 ms of speech) can be tolerated even in the worst case, i.e.,
the two packets are consecutive. Since packets arriving after
absolute deadline are discarded if the delay bound is to
statistical, then this maximum loss rate must include losses due
lateness, i.e., 0.98 will have to be the value of Zmin Wmin
than just that of Wmin
This is illustrated in the first column of Table Ia, which
of two subcolumns: one is for the choice of a deterministic
bound, the other one for that of a statistical delay bound and
combined bound on the probability of lateness or loss. If in a
Ferrari [Page 16]
RFC 1193 Requirements for Real-Time Services November 1990
there is a single entry, that entry is the same for both subcolumns
Note that the maximum setup time could be made much longer
connections had to be reserved in advance
Since voice is packetized at the client's level, we will not have
worry about the effects of fragmentation while translating
requirements into their lower-level correspondents
6.2 Non-interactive
At the level of the client, the video message stream consists of 1
Mbit frames, to be transmitted at the rate of 30 frames per second
Thus, the throughput bounds (both deterministic and average) are
taking into account the overhead of ATM cell headers, 4.14 Mbytes/s
As in the case of interactive voice, we have two alternatives for
specification of delay bounds: the first subcolumn is for
deterministic bound case, the second for that of a statistical
on delays and a combined probability bound on lateness or loss;
latter bound is set to at most 10 frames out of 100, i.e., three
of 30. However, the really important bound in this case is the
on delay jitter, set at 5 ms, which is roughly equal to half of
interval between two successive frames, and between 1/4 and 1/5
the transmission time. This dominance of the jitter bound is
reason why the other delay bounds are in parentheses
If we assume that video frames will have to be fragmented into
at some lower level in the protocol hierarchy, then
requirements must be translated at that level into those shown in
first column of Table II. The values of Dmax' have been
with x = 12.8 microseconds and f = 2605 fragments/frame. The
of Wmin' and of (Zmin Wmin)' is quite wide, and achieving its
value (a probability of 1) may turn out to be either very
or impossible. We observe, however, that a frame in which a
or more are missing or have been incorrectly received does not
to be discarded but can be played with gaps or patched with the
packets in lieu of the missing or corrupted ones. Thus, it may
possible to consider an optimistic approach (e.g., Zmin' = Zmin
Wmin' = Wmin, (Zmin Wmin)' = Zmin Wmin ) as sufficiently safe
6.3 Real-time
A real-time datagram is, for instance, an alarm condition to
transmitted in an emergency from one machine to another (or a
of others) in a distributed real-time system. The
requirements in this case are very simple: a deterministic bound
needed (we are assuming that this is a hard-real-time context),
reliability of delivery must be very high, and the service setup
should be very small. The value of 0.98 for Wmin in Table Ib
Ferrari [Page 17]
RFC 1193 Requirements for Real-Time Services November 1990
to account for the inevitable network errors and to suggest
retransmission should not be used as might be necessary if we
to have Wmin = 1, because it would be too slow. To
reliability in this case, error correcting codes or
redundancy will have to be resorted to instead
Note that one method for obtaining a very small setup time
of shipping such urgent datagrams on long-lasting
previously created between the hosts involved and with
appropriate characteristics. Note also that throughput
cannot be defined, since we are dealing with one small message only
which may not even have to be fragmented. Guarantees on the
bounds will fully satisfy the needs of the client in this case
6.4 File
Large files are to be copied from a disk to a remote disk. We
that the receiving disk's speed is greater than or equal to
sending disk's, and that the transfer could therefore proceed, in
absence of congestion, at the speed of the sending disk. The
size equals the size of one track (11 Kbytes, including disk
overhead such as intersector gaps), and the maximum input rate
5.28 Mbits/s. Taking into account the ATM cell headers, this
becomes 728 kbytes/s; this is the minimum peak throughput to
guaranteed by the system. The minimum average throughput to
provided is smaller, due to head switching times and setup
(seek times are even longer, hence need not be considered here):
set its value at 700 kbytes/s
Delay bounds are much less important in this example than in
previous ones; in Table Ib, we show deterministic and
bounds in parentheses. Reliability must be eventually 1 to
the integrity of the file's copy. This result will have to
obtained by error correction (which will increase the
requirements) or retransmission (which would break most delay
if they were selected on the basis of the first shipment only
of the last one).
The second column in Table II shows the results of translating
requirements to account for message fragmentation. The values x =
78.3 microseconds and f = 230 have been used to compute those
Dmax'.
7.
In this section, we briefly discuss some of the objections that
be raised concerning our approach to real-time service requirements
Some of the objections are fundamental ones: they are at least
Ferrari [Page 18]
RFC 1193 Requirements for Real-Time Services November 1990
related to the basic decisions to be made in the design of the
as they are to client requirements
Objection 1: Guarantees are not necessary
This is the most radical objection, as it stems from a
disagreement with our definition of real-time service. The problem
however, is not with definitions or terminologies: the
important question is whether a type of service such as the one
call "real-time" will be necessary or at least useful in
networks. This objection is raised by the optimists, those
believe that network bandwidth will be so abundant that
will become a disease of the past, and that delays will therefore
small enough that the enforcement of legalistic guarantees will
be necessary. The history of computers and communications, however
does not unfortunately support these arguments, while it
those of the pessimists. In a situation of limited
(limited with respect to the existing demand for them), we
that there is no serious solution of the real-time
problem other than one based on a policy for the allocation
resources that rigorously guarantees the satisfaction of
needs. Even if the approaches to be adopted in practical
will provide only approximate guarantees, it is important to
methods that offer without exceptions precisely defined bounds
These methods can at the very least be used as reference
for comparison and evaluation
Objection 2: Real-time services are too expensive because
of resources is very wasteful
This may be true if resources are exclusively reserved; for example
physical circuits used for bursty traffic in a circuit-
network. There are, however, other ways of building real-
services, based on priority mechanisms and preemption rather
exclusive reservation of resources. With these schemes, the real
time traffic always finds the resources it needs by preempting non
real-time traffic, as long as the real-time load is kept below
threshold. The threshold corresponds to the point where the
by real-time traffic for the bottleneck resource equals the amount
that resource in the system. With this scheme, all resources
used by real-time traffic can be used at any time by local tasks
non-real-time traffic. Congestion may affect the latter, but
real-time traffic. Thus, the only limitation is that a
cannot carry unbounded amounts of real-time traffic, and must
any further requests when it has reached the saturation point
Ferrari [Page 19]
RFC 1193 Requirements for Real-Time Services November 1990
Objection 3: Real-time services can be built on top of non-real-
servers
If one accepts our interpretation of the term "guarantee," one
easily see that performance guarantees cannot be provided by
higher-level server unless it can rely on real-time support by
underlying server. Since this is true at all levels, we
that a real-time network service and similar services at
intermediate levels are needed to provide guaranteed performance
human clients and applications
Objection 4: Delay bounds are not necessary, throughput
suffice
Guaranteeing minimum throughput bounds does not automatically and
general result in any stringent upper bound on delay. Delays in
hosts and nodes of a packet-switching network fluctuate because
bursty real-time message streams, starting and ending of traffic
individual connections (even those with continuous, constant-
traffic), and the behavior of scheduling algorithms. Even if
did not fluctuate, but had a constant value, it would be possible
a given throughput bound to be satisfied with many different
values for the delay of each message. If delay bounds are wanted
they must be explicitly guaranteed and enforced. (In a circuit
switching network, the circuit assigned to a connection has its
throughput and its own delay. These values may be considered
explicitly guaranteed and enforced.)
But are delay bounds wanted? We believe they are in digital
and audio communication, especially in the form of delay
bounds, and they will be in other contexts as soon as a service
can bound delays is offered
Objection 5: Satisfaction of statistical bounds is impossible
verify
Strictly speaking, this objection is valid. No matter how
packets on a connection have been delayed beyond their bound (or
or delivered with errors), it is always in principle possible for
server to redress the situation in the future and meet the
statistical requirements. A more sensible and verifiable bound
be a fractional one (see Section 3). For instance, such a
could be specified as follows: out of 100 consecutive packets,
less than 97 shall not be late. In this case, the bound is no
Zmin, a probability of 0.97, but is given by the two values B = 97
and A = 100; it is not only their ratio that counts but also
individual values
Ferrari [Page 20]
RFC 1193 Requirements for Real-Time Services November 1990
8.
This paper has presented a specification of some of the
that human clients and applications may wish to impose on real-
communications. Though those listed seem to be among the most
and natural ones, no attempt has been made to be exhaustive
comprehensive
We have investigated delay bounds, throughput bounds,
bounds, and other requirements. We have studied how the
should be translated from the client's level into forms suitable (
correct) for lower levels, described some examples of
specification, and discussed some of the objections that may
raised
The material in this paper covers only part of the first phase in
design of a real-time service: that during which the
requirements are assembled and examined to extract useful
for the design of the server. Server needs and design
will be the subject of the subsequent paper mentioned several
above
Ralf Herrtwich and Dinesh Verma contributed ideas to, and
mistakes in, a previous version of the manuscript. The author
deeply indebted to them for their help and for the many
he had with them on the topics dealt with in this paper.
comments of Ramesh Govindan and Riccardo Gusella are also
acknowledged
[Brad64] Brady, P., "A Technique for Investigating On-Off
of Speech", Bell Systems Technical Journal, Vol. 44,
Pgs. 1-22, 1964.
[Ferr89a] Ferrari, D., "Real-Time Communication
Packet-Switching Wide-Area Networks", Technical
TR-89-022, International Computer Science Institute
Berkeley, May 1989.
[Ferr89b] Ferrari D., and D. Verma, "A Scheme for Real-Time
Establishment in Wide-Area Networks", IEEE J.
Areas Communications SAC-8, April 1990.
[Gait90] Gaitonde, S., D. Jacobson, and A. Pohm, "Bounding Delay
a Multifarious Token Ring Network", Communications of
Ferrari [Page 21]
RFC 1193 Requirements for Real-Time Services November 1990
ACM, Vol. 33, No. 1, Pgs. 20-28, January 1990.
[Herr89] Herrtwich R., and U. Brandenburg, "Accessing
Customizing Services in Distributed Systems",
Report TR-89-059, International Computer Science Institute
Berkeley, October 1989.
[Herr90] Herrtwich, R, personal communication, February 1990.
[Verm90] Verma, D., personal communication, February 1990.
Table
Examples of Client
Interactive Non-
Voice
Delay
deterministic:Dmax [ms] 200 - (1000) -
statistical:Dmax [ms] - 200 - (1000)
Zmin - (*) - (*)
jitter:Jmax [ms] 1 5
Throughput
deterministic:Tmin [kby/s] 8.834 4140
average:Tave [kby/s] 3.933 4140
I [s] 100 100
Reliability Bound:Wmin 0.98 (*) (0.90) (*)
Delay&Reliability:ZminWmin - 0.98 - 0.90
Sequencing yes
Absence of Duplications yes
Failure Recovery
max.repair time [s] 10 100
Max.Setup Time [s] 0.8 (o) 15 (o
----------------------------------
(*) To be chosen by the
(o) Could be much longer if advance reservations were
(+) Could be achieved by using a preexisting
Ferrari [Page 22]
RFC 1193 Requirements for Real-Time Services November 1990
Table
Examples of Client
Real-Time
Datagram
Delay
deterministic:Dmax [ms] 50 - (1500)
statistical:Dmax [ms] - (1000) -
Zmin - (0.95) -
jitter:Jmax [ms] - -
Throughput
deterministic:Tmin [kby/s] - 728
average:Tave [kby/s] - 700
I [s] - 100
Reliability Bound:Wmin 0.98 1
Delay&Reliability:ZminWmin - -
Sequencing -
Absence of Duplications yes
Failure Recovery
max.repair time [s] - 100
Max.Setup Time [s] 0 (+) 5 (o
----------------------------------
(*) To be chosen by the
(o) Could be much longer if advance reservations were
(+) Could be achieved by using a preexisting
Ferrari [Page 23]
RFC 1193 Requirements for Real-Time Services November 1990
Table
Translation of the Requirements in Table
Non-Interactive
Video
Delay
deterministic:Dmax' [ms] (966) - - (1482)
statistical:Dmax' [ms] - (966) (982) -
Zmin' - (*) (0.95) -
jitter:Jmax' [ms] 5 -
Reliability Bound:Wmin' 0.90-1 (*) 1
Delay&Reliability:(ZminWmin)' - 0.90-1 -
_____________________________________
(*) To be chosen by the
Security
Security considerations are not discussed in this memo
Author's
Domenico
University of
Computer Science
EECS
Berkeley, CA 94720
Phone: (415) 642-3806
EMail: ferrari@UCBVAX.BERKELEY.
Ferrari [Page 24]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
