[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
   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-

   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
   The list of Internet-Draft Shadow Directories can be accessed at


   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",
   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

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

   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

   "msg_no" (Unsigned Long) is the sequence number of the current BST

   "Lmsg_no" (Unsigned Long) is the sequence number of the last message
   that was received in order.


   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
   2. End: sequence number of the last packet that has not been
   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

   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.


   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,

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

   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

   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
   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