Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


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


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.


     [ 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 ]
/data/webs/external/dokuwiki/data/pages/rfc/rfc568.txt · Last modified: 2000/03/09 00:56 by

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki