NETBLT: A bulk data transfer protocol
RFC 998
Document | Type |
RFC - Experimental
(March 1987; No errata)
Obsoletes RFC 969
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 | ||
Stream | Legacy stream | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 998 (Experimental) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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, andShow full document text