RFC 1986
Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)
RFC 1986: Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP) 🦋
Working Group: Network Working Group 💜
Authors: W. Polites, W. Wollman, D. Woo (The MITRE Corporation), and R. Langan (U.S. ARMY CECOM) 👑
Category: Experimental 🧪
Date: August 1996 🌸
Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🙈
Status of this Memo 🌈
This memo defines an Experimental Protocol for the Internet community. It 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 ✨
Okay so this doc is all about the Enhanced Trivial File Transfer Protocol (ETFTP) 🎀. ETFTP is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], but as a file transfer application program 💅. It runs on top of the User Datagram Protocol (UDP), RFC 768 [2], which is its transport layer. The two protocols get layered together to make the ETFTP client server application 🦋. The name comes from Trivial File Transfer Protocol (TFTP), RFC 1350 [3], because ETFTP's program is built out of TFTP's source code (the building blocks!) 🧚. This implementation also builds on, but is different from, the work done by the National Imagery Transmission Format Standard [4].
This doc is out there for discussion and comments 🫶 about making data transfer tools faster (throughput, bestie!) over Internet Protocol (IP) compliant, half duplex, radio networks 📡.
There are so many file transfer programs for computer networks, and lots of them are designed for high-speed, low bit error rate (BER) cabled networks 💻. In tactical radio networks, though, traditional file transfer protocols like File Transfer Protocol (FTP) and TFTP don't always perform well 💀. The main reason is that tactical half duplex radio networks usually give you slow speeds, long delays, and a high BER on the links 📉. ETFTP is designed so a user can control transmission parameters and optimize file transfer rates over half-duplex radio links ✨.
The tactical radio network used to test this app was developed by the Survivable Adaptive Systems (SAS) Advanced Technology Demonstration (ATD) 🛰️. Part of the SAS ATD program was to deal with the problems of 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 discusses results 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 a Motorola LST-5C tactical Ultra High Frequency (UHF) satellite communications (SATCOM) radio 🔥. Table 1, "Network Transfer Rates," shows the equipment network connections and the bandwidth of the physical media linking 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 on network configurations that were both stationary and on-the-move 🚗. This setup didn't 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 on the Transmission Control Protocol (TCP) for reliable communications 🤝. For a bunch of file sizes, throughput measurements ranged between 80 and 400 bps 😭. At times TCP connections could be opened, but the data transfers were unsuccessful 💔. This was most likely because the TCP connection synchronization packets are smaller than the TCP data packets. Because the link had a high bit error rate, the smaller packets were way more likely to arrive 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 to the poor conditions of the communication link 💀.
The current focus is to increase 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 👯. Looking at the data helped determine that several factors limited throughput. A brief description of those limiting factors, plus solutions that can reduce these networking limitations, is provided below 🎀.
Link Quality
The channel quality of a typical narrow-band UHF satellite link doesn't support data communications well without adding a forward error correction (FEC) capability 😩. From the data collected, 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 improves an average 10e-3 BER channel to an average 10e-5 BER channel 🌟.
Delays
Including satellite propagation delays, the tactical satellite radios need approximately 1.25 seconds for radio synchronization before they can transmit any data across the communication channel ⏳. So limiting the number of channel accesses will help data throughput go up 📈. This can be done by minimizing the number of acknowledgments needed during the file transfer. FTP generates lots of acknowledgments, which decreases throughput by increasing the number of satellite channel accesses 🙈.
To clarify, when an FTP connection request is generated, it's 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 the modem/crypto synchronization happens ⏱️. Once synchronization is achieved, the FTP connection request is transmitted. The transmitting terminal then drops the channel, and the modem/crypto synchronization is lost 😵. Assuming the request was received successfully, the receiving host processes it and sends an acknowledgment. Then the modem/crypto have to synchronize again before the acknowledgment can be transmitted 🔁. On top of that, propagation delays over a UHF satellite add roughly 500 ms to the total round trip delay 🌍.
Solution: Compared to FTP, NETBLT significantly reduces the number of acknowledgments needed to finish a file transfer 💅. So leveraging the features available in an implementation of NETBLT will significantly improve throughput across the narrow-band UHF satellite communication link 👑.
To reduce the number of channel accesses, a bunch of AX.25 parameters were modified 🧚. These included the value of p for use in 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 before attempting to access the channel ⏰. The transmit tail increases the amount of time the radio carrier stays on before the channel gets dropped 📻. Transmit delay is normally equal to the radio synchronization time. By adjusting these parameters to fit the tactical satellite environment, you can get better communication performance 🌸.
First, in ETFTP, several packets within a buffer are transmitted in one burst 💥. If the buffer is split into ten packets, each of 1024 bytes, then 10,240 bytes of data get transmitted with each channel access. You can 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 make sure all the packets in the buffer are sent in a single channel access 🔑. Together, these two features let the system transmit an entire file (for example, 100,000 bytes) with just a single channel access, just by adjusting buffer size 🤯. Thirdly, the ETFTP protocol only acknowledges each buffer, not each packet. So a single acknowledgment is sent from the receiving terminal, containing a request for the missing packets within each buffer, which cuts down on the number of acknowledgment packets sent 🫶. That in turn reduces how often 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 👯♀️. Honestly though, this value of p would not be used if more users were sharing the satellite channel 🙈.
Backoffs 🔁
Okay so, most TCP packages come with slow start and backoff algorithms that assume packet loss means network congestion 🚦. But over a tactical half duplex channel shared by just two users, packet loss is mostly caused by poor channel quality, not congestion 😭. So a linear backoff at the transport layer is recommended 💖.
In a tactical radio network there are tons of cases where one host is hooked up to multiple radios 📻. Layer two handles channel access, and that gets tuned with parameters like p-persistence and slot time 🎛️. Here's the tea: the exponential backoff from the transport layer stacks on top of the random backoff from the data link layer, and in most cases that means the radio network misses a bunch of network access opportunities 💀. A linear backoff cuts down on those missed data link network access opportunities ✨.
The fix: the tunable parameters and timers were modified to resemble the ones suggested by NETBLT 🎀.
Packet Size 📦
In a tactical environment the channel conditions change super fast 🌪️. Constantly sending large packets under 10e-3 BER (that's bit error rate, bestie) conditions makes the effective throughput go down 📉.
The fix: packet sizes get adjusted on the fly based on how well the buffer transfers are going 🔄. If 99 percent of all packets within a buffer are received successfully, the 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 describes a datagram that includes all network overhead 📨. The term block describes 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 connection request came in on the well known port 🚀.
As stated earlier, the transport layer for ETFTP is UDP, which won't 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 let the NETBLT concepts get tested without modifying the operating system's transport or network layers 🧪. The stack for FTP, TFTP and ETFTP is shown in Table 2, "Four Layer Protocol Model," below 👇.
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 lets files 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 first 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," below 🧁. The Ethernet, SLIP, and AX.25 headers are mutually exclusive. They get stripped off and added by the appropriate hardware layer 🔧.
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 boundaryThe OPEN and RESPONSE messages are similar, and they're shown in Table 4, "OPEN and RESPONSE Message Types," below 👀. The client string field is used to carry the filename to be transferred 📄.
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 |
+---------------+---------------+---------------+---------------+Here's what each field in Table 4 means 🔍:
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," below ✨.
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 let a string field carry the reason for the message 💬. See Table 6, "QUIT, ABORT, and REFUSED Message Types," below 👇.
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 are the heavy lifters 💪, making up the bulk of the messages transferred. The last packet of each buffer gets flagged as an LDATA message, 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 🌸.
Table 7: DATA and LDATA Message Types
The header diagram is the bit layout for the next control message, with its field definitions below it, followed by the 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 |
+---------------+---------------+---------------+---------------+
|Buffer Number |
+---------------+---------------+---------------+---------------+
|High Consecutive Seq Num Rcvd |Packet Number |
+---------------+---------------+---------------+---------------+
|Data Area Checksum Value |Reserved (MBZ) |L|
+---------------+---------------+---------------+---------------+Here's what each field means 🎀:
Buffer Number: the first buffer number starts at0.Hi Con Seq Num: the acknowledgment for CONTROL messages.Packet Number: the first packet number starts at0.Data Checksum: checksum for the data area only.Reserved:Lis the last buffer bit, where0means false and1means true.
Okay, so the NULL-ACK message type is the reply you send to a CONTROL_OK message that changes the current packet size, burstsize, or burstrate. 💖 When you acknowledge that CONTROL_OK, you're basically confirming the change to the new packet size, burstsize, or burstrate. ✨ If nobody asked for any changes, a NULL-ACK is unnecessary, so skip it 🙈. Check out Table 8, "NULL-ACK Message Type," for the full scoop 💅.
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 |
+---------------+---------------+---------------+---------------+Next up are the CONTROL messages 🦋. They come in three subtypes, GO, OK, and RESEND, which you can see in Tables 9-12. The CONTROL message common header can be followed by any number of longword aligned subtype messages, so you can stack them up 🥞.
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 |
+---------------+---------------+---------------+---------------+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 ✨
Okay, so ETFTP is built from TFTP source code 🌸, which means it borrows a lot of TFTP's design. Just like TFTP, ETFTP does not support user password validation 🙈. It also can't change directories (no cd) or list them (no ls) 💀. Every filename has to be given as a full path, because relative paths aren't supported. The internal finite state machine got modified to support NETBLT message types, so it's not just TFTP with a new coat of paint 💅.
The NETBLT protocol is implemented as closely as possible to what RFC 998 describes, with a few exceptions 🦋. The client string field in the OPEN message type carries the filename of the file being transferred. Both netascii and binary transfers are supported 🍓.
Here's the lowkey best part 👑. If it's enabled, the new packet sizes, burstsizes, and burstrates get re-negotiated downwards when half or more of the blocks in a buffer need retransmission. On the flip side, if 99% of the packets in a buffer transfer successfully without any retransmissions, the packet size gets re-negotiated upwards. ✨ Iconic adaptive behavior, no cap 🔥.
The interactive commands the client process supports are similar to TFTP's. Here's the whole ETFTP command set 💜. Optional parameters are in square brackets, and 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)
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 🦋
Okay bestie, here's how a client and server transfer goes, step by step 🧚.
- The client sends an OPEN for the connection, blocksize, buffersize, burstsize, burstrate, transfer mode, and get or put. See the M bit of the reserved field 🌈.
- The server sends a RESPONSE with the agreed parameters 🫶.
- The receiver sends a CONTROL_GO to request sending of the first buffer 🚀.
Next, the sender starts the transfer by reading the file into multiple memory buffers ✨. See Figure 1, "File Segmentation," below. Each buffer is divided according to the number of bytes per block. Each block becomes a DATA packet, and those get concatenated according to the blocks per burst 💖. Bursts go out according to the burstrate. The last data block gets flagged as LDATA type 🏁.
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | 0 | | L | | 4 | | 3 | ---- | 2 | | 1 | | 0 |
| | | +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | --> | 1 | | L | | 3 | ---- | 2 | | 1 | | 0 |
+---+ +---+ +---+ +---+ +---+ +---+ +---+
File Multi Buffers Blocks per BurstFigure 1. File Segmentation
The receiver acknowledges each buffer as CONTROL_OK or CONTROL_RESEND 🎀. If any blocks are missing, a CONTROL_RESEND packet gets sent. If half or more of the blocks in a buffer are missing, an adaptive algorithm kicks in for the next buffer transfer 😭. If no blocks are missing, a CONTROL_OK packet gets sent 🥳.
The sender keeps re-transmitting blocks until it gets a CONTROL_OK 🔁. If the adaptive algorithm is set, new parameters get offered in that CONTROL_OK message 💅. The priority of the adaptive algorithm goes like this:
- Reduce packetsize by half (MIN = 16 bytes/packet)
- Reduce burstsize by one (MIN = 1 packet/burst)
- Reduce burstrate to actual tighttimer rate
If the new parameters are valid, the sender transmits a NULL-ACK packet to confirm the changes ✅.
Then the receiver sends a CONTROL_GO to request the next buffer 🏃♀️.
When the transfer ends, the sender sends a QUIT to close the connection 👋. The receiver acknowledges that close request with a DONE packet 💜.
2.4 TUNABLE PARAMETERS 🎀
okay so these are the knobs that literally decide how fast ETFTP goes 🔥 each one directly affects the throughput rate, so pay attention bestie 💅
Packetsize 📦 this is how many 8 bit bytes go in each packet. It only counts the user data bytes in a block (frame), not any network overhead. The valid range is 16 to 1,448 bytes. Most commercial network devices use an MTU of 1,500 bytes, and the de-facto industry standard is 576 byte packets ✨
Bufferblock 🧱 this is the number of blocks per buffer. Every implementation might have limits on memory, so the buffersize gets calculated by multiplying the packetsize times the bufferblocks 🍓
Baudrate 📡 this is the bits per second of the slowest link, which is the radios 😤 It sets how fast the sending process goes. The sending process can't detect how fast the network actually is, so the user must set the correct baudrate. no pressure 🙈
Burstsize 💥 this is the number of packets per burst, and it sets how many packets get bundled together and sent in one go for efficiency. burstsize times packetsize must not go over the available memory of any intervening network devices. On the Ethernet part of the network, all the packets go out almost instantly, so the sender has to wait for the network to drain its memory buffers before the next burst. The sending process needs to regulate how fast it puts packets into the network 🫶
Radiodelay ⏳ this is the time in seconds per burst it takes to sync up with the radio controllers. Any extra hardware delays should be set here too. It's the total delay of the link layer, like transmitter key-up, FEC, crypto synchronization, and propagation delays 🦋
These parameters get used to calculate the burstrate, which is how long one burst takes to transmit. The ov is 72 bytes of network encapsulation overhead per packet, and a byte is 8 bits:
burstrate = (packetsize+ov)*burstsize*8/baudrateNow the round trip time stuff 🌙 When data mostly flows in one direction, the OPEN and RESPONSE message types get timed, and the tactical radio delays get estimated from that. Using only one packet in each direction to estimate the link rate is statistically inaccurate, so it was decided that the radio delay should be a constant that the user interface provides. There's a default value of 2 seconds though 💜 The granularity is in seconds for two reasons. First, UNIX only has a sleep function in seconds. Second, in some applications like deep space probes, a 16-bit integer max of 32,767 seconds would be enough 🌌
2.5 DELAYS AND TIMERS ⏰
Several timers get derived from these parameters. The control timer measures the per buffer rate of transfer. The SENDER's copy is nicknamed the loosetimer:
loosetimer = (burstrate+radiodelay)*bufferblock/burstsizeThe RECEIVER's copy is the tighttimer, and it measures the elapsed time between CONTROL_GO and CONTROL_OK packets. The tighttimer gets sent back to the SENDER so the protocol can adjust for the speed of the network 🔄
The retransmit timer measures the network receive data function. It sets off an alarm signal (SIGALRM) to interrupt the network read. The retransmit timer (wait) starts out as the greater of twice the round trip or 4 times the radiodelay, plus a constant 5 seconds:
wait = MAX ( 2*roundtriptime, 4*radiodelay ) + 5 secondsand
alarm timeout = wait.Every time the same read times out, a five second backoff gets added to the next wait. The backoff is needed because the user supplied radiodelay, or the first measured round trip time, might be wrong to begin with 🙃
The RECEIVER sets its retransmit timer differently during a buffer transfer. Before the first DATA packet shows up, the original alarm timeout is used. Once the DATA packets start arriving, and for the whole duration of each buffer transfer, the RECEIVER's alarm timeout gets reset to the expected arrival time of the last DATA packet (blockstogo) plus the delay (wait). Each time a DATA packet comes in, the alarm goes down by one packet interval. The exact same algorithm gets used when receiving missing packets during a RESEND 🎯
alarmtimeout = blockstogo*burstrate/burstsize + waitThe death timer measures how long a connection sits idle 💀 In the ETFTP program, the death timer is set equal to the accumulated time of ten re-transmissions plus their associated backoffs. Because of that, the death timer value in the OPEN and RESPONSE message types is un-necessary. In the ETFTP program, that field could carry the radio delay value instead, so there's no need to create the two new fields 🧚
The keepalive timer resets the death timer. It triggers the sending of a KEEPALIVE packet to stop the remote host from closing the connection when its death timer expires. Because of how the ETFTP server process works, a keepalive timer wasn't necessary, although it is implemented 🫧
2.6 TEST RESULTS 📊
NETBLT has been tested on other high speed networks before, see RFC 1030 [6]. The results in Tables 13 and 14, "ETFTP Performance," came from files transferred across the network and LST-5C TACSAT radios. The radios were hooked together with a coaxial cable to make a "clean" link. A clean link means a BER of 10e-5 ✨ Throughput is the file size divided by the elapsed time, giving bits per second (bps). Elapsed time runs from the "get" or "put" command to the end of the transfer. It's an all inclusive measurement from the user's point of view, so it counts the connection time, transfer time, error recovery time, and disconnect time too. The user's idea of elapsed time is how long it takes to copy a file from disk to disk. These results only show average performance, 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 onTable 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 |
+-----------+-----------+-----------+-----------+-----------+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 ran across a tactical radio link with a maximum data rate of 16000 bps. While testing ETFTP, the team found that the delay from half duplex channel turnaround time was the biggest factor in throughput performance 😩 So they tried really hard to cut down how many times the channel had to be turned around. The easiest move is to use as big a buffer as necessary to read in a file, since acknowledgments only happen at buffer boundaries. That's not always doable, though, because disk storage can easily be bigger than available memory. The current ETFTP buffersize maxes out at 524,288 bytes 👑
Larger packetsizes also improved performance. The packetsize limit is based on the 1500 byte MTU of network store and forward devices. In a high BER environment, a big packetsize could hurt the chances of success. Shrinking the packetsize hurts performance, but it keeps reliability going strong 💪 When it's paired with FEC, both performance and reliability can stay at an acceptable level 🌈
Burstsize decides how long the radio transmitters stay keyed up. The dream scenario is for the first packet of a burst to land in the radio transmit buffer right as the last packet of the previous burst finishes sending. That way the radio transmitter never gets dropped for the length of one buffer 🦋 On a multi-user radio network, sending a full buffer would be super inconsiderate, since one transmit cycle could last several minutes instead of seconds. For voice communications, typical transmit durations are around five to twenty seconds. So the buffersize and burstsize could be adjusted to get similar transmission durations ✨
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 🚨
okay bestie, this part is NOT cute 😭 ETFTP is literally a security loophole in any UNIX environment 💀 There is no user/password validation at all. And all the problems that come with TFTP get copied right over into ETFTP 🙈
The server program has to be owned by root and setuid to root just to work. Like, that's a big deal. 👑 It was an experimental prototype, so the security issue got overlooked. But here's the plot twist: this protocol has actually proven to be a viable solution in tactical radio networks ✨ So the security issues will have to be addressed and corrected. No cap, that's not optional anymore 🫶
5. AUTHORS' ADDRESSES 🦋
these are the brilliant people who built this, so give them their flowers 💐
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.mil6. GLOSSARY 📖
the acronym cheat sheet, iykyk 🌸
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.that's the whole thing, bestie! 🌈💖 you made it through ETFTP 🧚
📦 where this page comes from
- ietf: rfc1986 1996-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms