rfc998.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,238 行 · 第 1/4 页

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
   connection management. The final sections describe NETBLT's packet
   formats.

3. Buffers and Packets

   NETBLT is designed to permit transfer of a very large amounts of data
   between two clients.  During connection setup the sending NETBLT can
   inform the receiving NETBLT of the transfer size; the maximum
   transfer length is 2**32 bytes.  This limit should permit any
   practical application.  The transfer size parameter is for the use of
   the receiving client; the receiving NETBLT makes no use of it.  A



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


   NETBLT receiver accepts data until told by the sender that the
   transfer is complete.

   The data to be sent must be broken up into buffers by the client.
   Each buffer must be the same size, save for the last buffer.  During
   connection setup, the sending and receiving NETBLTs negotiate the
   buffer size, based on limits provided by the clients.  Buffer sizes
   are in bytes only; the client is responsible for placing data in
   buffers on byte boundaries.

   NETBLT has been designed and should be implemented to work with
   buffers of any size.  The only fundamental limitation on buffer size
   should be the amount of memory available to the client.  Buffers
   should be as large as possible since this minimizes the number of
   buffer transmissions and therefore improves performance.

   NETBLT is designed to require a minimum amount of memory, allowing
   the client to allocate as much memory as possible for buffer storage.
   In particular, NETBLT does not keep buffer copies for retransmission
   purposes.  Instead, data to be retransmitted is recopied directly
   from the client buffer.  This means that the client cannot release
   buffer storage piece by piece as the buffer is sent, but this has not
   been a problem in preliminary NETBLT implementations.

   Buffers are broken down by the NETBLT layer into sequences of DATA
   packets.  As with the buffer size, the DATA packet size is negotiated
   between the sending and receiving NETBLTs during connection setup.
   Unlike buffer size, DATA packet size is visible only to the NETBLT
   layer.

   All DATA packets save the last packet in a buffer must be the same
   size.  Packets should be as large as possible, since NETBLT's
   performance is directly related to packet size.  At the same time,
   the packets should not be so large as to cause internetwork
   fragmentation, since this normally causes performance degradation.

   All buffers save the last buffer must be the same size; the last
   buffer can be any size required to complete the transfer.  Since the
   receiving NETBLT does not know the transfer size in advance, it needs
   some way of identifying the last packet in each buffer.  For this
   reason, the last packet of every buffer is not a DATA packet but
   rather an LDATA packet.  DATA and LDATA packets are identical save
   for the packet type.

4. Flow Control

   NETBLT uses two strategies for flow control, one internal and one at
   the client level.

   The sending and receiving NETBLTs transmit data in buffers; client
   flow control is therefore at a buffer level.  Before a buffer can be



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


   transmitted, NETBLT confirms that both clients have set up matching
   buffers, that one is ready to send data, and that the other is ready
   to receive data.  Either client can therefore control the flow of
   data by not providing a new buffer.  Clients cannot stop a buffer
   transfer once it is in progress.

   Since buffers can be quite large, there has to be another method for
   flow control that is used during a buffer transfer.  The NETBLT layer
   provides this form of flow control.

   There are several flow control problems that could arise while a
   buffer is being transmitted.  If the sending NETBLT is transferring
   data faster than the receiving NETBLT can process it, the receiver's
   ability to buffer unprocessed packets could be overflowed, causing
   packet loss.  Similarly, a slow gateway or intermediate network could
   cause packets to collect and overflow network packet buffer space.
   Packets will then be lost within the network.  This problem is
   particularly acute for NETBLT because NETBLT buffers will generally
   be quite large, and therefore composed of many packets.

   A traditional solution to packet flow control is a window system, in
   which the sending end is permitted to send only a certain number of
   packets at a time.  Unfortunately, flow control using windows tends
   to result in low throughput.  Windows must be kept small in order to
   avoid overflowing hosts and gateways, and cannot easily be updated,
   since an end-to-end exchange is required for each window change.

   To permit high throughput over a variety of networks and gateways,
   NETBLT uses a novel flow control method: rate control.  The
   transmission rate is negotiated by the sending and receiving NETBLTs
   during connection setup and after each buffer transmission.  The
   sender uses timers, rather than messages from the receiver, to
   maintain the negotiated rate.

   In its simplest form, rate control specifies a minimum time period
   per packet transmission.  This can cause performance problems for
   several reasons.  First, the transmission time for a single packet is
   very small, frequently smaller than the granularity of the timing
   mechanism.  Also, the overhead required to maintain timing mechanisms
   on a per packet basis is relatively high and lowers performance.

   The solution is to control the transmission rate of groups of
   packets, rather than single packets.  The sender transmits a burst of
   packets over a negotiated time interval, then sends another burst.
   In this way, the overhead decreases by a factor of the burst size,
   and the per-burst transmission time is long enough that timing
   mechanisms will work properly.  NETBLT's rate control therefore has
   two parts, a burst size and a burst rate, with (burst size)/(burst
   rate) equal to the average transmission time per packet.





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


   The burst size and burst rate should be based not only on the packet
   transmission and processing speed which each end can handle, but also
   on the capacities of any intermediate gateways or networks.
   Following are some intuitive values for packet size, buffer size,
   burst size, and burst rate.

   Packet sizes can be as small as 128 bytes.  Performance with packets
   this small is almost always bad, because of the high per-packet
   processing overhead.  Even the default Internet Protocol packet size
   of 576 bytes is barely big enough for adequate performance.  Most
   networks do not support packet sizes much larger than one or two
   thousand bytes, and packets of this size can also get fragmented when
   traveling over intermediate networks, lowering performance.

   The size of a NETBLT buffer is limited only by the amount of memory
   available to a client.  Theoretically, buffers of 100 Kbytes or more
   are possible.  This would mean the transmission of 50 to 100 packets
   per buffer.

   The burst size and burst rate are obviously very machine dependent.
   There is a certain amount of transmission overhead in the sending and
   receiving machines associated with maintaining timers and scheduling
   processes.  This overhead can be minimized by sending packets in
   large bursts.  There are also limitations imposed on the burst size
   by the number of available packet buffers in the operating system
   kernel. On most modern operating systems, a burst size of between
   five and ten packets should reduce the overhead to an acceptable
   level.  A preliminary NETBLT implementation for the IBM PC/AT sends
   packets in bursts of five.  It could send more, but is limited by the
   available memory.

   The burst rate is in part determined by the granularity of the
   sender's timing mechanism, and in part by the processing speed of the
   receiver and any intermediate gateways.  It is also directly related
   to the burst size.  Burst rates from 20 to 45 milliseconds per 5-
   packet burst have been tried on the IBM PC/AT and Symbolics 3600
   NETBLT implementations with good results within a single local-area
   network.  This value clearly depends on the network bandwidth and
   packet buffering available.

   All NETBLT flow control parameters (packet size, buffer size, burst
   size, and burst rate) are negotiated during connection setup.  The
   negotiation process is the same for all parameters.  The client
   initiating the connection (the active end) proposes and sends a set
   of values for each parameter in its connection request.  The other
   client (the passive end) compares these values with the highest-
   performance values it can support.  The passive end can then modify
   any of the parameters, but only by making them more restrictive.  The
   modified parameters are then sent back to the active end in its
   response message.




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


   The burst size and burst rate can also be re-negotiated after each
   buffer transmission to adjust the transfer rate according to the
   performance observed from transferring the previous buffer.  The
   receiving end sends burst size and burst rate values in its OK
   messages (described later).  The sender compares these values with
   the values it can support.  Again, it may then modify any of the
   parameters, but only by making them more restrictive.  The modified
   parameters are then communicated to the receiver in a NULL-ACK
   packet, described later.

   Obviously each of the parameters depend on many factors -- gateway
   and host processing speeds, available memory, timer granularity --
   some of which cannot be checked by either client.  Each client must
   therefore try to make as best a guess as it can, tuning for