idnits 2.17.1 draft-azmak-bst-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 684 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2001) is 8470 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 87 looks like a reference -- Missing reference section? '2' on line 203 looks like a reference -- Missing reference section? '3' on line 203 looks like a reference -- Missing reference section? '7' on line 203 looks like a reference -- Missing reference section? '4' on line 151 looks like a reference -- Missing reference section? '6' on line 171 looks like a reference -- Missing reference section? '5' on line 172 looks like a reference -- Missing reference section? 'CliIPNum' on line 322 looks like a reference -- Missing reference section? '0' on line 345 looks like a reference -- Missing reference section? '8' on line 595 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft O. Azmak, C. Leviatan, 2 I. Pechtalt 3 Document: draft-azmak-bst-00.txt Flash Networks, Inc. 4 Expires: 2001 February 2001 6 Boosted Session Transport (BST) Protocol for Improved Performance in 7 Satellite, Wireless and Mobile Networks 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 TCP treats packet losses as an indication of congestion in the 32 network, and it reduces transmission rates drastically until an 33 optimal rate is found for data transmission. The problems that 34 satellite and other wireless links pose to TCP have been addressed 35 elsewhere (please see Section 2). This paper proposes a new 36 Transport layer protocol, Boosted Session Transport (BST) that is 37 intended to work as a counterpart to TCP over a single wireless or 38 satellite hop. The BST protocol introduces a number of mechanisms to 39 specifically address the demands of satellite, wireless and mobile 40 networks, in terms of transient packet losses, large Round-Trip Time 41 (RTT), and need for more efficient use of available bandwidth. BST 42 has been designed to be used over the wireless access links to the 43 Internet; therefore, it is intended to work seamlessly with TCP in 44 order to provide wireless access to the whole of Internet, not to a 45 limited subset of it. This paper describes the BST protocol. 47 Table of Contents 48 Status of this Memo................................................1 49 Abstract ..........................................................1 50 Conventions used in this document..................................2 51 1. Introduction..............................................2 53 Azmak, et al. Informational - Expires December 2001 1 55 Boosted Session Transport (BST) Protocol February 2001 57 2. Background................................................3 58 3. BST Header Information....................................4 59 3.1. CONNECTION_RQST and CONNECTION_ACK........................5 60 3.2. NACK......................................................6 61 4. Connection Establishment & Release........................7 62 4.1. Connection Establishment..................................7 63 4.2. Connection Release........................................8 64 5. Data Transfer.............................................8 65 5.1. ACK/NACK..................................................8 66 5.1.1. Packet Loss v. Packet "Disorder"..........................9 67 5.2. Rate Control.............................................10 68 5.3. Bandwidth Sharing........................................10 69 5.3.1. Control and Data Queues..................................10 70 5.3.2. Simultaneous Connections.................................10 71 5.3.3. Non-BST Traffic..........................................11 72 6. Security Considerations..................................11 73 7. References...............................................12 74 8. Author's Addresses.......................................12 76 Conventions used in this document 78 BST indicates Boosted Session Transport. 80 The term "wireless" is meant to encompass not only satellite, but 81 also cellular, PCS, CDPD and other mobile data solutions, both in 2G 82 and 3G technologies. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 86 this document are to be interpreted as described in RFC-2119 [1]. 88 1. Introduction 90 This paper proposes a new protocol that is specifically designed to 91 overcome the performance degradation that TCP experiences in 92 wireless media. As it is well established, TCP's design principles 93 treat the network as a "black box", and consider packet loss only as 94 a sign of congestion in the network. Because of these principles, 95 TCP does not deal well with transient errors (due to noise or signal 96 drop out, as opposed to congestion in the network) and long Round- 97 Trip Times. In addition, TCP is too "chatty" to be effective over 98 wireless links. 100 Boosted Session Transport (BST) protocol was designed to improve the 101 bandwidth utilization in wireless (satellite and cellular) access 102 points to the Internet. It is designed to interwork with TCP as a 103 transport layer connection-oriented protocol. On the Client side, 104 TCP packets are converted into BST packets. These BST packets are 105 transmitted over the RF link, and the BST Server reconstitutes TCP 106 packets. These TCP packets are then routed to the Internet. During 107 the conversion to and from BST, TCP header information is replaced 109 Azmak, et al. Informational - Expires December 2001 2 111 Boosted Session Transport (BST) Protocol February 2001 113 with BST headers. TCP payload is compressed whenever possible, in 114 order to increase the effective throughput over the wireless link. 116 This paper is organized as follows. Section 2 provides background on 117 TCP performance in satellite networks. This background lends itself 118 to addressing the demands of terrestrial cellular networks, as well. 119 Section 3 provides the BST header information, BST messages and 120 their parameters. Section 4 describes connection establishment and 121 release in the BST protocol. Section 5 describes data transfer and 122 congestion avoidance mechanisms. Section 6 addresses the security 123 considerations. 125 2. Background 127 Performance degradation that TCP suffers over satellite links, and 128 potential resolutions have been discussed in earlier RFCs [2], [3]. 129 [2] provides a survey of research topics that are currently under 130 consideration to overcome TCP's problems in satellites. [3] provides 131 a description of the problems TCP faces in satellites and makes a 132 number of recommendations in dealing with those difficulties. In 133 addition, [7] highlights the requirements that "Long Thin Networks" 134 place on TCP, surveys proposed solutions, and makes a number of 135 recommendations. Many of the recommendations in [3] and [7] mirror 136 one another, and they pose the problem that wireless links pose to 137 TCP as follows. 139 TCP employs four mechanisms to monitor its transmission 140 characteristics: slow start, congestion avoidance, fast retransmit 141 and fast recovery. The problem that wireless links present to TCP 142 are: long feedback loop, large bandwidth * RTT (Round-Trip Time) 143 product, variable round-trip times, intermittent connectivity, and 144 increased Bit-Error Rate (BER). 146 Long feedback loop means that Acknowledgements will take longer to 147 reach the sender. This prolongs the initial period during which 148 slow-start algorithm controls the bandwidth utilization. With larger 149 RTT, it takes TCP longer to achieve optimal transmission speed, and 150 a lot of available bandwidth is not utilized. Faster methods for 151 connection bandwidth determination and optimal MTU sizing [4] are 152 needed to counter some of the effects of long feedback loops. 153 Regarding optimal MTU size, one should keep in mind that in 154 particularly wireless packet data networks, such as CDPD, where 155 available bandwidth is shared among a varying number of users with 156 varying bandwidth demands, optimal MTU size is likely to change over 157 the course of a single session. 159 Lange bandwidth*RTT product increases the amount traffic that TCP 160 has to maintain "in flight" without receiving Acknowledgements. 161 Having a larger number of packets "in flight" compounds the problems 162 that are caused by variable RTT, intermittent connectivity, and 163 larger BER. Therefore, efficient mechanisms are needed to limit 164 retransmissions only to lost packets, and to deal effectively with 165 packets arriving out of order ("packet disorder"). These mechanisms 167 Azmak, et al. Informational - Expires December 2001 3 169 Boosted Session Transport (BST) Protocol February 2001 171 can be implemented via Delayed ACKs [6] and Selective ACKs (SACK) 172 [5], combined with more effective management of transmit and receive 173 windows. 175 Variable RTT affects the order in which packets arrive at the 176 receiver. For instance, packets 1, 2, 3 sent in that order, may 177 arrive at the receiver in the order 2, 3, 1. Alternative 178 Acknowledgement methods that are mentioned above are needed in order 179 to differentiate packet loss from loss of packet order ("packet 180 disorder"), and to deal with the two cases more effectively. 182 Intermittent connectivity can be experienced in non-Geo Stationary 183 Orbit (GSO) satellite configurations [3], and also in cellular/PCS 184 networks due to handovers. These breaks in connectivity are likely 185 to introduce packet losses. Please see the discussion on larger BER 186 below on its implications for TCP. 188 Larger BER affects the TCP in an indirect way. By design, TCP treats 189 packet loss as a sign of congestion in the network; therefore, loss 190 of a single packet causes drastic reduction in transmission speeds. 191 Greater BER in wireless networks tends to cause packet loss due to 192 the channel characteristics of the radio frequency (RF) environment, 193 rather than congestion in the link. Another indirect effect of 194 greater BER is felt in the ordering of packets. This is due to the 195 Automatic Resend reQuest (ARQ) mechanisms that many wireless Link 196 Layer (L2) solutions employ. When an L2 ARQ protocol detects 197 corruption, it requests certain package(s) to be resent. This is 198 done below TCP/IP layers, and it introduces variable delay to the 199 transmission path. 201 In summary, a number of mechanisms have been recommended to enhance 202 TCP's performance over satellite, and by extension, over wireless 203 networks [2, 3, 7]. Boosted Session Transport (BST) protocol 204 incorporates many of these recommendations, and introduces new ideas 205 in order to maximize bandwidth utilization over wireless links in 206 which bandwidth is scarce and transient errors are frequent than in 207 terrestrial media. The improvements include a less chatty 208 transmission scheme, delayed ACKs, selective ACKs/NACKs (SACKs), 209 larger transmission windows and faster retransmission and recovery 210 algorithms, and mechanisms to differentiate packet loss from loss of 211 packet order. The rest of this paper describes the BST messages, 212 parameters, and basic data transmission. 214 3. BST Header Information 216 This section provides the format for the BST header, and describes 217 the parameters of the header. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Azmak, et al. Informational - Expires December 2001 4 225 Boosted Session Transport (BST) Protocol February 2001 227 | Dest port | Type | Flags | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | msg_no | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Lmsg no | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 "dest_port" (Short integer) is the port number for the remote end of 235 a BST connection. 237 "type" (Char) indicates which of the following messages is intended 238 in the current segment: 240 1. SHUTDOWN - Close BST connection 241 2. CONNECTION_RQST - Request a new connection 242 3. CONNECTION_ACK - Acknowledgement of a CONNECTION_RQST 243 4. MSG_LOST - a Negative Acknowledgement. 244 5. MSG_ALIVE - A message to keep a connection open, when there is no 245 data to be sent. 246 6. MSG_SEND - Message for regular data transfer. 248 "flags"(Unsigned Char) is used to indicate the following conditions: 249 1. Fragmentation (bit 7) - whether the payload has been fragmented; 250 2. Last Fragment (bit 6) - to identify the last fragment in such a 251 transfer. This bit is set to 1 in the last fragment. 252 3. Internal use (bit 2) - undefined; 253 4. BST Stop (bit 0) - is a flow-control flag that the receiver sends 254 to the sender to stop BST traffic in order to alleviate buffer 255 overflow. 257 "msg_no" (Unsigned Long) is the sequence number of the current BST 258 packet. 260 "Lmsg_no" (Unsigned Long) is the sequence number of the last message 261 that was received in order. 263 3.1. CONNECTION_RQST and CONNECTION_ACK 265 The header format and the list of parameters that are exchanged 266 during establishing a connection are provided below. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | TX_BW_SIZE | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | RX_BW_SIZE | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | KEEP_ALIVE_INTERVAL | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | RX_BW_TIMEOUT | 279 Azmak, et al. Informational - Expires December 2001 5 281 Boosted Session Transport (BST) Protocol February 2001 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | SRC_PORT | VERSION | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | MAX_RX_BW_SLOT | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | CliIPNum | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | CliIP | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | ... | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | CliIP | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 TX_BW_SIZE (Unsigned Long): Size of the TX window. Number of packets 298 after which an ACK is expected 300 RX_BW_SIZE (Unsigned Long): Size of the RX window. Number of packets 301 after which an ACK is sent. 303 KEEP_ALIVE_INTERVAL (Unsigned Long): The interval at which to send 304 an ACK in order to keep the connection open. 306 RX_BW_TIMEOUT (Unsigned Long): The interval after which an ACK is to 307 be sent, even in the absence of incoming packets. 309 SRC_PORT (Unsigned Short): BST local port number. 311 VERSION (Unsigned Short): BST version. 313 MAX_RX_BW_SLOT (Unsigned Long): Maximum number of bytes that can be 314 sent within a time slot. 316 TX_TIME_SLOT (Unsigned Long): Duration of a timeslot (in multiples 317 of 50ms.) 319 CliIpNum (Unsigned Long): Group Client: Number of subsets for which 320 the client is responsible. 322 CliIP[CliIPNum] (Array): IP address and subnet mask for each subnet. 324 3.2. NACK 326 The header format and the parameters that are used in Negative 327 Acknowledgement (NACK) are described below. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | num_of_holes | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | last_Received | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Azmak, et al. Informational - Expires December 2001 6 339 Boosted Session Transport (BST) Protocol February 2001 341 | hole[0] Start | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | hole[0] End | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | hole[0] Status | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | ... | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | hole[n] Start | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | hole[n] End | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | hole[n] Status | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 "num_of_holes" (Unsigned Long): The number of holes that are 357 identified in this message. 359 "last_Received" (Unsigned Long): The sequence number of the most 360 recently received packet. 362 "holes[]" (Array): An array of information for each gap (hole) in 363 reception. A hole is a contiguous set of packets that are expected 364 at the Receiver, but not received, even though packets with higher 365 sequence numbers have already been received. A hole is identified by 366 the following information: 367 1. Start: sequence number of the first packet that has not been 368 received. 369 2. End: sequence number of the last packet that has not been 370 received. 371 3. Status: indication of how many times the packets in a particular 372 hole have been re-requested. Each time the Receiver sends a NACK for 373 a particular hole, it increments the Status parameter by 1. 375 The "holes" array includes these three information elements for 376 every known hole at the time of a NACK. 378 4. Connection Establishment & Release 380 This section describes the mechanisms for connection establishment 381 and release. The terms "Client" and "Server" are used to identify 382 the two ends of a connection. Even though the protocol is symmetric, 383 in the rest of the paper, "Client" is the agent that initiates 384 connection setup and release. 386 4.1. Connection Establishment 388 Connection establishment is done via two-way handshake, as opposed 389 to TCP's three-way handshake. The Client sends a CONNECTION_RQST 390 message to request a new connection. The Server responds with 391 CONNECTION_ACK message to complete the connection. When the Client 393 Azmak, et al. Informational - Expires December 2001 7 395 Boosted Session Transport (BST) Protocol February 2001 397 receives the CONNECTION_ACK message, it can move to the data 398 transfer stage. 400 The Client will attempt to request a connection for a limited number 401 of times. The parameter CONNECT_RETRIES determines the number of 402 times that the Client will attempt a connection. 404 At each connection request, the Client will wait for a limited 405 period to receive an acknowledgement. This duration is determined by 406 the CONNECT_TIMEOUT timer. 408 The Client will stop its attempts after the number of unsuccessful 409 connection requests reaches the value indicated by CONNECT_RETRIES. 411 4.2. Connection Release 413 Either side, the Client or the Server, can initiate connection 414 release. Typically, an application that is running on a Client will 415 instruct BST (or TCP for that matter) to close an existing 416 connection. This is done via SHUTDOWN message. No acknowledgement is 417 expected. 419 In addition, each side may close its end of a connection and release 420 resources independent of the other, if one of the following two 421 conditions occur; (a) No packet has been received from the other 422 side for a duration that is specified by the KEEP_ALIVE_TO timer, 423 (b) there has been no data exchange - excluding MSG_ALIVE messages - 424 between the two sides for a duration that is specified by the 425 IDLE_TO timer. MSG_ALIVE messages maintain a connection in open 426 state, even when no user/application data is flowing, in order to 427 avoid frequent teardown and re-establishment of BST sessions. 429 5. Data Transfer 431 Data transfer occurs via MSG_SEND and ACK/NACK (MSG_ALIVE/MSG_LOST) 432 messages. BST incorporates a number of mechanisms in order to 433 improve the throughput over a wireless link. 435 These mechanisms are reduced number of Acknowledgement messages, 436 selective negative Acknowledgement, dynamic rate control and 437 Bandwidth sharing. They are described below. 439 5.1. ACK/NACK 441 In BST, the Client (Receiver) sends an Acknowledgement for every n 442 packets. The value of n is determined by either of two parameters, 443 "RX_BW_SIZE", or "RX_BUF_SIZE". How these parameters differ from one 444 another is described later in this document. 446 Similarly, the Server (Sender) expects to receive an Acknowledgement 447 for every m packets that it sends. The value of m is determined by 448 either of two parameters, TX_BW_SIZE or TX_BUF_SIZE. Clearly, 449 TX_BUF_SIZE and RX_BUF_SIZE (and TX_BW_SIZE & RX_BW_SIZE) are 451 Azmak, et al. Informational - Expires December 2001 8 453 Boosted Session Transport (BST) Protocol February 2001 455 related to one another, and the values of these parameters are 456 exchanged between the Server and the Client during connection 457 establishment. The RX and TX parameters are similar in concept to 458 the "advertised window size" and "cwnd", respectively; however, they 459 operate differently, in that this information is not contained in 460 every packet that traverses the network. It is exchanged between the 461 two parties when the connection is made. Determination of optimal 462 values for these parameters over a dynamic link is beyond the scope 463 of this paper. 465 In addition, two timers, RX_BUF_TIMEOUT and RX_BW_TIMEOUT, 466 associated with the parameters RX_BUF_SIZE and RX_BW_SIZE, 467 respectively, are used to guarantee that an Acknowledgement or 468 Negative Acknowledgement is sent within a reasonable time in the 469 case of high packet loss or large delays between the Sender and the 470 Receiver. Determination of optimal values for these parameters is 471 beyond the scope of this paper. 473 5.1.1. Packet Loss v. Packet "Disorder" 475 BST differentiates lost packets from packets that are received out 476 of order (packet disorder). This is done in order to limit the 477 number of unnecessary retransmissions over links that are bandwidth 478 limited and prone to noise. 480 At the Receiver, packet loss and packet disorder can be 481 indistinguishable. For instance, when one considers the case in 482 which the Sender sends packets 1, 2 and 3 in order, and the Receiver 483 receives packets 1 and 3 in that order, but does not receive packet 484 2. At this point, the Receiver cannot differentiate whether packet 485 is lost or delayed in the network. In order to resolve this 486 confusion, the BST waits for a period of time, in order to see if 487 packets that are expected will arrive, before reporting them missing 488 to the Sender. 490 This is accomplished with the aid of two timers, DISORDER_TIME and 491 HOLE_REPORT_TIME. If the Receiver receives a packet that is deemed 492 to be out of order, it will wait for a period of time determined by 493 DISORDER_TIME before declaring a "hole". This hole will be reported 494 to the Sender in the next NACK message. A NACK will never be 495 initiated for a potential hole before its DISORDER_TIME timer 496 expires. 498 HOLE_REPORT_TIME determines the period at the end of which a hole is 499 to send a NACK. In the NACK, the Receiver is to report all known 500 holes to the Sender via a NACK message. When there is at least one 501 definite hole whose HOLE_REPORT_TIME timer has expired, the NACK 502 will include all other holes, even if their HOLE_REPORT_TIME timers 503 have not yet expired. 505 In this way, HOLE_REPORT_TIME timer makes it possible to avoid 506 excessive NACKs in a noisy environment (high BER), in which packet 507 loss rate may be high. 509 Azmak, et al. Informational - Expires December 2001 9 511 Boosted Session Transport (BST) Protocol February 2001 513 5.2. Rate Control 515 BST employs a time-division mechanism for transmission. The Sender 516 determines a time-slot, and the maximum number of packets that can 517 be sent during each time-slot. Therefore, by increasing or 518 decreasing the number of packets that can be transmitted during each 519 time-slot, BST can manage the rate of transmission. 521 The specifics of the rate control mechanism are beyond the scope of 522 this paper. 524 5.3. Bandwidth Sharing 526 The BST protocol has the ability to support a number of simultaneous 527 connections. In addition, it is able to support non-BST traffic in a 528 pass-through mode. These mechanisms are described below. 530 5.3.1. Control and Data Queues 532 For each BST link, two queues are defined at the Sender: 533 1. Data packets. 534 2. Control messages and data packets that are to be retransmitted. 536 These queues may be defined on a per-connection basis, or they may 537 be shared among several BST connections. 539 In each time-slot, control messages and retransmitted data packets 540 are given priority. Data packets from queue 1 are transmitted, only 541 if there is additional bandwidth available. 543 5.3.2. Simultaneous Connections 545 When a link is shared among several BST connections, each connection 546 is allocated a share of the overall bandwidth. Each connection is 547 guaranteed a minimum bandwidth, and the remaining bandwidth is 548 distributed in equal chunks in a round-robin fashion among all 549 existing connections. 551 This approach guarantees each connection the ability to maintain its 552 status, because no connection is denied the ability to send at least 553 one message within each time-slot. In those cases where some of the 554 connections need additional bandwidth and others do not, this 555 approach also makes it possible to make better use of the overall 556 bandwidth. 558 In addition, BST can manage its TX & RX windows and timers, on a 559 per-connection basis, or on a per-link (multiple connections) basis. 560 Similar parameters determine which approach is taken, in terms of 561 BST link management. TX_BUF_SIZE, RX_BUF_SIZE, RX_BUF_TIMEOUT 562 parameters are used when multiple connections are managed 564 Azmak, et al. Informational - Expires December 2001 10 566 Boosted Session Transport (BST) Protocol February 2001 568 simultaneously. TX_BW_SIZE, RX_BW_SIZE and RX_BW_TIMEOUT parameters 569 are used when each connection is managed separately. 571 5.3.3. Non-BST Traffic 573 Under certain circumstances, BST enables a connection to bypass BST 574 in favor of TCP or UDP traffic. In order to support this ability, a 575 portion of the available bandwidth is allocated to non-BST traffic. 576 Size of non-BST bandwidth is determined by the NON_BST_BW parameter. 577 If none of the existing connections request bandwidth for non-BST 578 traffic, this bandwidth is returned to the BST pool, to be utilized 579 by BST connections. 581 6. Security Considerations 583 The BST protocol does not affect any of the Transport layer security 584 protocols, such as Secure Sockets Layer (SSL), or Transport Layer 585 Security (TLS). This is because, BST does not modify the contents of 586 the TCP payload. 588 Similarly, BST does not pose any potential security risk to Layer 2 589 Protocols, such Point-to-Point Protocol (PPP), because it does not 590 modify IP information. 592 On the other hand, the BST protocol replaces TCP headers with BST 593 headers over the wireless/satellite hop. As a result, potential 594 security issues exist with the Security Architecture for the 595 Internet Protocol (IPSec) [8]. This is due to the fact that 596 Authentication Header (AH) and Encapsulating Security Payload (ESP) 597 information is calculated using much of the TCP header information. 598 Possible resolutions exist, such as managing two secure and 599 interrelated links, one over the BST hop and another over the TCP 600 connections spanning any intranet, or the rest of the Internet. At 601 this writing, possible resolutions are under study. 603 Azmak, et al. Informational - Expires December 2001 11 605 Boosted Session Transport (BST) Protocol February 2001 607 7. References 609 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement 610 Levels", BCP 14, RFC 2119, March 1997 612 2 Allman, M., ed., et al. "Ongoing TCP Research Related to 613 Satellites", RFC 2160, February 2000. 615 3 Allman, M. Glover, D., Sanchez, L., "Enhancing TCP Over Satellite 616 Channels using Standard Mechanisms", RFC 2488, January 1999. 618 4 Mogul, J., and Deering, S., "Path MTU Discovery", RFC 1191, 619 November 1990. 621 5 Mathis, M., Mahdavi, J., Floyd, S. and Romanow, A., "TCP Selective 622 Acknowledgement Options", RFC 2018, October 1996. 624 6 Braden, R., "Requirements for Internet Hosts -- Communication 625 Layers, STD 3, RFC 1121, October 1989. 627 7 Montenegro, G., Dawkins, et al., "Long Thin Networks", RFC 2757, 628 January 2000. 630 8 Kent, S., Atkinson, R., "Security Architecture for the Internet 631 Protocol", RFC 2401, November 1998. 633 8. Author's Addresses 635 Okan Azmak 636 Flash Networks, Inc. 637 2137 Highway 35 N Phone: 1-732-203-4070 x21 638 Holmdel, NJ USA Email: okan@flashnetworks.com 640 Chava Leviatan 641 Flash Networks, Inc. 642 16 Galgalei Haplada St 643 Herzelia 46733 Phone: +972 (9) 958 0666 x221 644 Israel Email: chava@flashnetworks.com 646 Itzcak Pechtalt 647 Flash Networks, Inc. 648 16 Galgalei Haplada St 649 Herzelia 46733 Phone: +972 (9) 958 0666 x219 650 Israel Email: itzcak@flashnetworks.com 652 Azmak, et al. Informational - Expires December 2001 12