RFC 1193
Client requirements for real-time communication services
RFC 1193: CLIENT REQUIREMENTS FOR REAL-TIME COMMUNICATION SERVICES 🎀
Okay bestie, this is RFC 1193 💖 It's from the Network Working Group, written by D. Ferrari at UC Berkeley, and dated November 1990. It's an informational memo, not a standard ✨ The header doesn't list any RFC that it obsoletes or updates, so there's nothing to tag there 🫶
Status of this Memo ✨
Okay so this memo describes client requirements for real-time communication services 🦋 It's giving "here's the info, everyone chime in," because it provides information for the Internet community and asks for discussion and suggestions for improvements 🗣️ It does not specify any standard 💅 Distribution of this memo is unlimited, so share away 🌸
Abstract 🦋
The big idea: a real-time communication service lets its clients specify their performance requirements AND get guarantees that those requirements will be satisfied 💜 In this paper the author proposes a set of performance specifications that seem appropriate for these services (think delay bounds, throughput bounds, and reliability bounds 📈) It also covers other requirements and desirable properties from the client's viewpoint, plus how each requirement gets translated so it works for the lower levels in the protocol hierarchy 🧚 Last but not least, there are examples of requirements specifications and a discussion of some possible objections to the approach 👀
This research was supported in part by AT&T Bell Laboratories, the University of California under a MICRO grant, and the International Computer Science Institute 🙏 The views and conclusions in this document are those of the author and should not be interpreted as representing official policies, either expressed or implied, of any of the sponsoring organizations 🫶
1. Introduction 💅
We call something real-time when it's a computer communication service whose clients are allowed to specify their performance requirements and to obtain guarantees about the fulfillment of those requirements ⏱️
Three terms in that definition need some extra explaining: clients, performance, and guarantees 🎀
Network architecture usually looks like a stack of protocol layers, at least logically 🥞 The client and server idea applies to lots of different pairs: every layer, with help from the layers under it, provides a service to the layer right above it, and is a client of its underlying layers 🧩 In this paper our thoughts generally apply to any client-server pair. However, most of them especially refer to human clients (users, programmers) and to the ways those clients express their communication and processing needs to the system (e.g., interactive commands, application programs) 💌 This type of client is super important, because client needs at lower layers can be seen as translations of the needs expressed by human clients at the top of the hierarchy 👑 When the client is human, the server is the entire (distributed) system, including the hosts, their operating systems, and the networks interconnecting them 🖥️
As for the generic term, performance, we give it a pretty broad meaning 📊 It includes not just delay and throughput (the two main network performance indices) but also reliability of message delivery 💖 Real-time communication is concerned with the parts of quality of service that have to do with performance in this broad sense ✨
The term guarantee has a rather strong legal flavor ⚖️ When a server guarantees a given level of performance for a client's communications, it commits to providing that performance AND to paying appropriate penalties if the actual performance turns out to be insufficient 💸 The client, on the other hand, has to obey certain rules, and won't be entitled to the requested performance guarantees unless those rules are scrupulously obeyed 🙃 In other words, client and server enter into a contract spelling out their respective rights and duties, the benefits that will accrue, the conditions under which those benefits will materialize, and the penalties they'll incur for not keeping their mutual promises 📜 We believe a legal viewpoint is to be adopted if serious progress in the delivery of communication services (not only the real-time ones) is desired 🙌 Utility services, as well as other kinds of service, are provided under legally binding contracts, and a mature computer communication utility cannot fail to do the same 💅 In the field of real-time communication, that contract will by definition include performance guarantees 🫶
Real-time services may be offered in any kind of network or internetwork 🌐 Some of their predictable applications are:
- (a) digital continuous-media (motion video, audio) communication: lower bounds on throughput and upper bounds on delay or delay variability or both are needed to ensure any desired level of output quality; in the interactive case, both the values of delay and delay variabilities have to be bounded; some limited message losses are often tolerable in the cases of video and voice (whenever very high quality is not required), but usually not in the case of sound 🎶
- (b) transmission of urgent messages in real-time distributed systems: delay bounds are the important guarantees to be provided in these applications; losses should ideally be impossible 🚨
- (c) urgent electronic-mail messages and, more in general, urgent datagrams: again, delay is the obvious index to be bounded in this case, but small probabilities of losses can often be tolerated 📨
- (d) transfers of large files: minimum throughput bounds are usually more important than delay bounds in this application; also, all pieces of a file must be delivered with probability 1 📁
- (e) fast request-reply communication: e.g., data base queries, information retrieval requests, remote procedure calls; this is another case in which delay (more precisely, round-trip delay) is the index of primary interest; reliability requirements are generally not very stringent 🏃♀️
We conjecture (aka we're calling it now 🔮) that when networks start offering well-designed and reasonably-priced real-time services, the use of those services will grow beyond the expectations of most observers 📈 This will mainly happen because new performance needs will be induced by the availability of guaranteed-performance options 💫 As the history of transportation and communication has repeatedly shown, faster services bring about major increases in the shipments that are perceived as urgent 🚚 It'll be even more obvious whenever the quality of service provided to non-real-time clients deteriorates 😬 From this comment it is clear that we assume real-time services will coexist within the same networks and internetworks with non-real-time communications 🤝 Honestly, postulating a world where the two types of service are segregated rather than integrated would be unrealistic, since it would go against the clear trend toward the eventual integration of all information services 🌈 For the same reason, the traffic in the network is assumed to be 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 uncompressed continuous fixed-rate streams to very short and erratic bursts of information) 💥
This paper discusses the client requirements and characteristics of a real-time communication service 📝 Server requirements and design principles will be the subject of a subsequent paper 🔜 Section 2 contains some considerations about the ways clients specify their requirements, and the ways a server should reply to requests for real-time services 💌 Performance requirements are presented in Section 3; other properties that clients may need or desire are described in Section 4 🎀 Section 5 deals with the problem of translating the requirements of a human client or an application into the equivalent lower-level ones 🧃 In Section 6, we briefly present four examples of client requirement specifications, and in Section 7 we discuss some of the objections that can be raised against our approach 🔍
2. Client Requests and Server Replies 👑
No real-time service can be provided if the client doesn't specify, together with the requirements, the characteristics of the expected input traffic 📥 Describing input traffic and all the various requirements takes a lot of work on the client's part 😭 Gathering the necessary information and inputting it may be very time-consuming. A well-designed real-time communication service will minimize the effort the client has to spend 🫶
Sensible default values, the possibility of partial or incremental specifications (e.g., by editing preexisting specifications), and a number of standard descriptions should be provided 💅 These descriptions will include characterizations of inputs (e.g., those of a video stream for multimedia conferencing, an HDTV stream, a hi-fi audio stream, a file transfer stream, and so on) and standard sets of requirements ✨ With these aids, it might be possible for a human client to specify their request by a short phrase, perhaps followed by a few characters representing options or changes to the standard or default values 🍓
Since requests for real-time services may be denied because of a mismatch between the client's demands and the resources available to the server, the client will appreciate being informed about the reasons for any rejection 🙏 That way the request can be modified and resubmitted, postponed, or cancelled altogether [Herr89] 📨 The information provided by the server to a human client should be meaningful, useful, and non-redundant 🧠 The reason for rejection should be understandable by the client (who should be assumed not to know any of the details of the operating system, of the protocols, or of the network), and should be accompanied by data that will be useful to the client in deciding what to do, as well as how the request ought to be modified to make it successful 🔧 For example, if a bound specified by the client cannot be guaranteed by the server under its current load, the information returned should include the minimum or maximum value of the bound that the server could guarantee 📊 The client can then decide whether that bound (possibly with some other modifications as well) would be acceptable, 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 that just described [Herr89] 🤖 Another standard interface, the one between 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 implemented by the server 💸 These should be fair (or at least perceived to be fair) and easy to understand 🥹 The client should be able easily to estimate charges for given performance guarantees as a function of distance, time of day, and other variables, or to obtain these estimates from the server as a free off-line service 🎁
3. Performance Requirements ✨
okay bestie, now we're getting to the good stuff 🎀 A client can write a service requirement in the general form:
pred = TRUE,where some of the variables in predicate pred can be controlled or influenced by the server. so the server gets a say in the numbers 👀
A simple and popular kind of performance requirement is one with a bound 💖. A deterministic bound looks like this:
(var <= bound) = TRUE, or var <= bound,Here var is server-controlled, while bound is client-specified. These bounds are upper bounds. Swap the < for a > and they turn into lower bounds 🔄
When the variable is a probability, we get a statistical bound, and the bound in that case is a probability bound. If the predicate is a deterministic bound, it looks like:
Prob (var <= bound) >= probability-bound.In this one, the variable gets an upper bound and the probability gets a lower bound. Also, deterministic bounds can be seen as statistical bounds that are satisfied with probability 1 💅
Then there's the fractional bound, which is very giving statistical bound energy:
Ca (var <= bound) >= b,var has a value for each message in a stream, and Ca is a function that counts how many times var satisfies the bound over any a consecutive messages in the stream. This number Ca must satisfy bound b. obviously, a fractional bound is only realizable if b <= a. 🙃 we won't be calling out fractional bounds explicitly later on, but they can be used in lieu of statistical bounds, and they have the advantages of being easy to verify and of higher practical interest 🫶
In this section, we're only looking at the requirements that are most likely to be useful to real-time clients 🦋
3.1 Delay requirements
Depending on the app, clients might want to specify their delay requirements in different ways [Gait90] 🧚 The delays involved will usually be the ones for application-oriented messages the client knows about. For example, the delay between the start of the client-level transmission of a video frame, file, or urgent datagram and the end of the client-level reception of that same frame, file, or urgent datagram.
(In those cases, like some distributed real-time systems where message deadlines get assigned instead of message delays, we can always compute the delays from knowing the deadlines and the sending times. That brings us right back to a delay bound requirement 🔁)
Also, these are the delays of messages that get successfully delivered to the destination. The fraction of messages that don't make it, which the delay bounds won't apply to, gets bounded by reliability specifications.
Note that clients express delay bounds by implicitly referring to their own clocks. So the design of a real-time service for a large network has to think about how non-synchronized clocks affect bounds enforcement [Verm90] ⏰
Some of the forms a delay requirement can take are:
(i) deterministic delay bound:
Di <= Dmax for all i,the client is delivered to the destination client-level entity, and Dmax is the delay upper bound specified by the client. In our descriptions we assume, without loss of generality, that the client requesting a real-time service is the sending client, and that the destination (which could be a remote agent of the client or another user) is a third party with respect to the establishment of the particular communication being considered (In our descriptions we assume, without loss of generality, that the client requesting a real-time service is the sending client, and that the destination (which could be a remote agent of the client or another user) is a third party with respect to the establishment of the particular communication being considered.);
(ii) statistical delay bound:
Prob ( Di <= Dmax ) >= Zmin,where Di and Dmax are defined as above, and Zmin is the lower 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 of the i-th message delivered to the destination, and Jmax is the upper jitter bound to be specified by the client together with D. Note that an equivalent form of this requirement is assigning a deterministic upper bound D + Jmax and a deterministic 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 be within its limits.
Other forms of delay bound include bounds on average delay, delay variance, and functions of the sequence number of each message, for example, Dmax(i) for the deterministic case. There might be apps where one of these is the preferred form. But since we haven't found any so far, we believe the four types listed as (i)-(iv) above will cover the great majority of practical cases 💜
3.2 Throughput requirements
The actual throughput of an information transfer from a source to a destination is bounded above by the rate at which the source sends messages into the system. Throughput can be lower than this rate because of unsuccessful delivery or message loss. It's also bounded above by the maximum throughput, which depends on things like network load 📈
As the source increases its input rate, the actual throughput grows up to a limit and then stops. Clients who care about throughput will want to make sure saturation is never reached, or is only reached with a suitably small probability and for acceptably short intervals 😤
Also, if the bandwidth allocated to a transfer isn't constant, but changes dynamically on demand to handle, at least to some extent, peak requests, clients will be interested in adding an average throughput requirement. That requirement should include info about the length of the interval over which the average must be computed [Ferr89a] 🍓
So, reasonable forms for throughput requirements look like this:
(i) deterministic throughput bound:
Ti >= Tmin, for all i,where Ti is the throughput actually provided by the server, and Tmin is the lower bound of throughput specified by the client. That's the minimum throughput the server must offer to the client 🫡
(ii) statistical throughput bound:
Prob (Ti >= Tmin) >= Vmin,where Ti and Tmin are defined as above, and Vmin is the lower bound of the probability that the server will provide a throughput greater than the lower bound;
(iii) average throughput bound:
T >= Tave,where T is the average throughput provided by the server, Tave is its lower bound specified by the client, and both variables are averaged over an interval of duration I specified by the client. The above inequality must obviously hold for all intervals of duration I, i.e., even for the one over which T is minimum 🧐
One clear difference between delay bounds and throughput bounds: while the server is responsible for delays, the actual throughputs of a non-saturated system are dictated by the input rates. Those are determined primarily by the clients (though the server can influence them through flow-control mechanisms) 🔥
3.3 Reliability requirements
ngl, the usefulness of error control via acknowledgments and retransmission in real-time apps is kinda doubtful 💀 This is especially true in environments where message losses are usually higher, like wide-area networks. The extra delays from acknowledgment, retransmission, and out-of-sequence delivery are likely to be intolerable in apps with stringent delay bounds, like ones dealing with continuous media.
Thankfully, losing some messages (like video frames or voice packets) is often tolerable in these apps. Losing sound packets, though, is generally intolerable 🔊 In other cases, completeness of information delivery is essential (for example, in file transfer apps), and traditional retransmission schemes will probably have to be used there 📁
A message may be incorrect when delivered, or it may be lost in the network, meaning it's not delivered at all. Network unreliability (due to noise, for example) is usually the cause of the former. Buffer overflow (from congestion), or node or link failure, cause the latter. The client doesn't care about this distinction. For the client, the message is lost in both cases 🙅♀️ So the simplest form a reliability bound can take, and also, we believe, the one that'll be most popular, is:
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 will obviously be bounded above by 1 - Wmin. This is a statistical bound, but, as noted in Section 3, a deterministic reliability bound results if we set Wmin = 1 💖
In apps where any message delivered with a delay greater than Dmax must be discarded, the fraction of messages usable by the destination will be bounded below by Wmin Zmin. The client may actually specify the value of this product, and let the server decide the individual values of the two bounds. That decision can be subject to a client-assigned constraint, e.g., that the price of the service to the client be minimum 💸
If the value of Wmin is greater than the system's reliability (the probability that a delivered message is correct), then there's no buffer space allocation in the hosts, interfaces, switches, routers or gateways that will let the client-specified Wmin be guaranteed. In this case, the server uses error correcting codes, or (if the app permits) retransmission, or duplicate messages, or (if the sequencing problem discussed in Section 4.1 can be solved satisfactorily or isn't a problem) multiple physical channels for the same logical channel, or has to refuse the request 🙈
4. Other Required or Desirable Properties 🌈
In this section, we briefly describe client requirements that can't be easily expressed as bounds, but are still related to communication performance. These include sequencing, absence of duplications, failure recovery, and service setup time. We're not concerned here with features that might be super important but have a functionality (like multicast capabilities) or security (like client authentication) rather than a performance flavor. Requirements in those areas will generally have appreciable effects on performance too, but we don't discuss them only because of space limitations 🧸
For a given app, some of these properties may be required, and some others only desirable. Also, some may be best represented as Boolean variables (present or absent), some others as continuous or multi-valued discrete variables, and others yet as partially qualitative specifications ✨
4.1. Sequencing ✨
okay so, for message streams (not single datagrams 📨), it may be necessary or desirable that messages get delivered in sequence, even if the sequence isn't complete yet 🧵. If not every lower-level server can deliver messages in order, a resequencing step may have to happen at some higher level in the hierarchy. And when reliability requirements make retransmission necessary, resequencing can delay a bunch of messages by pretty long times 😭. So an adequate amount of buffer space will have to be provided for that at the resequencer's level in the protocol hierarchy 🧺.
If sequencing isn't guaranteed by all servers at all levels, the application may be able to tolerate out-of-sequence messages as long as there aren't many of them, or if the delay bound is so big that very few out-of-sequence messages get tossed for being too late 🙈. The client could be allowed to specify a bound on the probability that a message is delivered out of sequence, or to bundle out-of-sequence losses with the other types of message loss described 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 for buffer overflow, how much for network error, and how much for imperfect sequencing, taking into account how strict the delay bounds are 💅.
On the other hand, with fixed-route connections and appropriate queueing and scheduling in the hosts and in the network, it's often not too hard to ensure sequenced delivery at the various layers, which means also at the top 👑.
4.2. Absence of duplications 🦋
Most of the sequencing tea applies to duplication of messages too 🫖. It is, however, easier and faster to eliminate duplications than to resequence, as long as some layer keeps track of the sequence numbers of the messages already received. The specification of a bound may be needed only if duplications become very frequent, but this would be a symptom of serious network malfunction, and should not be dealt with in the same way as we handle delays or message losses 🚨. These observations do not apply, of course, to the case of intentional duplication for higher reliability.
4.3. Failure recovery 🛠️
The contract between client and server of a real-time service will have to specify what will happen in the event of a server failure 📜. Ideally, from the client's viewpoint, failures should be perfectly masked, and service should be completely fault-tolerant 🛡️. As we have already mentioned, however, it is usually unrealistic to expect that performance guarantees can be honored even in the presence of failures 😤. A little less unrealistic is to assume that service can resume a short time after a failure has disrupted it. In general, clients may not only wish to know what will happen if a failure occurs, but also have a guaranteed upper bound on the likelihood of such an occurrence:
Prob (failure) <= Fmax.Different applications have different failure recovery requirements. Urgent datagrams or urgent message streams in most real-time distributed systems will probably not benefit much from recovery, unless it can be made so fast that hard deadlines may still be satisfied, at least in some cases ⏱️. In the case of video or audio transmission, timely resumption of service will normally be super useful or even necessary; thus, clients may need to be given guarantees about the upper bounds of mean or maximum time to repair. This may also be the case for other applications in which the deadlines are not so stringent, or where the main emphasis is on throughput and/or reliability rather than on delay 🎬.
In communications over multi-node routes and/or long distances, the network itself may contain several messages for each source-destination pair at the time a failure occurs 🌍. The recovery scheme will have to solve the problems of failure notification (to all the system's components involved, and possibly also to the clients) and disposition of messages in transit 📬. The solutions adopted may make duplicate elimination necessary even in contexts in which no duplicates are ever created in the absence of failures 🫠.
4.4. Service setup time 🎟️
Real-time services must be requested before they can be used to communicate [Ferr89b]. Some clients may be interested in long-term arrangements which are set up soon after the signing of a contract and are kept in existence for long times (days, months, years) 📆. Others, typically for economical reasons, may wish to be allowed to request services dynamically and to avoid paying for them even when not in use 💸. The extreme case of short-term service is that in which the client wants to send one urgent datagram, but this is probably best handled by a service broker ("the datagraph office") using a permanent setup shared by many (or all) urgent datagrams 📮. In most other cases, a request for a short-term or medium-term service must be processed by the server before the client is allowed to receive that service (i.e., to send messages) 🙅. Certain applications will need the setup time to be short or, in any case, bounded: the maximum time the client will have to wait for a (positive or negative) reply to a request may have to be guaranteed by the server in the contract ⏳.
5. Translating Requirements 🔁
Performance specifications and other requirements are assigned at the top level, that of the human client or application, either explicitly or implicitly (see Section 2) 🧑💻. To be satisfied, these specifications need the support of all the underlying layers: we believe that a real-time service cannot be implemented on top of a server at some level that is unable to guarantee performance 🙅. (Some of the other requirements can be satisfied even without this condition: for example, reliable delivery (when retransmission is acceptable) and sequencing.) Upper-level requirements must be translated into lower-level ones, so that the implementation of the former will be adequately supported. How should this be done? 🤔
5.1. Delay requirements ⏰
The method for translating delay bounds macroscopically depends on the type of bound to be translated. All methods have to deal with two problems: the effects of delays in the individual layers, and the effects of message fragmentation on the requirements 🧩.
(i) Deterministic delay bound. A deterministic bound on the delay encountered by a message in each layer (or group of layers) in the hosts will have to be estimated and enforced. The delay bound for a server at a given level will be obtained by subtracting the delay bounds of the layers above it in both the sending and the receiving host from the original global bound:
Dmax' = Dmax - SUMi {d(max,i)}.Message fragmentation can be handled by recalling that delay is defined as the difference between the instant of completion of the reception of a message and the instant when its shipment began. If x is the interfragment time (assumed constant for simplicity here) and f is the number of fragments in a message, we have
Dmax' = Dmax - x(f-1),where Dmax' is the fragment delay bound corresponding to the message delay bound Dmax, i.e., the delay of the first fragment.
(ii) Statistical delay bound. The statistical case is more complicated. If the bounds on the delay in each layer (or group of layers) are statistical, we may approach the problem of the messages delayed beyond the bound pessimistically, in which case we shall write
Zmin' = Zmin / (PRODi {z(min,i)}),where the index i spans the layers (or group of layers) above the given lower-level server, Zmin' is the probability bound to be enforced by that lower-level server, and d(max,i) and z(min,i) are the bounds for layer i. (A layer has a sender side and a receiver side at the same level in the hierarchy.) The expression for Zmin' is pessimistic because it assumes that a message delayed beyond its bound in a layer will not be able to meet the global bound Dmax. (The expression above and the next one assume that the delays of a message in the layers are statistically independent of each other. This assumption is usually not valid, but, in the light of the observations that follow the next expression, the error should be tolerable.)
At the other extreme, we have the optimistic approach, which assumes that a message will not satisfy the global bound only if it is delayed beyond its local bound in each layer:
Zmin' = 1 - (1 - Zmin)/(PRODi {1 - z(min,i)}).The correct assumption will be somewhere in between the pessimistic and the optimistic ones. However, in order to be able to guarantee the global bound, the system will have to choose the pessimistic approach, unless a better approximation to reality can be found. An alternative that may turn out to be more convenient is the one of considering the bounds in the layers as deterministic, in which case Zmin' will equal Zmin, and the global bound will be statistical only because the network will guarantee a statistical bound.
When estimating the effects of message fragmentation, the new bounds must refer to the fragment stream as though its components were independent of each other. Assuming sequential delivery of fragments, a message is delayed beyond its bound if its last fragment is delayed beyond the fragment bound. Our goal can be achieved by imposing the same probability bound on fragments as on messages [Verm90]. Thus,
Zmin' = Zmin.Note that both expressions for Dmax' given in (i) above apply to the statistical delay bound case as well.
(iii) Deterministic delay-jitter bound. For the case of layer to 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 layer 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 message fragmentation only if the underlying server did not guarantee sequenced delivery, and if no resequencing of fragments were provided by the corresponding reassembly layer on the receiving side.
(iv) Statistical delay-jitter bound. The interested reader will be able with little effort to derive the translation formulas for this case from the definition in Section 3.1 (iv) and from the discussion in (ii) and (iii) above.
5.2. Throughput requirements 🚀
Since all layers are in cascade, the throughput bounds would be the same for all of them if headers and sometimes trailers were not added at each layer for encapsulation or fragmentation. Thus, throughput bounds have to be increased as the request travels downward through the protocol hierarchy, and the server at each layer knows by how much, since it is responsible for these additions.
5.3 Reliability requirements
Okay so, if we assume (pretty realistically!) that the chance of a message getting lost inside a host is extremely small, then we don't have to change the value of Wmin when we switch layers 🫶.
Fragmentation acts kinda like it does on statistical delay bounds, BUT, and this is the tea 🍵, in a given app a message can get lost even if only ONE of its fragments gets lost 😭. So we get:
Wmin' = 1 - (1 - Wmin)/f ,where Wmin' is the lower bound of the correct delivery probability for the fragment stream, and f is the number of fragments per message. The optimistic viewpoint (the one we picked in Section 5.1 (ii)) gives Wmin' = Wmin, and the observations made in that section about the true bound and about providing guarantees apply 💅.
5.4 Other requirements
Of the requirements and desiderata from Section 4, the ones specified as a Boolean value or a qualitative attribute don't need to be modified for lower-level servers unless they're satisfied in some layer above those servers (e.g., no sequencing is to be required below the level where a resequencer operates). When they're represented by a bound (e.g., one on the setup time, as described in Section 4.4), then bounds for the layers above a lower-level server will have to be chosen to calculate the corresponding bound for that server. The translation discussions above will, in most cases, provide the necessary techniques for doing these calculations 🧮.
The requirement that the server give clear and useful replies to client requests (see Section 2) raises an interesting problem: reverse translation, that is, going from lower-level to upper-level specifications. But at least in most cases, this doesn't seem too hard. All the translation formulas we wrote above are super easily invertible (in other words, it's straightforward to express Dmax as a function of Dmax', Zmin as a function of Zmin', and so on) 🙌.
6. Examples ✨
In this section we walk through some examples of client requirements for real-time services. Simplifying assumptions are introduced to cut down on detail and boost clarity. Our goal is to figure out how useful the set of requirements proposed above is, and to dig into some problems that might pop up in practical cases. Every example runs on one assumption: the network's transmission rate is 45 Mbits/s, and the hosts can keep up with this rate when processing messages 🚀.
6.1 Interactive voice
Let's say human clients are specifying requirements for voice that's already digitized (at a 64 kbits/s rate) and packetized (packet size: 48 bytes, coinciding with the size of an ATM cell; packet transmission time: 8.53 microseconds; packet interarrival time: 6 ms) 📞. Since the communication is interactive, deterministic (and statistical) delay bounds play a very important role. Jitter is also important, but it doesn't dominate the other requirements the way it does in non-interactive audio or video communication (see Section 6.2). The minimum throughput offered by the system must correspond to the maximum input rate, i.e., 64 kbits/s. In fact, because of header overhead (5 control bytes for every 48 data bytes), total guaranteed 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 the client, which in this case would be 8 kbytes/s.) The minimum average throughput over an interval as long as 100 s is 44% of Tmin, due to the silence periods [Brad64].
Voice can handle limited packet losses without making the speech unintelligible at the receiving end 🗣️. We assume that a maximum loss of two packets out of 100 (each packet corresponding to 6 ms of speech) can be tolerated even in the worst case, i.e., when the two packets are consecutive. Since packets arriving after their absolute deadline are discarded if the delay bound is to be statistical, this maximum loss rate must include losses due to lateness. In other words, 0.98 will have to be the value of Zmin Wmin rather than just that of Wmin 😤.
This is illustrated in the first column of Table Ia, which consists of two subcolumns: one is for the choice of a deterministic delay bound, the other one for that of a statistical delay bound and a combined bound on the probability of lateness or loss. If in a row there is a single entry, that entry is the same for both subcolumns. Note that the maximum setup time could be made much longer if connections had to be reserved in advance ⏳.
Since voice is packetized at the client's level, we won't have to worry about the effects of fragmentation while translating the requirements into their lower-level correspondents.
6.2 Non-interactive video
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 the specification of delay bounds: the first subcolumn is for the deterministic bound case, the second for that of a statistical bound on delays and a combined probability bound on lateness or loss. The latter bound is set to at most 10 frames out of 100, i.e., three out of 30. However, the really important bound in this case is the one on delay jitter, set at 5 ms, which is roughly equal to half of the interval between two successive frames, and between 1/4 and 1/5 of the transmission time. This dominance of the jitter bound is the reason why the other delay bounds are in parentheses 🙈.
If we assume that video frames will have to be fragmented into cells at some lower level in the protocol hierarchy, then these requirements must be translated at that level into those shown in the first column of Table II. The values of Dmax' have been calculated with x = 12.8 microseconds and f = 2605 fragments/frame. The range of Wmin' and of (Zmin Wmin)' is quite wide, and achieving its higher value (a probability of 1) may turn out to be either very expensive or impossible 💸. We observe, however, that a frame in which a packet or more are missing or have been incorrectly received does not have to be discarded. It can be played with gaps or patched with the old packets in lieu of the missing or corrupted ones. Thus, it may be possible to consider an optimistic approach (e.g., Zmin' = Zmin, Wmin' = Wmin, (Zmin Wmin)' = Zmin Wmin) as sufficiently safe 🌈.
6.3 Real-time datagram
A real-time datagram is, for instance, an alarm condition to be transmitted in an emergency from one machine to another (or a group of others) in a distributed real-time system 🚨. The client requirements in this case are very simple: a deterministic bound is needed (we are assuming that this is a hard-real-time context), the reliability of delivery must be very high, and the service setup time should be very small. The value of 0.98 for Wmin in Table Ib tries to account for the inevitable network errors and to suggest that retransmission should not be used, as might be necessary if we wanted to have Wmin = 1, because it would be too slow 🐢. To increase reliability in this case, error correcting codes or spatial redundancy will have to be resorted to instead.
Note that one method for obtaining a very small setup time consists of shipping such urgent datagrams on long-lasting connections previously created between the hosts involved and with the appropriate characteristics ⚡. Note also that throughput requirements cannot be defined, since we are dealing with one small message only, which may not even have to be fragmented. Guarantees on the other bounds will fully satisfy the needs of the client in this case 💖.
6.4 File transfer
Large files are to be copied from a disk to a remote disk 💾. We assume that the receiving disk's speed is greater than or equal to the sending disk's, and that the transfer could therefore proceed, in the absence of congestion, at the speed of the sending disk. The message size equals the size of one track (11 Kbytes, including disk surface overhead such as intersector gaps), and the maximum input rate is 5.28 Mbits/s. Taking into account the ATM cell headers, this rate becomes 728 kbytes/s; this is the minimum peak throughput to be guaranteed by the system. The minimum average throughput to be provided is smaller, due to head switching times and setup delays (seek times are even longer, hence need not be considered here). We set its value at 700 kbytes/s 📀.
Delay bounds are much less important in this example than in the previous ones. In Table Ib, we show deterministic and statistical bounds in parentheses. Reliability must be eventually 1 to ensure the integrity of the file's copy 🫡. This result will have to be obtained by error correction (which will increase the throughput requirements) or retransmission (which would break most delay bounds if they were selected on the basis of the first shipment only instead of the last one).
The second column in Table II shows the results of translating these requirements to account for message fragmentation. The values x = 78.3 microseconds and f = 230 have been used to compute those of Dmax'.
7. Discussion 💬✨
okay bestie, time for the spicy part 🌶️ we're going to look at some objections people could totally raise about how we're approaching real-time service requirements. some of them are lowkey foundational, like they're about the basic design choices for the server just as much as what clients need 💅
Objection 1: Guarantees are not necessary.
this one is the most radical because it comes from a full-on disagreement with how we define real-time service 😤 but the question isn't really about definitions or terminology. the real question is whether a kind of service like our "real-time" one will be necessary, or at least useful, in future networks 🔮 this objection comes from the optimists, who think network bandwidth will be so abundant that congestion becomes a disease of the past, so delays will be small enough that legalistic guarantees won't be needed. ngl the history of computers and communications doesn't really back that up 😭 it backs up the pessimists instead. when resources are limited (limited compared to how much demand there is for them), we believe there's no serious solution to the real-time communication problem except one based on an allocation policy that rigorously guarantees performance needs 🎀 even if practical networks only end up giving approximate guarantees, it's important to come up with methods that offer precisely defined bounds without exceptions ✨ at the very least, those methods can be used as reference approaches for comparison and evaluation 🧚
Objection 2: Real-time services are too expensive because reservation of resources is very wasteful.
this might be true if resources get exclusively reserved, like physical circuits used for bursty traffic in a circuit-switched network 🙈 but there are other ways to build real-time services, based on priority mechanisms and preemption instead of 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 stays below a threshold 🦋 that threshold is the point where the demand from real-time traffic for the bottleneck resource equals the amount of that resource in the system 📊 with this scheme, all resources not used by real-time traffic can be used at any time by local tasks and non-real-time traffic 🌈 congestion may affect the latter, but not real-time traffic 🛡️ so the only limitation is that a network can't carry unbounded amounts of real-time traffic, and it must refuse any further requests once it has reached the saturation point 🚫
Objection 3: Real-time services can be built on top of non-real-time servers.
if you accept our interpretation of the term "guarantee" (and you should 😤), then it's super easy to see that performance guarantees can't be provided by a higher-level server unless it can rely on real-time support from its underlying server 🧱 since this is true at all levels, we conclude that a real-time network service, plus similar services at all intermediate levels, is needed to provide guaranteed performance to human clients and applications 👑
Objection 4: Delay bounds are not necessary, throughput requirements suffice.
guaranteeing minimum throughput bounds doesn't automatically, or in general, lead to any stringent upper bound on delay 🙅♀️ delays in the hosts and nodes of a packet-switching network fluctuate because of bursty real-time message streams, traffic starting and ending on individual connections (even ones with continuous, constant-rate traffic), and the behavior of scheduling algorithms 🎢 even if delays didn't fluctuate and just had a constant value, a given throughput bound could still be satisfied with many different constant values for the delay of each message 🤷♀️ so 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 own throughput and its own delay. these values may be considered as explicitly guaranteed and enforced.)
but are delay bounds wanted? we believe they are, especially in digital video and audio communication, in the form of delay jitter bounds. and they will be in other contexts as soon as a service that can bound delays is offered 🎬🎧
Objection 5: Satisfaction of statistical bounds is impossible to verify.
ok, strictly speaking this objection is valid 😭 no matter how many packets on a connection have been delayed past their bound (or lost, or delivered with errors), it's always in principle possible for the server to make it up in the future and meet the given statistical requirements 🙃 a more sensible and verifiable bound would be a fractional one (see Section 3) 📐 for instance, it could be specified like this: out of 100 consecutive packets, no less than 97 shall not be late 💯 in this case, the bound is no longer Zmin, a probability of 0.97, but is given by the two values B = 97 and A = 100 ✨
it's not only their ratio that counts but also their individual values. that's the whole trick 🧮
8. Conclusion 🎓
okay so this paper has presented a specification of some of the requirements that human clients and applications may wish to impose on real-time communications 🌸 even though the ones listed seem like some of the most useful and natural ones, no attempt has been made to be exhaustive and comprehensive 🤍
we investigated delay bounds, throughput bounds, reliability bounds, and other requirements 💜 we studied how the requirements should be translated from the client's level into forms that are suitable (and correct) for lower levels, described some examples of requirement specification, and discussed some of the objections that may be raised 🍓
the material in this paper covers only part of the first phase in the design of a real-time service: the part where the various requirements are assembled and examined to extract useful suggestions for the design of the server 🔍 server needs and design principles will be the subject of the subsequent paper mentioned several times above 📚
Acknowledgments 🫶
Ralf Herrtwich and Dinesh Verma contributed ideas to, and corrected mistakes in, a previous version of the manuscript 💌 the author is deeply indebted to them for their help and for the many discussions he had with them on the topics dealt with in this paper 🙏 the comments of Ramesh Govindan and Riccardo Gusella are also gratefully acknowledged 🌷
References 📚
[Brad64]Brady, P., "A Technique for Investigating On-Off Patterns of Speech", Bell Systems Technical Journal, Vol. 44, Pgs. 1-22, 1964.[Ferr89a]Ferrari, D., "Real-Time Communication in Packet-Switching Wide-Area Networks", Technical Report TR-89-022, International Computer Science Institute, Berkeley, May 1989.[Ferr89b]Ferrari D., and D. Verma, "A Scheme for Real-Time Channel Establishment in Wide-Area Networks", IEEE J. Selected Areas Communications SAC-8, April 1990.[Gait90]Gaitonde, S., D. Jacobson, and A. Pohm, "Bounding Delay on a Multifarious Token Ring Network", Communications of the ACM, Vol. 33, No. 1, Pgs. 20-28, January 1990.[Herr89]Herrtwich R., and U. Brandenburg, "Accessing and Customizing Services in Distributed Systems", Technical 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.
Now for the tables, in all their glory 📋
Table Ia
Examples of Client Requirements
Interactive Non-Interactive
Voice Video
Delay Bounds
deterministic:Dmax [ms] 200 - (1000) -
statistical:Dmax [ms] - 200 - (1000)
Zmin - (*) - (*)
jitter:Jmax [ms] 1 5
Throughput Bounds
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 yes
Absence of Duplications yes yes
Failure Recovery:
max.repair time [s] 10 100
Max.Setup Time [s] 0.8 (o) 15 (o)
----------------------------------
(*) To be chosen by the server
(o) Could be much longer if advance reservations were required
(+) Could be achieved by using a preexisting connection Table Ib
Examples of Client Requirements
Real-Time File
Datagram Transfer
Delay Bounds
deterministic:Dmax [ms] 50 - (1500)
statistical:Dmax [ms] - (1000) -
Zmin - (0.95) -
jitter:Jmax [ms] - -
Throughput Bounds
deterministic:Tmin [kby/s] - 728
average:Tave [kby/s] - 700
I [s] - 100
Reliability Bound:Wmin 0.98 1
Delay&Reliability:ZminWmin - -
Sequencing - yes
Absence of Duplications yes yes
Failure Recovery:
max.repair time [s] - 100
Max.Setup Time [s] 0 (+) 5 (o)
----------------------------------
(*) To be chosen by the server
(o) Could be much longer if advance reservations were required
(+) Could be achieved by using a preexisting connection Table II
Translation of the Requirements in Table I
Non-Interactive File
Video Transfer
Delay Bounds
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 serverSecurity Considerations 🔐
okay, this is the one spot where the original keeps it short 🥺 security considerations are not discussed in this memo.
Author's Address 💌
Domenico Ferrari
University of California
Computer Science Division
EECS Department
Berkeley, CA 94720
Phone: (415) 642-3806
EMail: ferrari@UCBVAX.BERKELEY.EDU📦 where this page comes from
- ietf: rfc1193 1990-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms