rfc508.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         L. Pfeifer
Request for Comments: 508                                      J. McAfee
NIC: 16159                            Computer Systems Laboratory / UCSB
                                                              7 May 1973

               REAL-TIME DATA TRANSMISSION ON THE ARPANET

I. INTRODUCTION

   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.

V. PROCEDURE

   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]