Throughput degradations for single packet messages
RFC 632

Document Type RFC - Unknown (May 1974; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 632 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       H. Opderbeck
Request for Comments: #632                                  UCLA-NMC
NIC # 30239                                                 20 May 1974

           Throughput Degradations for Single Packet Messages

The transmission of digitized speech over the ARPANET represents a new
dimension in the use of packet switching systems.  The throughput and
delay requirements for this newly emerging application area are quite
different from the throughput and delay requirements for interactive use
or file transfers.  In particular, we need to achieve a high throughput
for small messages since long messages result in long source delays to
fill the large buffers.  Therefore we are currently studying the
throughput limits for single-packet messages.  We realize that up to now
little attempt was made to optimize throughput for low delay traffic.
It was nevertheless surprising for us to find out that the observed
throughput for single-packet messages is in many cases only about one
fourth of what one would expect.  In what follows we are going to
explain why this happens and what could be done to correct this

On April 1, 1974, we sent, using the IMP message generator, single-
packet messages at the highest possible rate ("RFNM-driven") from the
MOFFET-IMP to the SRI-IMP.  There are two three-hop paths from MOFFET to
SRI, one of them involving two 230.4 kbs circuits.  Since there was
hardly any interfering traffic we expected an average round-trip delay
of not more than 100 msec.  Assuming that there are, on an average, 3
messages in transmission between MOFFET and SRI and assuming a message
length of about 1000 bits this should result in a throughout of more
than 30 kbs.  The observed through was, however, less than 8 kbs.  A
repetition of the experiment showed the same result.  A more detailed
analysis of the collected data revealed that an average number of 3.5
messages were simultaneously in transmission between MOFFET and SRI.
The throughput degradation could therefore not have been due to
interfering traffic between these two sites.  Also the channel
utilization for all channels that were involved in the transmission was
less than 40 percent.  The observed mean round-trip times between MOFFET
and SRI, however, were about 500 msec.  Since these large round-trip
times were obviously not due to physical limitations, we studied the
flow control mechanism for single-packet messages and were able to come
up with an explanation for this undesirable behavior.

When a single-packet message arrives at the destination IMP out of order
(i.e., the logically preceding message has not yet arrived there) it is
not accepted by the destination IMP.  It is rather treated as a request
for the allocation of one reassembly buffer.  The corresponding ALLOCATE

Opderbeck                                                       [Page 1]
RFC 632    Throughput Degradations for Single Packet Messages   May 1974

is then sent back to the source IMP only after the RFNM for the previous
message has been processed.  We therefore may have the following
sequence of events:

     1  MSG(i) sent from SOURCE-IMP (message i is sent from the source
        IMP to the destination IMP).

     2  MSG(i+1) sent from SOURCE-IMP.

     3  MSG(i+1) arrives at DEST-IMP (due to an alternate path or a line
        error, message (i+1) arrives at the destination IMP out of
        order; it is treated as a request for one reassembly buffer
        allocation and then discarded).

     4  MSG(i) arrives at DEST-IMP (message i arrives at the destination
        IMP; it is put on the proper HOST output queue).

     5  RFNM(i) sent from DEST-IMP (after message i has been accepted by
        the destination HOST the RFNM is sent to the source IMP).

     6  ALL(i+1) sent from DEST-IMP (only after the RFNM for message i
        has been processed can the ALLOCATE for message i + 1 be sent).

     7  RFNM(i) arrives at SOURCE-IMP.

     8  ALL(i+1) arrives at SOURCE-IMP.

     9  MSG(i+1) arrives at DEST-IMP (now message i+1 is put on the
        proper HOST output queue.)

    10  RFNM(i+1) sent form DEST-IMP.

    11  RFNM(i+1) arrives at SOURCE-IMP.

Note that the round-trip time for message i+1 is the time interval
between event 2 and event 11.  Therefore the round-trip time for message
i+1 is more than twice as large as it would have been if it had arrived
in order, other conditions being unchanged.  Therefore a line error will
in many cases not only delay the message in error but also the next
single-packet message if this message follows the preceding message
within 125 msec, the error retransmission timeout interval.  Also, a
faster, alternate path to the destination IMP can actually slow down the
transmission since it causes messages to arrive there out of order.

Opderbeck                                                       [Page 2]
RFC 632    Throughput Degradations for Single Packet Messages   May 1974
Show full document text