rfc1986.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,180 行 · 第 1/4 页

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.