The ARPA Network is rapidly proving to be a useful tool in computer communications and resource sharing. It has been proposed that the same network might also be able to support real-time processes such as audio or video communications for conferencing purposes. The degree of support of these types of processes will largely be determined by transmission bit-rates and delays.
The IMP subnetwork throughput rates (one way) average about 37 kilobits[1], therefore an external process must operate at a bit-rate below that level. This would imply some form of data compression for both audio and video transmission. Research in these areas is still in progress so these processes must be simulated at the present time.
In addition to bit-rate, system response time (system delay) is an important factor since this has direct influence on the amount of data which must be buffered in order to keep a real-time process running without discontinuities or gaps. Such delays may be caused by network loading, host loading, or an excessive number of IMP-to- IMP hops in the transmission path.
In order to get a feel for the ability of the network to support a real-time process an experiment was conducted with real-time data being sent from the UCSB SEL810-B computer, by way of the UCSB IBM 360 host, onto the ARPA Network and into a host discard socket in the UCLA IBM 360 computer. This particular data path very nearly duplicates the path which might be taken if real-time devices were attached to large scale host computers operating in their normal mode (usually timesharing). The experiment consisted of measuring the duration of gaps incurred at various process bit-rates, and buffer sizes ranging from one to eight network packets.
Earlier experiments at MIT[2] simulated vocoded speech transmission over the ARPA Network using the TX-2 computer and "Fake host 3" in a destination IMP. Speech was sampled by the TX-2 and simulated speech data blocks were sent to a particular fake host. Receipt of an acknowledgment by TX-2 indicated that the corresponding blocks of speech data could be reconstituted. Experiments were conducted with bit-rates from 2400-17000 bps and varying block sizes (depending on
Pfeifer & MacAfee [Page 1]
RFC 508 Real-Time Data Transmission On The Arpanet 7 May 1973
the number of hops), and conclusions were reached that with delay characteristics similar to a lightly loaded ARPA Network speech communications could be satisfactory from a human-factors standpoint.
II. CONFIGURATION
Data for this experiment originated in an SEL 810-B computer located in the Electrical Engineering Department at UCSB. This 70ns cycle time computer is the heart of an interactive signal processing system developed by Retz[3]. It has associated hardware such as a card reader, two IBM 1311 disk drives, a drum storage unit, A/D and D/A converters, Teletype, Tektronix 611 storage display unit, OLS keyboard, and a connection to an IBM 1800 computer. This system is linked to the UCSB IBM 360/75 via a 500 kilobit line for high speed data transfers. Software in both the SEL 810-B and the IBM 360 enables the SEL to communicate with the ARPA Network.
The hardware configuration of the data path between the SEL 810-B and UCLA is shown in Figure 1. For simulating speech transmission, the SEL is thought of as a "speech processor", analyzing and encoding the one-way conversation of a person at UCSB talking to someone at UCLA. The fact that there was no "speech processor" at UCLA probably had little or no effect on the measurements that were made. This is substantiated by noting that the SEL was a dedicated processor that did not introduce delays and if a similar dedicated processor was attached to the host computer at UCLA it probably would not have caused delays either. However, the UCLA host merely discarded the data it received, thereby going through fewer steps than if an external processor was attached, and so our simulation was not exact.
A configuration such as that of Figure 1 did yield information about host-to-host transmission, since the SEL was essentially a zero-delay data generator. If real-time processors are to access the ARPA Network through large-scale time-shared host computers then host-to- host transmission rate and delay are important measurements. In this configuration we can expect the host computers to be the primary bottlenecks in the data path.
Pfeifer & MacAfee [Page 2]
RFC 508 Real-Time Data Transmission On The Arpanet 7 May 1973
UCSB UCLA |------------------------------------------| |-----------------| +--------+ +-------+ +-------+ | | | | | | | | 500 Kb/s | | | | |SEL810-B| +------+ | +------+ |IBM | |IBM | | |<-|INTER-|<->|INTER-|->|360/75 | |360/91 | | |->|FACE | |FACE |<-| | | +----+|DISCARD | | +------+ +------+ | | | | NCP|-->+----+ | | | | | +----+| | | +--------+ +---^---+ +----^--+ +----+ | | |<--100 Kb/s--> | | V V | V | +-----+ +-----+ +-----+ | D/A | | IMP |<---/ /<---| IMP | +-----+ | |--->/ /--->| | | +-----+ \ / +-----+ -|\ | \ / -| \<-+ 50 Kb/s -| / -|/SPEAKER Figure 1. Hardware configuration of data path used for sending real-time data from the SEL 810-B to the UCLA host discard socket.
The host response time to requests from the external processor or the Network will be a function of type of host computer (IBM, DEC, UNIVAC, etc.), job load, and priorities given to both the Network and the external processor. If host computers cannot provide the necessary throughput and necessary response times, then real-time devices may have to connect directly to IMPs (assuming the Network can properly support these devices).
III. SOFTWARE
The standard NCP software was used in both host computers. Several custom programs were required in the UCSB computers in order to transfer the data and make measurements. These can be divided into three categories:
1) I/O Programs.
Routines were written for both the IBM 360 and the SEL to handle the transfer of data between the two computers and to enable the SEL to send an "attention interrupt" to the IBM 360. These programs form the software part of the SEL/360 high-speed data link and are necessary for any communication between the two computers.
Pfeifer & MacAfee [Page 3]
RFC 508 Real-Time Data Transmission On The Arpanet 7 May 1973
2) Network Communications Programs
A protocol was developed which enabled the SEL to communicate to the 360 the desired Network connections to be made or broken, and the desired transfer of data across these connections. This protocol was implemented for each computer using the above I/O routines.
3) Measurement Control Program
This assembly language program caused the SEL to push data towards the receiving host (UCLA) at a specified SEL process bit-rate. The program was also responsible for detecting and measuring the duration of any gaps introduced in the process.
IV. METHOD
Within the SEL two buffers, each of 1 to 8 network packets in length, are first loaded with alternating bit patterns in consecutive 16-bit words. A conversion process is then initiated on one of the buffers at a sampling frequency necessary to give the desired bit-rate. Since data is being sent out to a destination host we would expect the buffers to be filled by an analog-to-digital conversion process. However, in this experiment, the process of digital-to-analog conversion is used instead so that we can listen to the alternating bit patterns as a steady tone while still simulating an A-to-D process.
When a buffer is filled (played out) a "write" operation is initiated to send that buffer to UCLA. The next buffer is then tested to see if the previous "write" has been completed, i.e. the buffer is empty. If the next buffer is empty the process continues normally. If the next buffer is not empty it means that one of the computers on the Network has not taken the data fast enough, therefore a gap has been introduced in the real-time process. At this point the D-to-A converter is shut off resulting in an audible break in the tone that is being played out. A timer is also started to test for the empty buffer every one millisecond and to measure the duration of the gap. When the next buffer is finally emptied the D-to-A process is resumed and the gap data recorded in a table.
A connection to the UCLA host discard socket was first established using the network communications programs. Every test from this point on required a repetition of the following steps.
Pfeifer & MacAfee [Page 4]
RFC 508 Real-Time Data Transmission On The Arpanet 7 May 1973
1) Initialize the UCSB IBM 360 for double buffered data transfers using specified buffer sizes.
2) Initialize the SEL measurement control program with the proper buffer size and process bit-rate.
3) Start the test. A constant tone from the speaker indicates that the process is being properly maintained. Gaps in the tone indicate gaps in the process.
4) After 30 seconds, stop the test.
5) Examine the gap table to determine the number of gaps, the duration of each gap, and the average duration.
The entire procedure was carried out from the SEL end using the interactive On-Line System. The timing interval of 30 seconds was measured with a sweep second hand of a watch and the test was started and stopped manually. All tests were conducted during prime time to obtain typical loading conditions.
VI. RESULTS
A total of 179 tests were conducted. Of these, 176 were 30 second tests and three were long duration tests. Table I contains the results of the 30 second tests. Buffer sizes were varied from one to eight Network packets and for each buffer setting 22 different process bit-rates (usually in increments of 1200 bps) were attempted. These measurements were performed over a period of three days during prime time.
Those test conditions which were successful contain only two items of information in Table I: time of day and number of buffers transmitted. All but seven of the tests were successful. The tests which were unsuccessful, i.e. experienced gaps, are those entries in Table I which contain additional information such as number of gaps, and maximum, average and minimum gap duration.
An examination of those tests which failed shows that the longest gap which occurred was 8 seconds in duration. There were three other significant failures between 9:52 A.M. and 9:59 A.M. on 2/7/73. There are strong indications that it was the UCSB 360 that caused these gaps to occur. This conclusion is based upon the fact that the Electrical Engineering On-Line classroom (16 interactive graphics terminals) was in full use that day until 10:00 A.M. and the SEL connection to the IBM 360 has lower priority in the 360 than the UCSB
Pfeifer & MacAfee [Page 5]
RFC 508 Real-Time Data Transmission On The Arpanet 7 May 1973
On-Line System. The remaining three tests which failed did not do so at any regular time, bit-rate, or buffer size so no definite statements can be made about their source of delay.
The overall picture presented by Table I is very promising. In 96 percent of the trials a communications link of the two host computers and a portion of the ARPA Network was able to take data from a real- time process operating as high as 30,000 bits/second. Further encouragement is given by three additional tests which were carried out at 30,000 bps and a buffer size of 2,016 bits. On 2/5/73 at 2:20 P.M. a 5-minute test was executed with no gaps. On 2/6/73 at 11:58 A.M. the same test was executed for 8 minutes with no gaps. The third test was conducted for 18 minutes on 2/7/73 at 11:53 A.M. with no gaps in the process.
The tests were not carried out often enough or over a long enough period of time to obtain any statistical results or predictions. The measurement task is made somewhat difficult by the fact that the state of the overall communications link is never repeatable from one test to the next. For example, it was found that a test which failed could usually be repeated successfully, even when it was carried out within 15 seconds of the previous test.
Pfeifer & MacAfee [Page 6]
RFC 508 Real-Time Data Transmission On The Arpanet 7 May 1973
+-- +--------+ | time of day----| 9:35 | Results of a test for transmitting | # buffers sent-| 76 | data from a continuous external | |--------| process at UCSB (SEL 810B computer) KEY-| max. gap time--| 119 ms | through the UCSB Host computer, over | avg. gap time--| 50 ms | the ARPA network, and into a UCLA | min. gap time--| 2 ms | (site 65) Host discard socket | # gaps (discon-| 3 | (socket 9). Each test (approx.) 30 | tinuity in +--------+ sec. | process) +--
VII. CONCLUSIONS
Based upon the results of this experiment the following conclusions can be drawn:
1) High bit-rate real-time processes can use the ARPA Network to transmit data for relatively long periods of time.
2) Real-time processes accessing the Network through large-scale timesharing host computers can expect arbitrary delays or gaps, probably attributable to the host computers and not the Network.
Pfeifer & MacAfee [Page 9]
RFC 508 Real-Time Data Transmission On The Arpanet 7 May 1973
3) Techniques for handling gaps of 1/2 to 1 second may be possible but 8 second gaps, as measured in this experiment, will cause extreme hardship on any real-time process.
This experiment has pointed up the need to conduct additional tests using a complete transmission link with actual data and with monitoring equipment at both the sending and receiving ends. Our current and future efforts are directed toward carrying out such experiments.
REFERENCES
[1] "Interface Message Processors for the ARPA Computer Network", Quarterly Technical Report No. 16, 1 Oct 1972 to 31 Dec 1972, Bolt, Beraneck and Newman, Inc.
[2] Semiannual Technical Summary on Graphics, Lincoln Laboratory, Massachusetts Institute of Technology, Nov 1971.
[3] D.L. Retz, "An Interactive System for Signal Analysis: Design, Implementation, and Applications", CSL Report No 25, Computer Systems Lab, University of California, Santa Barbara, CA, 1972.
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Via Genie ]