Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Response to RFC 567 - cross country network bandwidth (RFC0568)

IP.com Disclosure Number: IPCOM000003659D
Original Publication Date: 1973-Sep-18
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 3K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J.M. McQuillan: AUTHOR

Abstract

This note serves as a brief correction to several fundamental errors in RFC 567 by L. Peter Deutsch.

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

Received at NIC 21-Sept-73

Network Working Group J. McQuillan

RFC #568 BBN-NET

NIC #18971 18 September 1973

Response to RFC 567 -- Cross-Country Network Bandwidth

This note serves as a brief correction to several fundamental errors in

RFC 567 by L. Peter Deutsch.

1. Not all packets are 1000 bits long. This is basic to the network

design.

2. RFNMs are 152 bits long (72 bits of hardware framing and 80 bits of

software identification and addressing). Host Host protocol messages

such as single-characters and allocates are 216 bits long (40 bits

of Host protocol, 8 bits for the character or ALL, and an additional

16 bits of IMP software header). This totals to 736 bits in each

direction, not 4000.

3. The number of single-character messages that can be supported is

therefore over 200 per second, not 37.5 per second. Not only is

such a traffic pattern unlikely, but it can be supported in the IMP

subnetwork much more readily than in most Hosts.

4. Furthermore, if the demand for remote echoing ever exceeds network

capacity, the TIPs and Hosts can simply buffer 2 characters per

message, doubling the effective bandwidth of the network. Of

course, dozens of characters can be packed into a single message

with nearly proportional increases in effective bandwidth, given the

size of the overhead. This buffering happens automatically and

incrementally with increasing load as the natural consequence of

slowed responses.

5. It is most likely that the poor echoing response cited by Deutsch is

not caused by peak network loads. If echoing was coming in 5-

character bursts, there would have to be _1000_ characters per

second coming from users of remote-echo systems to use all the

capacity of 3 50-kilobit paths.

6. This reasoning points up the more serious error in RFC 567: the

problems associated with bad echo response are delay problems, not

bandwidth. In designing the IMP software, we have used a bimodal

model of traffic, and attempted to provide low delay for interactive

RFC 568

traffic, and high throughput rates for bulk data transfers. It is

pointless to try for high data rates with short messages - the

overhead in bits, and also in IMP and Host processor wake-ups, is

too high. The primary factor in echoing performance is delay. As

an extreme example, echoing over a megabit per second satellite link

will lag a second or more behind input, with no bandwidth

limitations at all.

7. We agree that changes ...