Internet DRAFT - draft-azmak-bst
draft-azmak-bst
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
