Dismiss
There will be a system update on Friday, May 5th, 6 PM ET. You may experience a brief service interruption.
Browse Prior Art Database

Throughput degradations for single packet messages (RFC0632)

IP.com Disclosure Number: IPCOM000003705D
Original Publication Date: 1974-May-20
Included in the Prior Art Database: 2000-Sep-13
Document File: 5 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

H. Opderbeck: AUTHOR

Abstract

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 situation.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 22% of the total text.

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

situation.

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

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-I...