StarBurst MFTPTM Compared to Today's File Transfer Protocols: A White Paper

Background

File transfer is one of the most common applications over computer networks. Users of the Internet or other online services such as CompuServe or America Online access the network, find a server with the desired information, and use a file transfer protocol to download the file(s). Users of corporate networks likewise desire to transfer files back and forth. In fact, file transfer applications are the second largest source of data on networks after e-mail.

To satisfy the needs of today's complex, heterogeneous networks, a file transfer protocol should have the following capabilities:

1. Be able to have optimal performance on all kinds of data networks in use today, whether it be a LAN, a WAN, a satellite data network, a wireless network such as CDPD, or any combination of the above in an internetwork.
2. Be able to explicitly set the rate of transfer, so that large file transfers do not hog the bandwidth of the network, but can leave specific bandwidth available for other applications.
3. Be able to support multicast file transfer efficiently, i.e. the transfer of files from one source to many recipients (at least thousands) simultaneously, and reliably.

Today's commonly used file transfer protocols were largely designed in the seventies and consequently do not meet all of today's requirements. It is these limitations that have led to the development of StarBurst MFTP.

Today's File Transfer Protocols (FTP)

FTP stands for File Transfer Protocol. It is intended to be the workhorse file transfer protocol associated with the TCP/IP protocol suite. FTP is the file transfer application used for pulling documents off of the Internet, for example.

FTP runs on top of the TCP transport layer as shown in Figure 1. FTP depends on TCP for reliable delivery of data, as TCP provides connection-oriented service. This means acknowledged error correction of data transmissions and guaranteed ordering of frames. Connection-oriented transport protocols set up virtual circuits, where the virtual circuit makes the connection look like a physical circuit for the duration of setup.

TCP, like many other error correcting protocols, corrects data on the fly based on the concept of sliding windows. The transmitter sends out a window worth of data before requiring an acknowledgment. For maximal efficiency, the window size (i.e. the time to send out a window worth of data) should match the round trip network delay. If this matches, the transmitter will not have to wait for acknowledgments but can continue to send data continuously. This is illustrated in Figure 2 for a window size of 8. If the acknowledgment for packet one arrives concurrent with the sending of packet 8, then the transmitter can immediately continue to send packet 9 without stopping.

TCP uses dynamic windowing, where the window size is calculated and set dynamically based on measurements of round trip delay and other parameters such as receive buffer size. However, the delays incurred in satellite data networks are beyond the limit of window size, especially at high transmit rates, resulting in transfer inefficiency.

FTP requires the setup of two TCP virtual circuits, one for control and one for the actual data transfer. The control virtual circuit is used for logging in and setup of the file transfer, with the other used strictly for data transfer.

Hosts with multitasking operating systems, such as UNIX workstations, can have multiple FTP connections simultaneously to multiple sites allowing files to be sent to multiple sites concurrently.

However, this approach does not scale, as each new destination robs bandwidth from the others. Additionally, the source often cannot support more than about 10-20 simultaneous FTP sessions meaning that simultaneous file transfer to large numbers of recipients is not possible. This is shown in Figure 3.

Additionally, there are some networks that are inherently connectionless and usage of TCP is not recommended. For example, Cellular Digital Packet Data (CDPD) is a new packet switched wireless data networking technology that is an overlay on top of voice cellular systems. CDPD is primarily a connectionless service. Frequency hopping and roaming between cells all mean changes in connection, defeating the concept of a virtual circuit that stays constant for the time it exists. The CDPD Software Developer's Conference, held in the fall of 1994, gave the message to software developers to avoid creating applications that run on top of TCP, but rather use UDP, the connectionless transport service in TCP/IP, exclusively.

TFTP

There is a file transfer service in the TCP/IP suite that operates on top of UDP. It is the Trivial File Transfer Protocol, TFTP (see Figure 4). TFTP was designed to be a very simple alternative to FTP, and was conceived to be so simple it could be implemented in a ROM. One big usage originally envisioned was for machine boot of software at startup.

UDP provides a simple datagram service for transport. No error correction is provided, although error checking is done, with bad packets simply dropped. Packets may be delivered out of order. Thus, TFTP must provide the error control at the application layer to make sure that the file is transferred error free.

TFTP operates with a window of one with a fixed application layer message of 512 bytes. This means that every 512 bytes of transmission requires receipt of an acknowledgment before the transmitter can proceed to the next 512 bytes to be sent in the file. Window of one protocols work reasonably well when there is little round trip delay in the network, for example on a LAN. But if there is significant delay relative to the time to send a message, efficiency suffers greatly because the transmitter has to wait a high proportion of the time for acknowledgments. CDPD has this problem, as round trip delays are in the range of 250-500 msec., resulting in only about 50% of possible throughput.

Efficiency of TFTP is also poor in wireline wide area networks, especially at high speeds where the round trip delay of the network represents a large amount of data. With round trip delays of 50 msec. (not unusual in WANs), the effective throughput is only about 5% of port speed at T1 rates as illustrated in Figure 5.

TFTP is practically unusable over satellite networks with their high delays.

TFTP likewise does not support multicast, but like FTP, multiple point to point sessions can be set up concurrently if the sender is in a multitasking operating system environment.

The StarBurst MFTP Solution

Fortunately, help is on the way. StarBurst Communications has developed a new file transfer protocol and product line based on this protocol. It is called StarBurst MFTP (Multicast File Transfer Protocol) and it operates over UDP in the TCP/IP protocol suite. This product line and protocol satisfy all of the requirements of today for file transfer. An explicit transmit rate is settable, allowing a known amount of bandwidth to be reserved for other applications. The protocol is very efficient, with virtually no performance degradation due to delays over satellite or wireless networks. And finally, StarBurst MFTP was designed for multicast and broadcast usage over data networks of all sorts including wireline and wireless WANs, where multicast and broadcast services are just now becoming available. Until StarBurst MFTP, no broadcast or multicast file transfer product has existed on the market, and StarBurst Communications has filled this void.

The whole concept of windowing does not work effectively in a one to many context. Usage of windowing techniques also results in performance degradation under large delay situations such as found in satellite and wireless WAN networks. As a result, StarBurst Communications developed StarBurst MFTP specifically to address both unicast and multicast file transfer without depending on windowing for implementation.

How Does It Work?

There are three basic entities defined in the StarBurst MFTP protocol; the frame, which is a link layer entity and has the same meaning for StarBurst MFTP as for other protocols, the block which consists of a number of frames, usually hundreds or possibly even thousands, and a pass, which consists of transmission of the whole file on the first pass, and missing pieces on subsequent passes. Clients are obliged to send acknowledgments about the previous block at block boundaries. A selective reject negative acknowledgment indicates those frames within the block that are missing or in error.

Unlike conventional protocols, the StarBurst MFTP transmitter does not stop and wait for acknowledgments before continuing transmission. Rather, it transmits continuously until the whole file has been transmitted, at which point it sends another "pass" consisting of only those frames that were negatively acknowledged. A third or fourth pass may be required to complete error free transmission to all clients. This is illustrated in Figure 6.

For example, frame 251 in block 1, frames 286 and 294 in block 2, and frames 101 and 290 in block 4 are negatively acknowledged during Pass 1 and retransmitted in Pass 2 as illustrated in Figure 6. Thus, in this case, the second pass consists of the resending of five frames.

The concepts of not stopping and multiple passes results in optimal file transfer efficiency. The transmitter is transmitting the file virtually all of the time so that speeds can approach the theoretical, and only bad frames are resent. Performance is independent of network round trip delay, important for high speed wireline, satellite, and CDPD wireless infrastructures. And, multicast as well as unicast service is offered.

StarBurst MFTP Versus Multiple FTP Sessions: A Performance Analysis

For small numbers of clients, multiple FTP sessions can be used to send files simultaneously to the clients and is a possible current alternative to StarBurst MFTP. However, the performance (i.e., the speed of transfer) is only about 1/n as great as if StarBurst MFTP is used, where n is the number of clients.

The reason for this is illustrated in Figure 7. With multiple FTP sessions, the file is replicated and sent n times from the server to the clients, where n = 4 in the figure. The link from the server to the network that connects to the clients must then be shared among the n transmissions in the case of multiple FTP sessions, whereas in the case of a multicast file transfer using StarBurst MFTP there is only one transmission on a multicast address, which is replicated in a suitable place in the network for delivery to the multiple clients as illustrated in Figure 8.

Figure 8 shows a multicast frame relay network using a One-Way Multicast frame relay setup. Not shown are the individual frame relay DLCls (addresses) that connect the StarBurst server to each individual client, which allows point to point traffic as well as multicast traffic.

Figure 7 and Figure 8 show T1 connections to both the clients and the server. In Figure 7, multiple FTP sessions are sent over a router network to the clients. The T1 link at the server site must be shared with the four clients, since the four individual FTP sessions are originated at the server.

In Figure 8, transmission from the server to the clients is via a multicast frame relay DLCI to the multicast server located inside the network, which in turn replicates the data and transports it to the individual DLCls connected to the clients. Although Figure 8 shows a multicast frame relay network, multicast IP router networks work in similar fashion. In this case, the network replication for delivery will be performed by routers in the network.

The protocol overhead for FTP and StarBurst MFTP is the same in both cases, as the TCP header is 16 bytes larger than the UDP header, and the StarBurst MFTP header is 16 bytes. This is illustrated in Figure 9.

Table 1 shows a comparison of performance between file transfer using multiple FTP sessions and one using StarBurst MFTP on a four client multicast network. The network connections to server and clients are all at T1, or 1.544 Mbps as shown in Figures 7 and 8 for this example. A Maximum Transmission Unit (MTU, the size of the network layer datagram) of 576 bytes is used for comparison, resulting in a data payload of 528 bytes in both cases. This MTU size is guaranteed to be supported by all elements in a network without fragmentation of frames which adds inefficiency. Many networks actually can run at higher MTU sizes than 576 bytes. Table 1 compares performance assuming no errors in both cases, and four clients.

In summary, transfer rates for multiple FTP sessions are limited to 1/n times the available band width, where n is the number of recipients. In contrast, multicast file transfer using StarBurst MFTP provides the ability to send at a full bandwidth rate to any number of recipients.

Groups

StarBurst MFTP has the additional capability to dynamically set up and tear down groups and add and delete members of a group to which a file is to be transferred. This capability provides a level of flexibility and convenience to the user not possible with multiple FTP sessions.

Dynamic groups capability is able to operate in two different network environments; multicast IP for routed networks, and multicast frame relay or multicast SMDS for bridged environments. In the latter case, the group is set up totally in the application layer under control of StarBurst MFTP. In routed networks, the routers route based on the location of members of the group using the IGMP protocol described in RFC1112.

Conclusion

StarBurst MFTP is the approach that makes most sense for the electronic dissemination of information from one to many recipients. It takes advantage of new network services such as multicast frame relay, multicast SMDS, and multicast IP. And it is optimally efficient as the transmitter does not wait for acknowledgments before transmitting. It is delay insensitive and only bad or missing frames are resent. The transfer rate is explicitly settable, preventing a large file transfer from hogging the whole network and preventing other network applications during the transfer. StarBurst MFTP is also available on multiple computer platforms, and these different platforms may coexist in the network.