1 files changed, 120 insertions, 0 deletions
diff --git a/doc/rfc/rfc568.txt b/doc/rfc/rfc568.txt
new file mode 100644
index 0000000..f8228b6
--- /dev/null
+++ b/doc/rfc/rfc568.txt
@@ -0,0 +1,120 @@
+
+
+
+
+
+
+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 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+