Response to RFC 567 - cross country network bandwidth
A correction to packet-size estimates in a discussion of remote echoing and network bandwidth.
McQuillan, J.M., "Response to RFC 567 - cross country network bandwidth", RFC 568, DOI 10.17487/RFC0568, September 1973, <https://www.rfc-editor.org/info/rfc568>.
@misc{rfc568,
series = {Request for Comments},
number = 568,
howpublished = {RFC 568},
publisher = {RFC Editor},
doi = {10.17487/RFC0568},
url = {https://www.rfc-editor.org/info/rfc568},
author = {J.M. McQuillan},
title = {{Response to RFC 567 - cross country network bandwidth}},
pagetotal = 3,
year = 1973,
month = sep,
} RFC text
Contents
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 to TELNET protocol may well improve
performance by reducing network traffic, and, more importantly,
reducing demands for Host processing. In cases of network paths
with long delay, especially satellite links, such changes are
essential for interactive echoing.
JMcQ/jm
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 10/99 ]
ISO Plain Language
On this page
§1Correcting the Packet Assumptions
McQuillan says RFC 567 makes several fundamental errors, beginning with the assumption that all packets are 1000 bits long. The RFC states that packet sizes vary and gives separate sizes for return-to-host messages and Host-Host protocol messages.
It gives an RFNM size of 152 bits and a single-character or allocate Host-Host message size of 216 bits. The author's calculation totals 736 bits in each direction, rather than 4000 bits.
The earlier estimate treated every packet as the same size. This correction uses the sizes of the message types involved in remote echoing.
§2Traffic Rate and Buffering
From the revised message sizes, McQuillan estimates that the network can support over 200 single-character messages per second, not 37.5. He notes that this pattern is unlikely and that the IMP subnetwork can support it more readily than most hosts.
If remote-echo demand exceeded network capacity, TIPs and hosts could buffer two characters per message, which the RFC says would double effective bandwidth. It also says that packing more characters into a message can increase effective bandwidth nearly proportionally, with responses slowing as load rises.
The corrected sizes allow many more single-character messages than the earlier estimate. Grouping characters into a message can also reduce the effect of message overhead.
§3Why Echoing Can Still Be Slow
The RFC argues that poor echo response is mainly a delay problem, not a bandwidth problem. The IMP software was designed to give interactive traffic low delay and bulk transfers high throughput; short messages have high overhead in bits and processor wake-ups.
As an extreme illustration, the author says echoing over a megabit-per-second satellite link could lag a second or more even without bandwidth limits. He agrees that TELNET changes may improve performance by reducing network traffic and host processing, especially on long-delay paths such as satellite links.
A link can have plenty of capacity and still feel slow if each response takes a long time to travel. The author supports TELNET changes that reduce the work and traffic involved.