idnits 2.17.1 draft-ietf-rohc-tcp-taroc-04.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 36 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 36 pages 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. ** The abstract seems to contain references ([6], [4,5], [2,3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 21, 2001) is 8192 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 23 looks like a reference -- Missing reference section? '2' on line 1166 looks like a reference -- Missing reference section? '3' on line 1166 looks like a reference -- Missing reference section? '4' on line 49 looks like a reference -- Missing reference section? '5' on line 49 looks like a reference -- Missing reference section? '6' on line 49 looks like a reference -- Missing reference section? '7' on line 171 looks like a reference -- Missing reference section? '19' on line 987 looks like a reference -- Missing reference section? '8' on line 196 looks like a reference -- Missing reference section? '9' on line 197 looks like a reference -- Missing reference section? '10' on line 1166 looks like a reference -- Missing reference section? '11' on line 277 looks like a reference -- Missing reference section? '12' on line 277 looks like a reference -- Missing reference section? '18' on line 523 looks like a reference -- Missing reference section? '13' on line 531 looks like a reference -- Missing reference section? '14' on line 531 looks like a reference -- Missing reference section? '15' on line 930 looks like a reference -- Missing reference section? '20' on line 1301 looks like a reference -- Missing reference section? '16' on line 1135 looks like a reference -- Missing reference section? '17' on line 1135 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROHC WG HongBin Liao, Microsoft Research Asia 3 Internet Draft Qian Zhang, Microsoft Research Asia 4 Expires: May 2002 Wenwu Zhu, Microsoft Research Asia 5 Ya-Qin Zhang, Microsoft Research Asia 7 Richard Price, Siemens/Roke Manor 8 Robert Hancock, Siemens/Roke Manor 9 Stephen McCann, Siemens/Roke Manor 10 Mark A West, Siemens/Roke Manor 11 Abigail Surtees, Siemens/Roke Manor 12 Paul Ollis, Siemens/Roke Manor 14 November 21, 2001 16 TCP-Aware RObust Header Compression (TAROC) 17 draft-ietf-rohc-tcp-taroc-04.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026 [1]. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsolete by other documents 31 at any time. It is inappropriate to use Internet- Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 1. Abstract 42 As a major transport protocol of current Internet, TCP has the 43 problem of the large header overhead on bandwidth-limited links. 44 Header compression has been proven to be efficient for using TCP 45 over bandwidth-limited reliable links. Unfortunately, existing 46 TCP/IP header compression schemes do not work well on noisy links, 47 especially the one with high bit error rate and long roundtrip time. 48 In addition, existing schemes [2,3] have not addressed some TCP 49 options such as SACK [4,5] and Timestamps [6]. 51 draft-ietf-rohc-tcp-taroc-04.txt 53 A robust and efficient header compression scheme for TCP/IP, called 54 TAROC, is presented in this document. TAROC is composed of a 55 behavior-aware control mechanism, called TAROC-C, and a detailed 56 header encoding scheme. In this draft, the Efficient Protocol 57 Independent Compression (EPIC-LITE) scheme is used as the compressed 58 header encoding framework. The window-based LSB encoding is 59 introduced in our scheme for compressing redundant fields and 60 reducing error propagation. The key point of TAROC-C is the TCP 61 congestion window tracking approach, which can be used to improve 62 the efficiency of the window-based encoding and the performance of 63 the overall header compression scheme. With the dynamical congestion 64 window tracking, our scheme can achieve good performance even when 65 the feedback channel is not available. 67 draft-ietf-rohc-tcp-taroc-04.txt 69 Table of Contents 71 Status of this Memo................................................1 72 1. Abstract........................................................1 73 2. Conventions used in this document...............................6 74 3. Introduction....................................................6 75 4. The concept and components of TCP-Aware RObust Header compression 76 and Efficient Protocol Independent Compression (EPIC-LITE) scheme..8 77 5. The framework of TAROC-C........................................9 78 5.1. TCP congestion window tracking.............................9 79 5.1.1. General principle of congestion window tracking.......9 80 5.1.2. Congestion window tracking based on Sequence Number..10 81 5.1.3. Congestion window tracking based on Acknowledgment 82 Number......................................................11 83 5.1.4. Further discussion on congestion window tracking.....13 84 5.2. Compressor/decompressor state management with TAROC-C.....13 85 5.2.1. Compressor states....................................13 86 5.2.1.1. Initialization and Refresh (IR) state...........14 87 5.2.1.2. First Order (FO) State..........................14 88 5.2.1.3. Second Order (SO) State.........................14 89 5.2.2. Decompressor states..................................15 90 5.3. Compressor logic in TAROC-C...............................15 91 5.3.1. IR state.............................................15 92 5.3.2. FO state.............................................16 93 5.3.3. SO state.............................................16 94 5.4. Decompressor logic in TAROC-C.............................17 95 5.4.1. No Context State.....................................17 96 5.4.2. Full Context State...................................17 97 5.5. Modes of operation........................................18 98 5.5.1. Unidirectional mode -- U-mode........................18 99 5.5.2. Bi-directional Optimistic mode -- O-mode............18 100 5.5.2.1. Compressor states and logic (O-mode)...........18 101 5.5.2.2. Decompressor states and logic (O-mode).........19 102 5.5.3. Bi-directional Reliable mode -- R-mode..............19 103 5.5.3.1. Compressor states and logic (R-mode)...........19 104 5.5.3.2. Decompressor states and logic (R-mode).........20 105 5.6. Implementation issues.....................................20 106 5.6.1. Determine the value K................................20 107 5.6.2. Determine the value N................................20 108 5.6.3. Determine the frequency of updating context..........20 109 6. Coding scheme and compressed packet header format..............21 110 6.1. Window-based LSB encoding and fixed-payload encoding......21 111 6.2. The framework of EPIC-LITE scheme.........................21 112 6.3. ROHC Profile for compression of TCP/IP....................22 113 7. Conclusions....................................................24 114 8. Acknowledgments................................................25 115 9. Security considerations........................................25 116 10. Authors' addresses............................................26 117 11. References....................................................26 118 12. Intellectual property considerations..........................29 119 Appendix A - Simulation results...................................29 120 A.1. Simulation topology.......................................29 121 A.2. Tested header compression schemes.........................29 123 draft-ietf-rohc-tcp-taroc-04.txt 125 A.3. Simulations and results...................................30 126 A.3.1. 384kb................................................30 127 A.3.2. 114kb................................................32 128 A.3.3. 64kb.................................................33 129 A.3.4. 9.6kb................................................35 131 draft-ietf-rohc-tcp-taroc-04.txt 133 Document History 135 04 Nov. 21, 2001 Separate the control mechanism, TAROC-C, with 136 the detailed compressed packet formats 137 generation approach; 138 TAROC-C does not have an IPR-statement; 139 Introduce the simple TCP/IP profile; 140 Use EPIC-LITE as coding framework to simplify 141 the creation of new TCP/IP compressed header 142 format. 143 03 Oct. 26, 2001 Modify our TCP congestion window estimation 144 scheme with the MAX and MIN boundary; 145 Clarify the initialization and state 146 transition process in compressor state 147 management; 148 Add the CRC option in our compressed header. 149 02 July 20, 2001 Integrate TAROC with ROHC framework; 150 Add a second order (SO) state on compressor 151 side for fixed-payload packets compression; 152 Modify the coding method for type 153 identification and adjust corresponding packet 154 format to improve compression efficiency; 155 Update the simulation results. 156 01 March 01, 2001 Improve congestion window tracking algorithm 157 to handle the special cases where congestion 158 indications are lost; 159 Improve the compression efficiency by adding 160 fixed-payload encoding; 161 Change in header format accordingly. 162 00 November 17, 2000 First release. 164 draft-ietf-rohc-tcp-taroc-04.txt 166 2. Conventions used in this document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [7]. 172 Other terminologies, such as Profile, Context, Compressed header 173 format, Encoding method, Indicator flags, Set of compressed header 174 formats, Library of encoding methods, Input language, Control field, 175 are defined in [19]. 177 3. Introduction 179 The necessity and importance of doing TCP/IP header compression on 180 low- or medium-speed links have been discussed in [3]. For 181 conciseness, the general background information on header 182 compression has not been discussed in detail in this draft. Detailed 183 information can be found in RFC2507 [3]. Existing header compression 184 schemes, such as VJHC [2] and IPHC [3], rely on transmitting only 185 the difference from the previous header in order to reduce the large 186 overhead of TCP/IP header. 188 Although VJHC works well over reliable links, when used over 189 unreliable link, such as wireless links, it induces many additional 190 errors due to inconsistent contexts between the compressor and the 191 decompressor. Considering the high bit error rate in wireless 192 channel, if a packet gets lost, the compressed header of next packet 193 cannot be correctly decompressed. Then the decompressor must send 194 the request for resynchronization and in the meanwhile discard all 195 compressed header. A fatal result of this effect is that it prevents 196 TCP Fast Retransmit algorithm [8] from being fired and always causes 197 TCP retransmission timeout. This effect is shown in detail in [9]. 199 IPHC proposes two simple mechanisms, the TWICE algorithm and the 200 full header request mechanism, to reduce the errors due to the 201 inconsistent contexts between the compressor and the decompressor. 202 The TWICE algorithm assumes that only the Sequence Number field of 203 TCP segments are changing during the connection and the deltas among 204 consecutive packets are constant in most cases. However, these 205 assumptions are not always true, especially when TCP Timestamp and 206 SACK options are used. The full header request mechanism needs a 207 feedback channel, which is unavailable in some circumstances. Even 208 when the feedback channel is available, this mechanism still cannot 209 perform well enough if the roundtrip time of this link is very long. 210 Once a packet is corrupted on the noisy link, there are still 211 several consecutive packets dropped due to the inconsistency between 212 the compressor and the decompressor. 214 This Internet draft describes a new header compression scheme (TAROC, 215 or TCP-Aware RObust header Compression), which consists of two 216 components, TAROC-C (TCP-Aware RObust Header Compression Control 217 mechanism) and EPIC-LITE (Efficient Protocol Independent Compression 219 draft-ietf-rohc-tcp-taroc-04.txt 221 scheme). By combining them together, our scheme is more robust 222 against packet loss and hence achieves better performance over 223 wireless links. 225 draft-ietf-rohc-tcp-taroc-04.txt 227 4. The concept and components of TCP-Aware RObust Header compression 228 and Efficient Protocol Independent Compression (EPIC-LITE) scheme 230 This section first describes the concept of the TCP-aware robust 231 header compression (TAROC) proposal and then discusses how this 232 concept leads to a better performance when used over unreliable 233 links. 235 To design suitable mechanisms for efficient compression of all 236 TCP/IP header fields, it would be important to analyze their change 237 patterns first. It is known that the change patterns of several TCP 238 fields (for example, Sequence Number, Acknowledgement Number, Window, 239 etc.) are completely different from the ones of RTP, which had 240 already discussed in detail in [10], and are very hard to predict. 241 Thus, it is hard to encode these fields with k-LSB both efficiently 242 and robustly. On the other hand, Window-based LSB encoding [10], 243 which does not assume the linear changing pattern of the target 244 header fields, is more suitable to encode those TCP fields both 245 efficiently and robustly. 247 The main idea of TAROC-C, the control mechanism of TAROC, is the 248 combination of the Window-based LSB encoding (W-LSB encoding) and 249 dynamically TCP congestion window tracking. In W-LSB encoding, a 250 sliding window (VSW), which equals to the value r mentioned in the 251 Section 6.4 in EPIC-LITE [19], is maintained on the compressor side. 252 The compressor gets inconsistent with the decompressor only when the 253 reference value on the decompressor side is out of this VSW. By 254 keeping the sliding window large enough, the compressor rarely gets 255 out of synchronization with the decompressor. 257 However, the larger the sliding window is, the less the header 258 compression gains. To shrink the window size, the compressor needs 259 some form of feedback to get sufficient confidence that a certain 260 value will not be used as a reference by the decompressor. Then the 261 window can be advanced by removing that value and all other values 262 older than it. Obviously, when a feedback channel is available, 263 confidence can be achieved by proactive feedback in the form of ACKs 264 from the decompressor. A feedback channel, however, is unavailable 265 or expensive in some environments. In this Internet draft, a 266 mechanism based on dynamically tracking TCP congestion window is 267 proposed to explore such feedbacks from the nature feedback-loop of 268 TCP protocol itself. 270 Since TCP is a window-based protocol, a new segment cannot be 271 transmitted without getting the acknowledgment of segment in the 272 previous window. Upon receiving the new segment, the compressor can 273 get enough confidence that the decompressor has received the segment 274 in the previous window and then shrink the sliding window by 275 removing all the values older than that segment. 277 As originally outlined in [11] and specified in [12], TCP is 278 incorporated with four congestion control algorithms: slow-start, 279 congestion-avoidance, fast retransmit, and fast recovery. The 281 draft-ietf-rohc-tcp-taroc-04.txt 283 effective window of TCP is mainly controlled by the congestion 284 window and may change during the entire connection life. TAROC-C 285 designs a mechanism to track the dynamics of TCP congestion window, 286 and control the sliding window of W-LSB encoding by the estimated 287 congestion window. By combining the W-LSB encoding and TCP 288 congestion window tracking, TAROC can achieve better performance 289 over high bit-error-rate links. 291 Note that in one-way TCP traffic, only the information about 292 sequence number or acknowledgment number is available for tracking 293 TCP congestion window. TAROC-C does not require that all one-way TCP 294 traffics must cross the same compressor. The detail will be 295 described in the following sections. The topology assumption of 296 TAROC is the same as the one in VJHC. 298 The TAROC scheme achieves its compression gain by establishing state 299 information at both ends of the link, i.e., at the compressor and at 300 the decompressor. Header compression with TAROC can be characterized 301 as an interaction between two state machines, one compressor machine 302 and one decompressor machine, each instantiated once per context. 304 The Efficient Protocol Independent Compression (EPIC-LITE) scheme, 305 which had been discussed in detail in [19], is used to generate new 306 ROHC profiles. This scheme takes as its input a list of fields in the 307 protocol stack to be compressed, and for each field a choice of one 308 or more compression techniques. Using this input EPIC-LITE derives a 309 set of compressed header formats that can be used to quickly and 310 efficiently compress and decompress headers. 312 A TCP/IP profile is proposed to describe the behaviors of each field 313 in TCP/IP header. 315 In the rest of this draft, the control mechanism, TAROC-C, and the 316 detailed compressed packet header format will be discussed in detail 317 respectively. More specifically, the TCP congestion window tracking 318 algorithm, the state machines in the header compression framework, 319 and the logics of the compressor/decompressor, are described in 320 TAROC-C. 322 5. The framework of TAROC-C 324 5.1. TCP congestion window tracking 326 5.1.1. General principle of congestion window tracking 328 The general principle of congestion window tracking is as follows. 329 The compressor imitates the congestion control behavior of TCP upon 330 receiving each segment, in the meantime, estimates the congestion 331 window (cwnd) and the slow start threshold (ssthresh). Besides the 333 draft-ietf-rohc-tcp-taroc-04.txt 335 requirement of accuracy, there are also some other requirements for 336 the congestion window tracking algorithms: 338 - Simplex link. The tracking algorithm SHOULD always only take 339 Sequence Number or Acknowledgment Number of a one-way TCP 340 traffic into consideration. It SHOULD NOT use Sequence Number 341 and Acknowledgment Number of that traffic simultaneously. 343 - Misordering resilience. The tracking algorithm SHOULD work 344 well while receiving misordered segments. 346 - Multiple-links. The tracking algorithm SHOULD work well when 347 not all the one-way TCP traffics are crossing the same link. 349 - Slightly overestimation. If the tracking algorithm cannot 350 guarantee the accuracy of the estimated cwnd and ssthresh, it is 351 RECOMMANDED that it produces a slightly overestimated one. 353 The following sections will describe two congestion window tracking 354 algorithms, which use Sequence Number and Acknowledgment Number of a 355 one-way TCP traffic, respectively. 357 5.1.2. Congestion window tracking based on Sequence Number 359 This algorithm (Algorithm SEQ) contains 3 states: SLOW-START, 360 CONGESTION-AVOIDANCE, and FAST-RECOVERY, which are equivalent to the 361 states in TCP congestion control algorithms. It maintains 2 362 variables: cwnd and ssthresh. 364 +-------------+ 365 | | 366 ---------------->| CONGESTION- | 367 | | AVOIDANCE | 368 | ----| |<--- 369 +------------+ | +-------------+ | 370 | | | | 371 | SLOW-START | | | 372 | | | +-------------+ | 373 +------------+ | | | | 374 | |-->| FAST- |---- 375 | | RECOVERY | 376 ---------------->| | 377 +-------------+ 379 Initially, this algorithm starts in state SLOW-START with ssthresh 380 set to ISSTHRESH and cwnd set to IW. 382 Upon receiving a segment, if it is the first segment, which is not 383 necessary to be the SYN segment, the algorithm sets the current 384 maximum Sequence Number (CMAXSN) and the current minimum Sequence 385 Number (CMINSN) to this segment's sequence number; otherwise, the 386 algorithm takes a procedure according to the current state. 388 draft-ietf-rohc-tcp-taroc-04.txt 390 - SLOW-START 392 * If the new Sequence Number (NSN) is larger than CMAXSN, 393 increase cwnd by the distance between NSN and CMAXSN, and 394 update CMAXSN and CMINSN based on the following rules: 395 CMAXSN = NSN 396 if (CMAXSN - CMINSN) > cwnd) 397 CMINSN = cwnd - CMAXSN; 398 If the cwnd is larger than ssthresh, the algorithm transits to 399 CONGESTION-AVOIDANCE state; 401 * If the distance between NSN and CMAXSN is less than or equal 402 to 3*MSS, ignore it; 404 * If the distance is larger than 3*MSS, halve the cwnd and set 405 ssthresh to MAX(cwnd, 2*MSS). After that, the algorithm 406 transits into FAST-RECOVERY state. 408 - CONGESTION-AVOIDANCE 410 * If NSN is larger than CMAXSN, increase cwnd by ((NSN- 411 CMAXSN)*MSS)/cwnd and then update CMAXSN and CMINSN based on 412 the following rules: 413 CMAXSN = NSN 414 if (CMAXSN - CMINSN) > cwnd) 415 CMINSN = cwnd - CMAXSN; 417 * If the distance between NSN and CMAXSN is less than or equal 418 to 3*MSS, ignore it; 420 * If the distance is larger than 3*MSS, halve the cwnd and set 421 ssthresh to MAX(cwnd, 2*MSS). After that, the algorithm 422 transits into FAST-RECOVERY state. 424 - FAST-RECOVERY 426 * If NSN is larger than or equal to CMAXSN + cwnd, the algorithm 427 transits into CONGESTION-AVOIDANCE state; 429 * Otherwise, ignore it. 431 In this algorithm, MSS is denoted as the estimated maximum segment 432 size. The implementation can use the MTU of the link as an 433 approximation of this value. ISSHRESH and IW are the initial values 434 of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily 435 high. IW SHOULD be set to 4*MSS. 437 5.1.3. Congestion window tracking based on Acknowledgment Number 439 draft-ietf-rohc-tcp-taroc-04.txt 441 +-------------+ 442 | | 443 ---------------->| CONGESTION- | 444 | | AVOIDANCE | 445 | ----| |<--- 446 +------------+ | +-------------+ | 447 | | | | 448 | SLOW-START | | | 449 | | | +-------------+ | 450 +------------+ | | | | 451 | |-->| FAST- |---- 452 | | RECOVERY | 453 ---------------->| | 454 +-------------+ 456 This algorithm (Algorithm ACK) maintains 3 states: SLOW-START, 457 CONGESTION-AVOIDANCE and FAST-RECOVERY, which are equivalent to the 458 states in TCP congestion control algorithms. It also maintains 2 459 variables: cwnd and ssthresh. 461 Initially, this algorithm starts in state SLOW-START with ssthresh 462 set to ISSTHRESH and cwnd set to IW. 464 Upon receiving a segment, if it is the first segment, which is not 465 necessary to be the SYN segment, the algorithm sets the current 466 maximum Acknowledgment Number (CMAXACK) to this segment's 467 acknowledgment number; otherwise, the algorithm takes a procedure 468 according to the current state. 470 - SLOW-START 472 * If the new Acknowledgment Number (NEWACK) is larger than 473 CMAXACK, increase cwnd by the distance between NEWACK and 474 CMAXACK, set duplicate ack counter (NDUPACKS) to 0, and update 475 CMAXACK accordingly; If the cwnd is larger than ssthresh, the 476 algorithm transits to CONGESTION-AVOIDANCE state; 478 * If NEWACK is equal to CMAXACK, increase the NDUPACKS by 1. If 479 NDUPACKS is greater than 3, halve the cwnd and set ssthresh to 480 MAX(cwnd, 2*MSS). Consequently, the algorithm transits into 481 FAST-RECOVERY state; 483 * Otherwise, set NDUPACKS to 0. 485 - CONGESTION-AVOIDANCE 487 * If NEWACK is larger than CMAXACK, increase cwnd by ((NEWACK- 488 CMAXACK)*MSS)/cwnd, set NDUPACKS to 0 and update CMAXACK 489 accordingly; 491 * If NEWACK is equal to CMAXACK, increase NDUPACKS by 1. If 492 NDUPACKS is greater than 3, halve the cwnd and set ssthresh to 494 draft-ietf-rohc-tcp-taroc-04.txt 496 MAX(cwnd, 2*MSS). After that, the algorithm transits into 497 FAST-RECOVERY state; 499 * Otherwise, set NDUPACKS to 0. 501 - FAST-RECOVERY 503 * If NEWACK is larger than CMAXACK, set NDUPACKS to 0. 504 Consequently, the algorithm transits into CONGESTION-AVOID 505 state; 507 * Otherwise, ignore it. 509 In this algorithm, MSS is denoted as the estimated maximum segment 510 size. The implementation can use the MTU of the link as an 511 approximation of this value. ISSHRESH and IW are the initial values 512 of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily 513 high. IW SHOULD be set to 4*MSS. 515 5.1.4. Further discussion on congestion window tracking 517 In some cases, it is inevitable for the tracking algorithms to 518 overestimate the TCP congestion window. Also, it SHOULD be avoided 519 that the estimated congestion window gets significantly smaller that 520 the actual one. For all of these cases, TAROC simply applies two 521 boundaries on the estimated congestion window size. One of the two 522 boundaries is the MIN boundary, which is the minimum congestion 523 window size and whose value is determined according to the [18]; the 524 other boundary is the MAX boundary, which is the maximum congestion 525 window size. There are two possible approaches to setting this MAX 526 boundary. One is to select a commonly used maximum TCP socket buffer 527 size. The other one is to use the simple equation W=sqrt(8/3*l), 528 where W is the maximum window size and l is the typical packet loss 529 rate. 531 If ECN mechanism is deployed, according to [13] and [14], the TCP 532 sender will set the CWR (Congestion Window Reduced) flag in the TCP 533 header of the first new data packet sent after the window reduction, 534 and the TCP receiver will reset the ECN-Echo flag back to 0 after 535 receiving a packet with CWR flag set. Thus, the CWR flag and the 536 ECN-Echo flag's transition from 1 to 0 can be used as another 537 indication of congestion combined with other mechanisms mentioned in 538 the tracking algorithm. 540 5.2. Compressor/decompressor state management with TAROC-C 542 5.2.1. Compressor states 544 There are three compressor states in TAROC: Initialization and 545 Refresh (IR) state, First Order (FO), and Second Order (SO) states. 546 The compressor starts in the lowest compression state (IR) and 548 draft-ietf-rohc-tcp-taroc-04.txt 550 transits gradually to the higher compression state. The compressor 551 will always operate in the highest possible compression state, under 552 the constraint that the compressor is sufficiently confident that 553 the decompressor has the information necessary to decompress a 554 header, which is compressed according to the state. 556 +----------+ 557 | | 558 +----------+ | FO State | +----------+ 559 | | <--------> | | <--------> | | 560 | IR State | +----------+ | SO State | 561 | | <----------------------------------> | | 562 +----------+ +----------+ 564 5.2.1.1. Initialization and Refresh (IR) state 566 The purpose of IR state is to initialize or refresh the static parts 567 of the context at the decompressor. In this state, the compressor 568 sends full header periodically with an exponentially increasing 569 period, which is so-called compression slow-start [3]. The 570 compressor leaves the IR state only when it is confident that the 571 decompressor has correctly received the static information. 573 To compress short-lived TCP transfers more efficiently, the 574 compressor should speed up the initial process. The compressor 575 enters the IR state when it receives the packet with SYN bit set and 576 sends IR packet. When it receives the first data packet of the 577 transfer, it should transit to FO state because that means the 578 decompressor has received the packet with SYN bit set and 579 established the context successfully at its side. Using this 580 mechanism can significantly reduce the number of context initiation 581 headers. 583 5.2.1.2. First Order (FO) State 585 The purpose of FO state is to efficiently transmit the difference 586 between the two consecutive packets in the TCP stream. When 587 operating in this state, the compressor and the decompressor should 588 have the same context. Only compressed packet is transmitted from 589 the compressor to the decompressor in this state. The compressor 590 transits back to IR state only when it finds that the context of 591 decompressor may be inconsistent, or there are remarkable changes in 592 the TCP/IP header. 594 5.2.1.3. Second Order (SO) State 596 The purpose of SO state is to efficiently transmit the fixed-payload 597 data. The compressor enters this state when it is sufficiently 598 confident that the decompressor has got the constant payload size of 599 the data transferring. 601 draft-ietf-rohc-tcp-taroc-04.txt 603 The compressor leaves this state and transits to the FO state when 604 the current payload size no longer conforms to the constant payload. 605 The compressor transits back to IR state only when it finds that the 606 context of decompressor may be inconsistent, or there are remarkable 607 changes in the TCP/IP header. 609 5.2.2. Decompressor states 611 The decompressor starts in its lowest compression state, "No 612 Context" and gradually transits to higher state, "Full Context". The 613 decompressor state machine normally never leaves the "Full Context" 614 state once it has entered this state. 616 +--------------+ +--------------+ 617 | No Context | <---> | Full Context | 618 +--------------+ +--------------+ 620 5.3. Compressor logic in TAROC-C 622 In TAROC-C, the compressor will start in the IR state and perform 623 different logics in different states. The following sub-sections 624 will describe the logic for each compressor sate in detail. 626 5.3.1. IR state 628 The operations of compressor in IR state can be summarized as 629 follows: 631 a) Upon receiving a packet, the compressor sends IR or IR-DYN packet 632 on the following conditions: 1) if it is the turn to send full 633 header packet according to compression slow-start, i.e. after 634 sending F_PERIOD compressed packets; 2) if the packet to be sent 635 is a retransmission of the packet in VSW and it was sent as IR or 636 IR-DYN packet previously. Otherwise, the compressor compresses 637 the packet using W-LSB encoding. If the compressor enters the IR 638 state for the first time or the static part of the TCP flow has 639 changed, it will send IR packet. Otherwise, it will send IR-DYN 640 packet because the decompressor has known the static part. 642 b) The packet is added into VSW as a potential reference after it 643 has been sent out. The compressor then invokes the Algorithm SEQ 644 and Algorithm ACK to track the congestion windows of the two one- 645 way traffics with different directions in a TCP connection. 646 Suppose that the estimated congestion windows are cwnd_seq and 647 cwnd_ack, while the estimated slow start thresholds are 648 ssthresh_seq and ssthresh_ack, respectively. Let W(cwnd_seq, 649 ssthresh_seq, cwnd_ack, ssthresh_ack) = K*MAX(MAX(cwnd_seq, 650 2*ssthresh_seq), MAX(cwnd_ack, 2*ssthresh_ack)). If the size of 651 VSW is larger than W(cwnd_seq, ssthresh_seq, cwnd_ack, 652 ssthresh_ack), the VSW can be shrunk. K is an implementation 653 parameter that will be further discussed in Section 5.6. 655 draft-ietf-rohc-tcp-taroc-04.txt 657 c) After sending F_PERIOD compressed packets, F_PERIOD SHOULD be 658 doubled. If it gets larger than W(cwnd_seq, ssthresh_seq, 659 cwnd_ack, ssthresh_ack), the compressor transits to FO or SO 660 state. If the compressor finds that the payload size of 661 consecutive packets is a constant value and one of such packets 662 is removed from the VSW, which means the decompressor has known 663 the exact value of the constant size, it may transit to SO state. 664 Otherwise it will transit to the FO state. 666 5.3.2. FO state 668 The operations of the compressor in the FO state can be summarized 669 as follows: 671 a) Upon receiving a packet, if it falls behind the VSW, i.e. it is 672 older than all the packets in VSW; the compressor transits to IR 673 state. Otherwise, the compressor compresses it using W-LSB 674 encoding and sends it. 676 b) The packet is added into VSW as a potential reference after it has 677 been sent out. The compressor then invokes the Algorithm SEQ and 678 Algorithm ACK to track the congestion windows of the two one-way 679 traffics with different directions in a TCP connection. Suppose 680 that the estimated congestion windows are cwnd_seq and cwnd_ack, 681 while the estimated slow start thresholds are ssthresh_seq and 682 ssthresh_ack, respectively. Let W(cwnd_seq, ssthresh_seq, cwnd_ack, 683 ssthresh_ack) = K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack, 684 2*ssthresh_ack)). If the size of VSW is larger than W(cwnd_seq, 685 ssthresh_seq, cwnd_ack, ssthresh_ack), the VSW can be shrunk. K is 686 also an implementation parameter, which can be set to the same 687 value as in the IR state. 689 c) If the VSW contains only one packet, which means there is a long 690 jump in the packet sequence number or acknowledge number, the 691 compressor will transit to the IR state and re-initialize the 692 algorithm for tracking TCP congestion window. Here, a segment 693 causes a long jump when the distance between its sequence number 694 (or acknowledgment number) and CMAXSN (or CMAXACK) is larger than 695 the estimated congestion window size, i.e., 697 |sequence number (acknowledgement number) � CMAXSN (CMAXACK)| > 698 estimated congestion window size. 700 d) If the compressor finds that the payload size of consecutive 701 packets is a constant value and one of such packets has been 702 removed from the VSW, which means the decompressor has known the 703 exact value of the constant size, it may transit to the SO state. 705 e) If the static context of transfers changed, the compressor will 706 transit to the IR state and re-initialize the algorithms for 707 tracking TCP congestion window. 709 5.3.3. SO state 711 draft-ietf-rohc-tcp-taroc-04.txt 713 The operations of the compressor in the SO state can be summarized 714 as follows: 716 a) Upon receiving a packet, if it falls behind the VSW, i.e. it is 717 older than all the packets in VSW; the compressor transits to IR 718 state. Otherwise, the compressor compresses it using fixed-payload 719 encoding and sends it. 721 b) The packet is added into VSW as a potential reference after it has 722 been sent out. The compressor then invokes the Algorithm SEQ and 723 Algorithm ACK to track the congestion windows of the two one-way 724 traffics with different directions in a TCP connection. Suppose 725 that the estimated congestion windows are cwnd_seq and cwnd_ack, 726 while the estimated slow start thresholds are ssthresh_seq and 727 ssthresh_ack, respectively. Let W(cwnd_seq, ssthresh_seq, cwnd_ack, 728 ssthresh_ack) = K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack, 729 2*ssthresh_ack)). If the size of VSW is larger than W(cwnd_seq, 730 ssthresh_seq, cwnd_ack, ssthresh_ack), the VSW can be shrunk. K is 731 an implementation parameter, which can be set to the same value as 732 in the IR state. 734 c) If the VSW contains only one packet, which means there is a long 735 jump in the packet sequence number or acknowledge number, the 736 compressor will transit to the IR state and re-initialize the 737 algorithms for tracking TCP congestion window. 739 d) If the payload size of the packets in VSW doesn't keep constant, 740 the compressor transits to the FO state. 742 e) If the static context of transfers changed, the compressor will 743 transit to the IR state and re-initialize the algorithms for 744 tracking TCP congestion window. 746 5.4. Decompressor logic in TAROC-C 748 The logic of the decompressor is simpler compared to the compressor. 750 5.4.1. No Context State 752 The decompressor starts in this state. Upon receiving an IR or IR- 753 DYN packet, the decompressor should verify the correctness of its 754 header by TCP checksum. If the verification succeeds, the 755 decompressor will update the context and use this packet as the 756 reference packet. After that, the decompressor will pass it to the 757 system's network layer and transit to Full Context State. Conformed 758 to ROHC framework [10], only IR or IR-DYN packets may be 759 decompressed in No Context state. 761 5.4.2. Full Context State 763 draft-ietf-rohc-tcp-taroc-04.txt 765 The operations of decompressor in Full Context state can be 766 summarized as follows: 768 a) Upon receiving an IR or IR-DYN packet, the decompressor should 769 verify the correctness of its header by TCP checksum. If the 770 verification succeeds, the decompressor will update the context and 771 use this packet as the reference packet. Consequently, the 772 decompressor will convert the packet into the original packet and 773 pass it to the network layer of the system. 775 b) Upon receiving the other type of packet, the decompressor will 776 decompress it. After that, the decompressor MUST verify the 777 correctness of the decompressed packet by the TCP checksum. If the 778 verification succeeds, the decompressor passes it to the system's 779 network layer. Then the decompressor will use it as the reference 780 value if this packet is not older than the current reference packet. 782 c) If consequent N packets fail to be decompressed, the decompressor 783 should transit downwards to No Context State. N is an implementation 784 parameter that will be further discussed in Section 5.6. 786 5.5. Modes of operation 788 There are three modes in ROHC framework, called Unidirectional, Bi- 789 directional Optimistic, and Bi-directional Reliable mode, 790 respectively. The mode transitions are conformed to ROHC framework. 791 However, the operations of each mode are different. 793 5.5.1. Unidirectional mode -- U-mode 795 When in U-mode, packets are sent in one direction only: from 796 compressor to decompressor. Therefore, feedbacks from decompressor 797 to the compressor are unavailable under this mode. 799 In the U-mode, the compressor and decompressor logic is the same as 800 the discussion in section 5.3 and 5.4. 802 5.5.2. Bi-directional Optimistic mode -- O-mode 804 When in O-mode, a feedback channel is used to send error recovery 805 requests and (optionally) acknowledgments of significant context 806 updates from the decompressor to the compressor. In this mode, the 807 VSW will be shrunk more efficiently. 809 5.5.2.1. Compressor states and logic (O-mode) 811 Following rules should be combined with the action defined in 812 section 5.3. 814 In the IR state, the compressor can transit to the FO or SO state 815 once it receives a valid ACK(O) for an IR packet sent (an ACK(O) can 816 only be valid if it refers to a packet sent earlier). If the packet 818 draft-ietf-rohc-tcp-taroc-04.txt 820 referred by the feedback is in the VSW, the compressor will remove 821 the packets older than the referred packet from the VSW window. 822 Because ACK(O) means that the packet referred by ACK(O) has been the 823 reference of the decompressor, the compressor doesn't need to keep 824 older packets. 826 If the compressor is in the FO or SO state, it will remove the 827 packets older than the referred packet from the VSW window. 829 Upon receiving an NACK(O), the compressor transits back to IR state. 831 5.5.2.2. Decompressor states and logic (O-mode) 833 The decompression states and the state transition logic are the same 834 as in the Unidirectional case (see section 5.5.1.). What differs is 835 the feedback logic. 837 Below, rules are defined stating which feedback to use when. 839 When an IR packet passes the verification, send an ACK(O). When an 840 IR-DYN packet or other packet is correctly decompressed, optionally 841 send an ACK(O). When any packet fails the verification, send an 842 NACK(O). 844 5.5.3. Bi-directional Reliable mode -- R-mode 846 The R-mode are a more intensive usage of the feedback channel and a 847 stricter logic at both the compressor and the decompressor that 848 prevents loss of context synchronization between the compressor and 849 decompressor except for very high residual bit error rates. Feedback 850 is sent to acknowledge all context updates. In this mode, the VSW 851 will be shrunk with the highest efficiency. 853 5.5.3.1. Compressor states and logic (R-mode) 855 Following rules should be reparation to the action defined in 856 section 5.3. 858 In IR state, the compressor should transit to the FO or SO state 859 only when it receives a valid ACK(R) for an IR or IR-DYN packet sent 860 (an ACK(R) can only be valid if it refers to an packet sent earlier). 861 If the packet referred by the feedback is in the VSW, the compressor 862 will remove the packets older than the referred packet from the VSW 863 window. Because ACK(R) means that the packet referred by ACK(R) has 864 been the reference of the decompressor; the compressor doesn't need 865 to keep older packets. 867 If the compressor is in the FO or SO state, when it receives a valid 868 ACK(R), it will remove the packets older than the referred packet 869 from the VSW window. In this mode, the compressor need not use 870 window tracking, because feedback can shrink VSW efficiently and 871 robustly. 873 draft-ietf-rohc-tcp-taroc-04.txt 875 Upon receiving an NACK(O), the compressor transits back to IR state. 877 5.5.3.2. Decompressor states and logic (R-mode) 879 Below, rules are defined stating which feedback to use when. 881 . When a packet is correctly decompressed and updates the context, 882 send an ACK(R). 884 . When any packet fails the verification, send a NACK(R). 886 The frequency of updating context will be discussed in section 5.6. 888 5.6. Implementation issues 890 5.6.1. Determine the value K 892 As mentioned above, the VSW SHOULD be shrunk when its size gets 893 larger than K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack, 894 2*ssthresh_ack)). Since the Fast Recovery algorithm was introduced 895 in TCP, several TCP variants had been proposed, which are different 896 only in the behaviors of Fast Recovery. Some of them need several 897 RTTs to be recovered from multiple losses in a window. Ideally, they 898 may send L*W/2 packets in this stage, where L is the number of lost 899 packets and W is the size of the congestion window where error 900 occurs. Some recent work [15] on improving TCP performance allows to 901 transmit packets even when receiving duplicate acknowledgments. Due 902 to the above concerns, it'd better keep K large enough so as to 903 prevent shrinking VSW without enough confidence that corresponding 904 packets had been successfully received. 906 Considering the bandwidth-limited environments and the limited 907 receiver buffer, a practical range of K is around 1~2. From the 908 simulation results, K=1 is good enough for most cases. 910 5.6.2. Determine the value N 912 We should distinguish out of synchronization from the packet errors 913 cause by the link. So considering the error condition of the link, N 914 should be higher than the packet burst error length, a practical 915 range of N is around 8~10. 917 5.6.3. Determine the frequency of updating context 919 The choice of the frequency of updating context, ACK(R), is a 920 balance between the efficiency and robustness, i.e. sending ACK(R) 921 more frequently improves the compression robustness but adds more 922 system overhead, and the vice versa. From a practical view, the 923 ACK(R) SHOULD be sent for every 4~8 successfully decompressed 924 packets. 926 draft-ietf-rohc-tcp-taroc-04.txt 928 6. Coding scheme and compressed packet header format 930 Following the requirement of TCP/IP header compression [15], TAROC 931 should fit into the ROHC framework. Thus, TAROC will conform to the 932 general format and the reserved packet types defined in [10]. A 933 compressed header format had been discussed in [20] in our past work. 934 As stated in [19], EPIC-LITE is a generic encoding scheme which can 935 automatically generate efficient packet format for the compressed 936 header. In this draft, TAROC adopts EPIC-LITE as the coding 937 framework. To use the EPIC-LITE coding framework, a suitable TCP/IP 938 profile is also needed as the input. In the following of this 939 section, we will discuss that in detail. 941 6.1. Window-based LSB encoding and fixed-payload encoding 943 As stated above, the change patterns of several TCP fields (for 944 example, Sequence Number, Acknowledgement Number, Window, etc.) are 945 completely different from the ones of RTP, and are very hard to 946 predict. Thus, Window-based LSB encoding, which does not assume the 947 linear changing pattern of the target header fields, is used in 948 TAROC to encode those TCP fields both efficiently and robustly. 950 The Window-based LSB encoding (W-LSB encoding) used in TAROC is a 951 slightly modified version of [10]. The major modifications can be 952 summarized as follows: 954 - For reference selection, the decompressor always choose the 955 one which is the last received non-retransmission value or 956 uncompressed value that had passed the TCP checksum successfully. 958 - After sending a value v (compressed or uncompressed), the 959 compressor always adds v into the VSW since each TCP segment is 960 protected by the TCP checksum. 962 The W-LSB encoding will be applied to several fields, such as IP-ID, 963 Sequence Number, Acknowledgment Number, Window fields, TCP Timestamp 964 option, etc. 966 For some applications, such as bulk data transferring, etc., the 967 payload size of each packet is usually a constant value, e.g. 1460 968 bytes. In such a case, the sequence number and acknowledgment number 969 can be represented as the following equation: 971 SEQ (or ACK) = m * MTU + n. 973 If all the packets in VSW have the same 'n', only 'm' need be 974 transmitted to the decompressor. The decompressor can obtain the 975 sequence number or acknowledgment number after correctly decoding 976 'm', and use them as the reference values. This encoding method is 977 called fixed-payload encoding. 979 6.2. The framework of EPIC-LITE scheme 981 draft-ietf-rohc-tcp-taroc-04.txt 983 The detailed information about EPIC-LITE, include the structure of 984 the EPIC-LITE compressed headers, the overview of the input language 985 for EPIC-LITE, the packet types available to EPIC-LITE, the library 986 of EPIC-LITE encoding methods, and how to create a new ROHC profile, 987 are described in [19]. 989 6.3. ROHC Profile for compression of TCP/IP 991 This session describes a ROHC profile for the compression of TCP/IP. 993 Note that the probabilities listed for each encoding method are 994 initial estimates only. These need to be refined with more accurate 995 values from genuine TCP/IP streams. 997 The profile for TCP/IP compression is given below: 999 only uses the following toolbox methods: 1000 - STATIC-KNOWN 1001 - STATIC-UNKNOWN 1002 - STATIC 1003 - IRREGULAR 1004 - LSB 1005 - VALUE 1006 - MSN-IRREGULAR 1007 - MSN-LSB 1008 - C 1010 profile_identifier 0xFFFF 1011 max_formats 200 1012 max_sets 1 1013 bit_alignment 8 1014 npatterns 224 1015 CO_packet TCP-IP 1017 TCP-IP = IPv4-header 1018 TCP-header 1019 msn 1021 msn = C(MSN-LSB(4,-1,90%)) | C(MSN-LSB(7,-1,9%)) | 1022 MSN-IRREGULAR(16,1%) 1024 IPv4-header = version 1025 header_len 1026 tos 1027 ecn 1028 length 1029 ip-id 1030 rf_flag 1031 df_flag 1033 draft-ietf-rohc-tcp-taroc-04.txt 1035 mf_flag 1036 offset 1037 ttl 1038 protocol 1039 ip_chksum 1040 src_address 1041 dst_address 1043 version = STATIC-KNOWN(4,4) 1045 header_len = STATIC-KNOWN(4,5) 1047 tos = C(STATIC(99%)) | IRREGULAR(6,1%) 1049 ecn = IRREGULAR(2,100%) 1051 length = IRREGULAR(16) 1053 ip-id = C(LSB(4,-1,90%)) | C(LSB(6,-1,8%)) | 1054 C(LSB(8,-1,1%)) | IRREGULAR(16,1%) 1056 rf_flag = VALUE(1,0,100%) 1058 df_flag = IRREGULAR(1,100%) 1060 mf_flag = VALUE(1,0,99%) | VALUE(1,1,1%) 1062 offset = C(STATIC(99%)) | IRREGULAR(13,1%) 1064 ttl = C(STATIC(99%)) | IRREGULAR(8,1%) 1066 protocol = STATIC-KNOWN(8,6) 1068 ip_chksum = IRREGULAR(16,100%) 1070 src_address = STATIC-UNKNOWN(32) 1072 dst_address = STATIC-UNKNOWN(32) 1074 TCP-header = source_port 1075 dest_port 1076 seqno 1077 ackno 1078 data_offset 1079 flags 1080 window 1081 tcp_chksum 1082 urg_ptr 1084 source_port = STATIC-UNKNOWN(16) 1086 dest_port = STATIC-UNKNOWN(16) 1088 draft-ietf-rohc-tcp-taroc-04.txt 1090 seqno = C(LSB(8,63,80%)) | C(LSB(14,127,10%)) | 1091 C(LSB(20,1023,5%)) | IRREGULAR(32,5%) 1093 ackno = C(LSB(8,-1,80%)) | C(LSB(14,-1,10%)) | 1094 C(LSB(20,-1,5%)) | IRREGULAR(32,5%) 1096 data_offset = IRREGULAR(4,100%) 1098 window = C(STATIC(80%)) | C(LSB(12,63,10%)) | 1099 IRREGULAR(16,10%) 1101 tcp_chksum = IRREGULAR(16,100%) 1103 urg_ptr = C(STATIC(99%)) | IRREGULAR(16,1%) 1105 flags = reserved 1106 cwr 1107 ece 1108 urg 1109 ack 1110 psh 1111 rst 1112 syn 1113 fin 1115 reserved = C(STATIC(90%)) | IRREGULAR(4,10%) 1117 cwr = VALUE(1,0,80%) | VALUE(1,1,20%) 1119 ece = VALUE(1,0,80%) | VALUE(1,1,20%) 1121 urg = VALUE(1,0,99%) | VALUE(1,1,1%) 1123 ack = VALUE(1,1,99%) | VALUE(1,0,1%) 1125 psh = IRREGULAR(1,100%) 1127 rst = VALUE(1,0,99%) | VALUE(1,1,1%) 1129 syn = VALUE(1,0,99%) | VALUE(1,1,1%) 1131 fin = VALUE(1,0,95%) | VALUE(1,1,5%) 1133 7. Conclusions 1135 Based on the requirements proposed in [16] and [17], a robust header 1136 compression scheme should be of transparency, ubiquity, and 1137 efficiency. It must be able to support both IPv4 and Ipv6 packet and 1138 tolerate error propagation. Different types of link delay and the 1140 draft-ietf-rohc-tcp-taroc-04.txt 1142 misordering of packets should be addressed. In addition, multiple 1143 links and unidirectional link should be supported in the proposed 1144 header compression scheme. Particularly for TCP/IP, the header 1145 compression scheme should compress TCP SACK and Timestamp options. 1147 From the above analysis, it can be seen that all these requirements 1148 can be satisfied in our proposed TAROC. 1150 Considering the behavior of TCP protocol itself, even the packets 1151 misordering occurs between the compressor and the decompressor, a 1152 good performance can still be achieved in TAROC. 1154 Note that in our scheme, we need to select a packet with correct 1155 checksum of the whole packet as a reference. In this way, it does 1156 not require link layer to treat the header and payload of the packet 1157 separately. 1159 Simulations results (Appendix A) demonstrate the effectiveness of 1160 control mechanism TAROC-C and corresponding header compression 1161 scheme, TAROC of TAROC. 1163 8. Acknowledgments 1165 When designing this protocol, earlier header compression ideas 1166 described in [2], [3] and [10] have been import sources of knowledge. 1168 This draft also benefited from discussion on the ROHC mailing list 1169 about the TAROC-C mechanism. 1171 9. Security considerations 1173 Security issues are not considered in this memo. 1175 draft-ietf-rohc-tcp-taroc-04.txt 1177 10. Authors' addresses 1179 HongBin Liao Tel: +86 10 62617711-3156 1180 Email: i-hbliao@microsoft.com 1182 Qian Zhang Tel: +86 10 62617711-3135 1183 Email: qianz@microsoft.com 1185 Wenwu Zhu Tel: +86 10 62617711-5405 1186 Email: wwzhu@microsoft.com 1188 Ya-Qin Zhang Tel: +86 10 62617711 1189 Email: yzhang@microsoft.com 1191 Microsoft Research Asia 1192 Beijing Sigma Center 1193 No.49, Zhichun Road, Haidian District 1194 Beijing 100080, P.R.C. 1196 Richard Price Tel: +44 1794 833681 1197 Email: richard.price@roke.co.uk 1199 Robert Hancock Tel: +44 1794 833601 1200 Email: robert.hancock@roke.co.uk 1202 Stephen McCann Tel: +44 1794 833341 1203 Email: stephen.mccann@roke.co.uk 1205 Mark A West Tel: +44 1794 833311 1206 Email: mark.a.west@roke.co.uk 1208 Abigail Surtees Tel: +44 1794 833131 1209 Email: abigail.surtees@roke.co.uk 1211 Paul Ollis Tel: +44 1794 833168 1212 Email: paul.ollis@roke.co.uk 1214 Roke Manor Research Ltd 1215 Romsey, Hants, SO51 0ZN 1216 United Kingdom 1218 11. References 1220 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, 1221 RFC 2026, October 1996. 1223 2 V. Jacobson, "Compressing TCP/IP headers for low-speed serial 1224 links", RFC 1144, February 1990. 1226 3 M. Degermark, B. Nordgren, and S. Pink, "IP Header Compression", 1227 RFC 2507, February 1999. 1229 draft-ietf-rohc-tcp-taroc-04.txt 1231 4 M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP Selective 1232 Acknowledgment Options", RFC 2018, October 1996. 1234 5 S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky, "An Extension 1235 to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, 1236 July 2000. 1238 6 V. Jacobson, R. Braden, and D. Borman, "TCP Extensions for High 1239 Performance", RFC 1323, May 1992. 1241 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1242 Levels", BCP 14, RFC 2119, March 1997. 1244 8 V. Jacobson, "Fast Retransmit", Message to the end2end-interest 1245 mailing list, April 1990. 1247 9 M. Degermark, M. Engan, B. Nordgren, and Stephen Pink, " Low-loss 1248 TCP/IP header compression for wireless networks", In the 1249 Proceedings of MobiCom, 1996. 1251 10 Bormann (ed.), et al., "RObust Header Compression (ROHC)", RFC 1252 3095, July 2001. 1254 11 V. Jacobson, "Congestion avoidance and control", In ACM SIGCOMM 1255 '88, 1988. 1257 12 M. Allman, V. Paxson, and W. R. Stevens, "TCP Congestion Control", 1258 RFC 2581, April 1999. 1260 13 K. Ramakrishnan, S. Floyd, "A Proposal to add Explicit Congestion 1261 Notification (ECN) to IP", RFC 2481, January 1999. 1263 14 K. K. RamaKrishnan, Sally Floyd, D. Black, "The Addition of 1264 Explicit Congestion Notification (ECN) to IP", Internet Draft 1265 (work in progress), June, 2001. 1267 15 L-E. Jonsson, "Requirements for ROHC IP/TCP header compression", 1268 Internet Draft (work in progress), June 20, 2001. 1270 16 M. Allman, H. Balakrishnan, and S. Floyd, "Enhancing TCP's Loss 1271 Recovery Using Limited Transmit", Internet Draft (work in 1272 progress), August 2000. 1274 17 M. Degermark, "Requirements for robust IP/UDP/RTP header 1275 compression", RFC 3096, July 2001. 1277 18 M. Allman, S. Floyd, and C. Partridge, "Increasing TCP's Initial 1278 Window", Internet Draft (work in progress), May 2001. 1281 19 Richard Price et al, "Framework for EPIC-LITE", , Internet Draft (work in progress), Oct. 2001. 1284 draft-ietf-rohc-tcp-taroc-04.txt 1286 20 H. Liao, Q. Zhang, W. Zhu, and Y.-Q. Zhang, �TCP-Aware RObust 1287 Header Compression (TAROC)�, Internet Draft (work in progress), 1288 Nov. 2001. 1290 12. Intellectual property considerations 1292 The TCP-Aware Robust header Compression Control mechanism, TAROC-C, 1293 and the Efficient Protocol Independent Compression scheme, EPIC-LITE, 1294 do not have an IPR statement. 1296 Appendix A - Simulation results 1298 To study the performance of various TCP/IP header compression 1299 schemes, we have simulated VJHC, IPHC and TAROC schemes on NS-2 1300 network simulator. The simulation result in gained by the TAROC 1301 coding scheme discussed in [20]. 1303 A.1. Simulation topology 1305 +------------+ +--------+ +-------------+ 1306 | |------------>| |------------>| | 1307 | Fixed Host | 8Mb 100ms | Router |Wireless link| Mobile Host | 1308 | |<------------| |<------------| | 1309 +------------+ +--------+ +-------------+ 1311 In this scenario, a fixed host is connected to the router with a WAN 1312 link (8Mb, 100ms). The queue size on the router is 6. The 1313 communication channel between the mobile host and the router 1314 simulates the wireless link, which has a wide range of bandwidth 1315 from 384kb to 9.6kb and a delay of 100ms. The bit error rate (BER) 1316 on this wireless link is from 1e-7 to 1e-3. TCP traffic is conveyed 1317 from the fixed host to the mobile host. 1319 It is known that, in wireless link under a high bit-error-rate 1320 situation, a smaller MTU is better in terms of the increasing chance 1321 of successful transmission. So different MTUs are selected under 1322 different BER conditions in our simulation. 1324 A.2. Tested header compression schemes 1325 Five header compression schemes in our simulation: 1327 NONE This scheme refers to the situation when no header 1328 compression is employed on the wireless link. 1330 VJHC This scheme employs RFC1144 on the wireless link. It 1331 assumes that the compressed header size is 4. 1333 IPHC This scheme employs RFC2507 on the wireless link, but 1334 without TWICE algorithm. The characteristics of the 1335 feedback channel are the same as the forward wireless 1336 link. It assumes that the compressed header size is 5. 1338 draft-ietf-rohc-tcp-taroc-04.txt 1340 TAROC It refers to the scheme proposed in this Internet Draft. 1341 The compressed header size is determined by the scheme 1342 described in this draft. 1344 IDEAL This scheme simulates the situation where header 1345 compression does not introduce additional errors. It 1346 assumes that the compressed header size is 4, the same one 1347 as in the VJHC. 1349 A.3. Simulations and results 1351 Based upon these configurations, enormous simulations have been 1352 tested. The followings are the results of several TCP variants, 1353 Tahoe, Reno and Sack on the wireless link with wide range of 1354 bandwidth, BER and MTU. 1356 Wireless link characteristics: 1358 * Bandwidth: 384kb, 114kb, 64kb, 9.6kb 1360 * Delay: 100ms 1362 * BER: 1e-8, 3e-8, 1e-7, 3e-7, 1e-6, 3e-6, 1e-5, 3e-5, 1e-4, 3e-4 1364 TCP Variants: Tahoe, Reno, Sack 1366 Header compression schemes: NONE, VJHC, IPHC, TAROC, IDEAL 1368 The following lists some of the results: 384kb for Tahoe, 114kb for 1369 Sack, 64kb for Reno, and 9.6kb for Sack. 1371 A.3.1. 384kb 1373 Tahoe 1374 +----+------+-----------+-----+------+------+-----+-----+ 1375 |BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL| 1376 | |(Byte)| | | | | | | 1377 +----+------+-----------+-----+------+------+-----+-----+ 1378 |1e-8|576 |Throughput |25470| 25457| 25179|25587|25603| 1379 | | | (Byte/s) | | | | | | 1380 | | |-----------+-----+------+------+-----+-----+ 1381 | | |Improvement| 0 |-0.05 |-1.14 |0.46 |0.52 | 1382 | | | (%s) | | | | | | 1383 +----+------+-----------+-----+------+------+-----+-----+ 1384 |3e-8|576 |Throughput |25770| 25764| 25696|25819|25839| 1385 | | | (Byte/s) | | | | | | 1386 | | |-----------+-----+------+------+-----+-----+ 1387 | | |Improvement| 0 | -0.02| -0.29| 0.19|0.27 | 1388 | | | (%s) | | | | | | 1389 +----+------+-----------+-----+------+------+-----+-----+ 1391 draft-ietf-rohc-tcp-taroc-04.txt 1393 +----+------+-----------+-----+------+------+-----+-----+ 1394 |BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL| 1395 | |(Byte)| | | | | | | 1396 +----+------+-----------+-----+------+------+-----+-----+ 1397 |1e-7|576 |Throughput |24564| 24185| 23550|24687|24717| 1398 | | | (Byte/s) | | | | | | 1399 | | |-----------+-----+------+------+-----+-----+ 1400 | | |Improvement| 0 | -1.54| -4.12| 0.50| 0.62| 1401 | | | (%s) | | | | | | 1402 +----+------+-----------+-----+------+------+-----+-----+ 1403 |3e-7|576 |Throughput |22256| 21240| 20216|22365|22407| 1404 | | | (Byte/s) | | | | | | 1405 | | |-----------+-----+------+------+-----+-----+ 1406 | | |Improvement| 0 | -4.56| -9.17| 0.50| 0.68| 1407 | | | (%s) | | | | | | 1408 +----+------+-----------+-----+------+------+-----+-----+ 1409 |1e-6|576 |Throughput |16703| 14638| 13840|16930|17027| 1410 | | | (Byte/s) | | | | | | 1411 | | |-----------+-----+------+------+-----+-----+ 1412 | | |Improvement| 0 |-12.36|-17.14| 1.36| 1.94| 1413 | | | (%s) | | | | | | 1414 +----+------+-----------+-----+------+------+-----+-----+ 1415 |3e-6|576 |Throughput | 9895| 7987 | 8086 |10255|10266| 1416 | | | (Byte/s) | | | | | | 1417 | | |-----------+-----+------+------+-----+-----+ 1418 | | |Improvement| 0 |-19.04|-18.03| 3.95| 4.06| 1419 | | | (%s) | | | | | | 1420 +----+------+-----------+-----+------+------+-----+-----+ 1421 |1e-5|296 |Throughput | 3531| 2803 | 2950 | 3825| 3826| 1422 | | | (Byte/s) | | | | | | 1423 | | |-----------+-----+------+------+-----+-----+ 1424 | | |Improvement| 0 |-20.62|-16.45| 8.33| 8.35| 1425 | | | (%s) | | | | | | 1426 +----+------+-----------+-----+------+------+-----+-----+ 1427 |3e-5|296 |Throughput | 1731| 1181 | 1317 | 1900| 1901| 1428 | | | (Byte/s) | | | | | | 1429 | | |-----------+-----+------+------+-----+-----+ 1430 | | |Improvement| 0 |-31.77|-23.92| 9.76| 9.82| 1431 | | | (%s) | | | | | | 1432 +----+------+-----------+-----+------+------+-----+-----+ 1433 |1e-4|168 |Throughput | 504 | 342 | 366| 635| 636| 1434 | | | (Byte/s) | | | | | | 1435 | | |-----------+-----+------+------+-----+-----+ 1436 | | |Improvement| 0 |-32.14|-27.38|25.99|26.19| 1437 | | | (%s) | | | | | | 1438 +----+------+-----------+-----+------+------+-----+-----+ 1439 |3e-4| 96 |Throughput | 97 | 80 | 91 | 202| 203| 1440 | | | (Byte/s) | | | | | | 1441 | | |-----------+-----+------+------+-----+-----+ 1442 | | |Improvement| 0 |-17.53| -6.19|108.2|109.3| 1443 | | | (%s) | | | | | | 1444 +----+------+-----------+-----+------+------+-----+-----+ 1446 draft-ietf-rohc-tcp-taroc-04.txt 1448 A.3.2. 114kb 1450 Sack 1451 +----+------+-----------+-----+------+------+-----+-----+ 1452 |BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL| 1453 | |(Byte)| | | | | | | 1454 +----+------+-----------+-----+------+------+-----+-----+ 1455 |1e-8|576 |Throughput |12105| 12636| 12605|12660|12662| 1456 | | | (Byte/s) | | | | | | 1457 | | |-----------+-----+------+------+-----+-----+ 1458 | | |Improvement| 0 | 4.39| 4.13 | 4.58| 4.60| 1459 | | | (%s) | | | | | | 1460 +----+------+-----------+-----+------+------+-----+-----+ 1461 |3e-8|576 |Throughput |12083| 12565|12474 |12642|12643| 1462 | | | (Byte/s) | | | | | | 1463 | | |-----------+-----+------+------+-----+-----+ 1464 | | |Improvement| 0 | 3.99 | 3.24 | 4.63| 4.63| 1465 | | | (%s) | | | | | | 1466 +----+------+-----------+-----+------+------+-----+-----+ 1467 |1e-7|576 |Throughput |12030| 12329| 12165|12582|12587| 1468 | | | (Byte/s) | | | | | | 1469 | | |-----------+-----+------+------+-----+-----+ 1470 | | |Improvement| 0 | 2.49 | 1.12 | 4.59| 4.63| 1471 | | | (%s) | | | | | | 1472 +----+------+-----------+-----+------+------+-----+-----+ 1473 |3e-7|576 |Throughput |11856| 11687|11326 |12392|12411| 1474 | | | (Byte/s) | | | | | | 1475 | | |-----------+-----+------+------+-----+-----+ 1476 | | |Improvement| 0 | -1.43| -4.47| 4.52| 4.68| 1477 | | | (%s) | | | | | | 1478 +----+------+-----------+-----+------+------+-----+-----+ 1479 |1e-6|576 |Throughput |11213| 9871 | 9177 |11737|11740| 1480 | | | (Byte/s) | | | | | | 1481 | | |-----------+-----+------+------+-----+-----+ 1482 | | |Improvement| 0 |-11.97|-18.16| 4.63| 4.70| 1483 | | | (%s) | | | | | | 1484 +----+------+-----------+-----+------+------+-----+-----+ 1485 |3e-6|576 |Throughput | 9258| 6578 | 6206 | 9719| 9784| 1486 | | | (Byte/s) | | | | | | 1487 | | |-----------+-----+------+------+-----+-----+ 1488 | | |Improvement| 0 |-28.95|-32.97| 4.98| 5.68| 1489 | | | (%s) | | | | | | 1490 +----+------+-----------+-----+------+------+-----+-----+ 1491 |1e-5|296 |Throughput | 3883| 2622 | 2587 | 4236| 4239| 1492 | | | (Byte/s) | | | | | | 1493 | | |-----------+-----+------+------+-----+-----+ 1494 | | |Improvement| 0 |-32.47|-33.38| 9.09| 9.17| 1495 | | | (%s) | | | | | | 1496 +----+------+-----------+-----+------+------+-----+-----+ 1498 draft-ietf-rohc-tcp-taroc-04.txt 1500 +----+------+-----------+-----+------+------+-----+-----+ 1501 |BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL| 1502 | |(Byte)| | | | | | | 1503 +----+------+-----------+-----+------+------+-----+-----+ 1504 |3e-5|296 |Throughput | 1786| 1111 | 1214 | 2000| 2012| 1505 | | | (Byte/s) | | | | | | 1506 | | |-----------+-----+------+------+-----+-----+ 1507 | | |Improvement| 0 |-37.79|-32.03|11.98|12.65| 1508 | | | (%s) | | | | | | 1509 +----+------+-----------+-----+------+------+-----+-----+ 1510 |1e-4|168 |Throughput | 489 | 325 | 361 | 640| 652| 1511 | | | (Byte/s) | | | | | | 1512 | | |-----------+-----+------+------+-----+-----+ 1513 | | |Improvement| 0 |-33.54|-26.18|30.88|33.33| 1514 | | | (%s) | | | | | | 1515 +----+------+-----------+-----+------+------+-----+-----+ 1516 |3e-4| 96 |Throughput | 92 | 81 | 88 | 202 | 203 | 1517 | | | (Byte/s) | | | | | | 1518 | | |-----------+-----+------+------+-----+-----+ 1519 | | |Improvement| 0 |-11.96| -4.35|119.6|120.7| 1520 | | | (%s) | | | | | | 1521 +----+------+-----------+-----+------+------+-----+-----+ 1523 A.3.3. 64kb 1525 Reno 1526 +----+------+-----------+----+------+------+-----+-----+ 1527 |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| 1528 | |(Byte)| | | | | | | 1529 +----+------+-----------+----+------+------+-----+-----+ 1530 |1e-8|576 |Throughput |7317| 7743 | 7698 | 7763| 7764| 1531 | | | (Byte/s) | | | | | | 1532 | | |-----------+----+------+------+-----+-----+ 1533 | | |Improvement| 0| 5.82 | 5.21 | 6.10| 6.11| 1534 | | | (%s) | | | | | | 1535 +----+------+-----------+----+------+------+-----+-----+ 1536 |3e-8|576 |Throughput |7312| 7716 | 7672 | 7756| 7757| 1537 | | | (Byte/s) | | | | | | 1538 | | |-----------+----+------+------+-----+-----+ 1539 | | |Improvement| 0| 5.53| 4.92 | 6.07| 6.09| 1540 | | | (%s) | | | | | | 1541 +----+------+-----------+----+------+------+-----+-----+ 1542 |1e-7|576 |Throughput |7288| 7615 | 7556 | 7727| 7728| 1543 | | | (Byte/s) | | | | | | 1544 | | |-----------+----+------+------+-----+-----+ 1545 | | |Improvement| 0| 4.49| 3.68 | 6.02| 6.04| 1546 | | | (%s) | | | | | | 1547 +----+------+-----------+----+------+------+-----+-----+ 1549 draft-ietf-rohc-tcp-taroc-04.txt 1551 +----+------+-----------+----+------+------+-----+-----+ 1552 |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| 1553 | |(Byte)| | | | | | | 1554 +----+------+-----------+----+------+------+-----+-----+ 1555 |3e-7|576 |Throughput |7213| 7351 | 7222 | 7648| 7649| 1556 | | | (Byte/s) | | | | | | 1557 | | |-----------+----+------+------+-----+-----+ 1558 | | |Improvement| 0| 1.91| 0.12 | 6.03| 6.04| 1559 | | | (%s) | | | | | | 1560 +----+------+-----------+----+------+------+-----+-----+ 1561 |1e-6|576 |Throughput |6966| 6612 | 6286 | 7387| 7398| 1562 | | | (Byte/s) | | | | | | 1563 | | |-----------+----+------+------+-----+-----+ 1564 | | |Improvement| 0| -5.08| -9.76| 6.04| 6.20| 1565 | | | (%s) | | | | | | 1566 +----+------+-----------+----+------+------+-----+-----+ 1567 |3e-6|576 |Throughput |6206| 5070 | 4746 | 6562| 6580| 1568 | | | (Byte/s) | | | | | | 1569 | | |-----------+----+------+------+-----+-----+ 1570 | | |Improvement| 0|-18.30|-23.53| 5.74| 6.03| 1571 | | | (%s) | | | | | | 1572 +----+------+-----------+----+------+------+-----+-----+ 1573 |1e-5|296 |Throughput |3377| 2470 | 2312 | 3633| 3667| 1574 | | | (Byte/s) | | | | | | 1575 | | |-----------+----+------+------+-----+-----+ 1576 | | |Improvement| 0|-26.86|-31.54| 7.58| 8.59| 1577 | | | (%s) | | | | | | 1578 +----+------+-----------+----+------+------+-----+-----+ 1579 |3e-5|296 |Throughput |1576| 1065 | 1122 | 1755| 1773| 1580 | | | (Byte/s) | | | | | | 1581 | | |-----------+----+------+------+-----+-----+ 1582 | | |Improvement| 0|-32.42|-28.81|11.36|12.50| 1583 | | | (%s) | | | | | | 1584 +----+------+-----------+----+------+------+-----+-----+ 1585 |1e-4|168 |Throughput | 465| 319 | 340 | 595| 597| 1586 | | | (Byte/s) | | | | | | 1587 | | |-----------+----+------+------+-----+-----+ 1588 | | |Improvement| 0|-31.40|-26.88|27.96|28.39| 1589 | | | (%s) | | | | | | 1590 +----+------+-----------+----+------+------+-----+-----+ 1591 |3e-4| 96 |Throughput | 87| 79| 86 | 190| 194| 1592 | | | (Byte/s) | | | | | | 1593 | | |-----------+----+------+------+-----+-----+ 1594 | | |Improvement| 0| -9.20| -1.15|118.4|123.0| 1595 | | | (%s) | | | | | | 1596 +----+------+-----------+----+------+------+-----+-----+ 1598 draft-ietf-rohc-tcp-taroc-04.txt 1600 A.3.4. 9.6kb 1602 Sack 1603 +----+------+-----------+----+------+------+-----+-----+ 1604 |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| 1605 | |(Byte)| | | | | | | 1606 +----+------+-----------+----+------+------+-----+-----+ 1607 |3e-8|576 |Throughput |1116| 1187 | 1185 | 1190| 1191| 1608 | | | (Byte/s) | | | | | | 1609 | | |-----------+----+------+------+-----+-----+ 1610 | | |Improvement| 0| 6.36| 6.18 | 6.63| 6.72| 1611 | | | (%s) | | | | | | 1612 +----+------+-----------+----+------+------+-----+-----+ 1613 |1e-8|576 |Throughput |1116| 1188 | 1186 | 1191| 1192| 1614 | | | (Byte/s) | | | | | | 1615 | | |-----------+----+------+------+-----+-----+ 1616 | | |Improvement| 0| 6.45| 6.27 | 6.72| 6.81| 1617 | | | (%s) | | | | | | 1618 +----+------+-----------+----+------+------+-----+-----+ 1619 |1e-7|576 |Throughput |1116| 1183 | 1181 | 1190| 1191| 1620 | | | (Byte/s) | | | | | | 1621 | | |-----------+----+------+------+-----+-----+ 1622 | | |Improvement| 0| 6.00| 5.82 | 6.63| 6.72| 1623 | | | (%s) | | | | | | 1624 +----+------+-----------+----+------+------+-----+-----+ 1625 |3e-7|576 |Throughput |1114| 1173 | 1172 | 1188| 1190| 1626 | | | (Byte/s) | | | | | | 1627 | | |-----------+----+------+------+-----+-----+ 1628 | | |Improvement| 0| 5.30 | 5.21 | 6.64| 6.82| 1629 | | | (%s) | | | | | | 1630 +----+------+-----------+----+------+------+-----+-----+ 1631 |1e-6|576 |Throughput |1110| 1133 | 1144 | 1183| 1184| 1632 | | | (Byte/s) | | | | | | 1633 | | |-----------+----+------+------+-----+-----+ 1634 | | |Improvement| 0| 2.07| 3.06 | 6.58| 6.67| 1635 | | | (%s) | | | | | | 1636 +----+------+-----------+----+------+------+-----+-----+ 1637 |3e-6|576 |Throughput |1089| 1036 | 1070 | 1164| 1167| 1638 | | | (Byte/s) | | | | | | 1639 | | |-----------+----+------+------+-----+-----+ 1640 | | |Improvement| 0| -4.87|-1.74 | 6.89| 7.16| 1641 | | | (%s) | | | | | | 1642 +----+------+-----------+----+------+------+-----+-----+ 1643 |1e-5|296 |Throughput | 979| 855 | 935 | 1122| 1123| 1644 | | | (Byte/s) | | | | | | 1645 | | |-----------+----+------+------+-----+-----+ 1646 | | |Improvement| 0|-12.67|-4.49 |14.61|14.71| 1647 | | | (%s) | | | | | | 1648 +----+------+-----------+----+------+------+-----+-----+ 1650 draft-ietf-rohc-tcp-taroc-04.txt 1652 +----+------+-----------+----+------+------+-----+-----+ 1653 |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| 1654 | |(Byte)| | | | | | | 1655 +----+------+-----------+----+------+------+-----+-----+ 1656 |3e-5|296 |Throughput | 759| 500 | 600 | 900 | 908 | 1657 | | | (Byte/s) | | | | | | 1658 | | |-----------+----+------+------+-----+-----+ 1659 | | |Improvement| 0|-34.12|-20.95|18.58|19.63| 1660 | | | (%s) | | | | | | 1661 +----+------+-----------+----+------+------+-----+-----+ 1662 |1e-4|168 |Throughput | 341| 224| 252 | 455| 465| 1663 | | | (Byte/s) | | | | | | 1664 | | |-----------+----+------+------+-----+-----+ 1665 | | |Improvement| 0|-34.31|-26.10|33.43|36.36| 1666 | | | (%s) | | | | | | 1667 +----+------+-----------+----+------+------+-----+-----+ 1668 |3e-4| 96 |Throughput | 78| 67| 72 | 172| 173| 1669 | | | (Byte/s) | | | | | | 1670 | | |-----------+----+------+------+-----+-----+ 1671 | | |Improvement| 0|-14.10|-7.69 |120.5|121.8| 1672 | | | (%s) | | | | | | 1673 +----+------+-----------+----+------+------+-----+-----+