idnits 2.17.1 draft-rfced-exp-polites-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 982 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 121 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Experimental ', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1995) is 10542 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 846 looks like a reference -- Missing reference section? '2' on line 850 looks like a reference -- Missing reference section? '3' on line 853 looks like a reference -- Missing reference section? '4' on line 856 looks like a reference -- Missing reference section? '5' on line 860 looks like a reference -- Missing reference section? '6' on line 863 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Expires November 1996 INTERNET-DRAFT 4 Network Working Group W. Polites, W. Wollman, D. Woo 5 INTERNET-DRAFT The MITRE Corporation 6 Category: Experimental R. Langan 7 U.S. ARMY CECOM 8 June 1995 10 Enhanced Trivial File Transfer Protocol (ETFTP) 12 14 1. STATUS SECTION 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a 25 "working draft" or "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the internet-drafts Shadow 29 Directories on: 31 ftp.is.co.za (Africa) 32 nic.nordu.net (Europe) 33 ds.internic.net (US East Coast) 34 ftp.isi.edu (US West Coast) 35 munnari.oz.au (Pacific Rim) 37 2. INTRODUCTION SECTION 39 This document is a description of the Enhanced Trivial File Transfer 40 Protocol (ETFTP). This protocol is an experimental implementation of 41 the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file 42 transfer application program. It uses the User Datagram Protocol 43 (UDP), RFC 768 [2], as its transport layer. The two protocols are 44 layered to create the ETFTP client server application. The ETFTP 45 program is named after Trivial File Transfer Protocol (TFTP), RFC 1350 46 [3], because the source code from TFTP is used as the building blocks 47 for the ETFTP program. This implementation also builds on but differs 48 from the work done by the National Imagery Transmission Format 49 Standard [4]. 51 This document is published for discussion and comment on improving the 52 throughput performance of data transfer utilities over Internet 53 Protocol (IP) compliant, half duplex, radio networks. 55 There are many file transfer programs available for computer networks. 56 Many of these programs are designed for operations through high-speed, 57 low bit error rate (BER) cabled networks. In tactical radio networks, 58 traditional file transfer protocols, such as File Transfer Protocol 59 (FTP) and TFTP, do not always perform well. This is primarily because 60 tactical half duplex radio networks typically provide slow-speed, long 61 delay, and high BER communication links. ETFTP is designed to allow a 62 user to control transmission parameters to optimize file transfer 63 rates through half-duplex radio links. 65 The tactical radio network used to test this application was developed 66 by the Survivable Adaptive Systems (SAS) Advanced Technology 67 Demonstration (ATD). Part of the SAS ATD program was to address the 68 problems associated with extending IP networks across tactical radios. 69 Several tactical radios, such as, SINgle Channel Ground and Airborne 70 Radio Systems (SINCGARS), Enhanced Position Location Reporting Systems 71 (EPLRS), Motorola LST-5C, and High Frequency (HF) radios have been 72 interfaced to the system. This document will discuss results obtained 73 from using ETFTP across a point-to-point LST-5C tactical SATellite 74 COMmunications (SATCOM) link. The network includes a 25 Mhz 486 75 Personal Computer (PC) called the Army Lightweight Computer Unit 76 (LCU), Cisco 2500 routers, Gracilis PackeTen Network switches, 77 Motorola Sunburst Cryptographic processors, a prototype forward error 78 correction (FEC) device, and Motorola LST-5C tactical Ultra High 79 Frequency (UHF) satellite communications (SATC! OM) radio. Table 1, 80 "Network Trans fer Rates," describes the equipment network connections 81 and the bandwidth of the physical media interconnecting the devices. 83 Table 1: Network Transfer Rates 85 +-------------------------------+-------------------------------+ 86 | Equipment | Rate (bits per second) | 87 +-------------------------------+-------------------------------+ 88 | Host Computer (486 PC) | 10,000,000 Ethernet | 89 +-------------------------------+-------------------------------+ 90 | Cisco Router | 10,000,000 Ethernet to | 91 | | 19,200 Serial Line Internet | 92 | | Protocol (SLIP) | 93 +-------------------------------+-------------------------------+ 94 | Gracilis PackeTen | 19,200 SLIP to | 95 | | 16,000 Amateur Radio (AX.25) | 96 +-------------------------------+-------------------------------+ 97 | FEC | half rate or quarter rate | 98 +-------------------------------+-------------------------------+ 99 | Sunburst Crypto | 16,000 | 100 +-------------------------------+-------------------------------+ 101 | LST-5C Radio | 16,000 | 102 +-------------------------------+-------------------------------+ 104 During 1993, the MITRE team collected data for network configurations 105 that were stationary and on-the-move. This network configuration did 106 not include any Forward Error Correction (FEC) at the link layer. 107 Several commercially available implementations of FTP were used to 108 transfer files through a 16 kbps satellite link. FTP relies upon the 109 Transmission Control Protocol (TCP) for reliable communications. For 110 a variety of file sizes, throughput measurements ranged between 80 and 111 400 bps. At times, TCP connections could be opened, however, data 112 transfers would be unsuccessful. This was most likely due to the 113 smaller TCP connection synchronization packets, as compared to the TCP 114 data packets. Because of the high bit error rate of the link, the 115 smaller packets were much more likely to be received without error. In 116 most cases, satellite channel utilization was less than 20 percent. 117 Very often a file transfer would fail because FTP implementations 118 would curtail the transfer due t! o the poor conditions of the commu 119 nication link. 121 The current focus is to increase the throughput and channel 122 utilization over a point to point, half duplex link. Follow on 123 experiments will evaluate ETFTP's ability to work with multiple hosts 124 in a multicast scenario. Evaluation of the data collected helped to 125 determine that several factors limited data throughput. A brief 126 description of those limiting factors, as well as, solutions that can 127 reduce these networking limitations is provided below. 129 Link Quality 131 The channel quality of a typical narrow-band UHF satellite link does 132 not sufficiently support data communications without the addition of a 133 forward error correction (FEC) capability. From the data collected, 134 it was determined that the UHF satellite link supports, on average, a 135 10e-3 bit error rate. 137 Solution: A narrow-band UHF satellite radio FEC prototype was 138 developed that improves data reliability, without excessively 139 increasing synchronization requirements. The prototype FEC increased 140 synchronization requirements by less than 50 milliseconds (ms). The 141 FEC implementation will improve an average 10e-3 BER channel to an 142 average 10e-5 BER channel. 144 Delays 146 Including satellite propagation delays, the tactical satellite radios 147 require approximately 1.25 seconds for radio synchronization prior to 148 transmitting any data across the communication channel. Therefore, 149 limiting the number of channel accesses required will permit data 150 throughput to increase. This can be achieved by minimizing the number 151 of acknowledgments required during the file transfer. FTP generates 152 many acknowledgments which decreases throughput by increasing the 153 number of satellite channel accesses required. 155 To clarify, when a FTP connection request is generated, it is sent via 156 Ethernet to the router and then forwarded to the radio network 157 controller (RNC). The elapsed time is less than 30 ms. The RNC keys 158 the crypto unit and 950 ms later modem/crypto synchronization occurs. 159 After synchronization is achieved, the FTP connection request is 160 transmitted. The transmitting terminal then drops the channel and the 161 modem/crypto synchronization is lost. Assuming that the request was 162 received successfully, the receiving host processes the request and 163 sends an acknowledgment. Again the modem/crypto have to synchronize 164 prior to transmitting the acknowledgment. Propagation delays over a 165 UHF satellite also adds roughly 500 ms to the total round trip delay. 167 Solution: When compared to FTP, NETBLT significantly reduces the 168 number of acknowledgments required to complete a file transfer. 169 Therefore, leveraging the features available within an implementation 170 of NETBLT will significantly improve throughput across the narrow-band 171 UHF satellite communication link. 173 To reduce the number of channel accesses required, a number of AX.25 174 parameters were modified. These included the value of p for use 175 within the p-persistence link layer protocol, the slot time, the 176 transmit tail time, and the transmit delay time. The p-persistence is 177 a random number threshold between 0 and 255. The slot time is the 178 time to wait prior to attempting to access the channel. The transmit 179 tail increases the amount of time the radio carrier is held on, prior 180 to dropping the channel. Transmit delay is normally equal to the value 181 of the radio synchronization time. By adjusting these parameters to 182 adapt to the tactical satellite environment, improved communication 183 performance can be achieved. 185 First, in ETFTP, several packets within a buffer are transmitted 186 within one burst. If the buffer is partitioned into ten packets, each 187 of 1024 bytes, then 10,240 bytes of data is transmitted with each 188 channel access. It is possible to configure ETFTP's burstsize to equal 189 the number of packets per buffer. Second, the transmit tail time was 190 increased to hold the key down on the transmitter long enough to 191 insure all of the packets within the buffer are sent in a single 192 channel access. These two features, together, allow the system to 193 transmit an entire file (example, 100,000 bytes) with only a single 194 channel access by adjusting buffer size. Thirdly, the ETFTP protocol 195 only acknowledges each buffer, not each packet. Thus, a single 196 acknowledgment is sent from the receiving terminal containing a 197 request for the missing packets within each buffer, reducing the 198 number of acknowledgment packets sent. Which in turn, reduced the 199 number of times the channel has to be turned around. 201 To reduce channel access time, p-persistence was set to the maximum 202 value and slot time to a minimum value. These settings support 203 operations for a point-to-point communication link between two users. 204 This value of p would not be used if more users were sharing the 205 satellite channel. 207 Backoffs 209 TCP's slow start and backoff algorithms implemented in most 210 TCP packages assume that packet loss is due to network congestion. 211 When operating across a tactical half duplex communication channel 212 dedicated to two users, packet loss is primarily due to poor channel 213 quality, not network congestion. A linear backoff at the transport 214 layer is recommended. In a tactical radio network there are numerous 215 cases where a single host is connected to multiple radios. In a 216 tactical radio network, layer two will handle channel access. Channel 217 access will be adjusted through parameters like p-persistence and slot 218 time. The aggregate effect of the exponential backoff from the 219 transport layer added to the random backoff of the data link layer, 220 will in most cases, cause the radio network to miss many network 221 access opportunities. A linear backoff will reduce the number missed 222 data link network access opportunities 224 Solution: Tunable parameters and timers have been modified to resemble 225 those suggested by NETBLT. 227 Packet Size 229 In a tactical environment, channel conditions change rapidly. 230 Continuously transmitting large packets under 10e-3 BER conditions 231 reduces effective throughput. 233 Solution: Packet sizes are dynamically adjusted based upon the success 234 of the buffer transfers. If 99 percent of all packets within a buffer 235 are received successfully, packet size can be increased to a 236 negotiated value. If 50 percent or more of all packets within a 237 buffer are not successfully delivered, the packet size can be 238 decreased to a negotiated value. 240 3. PROTOCOL DESCRIPTION 242 Throughout this document the term packet is used to describe a 243 datagram that includes all network overhead. A block is used to 244 describe information, without any network encapsulation. 246 The original source files for TFTP, as downloaded from ftp.uu.net, 247 were modified to implement the ETFTP/NETBLT protocol. These same files 248 are listed in "UNIX Network Programming" [5]. 250 ETFTP was implemented for operations under the Santa Cruz Operations 251 (SCO) UNIX. In the service file, "/etc/services", an addition was made 252 to support "etftp" at a temporary well known port of "1818" using 253 "UDP" protocol. The file, "/etc/inetd.conf", was modified so the 254 "inetd" program could autostart the "etftpd" server when a connection 255 request came in on the well known port. 257 As stated earlier, the transport layer for ETFTP is UDP, which will 258 not be discussed further here. This client server application layer 259 protocol is NETBLT, with four notable differences. 261 The first change is that this NETBLT protocol is implemented on top of 262 the UDP layer. This allowed the NETBLT concepts to be tested without 263 modifying the operating system's transport or network layers. Table 2, 264 "Four Layer Protocol Model," shows the protocol stack for FTP, TFTP 265 and ETFTP. 267 Table 2: Four Layer Protocol Model 269 +---------------------------------------------------------------+ 270 | PROTOCOL STACK | 271 +---------------+---------------+---------------+---------------+ 272 |APPLICATION |FTP |TFTP |ETFTP/NETBLT | 273 +---------------+---------------+---------------+---------------+ 274 |TRANSPORT |TCP |UDP |UDP | 275 +---------------+---------------+---------------+---------------+ 276 |NETWORK |IP | 277 +---------------+---------------+---------------+---------------+ 278 |LINK |Ethernet, SLIP, AX.25 | 279 +---------------+---------------+---------------+---------------+ 281 The second change is a carryover from TFTP, which allows files to be 282 transferred in netascii or binary modes. A new T bit flag is assigned 283 to the reserved field of the OPEN message type. 285 The third change is to re-negotiate the DATA packet size. This change 286 affects the OPEN, NULL-ACK, and CONTROL_OK message types. A new R bit 287 is assigned to the reserved field of the OPEN message type. 289 The fourth change is the addition of two new fields to the OPEN 290 message type. The one field is a two byte integer for radio delay in 291 seconds, and the next field is two bytes of padding. 293 The ETFTP data encapsulation is shown in Table 3, "ETFTP Data 294 Encapsulation,". The Ethernet, SLIP, and AX.25 headers are mutually 295 exclusive. They are stripped off and added by the appropriate hardware 296 layer. 298 Table 3: ETFTP Data Encapsulation 300 +------------+------------+------------+------------+-----------+ 301 |Ethernet(14)| | |ETFTP/ | | 302 |SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) | 303 |AX.25(20) | | | | | 304 +------------+------------+------------+------------+-----------+ 306 3.1 MESSAGE TYPES AND FORMATS 308 Here are the ETFTP/NETBLT message types and formats. 310 MESSAGES VALUES 311 OPEN 0 Client request to open a new connection 312 RESPONSE 1 Server positive acknowledgment for OPEN 313 KEEPALIVE 2 Reset the timer 314 QUIT 3 Sender normal Close request 315 QUITACK 4 Receiver acknowledgment of QUIT 316 ABORT 5 Abnormal close 317 DATA 6 Sender packet containing data 318 LDATA 7 Sender last data block of a buffer 319 NULL-ACK 8 Sender confirmation of CONTROL_OK changes 320 CONTROL 9 Receiver request to 321 GO 0 Start transmit of next buffer 322 OK 1 Acknowledge complete buffer 323 RESEND 2 Retransmit request 324 REFUSED 10 Server negative acknowledgment of OPEN 325 DONE 11 Receiver acknowledgment of QUIT. 327 Packets are "longword-aligned", at four byte word boundaries. Variable 328 length strings are NULL terminated, and padded to the four byte 329 boundary. Fields are listed in network byte order. All the message 330 types share a common 12 byte header. The common fields are: 332 Checksum IP compliant checksum 333 Version Current version ID 334 Type NETBLT message type 335 Length Total byte length of packet 336 Local Port My port ID 337 Foreign Port Remote port ID 338 Padding Pad as necessary to 4 byte boundary 340 The OPEN and RESPONSE messages are similar and shown in Table 4, "OPEN 341 and RESPONSE Message Types,". The client string field is used to carry 342 the filename to be transferred. 344 Table 4: OPEN and RESPONSE Message Types 346 1 2 3 347 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 348 +---------------+---------------+---------------+---------------+ 349 |Checksum |Version |Type | 350 +---------------+---------------+---------------+---------------+ 351 |Length |Local Port | 352 +---------------+---------------+---------------+---------------+ 353 |Foreign Port |Longword Alignment Padding | 354 +---------------+---------------+---------------+---------------+ 355 |Connection ID | 356 +---------------+---------------+---------------+---------------+ 357 |Buffer size | 358 +---------------+---------------+---------------+---------------+ 359 |Transfer size | 360 +---------------+---------------+---------------+---------------+ 361 |DATA Packet size |Burstsize | 362 +---------------+---------------+---------------+---------------+ 363 |Burstrate |Death Timer Value | 364 +---------------+---------------+---------------+---------------+ 365 |Reserved(MBZ) |R|T|C|M|Maximum # Outstanding Buffers | 366 +---------------+---------------+---------------+---------------+ 367 |*Radio Delay |*Padding | 368 +---------------+---------------+---------------+---------------+ 369 |Client String . . . |Longword Alignment Padding | 370 +---------------+---------------+---------------+---------------+ 372 Connection ID The unique connection number 373 Buffer size Bytes per buffer 374 Transfer size The length of the file in bytes 375 DATA Packet size Bytes per ETFTP block 376 Burstsize Concatenated packets per burst 377 Burstrate Milliseconds per burst 378 Death Timer Seconds before closing idle links 379 Reserved M bit is mode: 0=read/put, 1=write/get 380 C bit is checksum: 0=header, 1=all 381 *T bit is transfer: 0=netascii, 1=binary 382 *R bit is re-negotiate: 0=off, 1=on 383 Max # Out Buffs Maximum allowed un-acknowledged buffers 384 Radio Delay *Seconds of delay from send to receive 385 Padding *Unused 386 Client String Filename. 388 The KEEPALIVE, QUITACK, and DONE messages are identical to the common 389 header, except for the message type values. See Table 5, "KEEPALIVE, 390 QUITACK, and DONE Message Types,". 392 Table 5: KEEPALIVE, QUITACK, and DONE Message Types 394 1 2 3 395 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 396 +---------------+---------------+---------------+---------------+ 397 |Checksum |Version |Type | 398 +---------------+---------------+---------------+---------------+ 399 |Length |Local Port | 400 +---------------+---------------+---------------+---------------+ 401 |Foreign Port |Longword Alignment Padding | 402 +---------------+---------------+---------------+---------------+ 404 The QUIT, ABORT, and REFUSED messages allow a string field to carry 405 the reason for the message. See Table 6, "QUIT, ABORT, and REFUSED 406 Message Types,". 408 Table 6: QUIT, ABORT, and REFUSED Message Types 410 1 2 3 411 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 412 +---------------+---------------+---------------+---------------+ 413 |Checksum |Version |Type | 414 +---------------+---------------+---------------+---------------+ 415 |Length |Local Port | 416 +---------------+---------------+---------------+---------------+ 417 |Foreign Port |Longword Alignment Padding | 418 +---------------+---------------+---------------+---------------+ 419 |Reason for QUIT/ABORT/REFUSED . . . | 420 +---------------+---------------+---------------+---------------+ 421 |. . . |Longword Alignment Padding | 422 +---------------+---------------+---------------+---------------+ 424 The DATA and LDATA messages make up the bulk of the messages 425 transferred. The last packet of each buffer is flagged as an LDATA 426 message. Each and every packet of the last buffer has the reserved L 427 bit set. The highest consecutive sequence number is used for the 428 acknowledgment of CONTROL messages. It should contain the ID number of 429 the current CONTROL message being processed. Table 7, "DATA and LDATA 430 Message Types,", shows the DATA and LDATA formats. 432 Table 7: DATA and LDATA Message Types 434 1 2 3 435 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 436 +---------------+---------------+---------------+---------------+ 437 |Checksum |Version |Type | 438 +---------------+---------------+---------------+---------------+ 439 |Length |Local Port | 440 +---------------+---------------+---------------+---------------+ 441 |Foreign Port |Longword Alignment Padding | 442 +---------------+---------------+---------------+---------------+ 443 |Buffer Number | 444 +---------------+---------------+---------------+---------------+ 445 |High Consecutive Seq Num Rcvd |Packet Number | 446 +---------------+---------------+---------------+---------------+ 447 |Data Area Checksum Value |Reserved (MBZ) |L| 448 +---------------+---------------+---------------+---------------+ 450 Buffer Number The first buffer number starts at 0 451 Hi Con Seq Num The acknowledgment for CONTROL messages 452 Packet Number The first packet number starts at 0 453 Data Checksum Checksum for data area only 454 Reserved L: the last buffer bit: 0=false, 1=true 456 The NULL-ACK message type is sent as a response to a CONTROL_OK 457 message that modifies the current packet size, burstsize, or 458 burstrate. In acknowledging the CONTROL_OK message, the sender is 459 confirming the change request to the new packet size, burstsize, or 460 burstrate. If no modifications are requested, a NULL-ACK message is 461 unnecessary. See Table 8, "NULL-ACK Message Type," for further 462 details. 464 Table 8: NULL-ACK Message Type 466 1 2 3 467 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 468 +---------------+---------------+---------------+---------------+ 469 |Checksum |Version |Type | 470 +---------------+---------------+---------------+---------------+ 471 |Length |Local Port | 472 +---------------+---------------+---------------+---------------+ 473 |Foreign Port |Longword Alignment Padding | 474 +---------------+---------------+---------------+---------------+ 475 |High Consecutive Seq Num Rcvd |New Burstsize | 476 +---------------+---------------+---------------+---------------+ 477 |New Burstrate |*New DATA Packet size | 478 +---------------+---------------+---------------+---------------+ 480 The CONTROL messages have three subtypes: GO, OK, and RESEND as shown 481 in Tables 9-12. The CONTROL message common header may be followed by 482 any number of longword aligned subtype messages. 484 Table 9: CONTROL Message Common Header 486 1 2 3 487 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 488 +---------------+---------------+---------------+---------------+ 489 |Checksum |Version |Type | 490 +---------------+---------------+---------------+---------------+ 491 |Length |Local Port | 492 +---------------+---------------+---------------+---------------+ 493 |Foreign Port |Longword Alignment Padding | 494 +---------------+---------------+---------------+---------------+ 496 Table 10: CONTROL_GO Message Subtype 498 1 2 3 499 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 500 +---------------+---------------+---------------+---------------+ 501 |Subtype |Padding |Sequence Number | 502 +---------------+---------------+---------------+---------------+ 503 |Buffer Number | 504 +---------------+---------------+---------------+---------------+ 506 Table 11: CONTROL_OK Message Subtype 508 1 2 3 509 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 510 +---------------+---------------+---------------+---------------+ 511 |Subtype |Padding |Sequence Number | 512 +---------------+---------------+---------------+---------------+ 513 |Buffer Number | 514 +---------------+---------------+---------------+---------------+ 515 |New Offered Burstsize |New Offered Burstrate | 516 +---------------+---------------+---------------+---------------+ 517 |Current Control Timer Value |*New DATA Packet size | 518 +---------------+---------------+---------------+---------------+ 520 Table 12: CONTROL_RESEND Message Subtype 522 1 2 3 523 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 524 +---------------+---------------+---------------+---------------+ 525 |Subtype |Padding |Sequence Number | 526 +---------------+---------------+---------------+---------------+ 527 |Buffer Number | 528 +---------------+---------------+---------------+---------------+ 529 |Number of Missing Packets |Longword Alignment Padding | 530 +---------------+---------------+---------------+---------------+ 531 |Packet Number (2 bytes) |. . . | 532 +---------------+---------------+---------------+---------------+ 533 |. . . |Longword Alignment Padding | 534 +---------------+---------------+---------------+---------------+ 536 3.2 ETFTP COMMAND SET 538 Being built from TFTP source code, ETFTP shares a significant portion 539 of TFTP's design. Like TFTP, ETFTP does NOT support user password 540 validation. The program does not support changing directories (i.e. 541 cd), neither can it list directories, (i.e. ls). All filenames must be 542 given in full paths, as relative paths are not supported. The internal 543 finite state machine was modified to support NETBLT message types. 545 The NETBLT protocol is implemented as closely as possible to what is 546 described in RFC 998, with a few exceptions. The client string field 547 in the OPEN message type is used to carry the filename of the file to 548 be transferred. Netascii or binary transfers are both supported. If 549 enabled, new packet sizes, burstsizes, and burstrates are 550 re-negotiated downwards when half or more of the blocks in a buffer 551 require retransmission. If 99% of the packets in a buffer is 552 successfully transferred without any retransmissions, packet size is 553 re-negotiated upwards. 555 The interactive commands supported by the client process are similar 556 to TFTP. Here is the ETFTP command set. Optional parameters are in 557 square brackets. Presets are in parentheses. 559 ? help, displays command list 560 ascii mode ascii, appends CR-LF per line 561 autoadapt toggles backoff function (on) 562 baudrate baud baud rate (16000 bits/sec) 563 binary mode binary, image transfer 564 blocksize bytes packet size in bytes (512 bytes/block) 565 bufferblock blks buffer size in blocks (128 blocks/buff) 566 burstsize packets burst size in packets (8 blocks/burst) 567 connect host [p] establish connection with host at port p 568 exit ends program 569 get rfile lfile copy remote file to local file 570 help same as ? 571 mode choice set transfer mode (binary) 572 multibuff num number of buffers (2 buffers) 573 put lfile rfile copy local file to remote file 574 quit same as exit 575 radiodelay sec transmission delay in seconds (2 sec) 576 status display network parameters 577 trace toggles debug display (off). 579 3.3 DATA TRANSFER AND FLOW CONTROL 581 This is the scenario between client and server transfers: 583 Client sends OPEN for connection, blocksize, buffersize, burstsize, 584 burstrate, transfer mode, and get or put. See M bit of reserved field. 586 Server sends a RESPONSE with the agreed parameters. 588 Receiver sends a CONTROL_GO request sending of first buffer. 590 Sender starts transfer by reading the file into multiple memory 591 buffers. See Figure 1, "File Segmentation,". Each buffer is divided 592 according to the number of bytes/block. Each block becomes a DATA 593 packet, which is concatenated according to the blocks/burst. Bursts 594 are transmitted according to the burstrate. Last data block is flagged 595 as LDATA type. 597 +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 598 | | | 0 | | L | | 4 | | 3 | ---- | 2 | | 1 | | 0 | 599 | | | +---+ +---+ +---+ +---+ +---+ +---+ +---+ 600 | | +-| | --> +---+ +---+ +---+ +---+ +---+ 601 | | --> | 1 | | L | | 3 | ---- | 2 | | 1 | | 0 | 602 +---+ +---+ +---+ +---+ +---+ +---+ +---+ 603 File Multi Buffers Blocks per Burst 605 Figure 1. File Segmentation 607 Receiver acknowledges buffer as CONTROL_OK or CONTROL_RESEND. 609 If blocks are missing, a CONTROL_RESEND packet is transmitted. If half 610 or more of the blocks in a buffer are missing, an adaptive algorithm 611 is used for the next buffer transfer. If no blocks are missing, a 612 CONTROL_OK packet is transmitted. 614 Sender re-transmits blocks until receipt of a CONTROL_OK. If the 615 adaptive algorithm is set, then new parameters are offered, in the 616 CONTROL_OK message. The priority of the adaptive algorithm is: 618 - Reduce packetsize by half (MIN = 16 bytes/packet) 619 - Reduce burstsize by one (MIN = 1 packet/burst) 620 - Reduce burstrate to actual tighttimer rate 622 If new parameters are valid, the sender transmits a NULL-ACK packet, 623 to confirm the changes. 625 Receiver sends a CONTROL_GO to request sending next buffer. 627 At end of transfer, sender sends a QUIT to close the connection. 629 Receiver acknowledges the close request with a DONE packet. 631 3.4 TUNABLE PARAMETERS 633 These parameters directly affect the throughput rate of ETFTP. 635 Packetsize The packetsize is the number of 8 bit bytes per 636 packet. This number refers to the user data bytes in a block, (frame), 637 exclusive of any network overhead. The packet size has a valid range 638 from 16 to 1,448 bytes. The Maximum Transfer Unit (MTU) implemented in 639 most commercial network devices is 1,500 bytes. The de-facto industry 640 standard is 576 byte packets. 642 Bufferblock The bufferblock is the number of blocks per buffer. 643 Each implementation may have restrictions on available memory, so the 644 buffersize is calculated by multiplying the packetsize times the 645 bufferblocks. 647 Baudrate The baudrate is the bits per second transfer rate of 648 the slowest link (i.e., the radios). The baudrate sets the speed of 649 the sending process. The sending process cannot detect the actual 650 speed of the network, so the user must set the correct baudrate. 652 Burstsize The burstsize in packets per burst sets how many 653 packets are concatenated and burst for transmission efficiency. The 654 burstsize times the packetsize must not exceed the available memory of 655 any intervening network devices. On the Ethernet portion of the 656 network, all the packets are sent almost instantaneously. It is 657 necessary to wait for the network to drain down its memory buffers, 658 before the next burst is sent. The sending process needs to regulate 659 the rate used to place packets into the network. 661 Radiodelay The radiodelay is the time in seconds per burst it 662 takes to synchronize with the radio controllers. Any additional 663 hardware delays should be set here. It is the aggregate delay of the 664 link layer, such as transmitter key-up, FEC, crypto synchronization, 665 and propagation delays. 667 These parameters above are used to calculate a burstrate, which is the 668 length of time it takes to transmit one burst. The ov is the overhead 669 of 72 bytes per packet of network encapsulation. A byte is defined as 670 8 bits. The burstrate value is: 672 burstrate = (packetsize+ov)*burstsize*8/baudrate 674 In a effort to calculate the round trip time, when data is flowing in 675 one direction for most of the transfer, the OPEN and RESPONSE message 676 types are timed, and the tactical radio delays are estimated. Using 677 only one packet in each direction to estimate the rate of the link is 678 statistically inaccurate. It was decided that the radio delay should 679 be a constant provided by the user interface. However, a default 680 value of 2 seconds is used. The granularity of this value is in 681 seconds because of two reasons. The first reason is that the UNIX 682 supports a sleep function in seconds only. The second reason is that 683 in certain applications, such as deep space probes, a 16-bit integer 684 maximum of 32,767 seconds would suffice. 686 3.5 DELAYS AND TIMERS 688 From these parameters, several timers are derived. The control timer 689 is responsible for measuring the per buffer rate of transfer. The 690 SENDER copy is nicknamed the loosetimer. 692 loosetimer = (burstrate+radiodelay)*bufferblock/burstsize 694 The RECEIVER copy of the timer is nicknamed the tighttimer, which 695 measures the elapsed time between CONTROL_GO and CONTROL_OK packets. 696 The tighttimer is returned to the SENDER to allow the protocol to 697 adjust for the speed of the network. 699 The retransmit timer is responsible for measuring the network receive 700 data function. It is used to set an alarm signal (SIGALRM) to 701 interrupt the network read. The retransmit timer (wait) is initially 702 set to be the greater of twice the round trip or 4 times the 703 radiodelay, plus a constant 5 seconds. 705 wait = MAX ( 2*roundtriptime, 4*radiodelay ) + 5 seconds 707 and 709 alarm timeout = wait. 711 Each time the same read times out, a five second backoff is added to 712 the next wait. The backoff is necessary because the initial user 713 supplied radiodelay, or the initial measured round trip time may be 714 incorrect. 716 The retransmit timer is set differently for the RECEIVER during a 717 buffer transfer. Before the arrival of the first DATA packet, the 718 original alarm time out is used. Once the DATA packets start arriving, 719 and for the duration of each buffer transfer, the RECEIVER alarm time 720 out is reset to the expected arrival time of the last DATA packet 721 (blockstogo) plus the delay (wait). As each DATA packet is received, 722 the alarm is decremented by one packet interval. This same algorithm 723 is used for receiving missing packets, during a RESEND. 725 alarmtimeout = blockstogo*burstrate/burstsize + wait 727 The death timer is responsible for measuring the idle time of a 728 connection. In the ETFTP program, the death timer is set to be equal 729 to the accumulated time of ten re-transmissions plus their associated 730 backoffs. As such, the death timer value in the OPEN and RESPONSE 731 message types is un-necessary. In the ETFTP program, this field could 732 be used to transfer the radio delay value instead of creating the two 733 new fields. 735 The keepalive timer is responsible for resetting the death timer. This 736 timer will trigger the sending of a KEEPALIVE packet to prevent the 737 remote host from closing a connection due to the expiration of its 738 death timer. Due to the nature of the ETFTP server process, a 739 keepalive timer was not necessary, although it is implemented. 741 3.6 TEST RESULTS 743 The NETBLT protocol has been tested on other high speed networks 744 before, see RFC 1030 [6]. These test results in Tables 13 and 14, 745 "ETFTP Performance," were gathered from files transferred across the 746 network and LST-5C TACSAT radios. The radios were connected together 747 via a coaxial cable to provide a "clean" link. A clean link is defined 748 to a BER of 10e-5. The throughput rates are defined to be the file 749 size divided by the elapsed time resulting in bits per second (bps). 750 The elapsed time is measured from the time of the "get" or "put" 751 command to the completion of the transfer. This is an all inclusive 752 time measurement based on user perspective. It includes the connection 753 time, transfer time, error recovery time, and disconnect time. The 754 user concept of elapsed time is the length of time it takes to copy a 755 file from disk to disk. These results show only the average 756 performances, including the occasional packet re-transmissions. The 757 network configuration was set as: 759 ETFTP Parameters: 761 Filesize 101,306 bytes 762 Radiodelay 2 seconds 763 Buffersize 16,384-131,072 bytes 764 Packetsize 512-2048 bytes 765 Burstsize 8-16 packets/burst 767 Gracilis PackeTen Parameters: 769 0 TX Delay 400 milliseconds 770 1 P Persist 255 [range 1-255] 771 2 Slot Time 30 milliseconds 772 3 TX Tail 300 milliseconds 773 4 Rcv Buffers 8 2048 bytes/buffer 774 5 Idle Code Flag 776 Radio Parameters: 778 Baudrate 16,000 bps 779 Encryption on 781 Table 13: ETFTP Performance at 8 Packets/Burst in Bits/Second 783 +-----------+-----------+-----------+-----------+-----------+ 784 |buffersize |packetsize |packetsize |packetsize |packetsize | 785 |(bytes) |2,048 bytes|1,448 bytes|1,024 bytes|512 bytes | 786 +-----------+-----------+-----------+-----------+-----------+ 787 | 16,384 | 7,153 | 6,952 | 6,648 | 5,248 | 788 +-----------+-----------+-----------+-----------+-----------+ 789 | 32,768 | 7,652 | 7,438 | 7,152 | 4,926 | 790 +-----------+-----------+-----------+-----------+-----------+ 791 | 65,536 | 8,072 | 8,752 | 8,416 | 5,368 | 792 +-----------+-----------+-----------+-----------+-----------+ 793 | 131,072 | 8,828 | 9,112 | 7,888 | 5,728 | 794 +-----------+-----------+-----------+-----------+-----------+ 796 Table 14: ETFTP Performance at 16 Packets/Burst in Bits/Second 798 +-----------+-----------+-----------+-----------+-----------+ 799 |buffersize |packetsize |packetsize |packetsize |packetsize | 800 |(bytes) |2,048 bytes|1,448 bytes|1,024 bytes|512 bytes | 801 +-----------+-----------+-----------+-----------+-----------+ 802 | 16,384 | 5,544 | 5,045 | 4,801 | 4,570 | 803 +-----------+-----------+-----------+-----------+-----------+ 804 | 32,768 | 8,861 | 8,230 | 8,016 | 7,645 | 805 +-----------+-----------+-----------+-----------+-----------+ 806 | 65,536 | 9,672 | 9,424 | 9,376 | 8,920 | 807 +-----------+-----------+-----------+-----------+-----------+ 808 | 131,072 | 10,432 | 10,168 | 9,578 | 9,124 | 809 +-----------+-----------+-----------+-----------+-----------+ 811 3.7 PERFORMANCE CONSIDERATIONS 813 These tests were performed across a tactical radio link with a maximum 814 data rate of 16000 bps. In testing ETFTP, it was found that the delay 815 associated with the half duplex channel turnaround time was the 816 biggest factor in throughput performance. Therefore, every attempt was 817 made to minimize the number of times the channel needed to be turned 818 around. Obviously, the easiest thing to do is to use as big a buffer 819 as necessary to read in a file, as acknowledgments occurred only at 820 the buffer boundaries. This is not always feasible, as available 821 storage on disk could easily exceed available memory. However, the 822 current ETFTP buffersize is set at a maximum of 524,288 bytes. 824 The larger packetsizes also improved performance. The limit on 825 packetsize is based on the 1500 byte MTU of network store and forward 826 devices. In a high BER environment, a large packetsize could be 827 detrimental to success. By reducing the packetsize, even though it 828 negatively impacts performance, reliability is sustained. When used in 829 conjunction with FEC, both performance and reliability can be 830 maintained at an acceptable level. 832 The burstsize translates into how long the radio transmitters are 833 keyed to transmit. In ETFTP, the ideal situation is to have the first 834 packet of a burst arrive in the radio transmit buffer, as the last 835 packet of the previous burst is just finished being sent. In this way, 836 the radio transmitter would never be dropped for the duration of one 837 buffer. In a multi-user radio network, a full buffer transmission 838 would be inconsiderate, as the transmit cycle could last for several 839 minutes, instead of seconds. In measuring voice communications, 840 typical transmit durations are on the order of five to twenty seconds. 841 This means that the buffersize and burstsize could be adjusted to have 842 similar transmission durations. 844 4. REFERENCE SECTION 846 [1] Clark, David D., Lambert, Mark L., Zhang, Lixia, March 1987, 847 "NETBLT: A Bulk Data Transfer Protocol", RFC 998, Internet 848 Architecture Board. 850 [2] Postel, J., August 1980, "User Datagram Protocol" RFC 768, 851 Internet Architecture Board. 853 [3] Sollins, July 1992, "Trivial File Transfer Protocol", RFC 1350, 854 Internet Architecture Board. 856 [4] MIL-STD-2045-44500, 18 June 1993, "Military Standard Tactical 857 Communications Protocol 2 (TACO 2) fot the National Imagery 858 Transmission Format Standard", Ft. Monmouth, New Jersey. 860 [5] Stevens, W. Richard, 1990, "UNIX Network Programming", 861 Prentice-Hall Inc., Englewood, New Jersey, Chapter 12. 863 [6] Lambert, M., November 1987, "On Testing the NETBLT Protocol over 864 Divers Networks", RFC 1030, Internet Architecture Board. 866 5. SECURITY CONSIDERATION SECTION 868 The ETFTP program is a security loophole in any UNIX environment. 869 There is no user/password validation. All the problems associated to 870 TFTP are repeated in ETFTP. The server program must be owned by root 871 and setuid to root in order to work. As an experimental prototype 872 program, the security issue was overlooked. Since this protocol has 873 proven too be a viable solution in tactical radio networks, the 874 security issues will have to be addressed, and corrected. 876 6. AUTHOR ADDRESS SECTION 878 William J. Polites 879 The Mitre Corporation 880 145 Wyckoff Rd. 881 Eatontown, NJ 07724 882 (908) 544-1414 883 wpolites@mitre.org 885 William Wollman 886 The Mitre Corporation 887 145 Wyckoff Rd. 888 Eatontown, NJ 07724 889 (908) 544-1414 890 wwollman@mitre.org 892 David Woo 893 The Mitre Corporation 894 145 Wyckoff Rd. 895 Eatontown, NJ 07724 896 (908) 544-1414 897 dwoo@mitre.org 899 Russ Langan 900 U.S. Army Communications Electronics Command (CECOM) 901 AMSEL-RD-ST-SP 902 ATTN: Russell Langan 903 Fort Monmouth, NJ 07703 904 (908) 427-2064 FAX: (908) 427-2822 905 langanr@doim6.monmouth.army.mil 907 7. GLOSSARY 909 ATD Advanced Technology Demonstration 910 AX.25 Amateur Radio X.25 Protocol 911 BER Bit Error Rate 912 EPLRS Enhanced Position Location Reporting Systems 913 ETFTP Enhanced Trivial File Transfer Protocol 914 FEC Forward Error Correction 915 FTP File Transfer Protocol 916 HF High Frequency 917 LCU Lightweight Computer Unit 918 ms milliseconds 919 MTU Maximum Transfer Unit 920 NETBLT NETwork Block Transfer protocol 921 NITFS National Imagery Transmission Format Standard 922 PC Personal Computer 923 RNC Radio Network Controller 924 SAS Survivable Adaptive Systems 925 SATCOM SATellite COMmunications 926 SCO Santa Cruz Operations 927 SINCGARS SINgle Channel Ground and Airborne Radio Systems 928 SLIP Serial Line Internet Protocol 929 TACO2 Tactical Communications Protocol 2 930 TCP Transmission Control Protocol 931 TFTP Trivial File Transfer Protocol 932 UDP User Datagram Protocol 933 UHF Ultra High Frequency 935 * Modification from NETBLT RFC 998. 936 * The new packet size is a modification to the NETBLT RFC 998. 937 * The new packet size is a modification to the NETBLT RFC 998. 939 INTERNET-DRAFT Expires November 1996 INTERNET-DRAFT