diff options
Diffstat (limited to 'doc/rfc/rfc1986.txt')
| -rw-r--r-- | doc/rfc/rfc1986.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc1986.txt b/doc/rfc/rfc1986.txt new file mode 100644 index 0000000..98b281a --- /dev/null +++ b/doc/rfc/rfc1986.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group W. Polites +Request for Comments: 1986 W. Wollman +Category: Experimental D. Woo + The MITRE Corporation + R. Langan + U.S. ARMY CECOM + August 1996 + + + Experiments with a Simple File Transfer Protocol for Radio Links + using Enhanced Trivial File Transfer Protocol (ETFTP) + + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +1. INTRODUCTION SECTION + + This document is a description of the Enhanced Trivial File Transfer + Protocol (ETFTP). This protocol is an experimental implementation of + the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file + transfer application program. It uses the User Datagram Protocol + (UDP), RFC 768 [2], as its transport layer. The two protocols are + layered to create the ETFTP client server application. The ETFTP + program is named after Trivial File Transfer Protocol (TFTP), RFC + 1350 [3], because the source code from TFTP is used as the building + blocks for the ETFTP program. This implementation also builds on but + differs from the work done by the National Imagery Transmission + Format Standard [4]. + + This document is published for discussion and comment on improving + the throughput performance of data transfer utilities over Internet + Protocol (IP) compliant, half duplex, radio networks. + + There are many file transfer programs available for computer + networks. Many of these programs are designed for operations through + high-speed, low bit error rate (BER) cabled networks. In tactical + radio networks, traditional file transfer protocols, such as File + Transfer Protocol (FTP) and TFTP, do not always perform well. This is + primarily because tactical half duplex radio networks typically + provide slow-speed, long delay, and high BER communication links. + ETFTP is designed to allow a user to control transmission parameters + to optimize file transfer rates through half-duplex radio links. + + + + +Polites, Wollman & Woo Experimental [Page 1] + +RFC 1986 ETFTP August 1996 + + + The tactical radio network used to test this application was + developed by the Survivable Adaptive Systems (SAS) Advanced + Technology Demonstration (ATD). Part of the SAS ATD program was to + address the problems associated with extending IP networks across + tactical radios. Several tactical radios, such as, SINgle Channel + Ground and Airborne Radio Systems (SINCGARS), Enhanced Position + Location Reporting Systems (EPLRS), Motorola LST-5C, and High + Frequency (HF) radios have been interfaced to the system. This + document will discuss results obtained from using ETFTP across a + point-to-point LST-5C tactical SATellite COMmunications (SATCOM) + link. The network includes a 25 Mhz 486 Personal Computer (PC) called + the Army Lightweight Computer Unit (LCU), Cisco 2500 routers, + Gracilis PackeTen Network switches, Motorola Sunburst Cryptographic + processors, a prototype forward error correction (FEC) device, and + Motorola LST-5C tactical Ultra High Frequency (UHF) satellite + communications (SATC! OM) radio. Table 1, "Network Trans fer Rates," + describes the equipment network connections and the bandwidth of the + physical media interconnecting the devices. + + Table 1: Network Transfer Rates + + +-------------------------------+-------------------------------+ + | Equipment | Rate (bits per second) | + +-------------------------------+-------------------------------+ + | Host Computer (486 PC) | 10,000,000 Ethernet | + +-------------------------------+-------------------------------+ + | Cisco Router | 10,000,000 Ethernet to | + | | 19,200 Serial Line Internet | + | | Protocol (SLIP) | + +-------------------------------+-------------------------------+ + | Gracilis PackeTen | 19,200 SLIP to | + | | 16,000 Amateur Radio (AX.25) | + +-------------------------------+-------------------------------+ + | FEC | half rate or quarter rate | + +-------------------------------+-------------------------------+ + | Sunburst Crypto | 16,000 | + +-------------------------------+-------------------------------+ + | LST-5C Radio | 16,000 | + +-------------------------------+-------------------------------+ + + During 1993, the MITRE team collected data for network configurations + that were stationary and on-the-move. This network configuration did + not include any Forward Error Correction (FEC) at the link layer. + Several commercially available implementations of FTP were used to + transfer files through a 16 kbps satellite link. FTP relies upon the + Transmission Control Protocol (TCP) for reliable communications. For + a variety of file sizes, throughput measurements ranged between 80 + and 400 bps. At times, TCP connections could be opened, however, data + + + +Polites, Wollman & Woo Experimental [Page 2] + +RFC 1986 ETFTP August 1996 + + + transfers would be unsuccessful. This was most likely due to the + smaller TCP connection synchronization packets, as compared to the + TCP data packets. Because of the high bit error rate of the link, + the smaller packets were much more likely to be received without + error. In most cases, satellite channel utilization was less than 20 + percent. Very often a file transfer would fail because FTP + implementations would curtail the transfer due t! o the poor + conditions of the commu nication link. + + The current focus is to increase the throughput and channel + utilization over a point to point, half duplex link. Follow on + experiments will evaluate ETFTP's ability to work with multiple hosts + in a multicast scenario. Evaluation of the data collected helped to + determine that several factors limited data throughput. A brief + description of those limiting factors, as well as, solutions that can + reduce these networking limitations is provided below. + +Link Quality + + The channel quality of a typical narrow-band UHF satellite link does + not sufficiently support data communications without the addition of + a forward error correction (FEC) capability. From the data + collected, it was determined that the UHF satellite link supports, on + average, a 10e-3 bit error rate. + + Solution: A narrow-band UHF satellite radio FEC prototype was + developed that improves data reliability, without excessively + increasing synchronization requirements. The prototype FEC increased + synchronization requirements by less than 50 milliseconds (ms). The + FEC implementation will improve an average 10e-3 BER channel to an + average 10e-5 BER channel. + +Delays + + Including satellite propagation delays, the tactical satellite radios + require approximately 1.25 seconds for radio synchronization prior to + transmitting any data across the communication channel. Therefore, + limiting the number of channel accesses required will permit data + throughput to increase. This can be achieved by minimizing the number + of acknowledgments required during the file transfer. FTP generates + many acknowledgments which decreases throughput by increasing the + number of satellite channel accesses required. + + To clarify, when a FTP connection request is generated, it is sent + via Ethernet to the router and then forwarded to the radio network + controller (RNC). The elapsed time is less than 30 ms. The RNC keys + the crypto unit and 950 ms later modem/crypto synchronization occurs. + After synchronization is achieved, the FTP connection request is + + + +Polites, Wollman & Woo Experimental [Page 3] + +RFC 1986 ETFTP August 1996 + + + transmitted. The transmitting terminal then drops the channel and the + modem/crypto synchronization is lost. Assuming that the request was + received successfully, the receiving host processes the request and + sends an acknowledgment. Again the modem/crypto have to synchronize + prior to transmitting the acknowledgment. Propagation delays over a + UHF satellite also adds roughly 500 ms to the total round trip delay. + + Solution: When compared to FTP, NETBLT significantly reduces the + number of acknowledgments required to complete a file transfer. + Therefore, leveraging the features available within an implementation + of NETBLT will significantly improve throughput across the narrow- + band UHF satellite communication link. + + To reduce the number of channel accesses required, a number of AX.25 + parameters were modified. These included the value of p for use + within the p-persistence link layer protocol, the slot time, the + transmit tail time, and the transmit delay time. The p-persistence + is a random number threshold between 0 and 255. The slot time is the + time to wait prior to attempting to access the channel. The transmit + tail increases the amount of time the radio carrier is held on, prior + to dropping the channel. Transmit delay is normally equal to the + value of the radio synchronization time. By adjusting these + parameters to adapt to the tactical satellite environment, improved + communication performance can be achieved. + + First, in ETFTP, several packets within a buffer are transmitted + within one burst. If the buffer is partitioned into ten packets, each + of 1024 bytes, then 10,240 bytes of data is transmitted with each + channel access. It is possible to configure ETFTP's burstsize to + equal the number of packets per buffer. Second, the transmit tail + time was increased to hold the key down on the transmitter long + enough to insure all of the packets within the buffer are sent in a + single channel access. These two features, together, allow the system + to transmit an entire file (example, 100,000 bytes) with only a + single channel access by adjusting buffer size. Thirdly, the ETFTP + protocol only acknowledges each buffer, not each packet. Thus, a + single acknowledgment is sent from the receiving terminal containing + a request for the missing packets within each buffer, reducing the + number of acknowledgment packets sent. Which in turn, reduced the + number of times the channel has to be turned around. + + To reduce channel access time, p-persistence was set to the maximum + value and slot time to a minimum value. These settings support + operations for a point-to-point communication link between two users. + This value of p would not be used if more users were sharing the + satellite channel. + + + + + +Polites, Wollman & Woo Experimental [Page 4] + +RFC 1986 ETFTP August 1996 + + +Backoffs + + TCP's slow start and backoff algorithms implemented in most TCP + packages assume that packet loss is due to network congestion. When + operating across a tactical half duplex communication channel + dedicated to two users, packet loss is primarily due to poor channel + quality, not network congestion. A linear backoff at the transport + layer is recommended. In a tactical radio network there are numerous + cases where a single host is connected to multiple radios. In a + tactical radio network, layer two will handle channel access. + Channel access will be adjusted through parameters like p-persistence + and slot time. The aggregate effect of the exponential backoff from + the transport layer added to the random backoff of the data link + layer, will in most cases, cause the radio network to miss many + network access opportunities. A linear backoff will reduce the number + missed data link network access opportunities + + Solution: Tunable parameters and timers have been modified to + resemble those suggested by NETBLT. + +Packet Size + + In a tactical environment, channel conditions change rapidly. + Continuously transmitting large packets under 10e-3 BER conditions + reduces effective throughput. + + Solution: Packet sizes are dynamically adjusted based upon the + success of the buffer transfers. If 99 percent of all packets within + a buffer are received successfully, packet size can be increased to a + negotiated value. If 50 percent or more of all packets within a + buffer are not successfully delivered, the packet size can be + decreased to a negotiated value. + +2. PROTOCOL DESCRIPTION + + Throughout this document the term packet is used to describe a + datagram that includes all network overhead. A block is used to + describe information, without any network encapsulation. + + The original source files for TFTP, as downloaded from ftp.uu.net, + were modified to implement the ETFTP/NETBLT protocol. These same + files are listed in "UNIX Network Programming" [5]. + + ETFTP was implemented for operations under the Santa Cruz Operations + (SCO) UNIX. In the service file, "/etc/services", an addition was + made to support "etftp" at a temporary well known port of "1818" + using "UDP" protocol. The file, "/etc/inetd.conf", was modified so + the "inetd" program could autostart the "etftpd" server when a + + + +Polites, Wollman & Woo Experimental [Page 5] + +RFC 1986 ETFTP August 1996 + + + connection request came in on the well known port. + + As stated earlier, the transport layer for ETFTP is UDP, which will + not be discussed further here. This client server application layer + protocol is NETBLT, with four notable differences. + + The first change is that this NETBLT protocol is implemented on top + of the UDP layer. This allowed the NETBLT concepts to be tested + without modifying the operating system's transport or network layers. + Table 2, "Four Layer Protocol Model," shows the protocol stack for + FTP, TFTP and ETFTP. + + Table 2: Four Layer Protocol Model + + +---------------------------------------------------------------+ + | PROTOCOL STACK | + +---------------+---------------+---------------+---------------+ + |APPLICATION |FTP |TFTP |ETFTP/NETBLT | + +---------------+---------------+---------------+---------------+ + |TRANSPORT |TCP |UDP |UDP | + +---------------+---------------+---------------+---------------+ + |NETWORK |IP | + +---------------+---------------+---------------+---------------+ + |LINK |Ethernet, SLIP, AX.25 | + +---------------+---------------+---------------+---------------+ + + The second change is a carryover from TFTP, which allows files to be + transferred in netascii or binary modes. A new T bit flag is assigned + to the reserved field of the OPEN message type. + + The third change is to re-negotiate the DATA packet size. This change + affects the OPEN, NULL-ACK, and CONTROL_OK message types. A new R + bit is assigned to the reserved field of the OPEN message type. + + The fourth change is the addition of two new fields to the OPEN + message type. The one field is a two byte integer for radio delay in + seconds, and the next field is two bytes of padding. + + The ETFTP data encapsulation is shown in Table 3, "ETFTP Data + Encapsulation,". The Ethernet, SLIP, and AX.25 headers are mutually + exclusive. They are stripped off and added by the appropriate + hardware layer. + + + + + + + + + +Polites, Wollman & Woo Experimental [Page 6] + +RFC 1986 ETFTP August 1996 + + + Table 3: ETFTP Data Encapsulation + + +------------+------------+------------+------------+-----------+ + |Ethernet(14)| | |ETFTP/ | | + |SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) | + |AX.25(20) | | | | | + +------------+------------+------------+------------+-----------+ + +2.1 MESSAGE TYPES AND FORMATS + + Here are the ETFTP/NETBLT message types and formats. + + MESSAGES VALUES + OPEN 0 Client request to open a new connection + RESPONSE 1 Server positive acknowledgment for OPEN + KEEPALIVE 2 Reset the timer + QUIT 3 Sender normal Close request + QUITACK 4 Receiver acknowledgment of QUIT + ABORT 5 Abnormal close + DATA 6 Sender packet containing data + LDATA 7 Sender last data block of a buffer + NULL-ACK 8 Sender confirmation of CONTROL_OK changes + CONTROL 9 Receiver request to + GO 0 Start transmit of next buffer + OK 1 Acknowledge complete buffer + RESEND 2 Retransmit request + REFUSED 10 Server negative acknowledgment of OPEN + DONE 11 Receiver acknowledgment of QUIT. + + Packets are "longword-aligned", at four byte word boundaries. + Variable length strings are NULL terminated, and padded to the four + byte boundary. Fields are listed in network byte order. All the + message types share a common 12 byte header. The common fields are: + + Checksum IP compliant checksum + Version Current version ID + Type NETBLT message type + Length Total byte length of packet + Local Port My port ID + Foreign Port Remote port ID + Padding Pad as necessary to 4 byte boundary + + The OPEN and RESPONSE messages are similar and shown in Table 4, + "OPEN and RESPONSE Message Types,". The client string field is used + to carry the filename to be transferred. + + + + + + +Polites, Wollman & Woo Experimental [Page 7] + +RFC 1986 ETFTP August 1996 + + + Table 4: OPEN and RESPONSE Message Types + + 1 2 3 + 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 + +---------------+---------------+---------------+---------------+ + |Checksum |Version |Type | + +---------------+---------------+---------------+---------------+ + |Length |Local Port | + +---------------+---------------+---------------+---------------+ + |Foreign Port |Longword Alignment Padding | + +---------------+---------------+---------------+---------------+ + |Connection ID | + +---------------+---------------+---------------+---------------+ + |Buffer size | + +---------------+---------------+---------------+---------------+ + |Transfer size | + +---------------+---------------+---------------+---------------+ + |DATA Packet size |Burstsize | + +---------------+---------------+---------------+---------------+ + |Burstrate |Death Timer Value | + +---------------+---------------+---------------+---------------+ + |Reserved(MBZ) |R|T|C|M|Maximum # Outstanding Buffers | + +---------------+---------------+---------------+---------------+ + |*Radio Delay |*Padding | + +---------------+---------------+---------------+---------------+ + |Client String . . . |Longword Alignment Padding | + +---------------+---------------+---------------+---------------+ + + Connection ID The unique connection number + Buffer size Bytes per buffer + Transfer size The length of the file in bytes + DATA Packet size Bytes per ETFTP block + Burstsize Concatenated packets per burst + Burstrate Milliseconds per burst + Death Timer Seconds before closing idle links + Reserved M bit is mode: 0=read/put, 1=write/get + C bit is checksum: 0=header, 1=all + *T bit is transfer: 0=netascii, 1=binary + *R bit is re-negotiate: 0=off, 1=on + Max # Out Buffs Maximum allowed un-acknowledged buffers + Radio Delay *Seconds of delay from send to receive + Padding *Unused + Client String Filename. + + The KEEPALIVE, QUITACK, and DONE messages are identical to the common + header, except for the message type values. See Table 5, "KEEPALIVE, + QUITACK, and DONE Message Types,". + + + + +Polites, Wollman & Woo Experimental [Page 8] + +RFC 1986 ETFTP August 1996 + + + Table 5: KEEPALIVE, QUITACK, and DONE Message Types + + 1 2 3 + 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 + +---------------+---------------+---------------+---------------+ + |Checksum |Version |Type | + +---------------+---------------+---------------+---------------+ + |Length |Local Port | + +---------------+---------------+---------------+---------------+ + |Foreign Port |Longword Alignment Padding | + +---------------+---------------+---------------+---------------+ + + + The QUIT, ABORT, and REFUSED messages allow a string field to carry + the reason for the message. See Table 6, "QUIT, ABORT, and REFUSED + Message Types,". + + Table 6: QUIT, ABORT, and REFUSED Message Types + + 1 2 3 + 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 + +---------------+---------------+---------------+---------------+ + |Checksum |Version |Type | + +---------------+---------------+---------------+---------------+ + |Length |Local Port | + +---------------+---------------+---------------+---------------+ + |Foreign Port |Longword Alignment Padding | + +---------------+---------------+---------------+---------------+ + |Reason for QUIT/ABORT/REFUSED . . . | + +---------------+---------------+---------------+---------------+ + |. . . |Longword Alignment Padding | + +---------------+---------------+---------------+---------------+ + + The DATA and LDATA messages make up the bulk of the messages + transferred. The last packet of each buffer is flagged as an LDATA + message. Each and every packet of the last buffer has the reserved L + bit set. The highest consecutive sequence number is used for the + acknowledgment of CONTROL messages. It should contain the ID number + of the current CONTROL message being processed. Table 7, "DATA and + LDATA Message Types,", shows the DATA and LDATA formats. + + + + + + + + + + + +Polites, Wollman & Woo Experimental [Page 9] + +RFC 1986 ETFTP August 1996 + + + Table 7: DATA and LDATA Message Types + + 1 2 3 + 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 + +---------------+---------------+---------------+---------------+ + |Checksum |Version |Type | + +---------------+---------------+---------------+---------------+ + |Length |Local Port | + +---------------+---------------+---------------+---------------+ + |Foreign Port |Longword Alignment Padding | + +---------------+---------------+---------------+---------------+ + |Buffer Number | + +---------------+---------------+---------------+---------------+ + |High Consecutive Seq Num Rcvd |Packet Number | + +---------------+---------------+---------------+---------------+ + |Data Area Checksum Value |Reserved (MBZ) |L| + +---------------+---------------+---------------+---------------+ + + Buffer Number The first buffer number starts at 0 + Hi Con Seq Num The acknowledgment for CONTROL messages + Packet Number The first packet number starts at 0 + Data Checksum Checksum for data area only + Reserved L: the last buffer bit: 0=false, 1=true + + The NULL-ACK message type is sent as a response to a CONTROL_OK + message that modifies the current packet size, burstsize, or + burstrate. In acknowledging the CONTROL_OK message, the sender is + confirming the change request to the new packet size, burstsize, or + burstrate. If no modifications are requested, a NULL-ACK message is + unnecessary. See Table 8, "NULL-ACK Message Type," for further + details. + + Table 8: NULL-ACK Message Type + + 1 2 3 + 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 + +---------------+---------------+---------------+---------------+ + |Checksum |Version |Type | + +---------------+---------------+---------------+---------------+ + |Length |Local Port | + +---------------+---------------+---------------+---------------+ + |Foreign Port |Longword Alignment Padding | + +---------------+---------------+---------------+---------------+ + |High Consecutive Seq Num Rcvd |New Burstsize | + +---------------+---------------+---------------+---------------+ + |New Burstrate |*New DATA Packet size | + +---------------+---------------+---------------+---------------+ + + + + +Polites, Wollman & Woo Experimental [Page 10] + +RFC 1986 ETFTP August 1996 + + + The CONTROL messages have three subtypes: GO, OK, and RESEND as shown + in Tables 9-12. The CONTROL message common header may be followed by + any number of longword aligned subtype messages. + + Table 9: CONTROL Message Common Header + + 1 2 3 + 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 + +---------------+---------------+---------------+---------------+ + |Checksum |Version |Type | + +---------------+---------------+---------------+---------------+ + |Length |Local Port | + +---------------+---------------+---------------+---------------+ + |Foreign Port |Longword Alignment Padding | + +---------------+---------------+---------------+---------------+ + + Table 10: CONTROL_GO Message Subtype + + 1 2 3 + 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 + +---------------+---------------+---------------+---------------+ + |Subtype |Padding |Sequence Number | + +---------------+---------------+---------------+---------------+ + |Buffer Number | + +---------------+---------------+---------------+---------------+ + + Table 11: CONTROL_OK Message Subtype + + 1 2 3 + 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 + +---------------+---------------+---------------+---------------+ + |Subtype |Padding |Sequence Number | + +---------------+---------------+---------------+---------------+ + |Buffer Number | + +---------------+---------------+---------------+---------------+ + |New Offered Burstsize |New Offered Burstrate | + +---------------+---------------+---------------+---------------+ + |Current Control Timer Value |*New DATA Packet size | + +---------------+---------------+---------------+---------------+ + + + + + + + + + + + + +Polites, Wollman & Woo Experimental [Page 11] + +RFC 1986 ETFTP August 1996 + + + Table 12: CONTROL_RESEND Message Subtype + + 1 2 3 + 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 + +---------------+---------------+---------------+---------------+ + |Subtype |Padding |Sequence Number | + +---------------+---------------+---------------+---------------+ + |Buffer Number | + +---------------+---------------+---------------+---------------+ + |Number of Missing Packets |Longword Alignment Padding | + +---------------+---------------+---------------+---------------+ + |Packet Number (2 bytes) |. . . | + +---------------+---------------+---------------+---------------+ + |. . . |Longword Alignment Padding | + +---------------+---------------+---------------+---------------+ + +2.2 ETFTP COMMAND SET + + Being built from TFTP source code, ETFTP shares a significant portion + of TFTP's design. Like TFTP, ETFTP does NOT support user password + validation. The program does not support changing directories (i.e. + cd), neither can it list directories, (i.e. ls). All filenames must + be given in full paths, as relative paths are not supported. The + internal finite state machine was modified to support NETBLT message + types. + + The NETBLT protocol is implemented as closely as possible to what is + described in RFC 998, with a few exceptions. The client string field + in the OPEN message type is used to carry the filename of the file to + be transferred. Netascii or binary transfers are both supported. If + enabled, new packet sizes, burstsizes, and burstrates are re- + negotiated downwards when half or more of the blocks in a buffer + require retransmission. If 99% of the packets in a buffer is + successfully transferred without any retransmissions, packet size is + re-negotiated upwards. + + The interactive commands supported by the client process are similar + to TFTP. Here is the ETFTP command set. Optional parameters are in + square brackets. Presets are in parentheses. + + ? help, displays command list + ascii mode ascii, appends CR-LF per line + autoadapt toggles backoff function (on) + baudrate baud baud rate (16000 bits/sec) + binary mode binary, image transfer + blocksize bytes packet size in bytes (512 bytes/block) + bufferblock blks buffer size in blocks (128 blocks/buff) + burstsize packets burst size in packets (8 blocks/burst) + + + +Polites, Wollman & Woo Experimental [Page 12] + +RFC 1986 ETFTP August 1996 + + + connect host [p] establish connection with host at port p + exit ends program + get rfile lfile copy remote file to local file + help same as ? + mode choice set transfer mode (binary) + multibuff num number of buffers (2 buffers) + put lfile rfile copy local file to remote file + quit same as exit + radiodelay sec transmission delay in seconds (2 sec) + status display network parameters + trace toggles debug display (off). + +2.3 DATA TRANSFER AND FLOW CONTROL + + This is the scenario between client and server transfers: + + Client sends OPEN for connection, blocksize, buffersize, burstsize, + burstrate, transfer mode, and get or put. See M bit of reserved + field. + + Server sends a RESPONSE with the agreed parameters. + + Receiver sends a CONTROL_GO request sending of first buffer. + + Sender starts transfer by reading the file into multiple memory + buffers. See Figure 1, "File Segmentation,". Each buffer is divided + according to the number of bytes/block. Each block becomes a DATA + packet, which is concatenated according to the blocks/burst. Bursts + are transmitted according to the burstrate. Last data block is + flagged as LDATA type. + + +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ + | | | 0 | | L | | 4 | | 3 | ---- | 2 | | 1 | | 0 | + | | | +---+ +---+ +---+ +---+ +---+ +---+ +---+ + | | +-| | --> +---+ +---+ +---+ +---+ +---+ + | | --> | 1 | | L | | 3 | ---- | 2 | | 1 | | 0 | + +---+ +---+ +---+ +---+ +---+ +---+ +---+ + File Multi Buffers Blocks per Burst + + Figure 1. File Segmentation + + Receiver acknowledges buffer as CONTROL_OK or CONTROL_RESEND. + + If blocks are missing, a CONTROL_RESEND packet is transmitted. If + half or more of the blocks in a buffer are missing, an adaptive + algorithm is used for the next buffer transfer. If no blocks are + missing, a CONTROL_OK packet is transmitted. + + + + +Polites, Wollman & Woo Experimental [Page 13] + +RFC 1986 ETFTP August 1996 + + + Sender re-transmits blocks until receipt of a CONTROL_OK. If the + adaptive algorithm is set, then new parameters are offered, in the + CONTROL_OK message. The priority of the adaptive algorithm is: + + - Reduce packetsize by half (MIN = 16 bytes/packet) + - Reduce burstsize by one (MIN = 1 packet/burst) + - Reduce burstrate to actual tighttimer rate + + If new parameters are valid, the sender transmits a NULL-ACK packet, + to confirm the changes. + + Receiver sends a CONTROL_GO to request sending next buffer. + + At end of transfer, sender sends a QUIT to close the connection. + + Receiver acknowledges the close request with a DONE packet. + +2.4 TUNABLE PARAMETERS + + These parameters directly affect the throughput rate of ETFTP. + + Packetsize The packetsize is the number of 8 bit bytes per + packet. This number refers to the user data bytes in a block, (frame), + exclusive of any network overhead. The packet size has a valid range + from 16 to 1,448 bytes. The Maximum Transfer Unit (MTU) implemented in + most commercial network devices is 1,500 bytes. The de-facto industry + standard is 576 byte packets. + + Bufferblock The bufferblock is the number of blocks per buffer. + Each implementation may have restrictions on available memory, so the + buffersize is calculated by multiplying the packetsize times the + bufferblocks. + + Baudrate The baudrate is the bits per second transfer rate of + the slowest link (i.e., the radios). The baudrate sets the speed of + the sending process. The sending process cannot detect the actual + speed of the network, so the user must set the correct baudrate. + + Burstsize The burstsize in packets per burst sets how many + packets are concatenated and burst for transmission efficiency. The + burstsize times the packetsize must not exceed the available memory of + any intervening network devices. On the Ethernet portion of the + network, all the packets are sent almost instantaneously. It is + necessary to wait for the network to drain down its memory buffers, + before the next burst is sent. The sending process needs to regulate + the rate used to place packets into the network. + + + + + +Polites, Wollman & Woo Experimental [Page 14] + +RFC 1986 ETFTP August 1996 + + + Radiodelay The radiodelay is the time in seconds per burst it + takes to synchronize with the radio controllers. Any additional + hardware delays should be set here. It is the aggregate delay of the + link layer, such as transmitter key-up, FEC, crypto synchronization, + and propagation delays. + + These parameters above are used to calculate a burstrate, which is the + length of time it takes to transmit one burst. The ov is the overhead + of 72 bytes per packet of network encapsulation. A byte is defined as + 8 bits. The burstrate value is: + + burstrate = (packetsize+ov)*burstsize*8/baudrate + + In a effort to calculate the round trip time, when data is flowing in + one direction for most of the transfer, the OPEN and RESPONSE message + types are timed, and the tactical radio delays are estimated. Using + only one packet in each direction to estimate the rate of the link is + statistically inaccurate. It was decided that the radio delay should + be a constant provided by the user interface. However, a default + value of 2 seconds is used. The granularity of this value is in + seconds because of two reasons. The first reason is that the UNIX + supports a sleep function in seconds only. The second reason is that + in certain applications, such as deep space probes, a 16-bit integer + maximum of 32,767 seconds would suffice. + +2.5 DELAYS AND TIMERS + + From these parameters, several timers are derived. The control timer + is responsible for measuring the per buffer rate of transfer. The + SENDER copy is nicknamed the loosetimer. + + loosetimer = (burstrate+radiodelay)*bufferblock/burstsize + + The RECEIVER copy of the timer is nicknamed the tighttimer, which + measures the elapsed time between CONTROL_GO and CONTROL_OK packets. + The tighttimer is returned to the SENDER to allow the protocol to + adjust for the speed of the network. + + The retransmit timer is responsible for measuring the network receive + data function. It is used to set an alarm signal (SIGALRM) to + interrupt the network read. The retransmit timer (wait) is initially + set to be the greater of twice the round trip or 4 times the + radiodelay, plus a constant 5 seconds. + + + + + + + + +Polites, Wollman & Woo Experimental [Page 15] + +RFC 1986 ETFTP August 1996 + + + wait = MAX ( 2*roundtriptime, 4*radiodelay ) + 5 seconds + + and + + alarm timeout = wait. + + Each time the same read times out, a five second backoff is added to + the next wait. The backoff is necessary because the initial user + supplied radiodelay, or the initial measured round trip time may be + incorrect. + + The retransmit timer is set differently for the RECEIVER during a + buffer transfer. Before the arrival of the first DATA packet, the + original alarm time out is used. Once the DATA packets start + arriving, and for the duration of each buffer transfer, the RECEIVER + alarm time out is reset to the expected arrival time of the last DATA + packet (blockstogo) plus the delay (wait). As each DATA packet is + received, the alarm is decremented by one packet interval. This same + algorithm is used for receiving missing packets, during a RESEND. + + alarmtimeout = blockstogo*burstrate/burstsize + wait + + The death timer is responsible for measuring the idle time of a + connection. In the ETFTP program, the death timer is set to be equal + to the accumulated time of ten re-transmissions plus their associated + backoffs. As such, the death timer value in the OPEN and RESPONSE + message types is un-necessary. In the ETFTP program, this field could + be used to transfer the radio delay value instead of creating the two + new fields. + + The keepalive timer is responsible for resetting the death timer. + This timer will trigger the sending of a KEEPALIVE packet to prevent + the remote host from closing a connection due to the expiration of + its death timer. Due to the nature of the ETFTP server process, a + keepalive timer was not necessary, although it is implemented. + +2.6 TEST RESULTS + + The NETBLT protocol has been tested on other high speed networks + before, see RFC 1030 [6]. These test results in Tables 13 and 14, + "ETFTP Performance," were gathered from files transferred across the + network and LST-5C TACSAT radios. The radios were connected together + via a coaxial cable to provide a "clean" link. A clean link is + defined to a BER of 10e-5. The throughput rates are defined to be the + file size divided by the elapsed time resulting in bits per second + (bps). The elapsed time is measured from the time of the "get" or + "put" command to the completion of the transfer. This is an all + inclusive time measurement based on user perspective. It includes the + + + +Polites, Wollman & Woo Experimental [Page 16] + +RFC 1986 ETFTP August 1996 + + + connection time, transfer time, error recovery time, and disconnect + time. The user concept of elapsed time is the length of time it takes + to copy a file from disk to disk. These results show only the average + performances, including the occasional packet re-transmissions. The + network configuration was set as: + + ETFTP Parameters: + + Filesize 101,306 bytes + Radiodelay 2 seconds + Buffersize 16,384-131,072 bytes + Packetsize 512-2048 bytes + Burstsize 8-16 packets/burst + + Gracilis PackeTen Parameters: + + 0 TX Delay 400 milliseconds + 1 P Persist 255 [range 1-255] + 2 Slot Time 30 milliseconds + 3 TX Tail 300 milliseconds + 4 Rcv Buffers 8 2048 bytes/buffer + 5 Idle Code Flag + + Radio Parameters: + + Baudrate 16,000 bps + Encryption on + + + Table 13: ETFTP Performance at 8 Packets/Burst in Bits/Second + + +-----------+-----------+-----------+-----------+-----------+ + |buffersize |packetsize |packetsize |packetsize |packetsize | + |(bytes) |2,048 bytes|1,448 bytes|1,024 bytes|512 bytes | + +-----------+-----------+-----------+-----------+-----------+ + | 16,384 | 7,153 | 6,952 | 6,648 | 5,248 | + +-----------+-----------+-----------+-----------+-----------+ + | 32,768 | 7,652 | 7,438 | 7,152 | 4,926 | + +-----------+-----------+-----------+-----------+-----------+ + | 65,536 | 8,072 | 8,752 | 8,416 | 5,368 | + +-----------+-----------+-----------+-----------+-----------+ + | 131,072 | 8,828 | 9,112 | 7,888 | 5,728 | + +-----------+-----------+-----------+-----------+-----------+ + + + + + + + + +Polites, Wollman & Woo Experimental [Page 17] + +RFC 1986 ETFTP August 1996 + + + Table 14: ETFTP Performance at 16 Packets/Burst in Bits/Second + + +-----------+-----------+-----------+-----------+-----------+ + |buffersize |packetsize |packetsize |packetsize |packetsize | + |(bytes) |2,048 bytes|1,448 bytes|1,024 bytes|512 bytes | + +-----------+-----------+-----------+-----------+-----------+ + | 16,384 | 5,544 | 5,045 | 4,801 | 4,570 | + +-----------+-----------+-----------+-----------+-----------+ + | 32,768 | 8,861 | 8,230 | 8,016 | 7,645 | + +-----------+-----------+-----------+-----------+-----------+ + | 65,536 | 9,672 | 9,424 | 9,376 | 8,920 | + +-----------+-----------+-----------+-----------+-----------+ + | 131,072 | 10,432 | 10,168 | 9,578 | 9,124 | + +-----------+-----------+-----------+-----------+-----------+ + +2.7 PERFORMANCE CONSIDERATIONS + + These tests were performed across a tactical radio link with a + maximum data rate of 16000 bps. In testing ETFTP, it was found that + the delay associated with the half duplex channel turnaround time was + the biggest factor in throughput performance. Therefore, every + attempt was made to minimize the number of times the channel needed + to be turned around. Obviously, the easiest thing to do is to use as + big a buffer as necessary to read in a file, as acknowledgments + occurred only at the buffer boundaries. This is not always feasible, + as available storage on disk could easily exceed available memory. + However, the current ETFTP buffersize is set at a maximum of 524,288 + bytes. + + The larger packetsizes also improved performance. The limit on + packetsize is based on the 1500 byte MTU of network store and forward + devices. In a high BER environment, a large packetsize could be + detrimental to success. By reducing the packetsize, even though it + negatively impacts performance, reliability is sustained. When used + in conjunction with FEC, both performance and reliability can be + maintained at an acceptable level. + + The burstsize translates into how long the radio transmitters are + keyed to transmit. In ETFTP, the ideal situation is to have the first + packet of a burst arrive in the radio transmit buffer, as the last + packet of the previous burst is just finished being sent. In this + way, the radio transmitter would never be dropped for the duration of + one buffer. In a multi-user radio network, a full buffer transmission + would be inconsiderate, as the transmit cycle could last for several + minutes, instead of seconds. In measuring voice communications, + typical transmit durations are on the order of five to twenty + seconds. This means that the buffersize and burstsize could be + adjusted to have similar transmission durations. + + + +Polites, Wollman & Woo Experimental [Page 18] + +RFC 1986 ETFTP August 1996 + + +3. REFERENCE SECTION + + [1] Clark, D., Lambert, M., and L. Zhang, + "NETBLT: A Bulk Data Transfer Protocol", RFC 998, MIT, + March 1987. + + [2] Postel, J., "User Datagram Protocol" STD 6, RFC 768, + USC/Information Sciences Institute, August 1980. + + [3] Sollins, K., "Trivial File Transfer Protocol", STD 33, + RFC 1350, MIT, July 1992. + + [4] MIL-STD-2045-44500, 18 June 1993, "Military Standard Tactical + Communications Protocol 2 (TACO 2) fot the National Imagery + Transmission Format Standard", Ft. Monmouth, New Jersey. + + [5] Stevens, W. Richard, 1990, "UNIX Network Programming", + Prentice-Hall Inc., Englewood, New Jersey, Chapter 12. + + [6] Lambert, M., "On Testing the NETBLT Protocol over + Divers Networks", RFC 1030, MIT, November 1987. + +4. SECURITY CONSIDERATIONS + + The ETFTP program is a security loophole in any UNIX environment. + There is no user/password validation. All the problems associated to + TFTP are repeated in ETFTP. The server program must be owned by root + and setuid to root in order to work. As an experimental prototype + program, the security issue was overlooked. Since this protocol has + proven too be a viable solution in tactical radio networks, the + security issues will have to be addressed, and corrected. + + + + + + + + + + + + + + + + + + + + +Polites, Wollman & Woo Experimental [Page 19] + +RFC 1986 ETFTP August 1996 + + +5. AUTHORS' ADDRESSES + + William J. Polites + The Mitre Corporation + 145 Wyckoff Rd. + Eatontown, NJ 07724 + + Phone: (908) 544-1414 + EMail:wpolites@mitre.org + + + William Wollman + The Mitre Corporation + 145 Wyckoff Rd. + Eatontown, NJ 07724 + + Phone: (908) 544-1414 + EMail:wwollman@mitre.org + + + David Woo + The Mitre Corporation + 145 Wyckoff Rd. + Eatontown, NJ 07724 + + Phone: (908) 544-1414 + EMail: dwoo@mitre.org + + + Russ Langan + U.S. Army Communications Electronics Command (CECOM) + AMSEL-RD-ST-SP + ATTN: Russell Langan + Fort Monmouth, NJ 07703 + + Phone: (908) 427-2064 + Fax: (908) 427-2822 + EMail: langanr@doim6.monmouth.army.mil + + + + + + + + + + + + + +Polites, Wollman & Woo Experimental [Page 20] + +RFC 1986 ETFTP August 1996 + + +6. GLOSSARY + + ATD Advanced Technology Demonstration + AX.25 Amateur Radio X.25 Protocol + BER Bit Error Rate + EPLRS Enhanced Position Location Reporting Systems + ETFTP Enhanced Trivial File Transfer Protocol + FEC Forward Error Correction + FTP File Transfer Protocol + HF High Frequency + LCU Lightweight Computer Unit + ms milliseconds + MTU Maximum Transfer Unit + NETBLT NETwork Block Transfer protocol + NITFS National Imagery Transmission Format Standard + PC Personal Computer + RNC Radio Network Controller + SAS Survivable Adaptive Systems + SATCOM SATellite COMmunications + SCO Santa Cruz Operations + SINCGARS SINgle Channel Ground and Airborne Radio Systems + SLIP Serial Line Internet Protocol + TACO2 Tactical Communications Protocol 2 + TCP Transmission Control Protocol + TFTP Trivial File Transfer Protocol + UDP User Datagram Protocol + UHF Ultra High Frequency + + * Modification from NETBLT RFC 998. + * The new packet size is a modification to the NETBLT RFC 998. + * The new packet size is a modification to the NETBLT RFC 998. + + + + + + + + + + + + + + + + + + + + +Polites, Wollman & Woo Experimental [Page 21] + |