NETBLT: A bulk data transfer protocol
RFC 998

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• rfc998

Network Working Group                                     David D. Clark
Request for Comments:  998                               Mark L. Lambert
Obsoletes:  RFC 969                                          Lixia Zhang
                                                                     MIT
                                                              March 1987

                 NETBLT: A Bulk Data Transfer Protocol

1. Status

   This document is a description of, and a specification for, the
   NETBLT protocol.  It is a revision of the specification published in
   NIC RFC-969.  The protocol has been revised after extensive research
   into NETBLT's performance over long-delay, high-bandwidth satellite
   channels.  Most of the changes in the protocol specification have to
   do with the computation and use of data timers in a multiple
   buffering data transfer model.

   This document is published for discussion and comment, and does not
   constitute a standard.  The proposal may change and certain parts of
   the protocol have not yet been specified; implementation of this
   document is therefore not advised.

2. 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.  Although NETBLT currently runs on top of the
   Internet Protocol (IP), it should be able to operate on top of any
   datagram protocol similar in function to IP.

   NETBLT's motivation is to achieve higher throughput than other
   protocols might offer.  The protocol achieves this goal by trying to
   minimize the effect of several network-related problems: network
   congestion, delays over satellite links, and packet loss.

   Its transmission rate-control algorithms deal well with network
   congestion; its multiple-buffering capability allows high throughput
   over long-delay satellite channels, and its various
   timeout/retransmit algorithms minimize the effect of packet loss
   during a transfer.  Most importantly, NETBLT's features give it good
   performance over long-delay channels without impairing performance
   over high-speed LANs.

Clark, Lambert, & Zhang                                         [Page 1]
RFC 998                                                       March 1987

   The protocol works by opening a connection between two "clients" (the
   "sender" and the "receiver"), transferring the data in a series of
   large data aggregates called "buffers", and then closing the
   connection.  Because the amount of data to be transferred can be very
   large, the client is not required to provide at once all the data to
   the protocol module.  Instead, the data is provided by the client in
   buffers.  The NETBLT layer transfers each buffer as a sequence of
   packets; since each buffer is composed of a large number of packets,
   the per-buffer interaction between NETBLT and its client is far more
   efficient than a per-packet interaction would be.

   In its simplest form, a NETBLT transfer works as follows:  the
   sending client loads a buffer of data and calls down to the NETBLT
   layer to transfer it.  The NETBLT layer breaks the buffer up into
   packets and sends these packets across the network in Internet
   datagrams.  The receiving NETBLT layer loads these packets into a
   matching buffer provided by the receiving client.  When the last
   packet in the buffer has arrived, the receiving NETBLT checks to see
   that all packets in that buffer have been correctly received.  If
   some packets are missing, the receiving NETBLT requests that they be
   resent.  When the buffer has been completely transmitted, the
   receiving client is notified by its NETBLT layer.  The receiving
   client disposes of the buffer and provides a new buffer to receive
   more data.  The receiving NETBLT notifies the sender that the new
   buffer is ready, and the sender prepares and sends the next buffer in
   the same manner.  This continues until all the data has been sent; at
   that time the sender notifies the receiver that the transmission has
   been completed.  The connection is then closed.

   As described above, the NETBLT protocol is "lock-step".  Action halts
   after a buffer is transmitted, and begins again after confirmation is
   received from the receiver of data.  NETBLT provides for multiple
   buffering, a transfer model in which the sending NETBLT can transmit
   new buffers while earlier buffers are waiting for confirmation from
   the receiving NETBLT.  Multiple buffering makes packet flow
   essentially continuous and markedly improves performance.

   The remainder of this document describes NETBLT in detail.  The next
   sections describe the philosophy behind a number of protocol
   features:  packetization, flow control, transfer reliability, and