doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc508.txt b/doc/rfc/rfc508.txt
new file mode 100644
index 0000000..c8735b4
--- /dev/null
+++ b/doc/rfc/rfc508.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+
+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
+
+
++-----+---------------------------------------------------------------+
+|PRO- |                BUFFER SIZE (BITS)                             |
+|CESS |                                                               |
+|BIT  |---------------------------------------------------------------+
+|RATE | 1008  | 2016  | 3024  | 4023  | 5040  | 6048  | 7056  | 8048  |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|5300 | 11:31 | 9:51  | 11:34 | 10:34 | 10:12 | 1:59  | 1:37  | 12:32 |
+|     |  158  |  81   |  45   |  41   |  33   |  28   |  24   |   21  |
++-----+-------+-------+-------+-------+-------+-----------------------+
+|6000 | 11:32 | 9:52  | 11:40 | 10:35 | 10:13 | 2:00  | 1:38  | 12:36 |
+|     |  180  |  89   |  61   |  46   |  37   |  31   |  27   |  23   |
+|     |       |-------|       |       |       |       |       |       |
+|     |       | 174ms |       |       |       |       |       |       |
+|     |       |   1   |       |       |       |       |       |       |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|7200 | 11:33 | 9:54  | 11:41 | 10:36 | 10:14 | 2:01  | 1:39  | 12:37 |
+|     |  216  |  109  |  72   |  54   |  44   |  37   |  33   |  23   |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|8400 | 11:34 | 7:55  | 11:42 | 10:37 | 10:14 | 2:02  | 1:40  | 12:38 |
+|     |  245  |  126  |  82   |  63   |  51   |  42   |  37   |  32   |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|9600 | 11:35 | 9:56  | 11:43 | 10:38 | 10:15 | 2:03  | 1:41  | 12:39 |
+|     |  287  |  83   |  99   |  73   |  58   |  49   |  42   |  36   |
+|     |       |-------|       |       |       |       |       |       |
+|     |       | 8 sec |       |       |       |       |       |       |
+|     |       |   1   |       |       |       |       |       |       |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|10800| 11:36 | 9:57  | 11:44 | 10:39 | 10:16 | 2:04  | 1:42  | 12:40 |
+|     |  318  |  138  |  109  |  81   |  65   |  56   |  47   |  42   |
+|     |       |-------|       |       |       |       |       |       |
+|     |       |  3 sec|       |       |       |       |       |       |
+|     |       |1.5 sec|       |       |       |       |       |       |
+|     |       |100 ms |       |       |       |       |       |       |
+|     |       |   2   |       |       |       |       |       |       |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|12000| 11:37 | 9:58  | 11:45 | 10:44 | 10:17 | 2:05  | 1:43  | 12:41 |
+|     |  358  |  180  |  119  |   91  |   73  |  61   |  52   |  46   |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|13200| 11:38 | 9:59  | 11:46 | 10:45 | 10:18 | 2:06  | 1:44  | 12:49 |
+|     |  396  |  188  |  132  |  101  |   80  |  67   |  57   |  49   |
+|     |       |-------|       |       |       |       |       |       |
+|     |       | 438 ms|       |       |       |       |       |       |
+|     |       | 269 ms|       |       |       |       |       |       |
+|     |       | 100 ms|       |       |       |       |       |       |
+|     |       |   2   |       |       |       |       |       |       |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+
+
+
+
+
+Pfeifer & MacAfee                                               [Page 7]
+
+RFC 508        Real-Time Data Transmission On The Arpanet     7 May 1973
+
+
+|14400| 11:39 | 10:45 | 11:46 | 10:46 | 10:18 | 2:07  | 1:45  | 12:50 |
+|     |  428  |  213  |  141  |  107  |  88   |  73   |  62   |  56   |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|15600| 11:39 | 10:46 | 11:47 | 10:47 | 10:19 | 2:08  | 1:46  | 12:51 |
+|     |  467  |  232  |  156  |  117  |  94   |  79   |  67   |  59   |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|16800| 11:40 | 11:15 | 11:43 | 10:48 | 10:20 | 2:09  | 1:47  | 12:52 |
+|     |  503  |  243  |  168  |  127  |  100  |  85   |  72   |  63   |
+|     |       |-------|       |       |       |       |       |       |
+|     |       | 190 ms|       |       |       |       |       |       |
+|     |       | 128 ms|       |       |       |       |       |       |
+|     |       |  29 ms|       |       |       |       |       |       |
+|     |       |   3   |       |       |       |       |       |       |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|18000| 11:41 | 11:17 | 11:48 | 10:49 | 10:21 | 2:10  | 1:48  | 1:00  |
+|     |  535  |  266  |  179  |  136  |  107  |  90   |  76   |  68   |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|19200| 11:42 | 11:18 | 11:49 | 10:50 | 10:22 | 2:11  | 1:49  | 1:20  |
+|     |  573  |  285  |  191  |  144  |  114  |  98   |  82   |  73   |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|20400| 11:42 | 11:19 | 11:50 | 10:51 | 10:23 | 2:12  | 1:50  | 1:21  |
+|     |  610  |  303  |  202  |  153  |  123  |  103  |  87   |  75   |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|21600| 11:43 | 11:20 | 11:51 | 10:52 | 10:24 | 2:13  | 1:51  | 1:22  |
+|     |  643  |  327  |  213  |  162  |  130  |  108  |  94   |  81   |
+|     |       |       |       |       |       |       |       |-------|
+|     |       |       |       |       |       |       |       | 98 ms |
+|     |       |       |       |       |       |       |       | 30 ms |
+|     |       |       |       |       |       |       |       |  5 ms |
+|     |       |       |       |       |       |       |       | 10    |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|22800| 11:44 | 11:21 | 11:51 | 10:53 | 10:25 | 2:14  | 1:52  | 1:27  |
+|     |  687  |  344  |  223  |  173  |  138  |  113  |  99   |  86   |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|24000| 11:44 | 11:22 | 11:52 | 10:54 | 10:26 | 2:15  | 1:53  | 1:29  |
+|     |  712  |  352  |  240  |  180  |  143  |  122  |  103  |  93   |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|25200| 11:45 | 11:23 | 11:53 | 10:55 | 10:27 | 2:16  | 1:54  | 1:30  |
+|     |  741  |  375  |  252  |  193  |  146  |  126  |  109  |  96   |
+|     |       |       |       |       |-------|       |       |       |
+|     |       |       |       |       | 149 ms|       |       |       |
+|     |       |       |       |       |  70 ms|       |       |       |
+|     |       |       |       |       |   2 ms|       |       |       |
+|     |       |       |       |       |  13   |       |       |       |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+
+
+
+
+
+
+Pfeifer & MacAfee                                               [Page 8]
+
+RFC 508        Real-Time Data Transmission On The Arpanet     7 May 1973
+
+
+|26400| 11:46 | 11:24 | 11:54 | 10:56 | 10:30 | 2:17  | 1:55  | 1:31  |
+|     |  786  |  395  |  264  |  203  |  160  |  131  |  113  | 100   |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|27600| 11:47 | 11:27 | 11:55 | 10:57 | 10:31 | 2:18  | 1:56  | 1:32  |
+|     |  819  |  410  |  276  |  213  |  167  |  140  |  119  |  104  |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|28800| 11:48 | 11:28 | 11:56 | 11:30 | 10:32 | 2:19  | 1:57  | 1:33  |
+|     |  856  |  429  |  287  |  217  |  171  |  145  |  125  |  110  |
++-----+-------+-------+-------+-------+-------+-------+-------+-------+
+|30000| 11:49 | 11:30 | 11:57 | 11:33 | 10:33 | 2:20  | 1:58  | 1:34  |
+|     |  896  |  447 ||  299  |  224  |  180  |  151  |  129  |  112  |
++-----+-------+------|+-------+-------+-------+-------+-------+-------+
+      | 2/7/73 (a.m.)||     2/6/73 (a.m.)     |     2/5/73 (p.m.)     |
+      +--------------|+-----------------------+-----------------------+
+                     V
+        2/5/73            |  2/6/73           |  2/7/73
+        5 min. test       |  8 min. test      |  10 min. test
+        @ 2:20 pm         |  @ 11:53 am       |  @ 11:53 am
+        no gaps           |  no gaps          |  no gaps
+        4669 buffers sent | 7141 buffers sent | 16071 buffers sent
+
+
+     +--              +--------+
+     | 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 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeifer & MacAfee                                              [Page 10]
+