Internet Draft O. Azmak, C. Leviatan, I. Pechtalt Document: draft-azmak-bst-00.txt Flash Networks, Inc. Expires: 2001 February 2001 Boosted Session Transport (BST) Protocol for Improved Performance in Satellite, Wireless and Mobile Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract TCP treats packet losses as an indication of congestion in the network, and it reduces transmission rates drastically until an optimal rate is found for data transmission. The problems that satellite and other wireless links pose to TCP have been addressed elsewhere (please see Section 2). This paper proposes a new Transport layer protocol, Boosted Session Transport (BST) that is intended to work as a counterpart to TCP over a single wireless or satellite hop. The BST protocol introduces a number of mechanisms to specifically address the demands of satellite, wireless and mobile networks, in terms of transient packet losses, large Round-Trip Time (RTT), and need for more efficient use of available bandwidth. BST has been designed to be used over the wireless access links to the Internet; therefore, it is intended to work seamlessly with TCP in order to provide wireless access to the whole of Internet, not to a limited subset of it. This paper describes the BST protocol. Table of Contents Status of this Memo................................................1 Abstract ..........................................................1 Conventions used in this document..................................2 1. Introduction..............................................2 Azmak, et al. Informational - Expires December 2001 1 Boosted Session Transport (BST) Protocol February 2001 2. Background................................................3 3. BST Header Information....................................4 3.1. CONNECTION_RQST and CONNECTION_ACK........................5 3.2. NACK......................................................6 4. Connection Establishment & Release........................7 4.1. Connection Establishment..................................7 4.2. Connection Release........................................8 5. Data Transfer.............................................8 5.1. ACK/NACK..................................................8 5.1.1. Packet Loss v. Packet "Disorder"..........................9 5.2. Rate Control.............................................10 5.3. Bandwidth Sharing........................................10 5.3.1. Control and Data Queues..................................10 5.3.2. Simultaneous Connections.................................10 5.3.3. Non-BST Traffic..........................................11 6. Security Considerations..................................11 7. References...............................................12 8. Author's Addresses.......................................12 Conventions used in this document BST indicates Boosted Session Transport. The term "wireless" is meant to encompass not only satellite, but also cellular, PCS, CDPD and other mobile data solutions, both in 2G and 3G technologies. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 1. Introduction This paper proposes a new protocol that is specifically designed to overcome the performance degradation that TCP experiences in wireless media. As it is well established, TCP's design principles treat the network as a "black box", and consider packet loss only as a sign of congestion in the network. Because of these principles, TCP does not deal well with transient errors (due to noise or signal drop out, as opposed to congestion in the network) and long Round- Trip Times. In addition, TCP is too "chatty" to be effective over wireless links. Boosted Session Transport (BST) protocol was designed to improve the bandwidth utilization in wireless (satellite and cellular) access points to the Internet. It is designed to interwork with TCP as a transport layer connection-oriented protocol. On the Client side, TCP packets are converted into BST packets. These BST packets are transmitted over the RF link, and the BST Server reconstitutes TCP packets. These TCP packets are then routed to the Internet. During the conversion to and from BST, TCP header information is replaced Azmak, et al. Informational - Expires December 2001 2 Boosted Session Transport (BST) Protocol February 2001 with BST headers. TCP payload is compressed whenever possible, in order to increase the effective throughput over the wireless link. This paper is organized as follows. Section 2 provides background on TCP performance in satellite networks. This background lends itself to addressing the demands of terrestrial cellular networks, as well. Section 3 provides the BST header information, BST messages and their parameters. Section 4 describes connection establishment and release in the BST protocol. Section 5 describes data transfer and congestion avoidance mechanisms. Section 6 addresses the security considerations. 2. Background Performance degradation that TCP suffers over satellite links, and potential resolutions have been discussed in earlier RFCs [2], [3]. [2] provides a survey of research topics that are currently under consideration to overcome TCP's problems in satellites. [3] provides a description of the problems TCP faces in satellites and makes a number of recommendations in dealing with those difficulties. In addition, [7] highlights the requirements that "Long Thin Networks" place on TCP, surveys proposed solutions, and makes a number of recommendations. Many of the recommendations in [3] and [7] mirror one another, and they pose the problem that wireless links pose to TCP as follows. TCP employs four mechanisms to monitor its transmission characteristics: slow start, congestion avoidance, fast retransmit and fast recovery. The problem that wireless links present to TCP are: long feedback loop, large bandwidth * RTT (Round-Trip Time) product, variable round-trip times, intermittent connectivity, and increased Bit-Error Rate (BER). Long feedback loop means that Acknowledgements will take longer to reach the sender. This prolongs the initial period during which slow-start algorithm controls the bandwidth utilization. With larger RTT, it takes TCP longer to achieve optimal transmission speed, and a lot of available bandwidth is not utilized. Faster methods for connection bandwidth determination and optimal MTU sizing [4] are needed to counter some of the effects of long feedback loops. Regarding optimal MTU size, one should keep in mind that in particularly wireless packet data networks, such as CDPD, where available bandwidth is shared among a varying number of users with varying bandwidth demands, optimal MTU size is likely to change over the course of a single session. Lange bandwidth*RTT product increases the amount traffic that TCP has to maintain "in flight" without receiving Acknowledgements. Having a larger number of packets "in flight" compounds the problems that are caused by variable RTT, intermittent connectivity, and larger BER. Therefore, efficient mechanisms are needed to limit retransmissions only to lost packets, and to deal effectively with packets arriving out of order ("packet disorder"). These mechanisms Azmak, et al. Informational - Expires December 2001 3 Boosted Session Transport (BST) Protocol February 2001 can be implemented via Delayed ACKs [6] and Selective ACKs (SACK) [5], combined with more effective management of transmit and receive windows. Variable RTT affects the order in which packets arrive at the receiver. For instance, packets 1, 2, 3 sent in that order, may arrive at the receiver in the order 2, 3, 1. Alternative Acknowledgement methods that are mentioned above are needed in order to differentiate packet loss from loss of packet order ("packet disorder"), and to deal with the two cases more effectively. Intermittent connectivity can be experienced in non-Geo Stationary Orbit (GSO) satellite configurations [3], and also in cellular/PCS networks due to handovers. These breaks in connectivity are likely to introduce packet losses. Please see the discussion on larger BER below on its implications for TCP. Larger BER affects the TCP in an indirect way. By design, TCP treats packet loss as a sign of congestion in the network; therefore, loss of a single packet causes drastic reduction in transmission speeds. Greater BER in wireless networks tends to cause packet loss due to the channel characteristics of the radio frequency (RF) environment, rather than congestion in the link. Another indirect effect of greater BER is felt in the ordering of packets. This is due to the Automatic Resend reQuest (ARQ) mechanisms that many wireless Link Layer (L2) solutions employ. When an L2 ARQ protocol detects corruption, it requests certain package(s) to be resent. This is done below TCP/IP layers, and it introduces variable delay to the transmission path. In summary, a number of mechanisms have been recommended to enhance TCP's performance over satellite, and by extension, over wireless networks [2, 3, 7]. Boosted Session Transport (BST) protocol incorporates many of these recommendations, and introduces new ideas in order to maximize bandwidth utilization over wireless links in which bandwidth is scarce and transient errors are frequent than in terrestrial media. The improvements include a less chatty transmission scheme, delayed ACKs, selective ACKs/NACKs (SACKs), larger transmission windows and faster retransmission and recovery algorithms, and mechanisms to differentiate packet loss from loss of packet order. The rest of this paper describes the BST messages, parameters, and basic data transmission. 3. BST Header Information This section provides the format for the BST header, and describes the parameters of the header. 0 1 2 3 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Azmak, et al. Informational - Expires December 2001 4 Boosted Session Transport (BST) Protocol February 2001 | Dest port | Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg_no | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lmsg no | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "dest_port" (Short integer) is the port number for the remote end of a BST connection. "type" (Char) indicates which of the following messages is intended in the current segment: 1. SHUTDOWN - Close BST connection 2. CONNECTION_RQST - Request a new connection 3. CONNECTION_ACK - Acknowledgement of a CONNECTION_RQST 4. MSG_LOST - a Negative Acknowledgement. 5. MSG_ALIVE - A message to keep a connection open, when there is no data to be sent. 6. MSG_SEND - Message for regular data transfer. "flags"(Unsigned Char) is used to indicate the following conditions: 1. Fragmentation (bit 7) - whether the payload has been fragmented; 2. Last Fragment (bit 6) - to identify the last fragment in such a transfer. This bit is set to 1 in the last fragment. 3. Internal use (bit 2) - undefined; 4. BST Stop (bit 0) - is a flow-control flag that the receiver sends to the sender to stop BST traffic in order to alleviate buffer overflow. "msg_no" (Unsigned Long) is the sequence number of the current BST packet. "Lmsg_no" (Unsigned Long) is the sequence number of the last message that was received in order. 3.1. CONNECTION_RQST and CONNECTION_ACK The header format and the list of parameters that are exchanged during establishing a connection are provided below. 0 1 2 3 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TX_BW_SIZE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RX_BW_SIZE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KEEP_ALIVE_INTERVAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RX_BW_TIMEOUT | Azmak, et al. Informational - Expires December 2001 5 Boosted Session Transport (BST) Protocol February 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRC_PORT | VERSION | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAX_RX_BW_SLOT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CliIPNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CliIP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CliIP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TX_BW_SIZE (Unsigned Long): Size of the TX window. Number of packets after which an ACK is expected RX_BW_SIZE (Unsigned Long): Size of the RX window. Number of packets after which an ACK is sent. KEEP_ALIVE_INTERVAL (Unsigned Long): The interval at which to send an ACK in order to keep the connection open. RX_BW_TIMEOUT (Unsigned Long): The interval after which an ACK is to be sent, even in the absence of incoming packets. SRC_PORT (Unsigned Short): BST local port number. VERSION (Unsigned Short): BST version. MAX_RX_BW_SLOT (Unsigned Long): Maximum number of bytes that can be sent within a time slot. TX_TIME_SLOT (Unsigned Long): Duration of a timeslot (in multiples of 50ms.) CliIpNum (Unsigned Long): Group Client: Number of subsets for which the client is responsible. CliIP[CliIPNum] (Array): IP address and subnet mask for each subnet. 3.2. NACK The header format and the parameters that are used in Negative Acknowledgement (NACK) are described below. 0 1 2 3 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | num_of_holes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last_Received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Azmak, et al. Informational - Expires December 2001 6 Boosted Session Transport (BST) Protocol February 2001 | hole[0] Start | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hole[0] End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hole[0] Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hole[n] Start | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hole[n] End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hole[n] Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "num_of_holes" (Unsigned Long): The number of holes that are identified in this message. "last_Received" (Unsigned Long): The sequence number of the most recently received packet. "holes[]" (Array): An array of information for each gap (hole) in reception. A hole is a contiguous set of packets that are expected at the Receiver, but not received, even though packets with higher sequence numbers have already been received. A hole is identified by the following information: 1. Start: sequence number of the first packet that has not been received. 2. End: sequence number of the last packet that has not been received. 3. Status: indication of how many times the packets in a particular hole have been re-requested. Each time the Receiver sends a NACK for a particular hole, it increments the Status parameter by 1. The "holes" array includes these three information elements for every known hole at the time of a NACK. 4. Connection Establishment & Release This section describes the mechanisms for connection establishment and release. The terms "Client" and "Server" are used to identify the two ends of a connection. Even though the protocol is symmetric, in the rest of the paper, "Client" is the agent that initiates connection setup and release. 4.1. Connection Establishment Connection establishment is done via two-way handshake, as opposed to TCP's three-way handshake. The Client sends a CONNECTION_RQST message to request a new connection. The Server responds with CONNECTION_ACK message to complete the connection. When the Client Azmak, et al. Informational - Expires December 2001 7 Boosted Session Transport (BST) Protocol February 2001 receives the CONNECTION_ACK message, it can move to the data transfer stage. The Client will attempt to request a connection for a limited number of times. The parameter CONNECT_RETRIES determines the number of times that the Client will attempt a connection. At each connection request, the Client will wait for a limited period to receive an acknowledgement. This duration is determined by the CONNECT_TIMEOUT timer. The Client will stop its attempts after the number of unsuccessful connection requests reaches the value indicated by CONNECT_RETRIES. 4.2. Connection Release Either side, the Client or the Server, can initiate connection release. Typically, an application that is running on a Client will instruct BST (or TCP for that matter) to close an existing connection. This is done via SHUTDOWN message. No acknowledgement is expected. In addition, each side may close its end of a connection and release resources independent of the other, if one of the following two conditions occur; (a) No packet has been received from the other side for a duration that is specified by the KEEP_ALIVE_TO timer, (b) there has been no data exchange - excluding MSG_ALIVE messages - between the two sides for a duration that is specified by the IDLE_TO timer. MSG_ALIVE messages maintain a connection in open state, even when no user/application data is flowing, in order to avoid frequent teardown and re-establishment of BST sessions. 5. Data Transfer Data transfer occurs via MSG_SEND and ACK/NACK (MSG_ALIVE/MSG_LOST) messages. BST incorporates a number of mechanisms in order to improve the throughput over a wireless link. These mechanisms are reduced number of Acknowledgement messages, selective negative Acknowledgement, dynamic rate control and Bandwidth sharing. They are described below. 5.1. ACK/NACK In BST, the Client (Receiver) sends an Acknowledgement for every n packets. The value of n is determined by either of two parameters, "RX_BW_SIZE", or "RX_BUF_SIZE". How these parameters differ from one another is described later in this document. Similarly, the Server (Sender) expects to receive an Acknowledgement for every m packets that it sends. The value of m is determined by either of two parameters, TX_BW_SIZE or TX_BUF_SIZE. Clearly, TX_BUF_SIZE and RX_BUF_SIZE (and TX_BW_SIZE & RX_BW_SIZE) are Azmak, et al. Informational - Expires December 2001 8 Boosted Session Transport (BST) Protocol February 2001 related to one another, and the values of these parameters are exchanged between the Server and the Client during connection establishment. The RX and TX parameters are similar in concept to the "advertised window size" and "cwnd", respectively; however, they operate differently, in that this information is not contained in every packet that traverses the network. It is exchanged between the two parties when the connection is made. Determination of optimal values for these parameters over a dynamic link is beyond the scope of this paper. In addition, two timers, RX_BUF_TIMEOUT and RX_BW_TIMEOUT, associated with the parameters RX_BUF_SIZE and RX_BW_SIZE, respectively, are used to guarantee that an Acknowledgement or Negative Acknowledgement is sent within a reasonable time in the case of high packet loss or large delays between the Sender and the Receiver. Determination of optimal values for these parameters is beyond the scope of this paper. 5.1.1. Packet Loss v. Packet "Disorder" BST differentiates lost packets from packets that are received out of order (packet disorder). This is done in order to limit the number of unnecessary retransmissions over links that are bandwidth limited and prone to noise. At the Receiver, packet loss and packet disorder can be indistinguishable. For instance, when one considers the case in which the Sender sends packets 1, 2 and 3 in order, and the Receiver receives packets 1 and 3 in that order, but does not receive packet 2. At this point, the Receiver cannot differentiate whether packet is lost or delayed in the network. In order to resolve this confusion, the BST waits for a period of time, in order to see if packets that are expected will arrive, before reporting them missing to the Sender. This is accomplished with the aid of two timers, DISORDER_TIME and HOLE_REPORT_TIME. If the Receiver receives a packet that is deemed to be out of order, it will wait for a period of time determined by DISORDER_TIME before declaring a "hole". This hole will be reported to the Sender in the next NACK message. A NACK will never be initiated for a potential hole before its DISORDER_TIME timer expires. HOLE_REPORT_TIME determines the period at the end of which a hole is to send a NACK. In the NACK, the Receiver is to report all known holes to the Sender via a NACK message. When there is at least one definite hole whose HOLE_REPORT_TIME timer has expired, the NACK will include all other holes, even if their HOLE_REPORT_TIME timers have not yet expired. In this way, HOLE_REPORT_TIME timer makes it possible to avoid excessive NACKs in a noisy environment (high BER), in which packet loss rate may be high. Azmak, et al. Informational - Expires December 2001 9 Boosted Session Transport (BST) Protocol February 2001 5.2. Rate Control BST employs a time-division mechanism for transmission. The Sender determines a time-slot, and the maximum number of packets that can be sent during each time-slot. Therefore, by increasing or decreasing the number of packets that can be transmitted during each time-slot, BST can manage the rate of transmission. The specifics of the rate control mechanism are beyond the scope of this paper. 5.3. Bandwidth Sharing The BST protocol has the ability to support a number of simultaneous connections. In addition, it is able to support non-BST traffic in a pass-through mode. These mechanisms are described below. 5.3.1. Control and Data Queues For each BST link, two queues are defined at the Sender: 1. Data packets. 2. Control messages and data packets that are to be retransmitted. These queues may be defined on a per-connection basis, or they may be shared among several BST connections. In each time-slot, control messages and retransmitted data packets are given priority. Data packets from queue 1 are transmitted, only if there is additional bandwidth available. 5.3.2. Simultaneous Connections When a link is shared among several BST connections, each connection is allocated a share of the overall bandwidth. Each connection is guaranteed a minimum bandwidth, and the remaining bandwidth is distributed in equal chunks in a round-robin fashion among all existing connections. This approach guarantees each connection the ability to maintain its status, because no connection is denied the ability to send at least one message within each time-slot. In those cases where some of the connections need additional bandwidth and others do not, this approach also makes it possible to make better use of the overall bandwidth. In addition, BST can manage its TX & RX windows and timers, on a per-connection basis, or on a per-link (multiple connections) basis. Similar parameters determine which approach is taken, in terms of BST link management. TX_BUF_SIZE, RX_BUF_SIZE, RX_BUF_TIMEOUT parameters are used when multiple connections are managed Azmak, et al. Informational - Expires December 2001 10 Boosted Session Transport (BST) Protocol February 2001 simultaneously. TX_BW_SIZE, RX_BW_SIZE and RX_BW_TIMEOUT parameters are used when each connection is managed separately. 5.3.3. Non-BST Traffic Under certain circumstances, BST enables a connection to bypass BST in favor of TCP or UDP traffic. In order to support this ability, a portion of the available bandwidth is allocated to non-BST traffic. Size of non-BST bandwidth is determined by the NON_BST_BW parameter. If none of the existing connections request bandwidth for non-BST traffic, this bandwidth is returned to the BST pool, to be utilized by BST connections. 6. Security Considerations The BST protocol does not affect any of the Transport layer security protocols, such as Secure Sockets Layer (SSL), or Transport Layer Security (TLS). This is because, BST does not modify the contents of the TCP payload. Similarly, BST does not pose any potential security risk to Layer 2 Protocols, such Point-to-Point Protocol (PPP), because it does not modify IP information. On the other hand, the BST protocol replaces TCP headers with BST headers over the wireless/satellite hop. As a result, potential security issues exist with the Security Architecture for the Internet Protocol (IPSec) [8]. This is due to the fact that Authentication Header (AH) and Encapsulating Security Payload (ESP) information is calculated using much of the TCP header information. Possible resolutions exist, such as managing two secure and interrelated links, one over the BST hop and another over the TCP connections spanning any intranet, or the rest of the Internet. At this writing, possible resolutions are under study. Azmak, et al. Informational - Expires December 2001 11 Boosted Session Transport (BST) Protocol February 2001 7. References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Allman, M., ed., et al. "Ongoing TCP Research Related to Satellites", RFC 2160, February 2000. 3 Allman, M. Glover, D., Sanchez, L., "Enhancing TCP Over Satellite Channels using Standard Mechanisms", RFC 2488, January 1999. 4 Mogul, J., and Deering, S., "Path MTU Discovery", RFC 1191, November 1990. 5 Mathis, M., Mahdavi, J., Floyd, S. and Romanow, A., "TCP Selective Acknowledgement Options", RFC 2018, October 1996. 6 Braden, R., "Requirements for Internet Hosts -- Communication Layers, STD 3, RFC 1121, October 1989. 7 Montenegro, G., Dawkins, et al., "Long Thin Networks", RFC 2757, January 2000. 8 Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 8. Author's Addresses Okan Azmak Flash Networks, Inc. 2137 Highway 35 N Phone: 1-732-203-4070 x21 Holmdel, NJ USA Email: okan@flashnetworks.com Chava Leviatan Flash Networks, Inc. 16 Galgalei Haplada St Herzelia 46733 Phone: +972 (9) 958 0666 x221 Israel Email: chava@flashnetworks.com Itzcak Pechtalt Flash Networks, Inc. 16 Galgalei Haplada St Herzelia 46733 Phone: +972 (9) 958 0666 x219 Israel Email: itzcak@flashnetworks.com Azmak, et al. Informational - Expires December 2001 12