On testing the NETBLT Protocol over divers networks
RFC 1030

Document Type RFC - Unknown (November 1987; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1030 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       M. Lambert
Request for Comments: 1030      M.I.T. Laboratory for Computer Science
                                                         November 1987

          On Testing the NETBLT Protocol over Divers Networks

STATUS OF THIS MEMO

   This RFC describes the results gathered from testing NETBLT over
   three networks of differing bandwidths and round-trip delays.  While
   the results are not complete, the information gathered so far has
   been very promising and supports RFC-998's assertion that that NETBLT
   can provide very high throughput over networks with very different
   characteristics.  Distribution of this memo is unlimited.

1. Introduction

   NETBLT (NETwork BLock Transfer) is a transport level protocol
   intended for the rapid transfer of a large quantity of data between
   computers.  It provides a transfer that is reliable and flow
   controlled, and is designed to provide maximum throughput over a wide
   variety of networks.  The NETBLT protocol is specified in RFC-998;
   this document assumes an understanding of the specification as
   described in RFC-998.

   Tests over three different networks are described in this document.
   The first network, a 10 megabit-per-second Proteon Token Ring, served
   as a "reference environment" to determine NETBLT's best possible
   performance.  The second network, a 10 megabit-per-second Ethernet,
   served as an access path to the third network, the 3 megabit-per-
   second Wideband satellite network.  Determining NETBLT's performance
   over the Ethernet allowed us to account for Ethernet-caused behaviour
   in NETBLT transfers that used the Wideband network.  Test results for
   each network are described in separate sections.  The final section
   presents some conclusions and further directions of research.  The
   document's appendices list test results in detail.

2. Acknowledgements

   Many thanks are due Bob Braden, Stephen Casner, and Annette DeSchon
   of ISI for the time they spent analyzing and commenting on test
   results gathered at the ISI end of the NETBLT Wideband network tests.
   Bob Braden was also responsible for porting the IBM PC/AT NETBLT
   implementation to a SUN-3 workstation running UNIX.  Thanks are also
   due Mike Brescia, Steven Storch, Claudio Topolcic and others at BBN
   who provided much useful information about the Wideband network, and

M. Lambert                                                      [Page 1]
RFC 1030              Testing the NETBLT Protocol          November 1987

   helped monitor it during testing.

3. Implementations and Test Programs

   This section briefly describes the NETBLT implementations and test
   programs used in the testing.  Currently, NETBLT runs on three
   machine types: Symbolics LISP machines, IBM PC/ATs, and SUN-3s.  The
   test results described in this paper were gathered using the IBM
   PC/AT and SUN-3 NETBLT implementations.  The IBM and SUN
   implementations are very similar; most differences lie in timer and
   multi-tasking library implementations.  The SUN NETBLT implementation
   uses UNIX's user-accessible raw IP socket; it is not implemented in
   the UNIX kernel.

   The test application performs a simple memory-to-memory transfer of
   an arbitrary amount of data.  All data are actually allocated by the
   application, given to the protocol layer, and copied into NETBLT
   packets.  The results are therefore fairly realistic and, with
   appropriately large amounts of buffering, could be attained by disk-
   based applications as well.

   The test application provides several parameters that can be varied
   to alter NETBLT's performance characteristics.  The most important of
   these parameters are:

        burst interval  The number of milliseconds from the start of one
                        burst transmission to the start of the next burst
                        transmission.

        burst size      The number of packets transmitted per burst.

        buffer size     The number of bytes in a NETBLT buffer (all
                        buffers must be the same size, save the last,
                        which can be any size required to complete the
                        transfer).

        data packet size
                        The number of bytes contained in a NETBLT DATA
                        packet's data segment.

        number of outstanding buffers
                       The number of buffers which can be in
                       transmission/error recovery at any given moment.

M. Lambert                                                      [Page 2]
RFC 1030              Testing the NETBLT Protocol          November 1987

   The protocol's throughput is measured in two ways.  First, the "real
   throughput" is throughput as viewed by the user: the number of bits
   transferred divided by the time from program start to program finish.
   Although this is a useful measurement from the user's point of view,
Show full document text