idnits 2.17.1 draft-ietf-rohc-tcp-epic-02.txt: -(1000): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 22 longer pages, the longest (page 11) being 61 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. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([ROHC]), 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'PAGE 1' is mentioned on line 55, but not defined == Missing Reference: 'PAGE 2' is mentioned on line 98, but not defined == Missing Reference: 'PAGE 3' is mentioned on line 154, but not defined == Missing Reference: 'PAGE 4' is mentioned on line 210, but not defined == Missing Reference: 'PAGE 5' is mentioned on line 265, but not defined == Missing Reference: 'PAGE 6' is mentioned on line 321, but not defined == Missing Reference: 'PAGE 7' is mentioned on line 376, but not defined == Missing Reference: 'PAGE 8' is mentioned on line 430, but not defined == Missing Reference: 'PAGE 9' is mentioned on line 484, but not defined == Missing Reference: 'PAGE 10' is mentioned on line 540, but not defined == Missing Reference: 'PAGE 11' is mentioned on line 592, but not defined == Missing Reference: 'PAGE 12' is mentioned on line 648, but not defined == Missing Reference: 'PAGE 13' is mentioned on line 703, but not defined == Missing Reference: 'PAGE 14' is mentioned on line 757, but not defined == Missing Reference: 'PAGE 15' is mentioned on line 812, but not defined == Missing Reference: 'PAGE 16' is mentioned on line 868, but not defined == Missing Reference: 'PAGE 17' is mentioned on line 919, but not defined == Missing Reference: 'TAROC-3' is mentioned on line 920, but not defined == Missing Reference: 'PAGE 18' is mentioned on line 971, but not defined == Missing Reference: 'PAGE 19' is mentioned on line 1028, but not defined == Missing Reference: 'PAGE 20' is mentioned on line 1048, but not defined == Missing Reference: 'PAGE 21' is mentioned on line 1104, but not defined == Missing Reference: 'PAGE 22' is mentioned on line 1160, but not defined == Missing Reference: 'PAGE 23' is mentioned on line 1178, but not defined == Unused Reference: 'RFC-1144' is defined on line 956, but no explicit reference was found in the text == Unused Reference: 'RFC-1951' is defined on line 960, but no explicit reference was found in the text == Unused Reference: 'TAROC-4' is defined on line 1000, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'EPIC' -- Possible downref: Non-RFC (?) normative reference: ref. 'HUFF' ** Downref: Normative reference to an Informational RFC: RFC 1951 -- Possible downref: Non-RFC (?) normative reference: ref. 'CONG1' ** Obsolete normative reference: RFC 2581 (ref. 'CONG2') (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2481 (Obsoleted by RFC 3168) -- Possible downref: Non-RFC (?) normative reference: ref. 'ECN' -- Possible downref: Non-RFC (?) normative reference: ref. 'TCPREQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'INITWIN' -- Possible downref: Non-RFC (?) normative reference: ref. 'TAROC-4' Summary: 8 errors (**), 0 flaws (~~), 30 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Richard Price, Siemens/Roke Manor 3 INTERNET-DRAFT Robert Hancock, Siemens/Roke Manor 4 Expires: May 2002 Stephen McCann, Siemens/Roke Manor 5 Mark A West, Siemens/Roke Manor 6 Abigail Surtees, Siemens/Roke Manor 7 Paul Ollis, Siemens/Roke Manor 9 Qian Zhang, Microsoft Research Asia 10 Hongbin Liao, Microsoft Research Asia 11 Wenwu Zhu, Microsoft Research Asia 12 Ya-Qin Zhang, Microsoft Research Asia 14 21 November, 2001 16 TCP/IP Compression for ROHC 17 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 [RFC-2026]. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This document is a submission to the IETF ROHC WG. Comments should be 40 directed to the mailing list of ROHC, rohc@cdt.luth.se. 42 Abstract 44 This draft describes a ROHC profile for the robust compression of 45 TCP/IP. 47 The RObust Header Compression [ROHC] scheme is designed to compress 48 packet headers over error prone channels. It is built around an 49 extensible core framework that can be tailored to compress new 50 protocol stacks by adding additional ROHC profiles. 52 The new profile for TCP/IP compression is provided by the Efficient 53 Protocol Independent Compression (EPIC-LITE) scheme. 55 Price et al. [PAGE 1] 56 Table of contents 58 Status of this Memo................................................1 59 Abstract...........................................................1 60 1. Introduction...................................................2 61 3. ROHC Profile for compression of TCP/IP.........................3 62 4. The concept and framework of TAROC-C...........................5 63 4.1. TCP congestion window tracking.............................7 64 4.2. Compressor/decompressor state machine with TAROC-C........11 65 4.3. Compressor logic in TAROC-C...............................12 66 4.4. Decompressor logic in TAROC-C.............................14 67 4.5. Modes of operation........................................15 68 4.6. Implementation issues.....................................17 69 4.7. Performance of TAROC-C....................................17 70 5. Security considerations.......................................18 71 6. Acknowledgements..............................................18 72 7. References....................................................18 73 Appendix A. Packet types provided by ROHC framework..............21 74 A.1. CO packet................................................21 75 A.2. IR-DYN packet............................................22 76 A.3. IR packet................................................22 78 1. Introduction 80 This document describes a method for compressing TCP/IP headers 81 within the [ROHC] framework. 83 The new profile for TCP/IP compression is provided by the Efficient 84 Protocol Independent Compression (EPIC) scheme. EPIC takes as its 85 input a BNF description of the protocol stack to be compressed, and 86 derives a set of packet formats that can be used to quickly and 87 efficiently compress and decompress headers. 89 A TCP-Aware RObust Header Compression Control scheme, TAROC-C, is 90 also introduced in this draft. The key point of TAROC-C is the TCP 91 congestion window tracking mechanism, which can be used to improve 92 the efficiency of the window-based encoding and the performance of 93 the overall header compression scheme without sacrificing the 94 robustness. With the dynamic congestion window tracking, our scheme 95 can achieve good performance even when the feedback channel is not 96 available. 98 Price et al. [PAGE 2] 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC-2119]. 105 3. ROHC Profile for compression of TCP/IP 107 This chapter describes a simple ROHC profile for the compression of 108 TCP/IP. 110 Note that the current TCP/IP profile is designed specifically to test 111 implementations of [EPIC]. The profile is not designed to compress 112 TCP/IP with a high level of efficiency. 114 The profile supports all TCP options (it does not compress the 115 options, but instead passes them through transparently as part of the 116 payload). 118 The profile for TCP/IP compression is given below: 120 profile_identifier 0xFFFF 121 max_formats 200 122 max_sets 1 123 bit_alignment 8 124 npatterns 224 125 CO_packet TCP-IP 127 ; The profile identifier is a placeholder. 129 ; The IR-DYN_packet and IR_packet parameters are not specified. This 130 ; means that the IR-DYN and IR packets are generated using the same 131 ; encoding method "TCP/IP" as for the CO packets. 133 ; The encoding methods used by the TCP/IP profile are given below: 135 TCP-IP = IPv4-header 136 TCP-header 137 msn 139 msn = C(MSN-LSB(4,-1,90%)) | C(MSN-LSB(7,-1,9%)) | 140 MSN-IRREGULAR(16,1%) 142 IPv4-header = version 143 header_len 144 tos 145 ecn 146 length 147 ip-id 148 rf_flag 149 df_flag 150 mf_flag 151 offset 152 ttl 154 Price et al. [PAGE 3] 155 protocol 156 ip_chksum 157 src_address 158 dst_address 160 version = STATIC-KNOWN(4,4) 162 header_len = STATIC-KNOWN(4,5) 164 tos = C(STATIC(99%)) | IRREGULAR(6,1%) 166 ecn = IRREGULAR(2,100%) 168 length = IRREGULAR(16) 170 ip-id = C(LSB(4,-1,90%)) | C(LSB(6,-1,8%)) | 171 C(LSB(8,-1,1%)) | IRREGULAR(16,1%) 173 rf_flag = VALUE(1,0,100%) 175 df_flag = IRREGULAR(1,100%) 177 mf_flag = VALUE(1,0,99%) | VALUE(1,1,1%) 179 offset = C(STATIC(99%)) | IRREGULAR(13,1%) 181 ttl = C(STATIC(99%)) | IRREGULAR(8,1%) 183 protocol = STATIC-KNOWN(8,6) 185 ip_chksum = IRREGULAR(16,100%) 187 src_address = STATIC-UNKNOWN(32) 189 dst_address = STATIC-UNKNOWN(32) 191 TCP-header = source_port 192 dest_port 193 seqno 194 ackno 195 data_offset 196 flags 197 window 198 tcp_chksum 199 urg_ptr 201 source_port = STATIC-UNKNOWN(16) 203 dest_port = STATIC-UNKNOWN(16) 205 seqno = C(LSB(8,63,80%)) | C(LSB(14,127,10%)) | 206 C(LSB(20,1023,5%)) | IRREGULAR(32,5%) 208 ackno = C(LSB(8,-1,80%)) | C(LSB(14,-1,10%)) | 210 Price et al. [PAGE 4] 211 C(LSB(20,-1,5%)) | IRREGULAR(32,5%) 213 data_offset = IRREGULAR(4,100%) 215 window = C(STATIC(80%)) | C(LSB(12,63,10%)) | 216 IRREGULAR(16,10%) 218 tcp_chksum = IRREGULAR(16,100%) 220 urg_ptr = C(STATIC(99%)) | IRREGULAR(16,1%) 222 flags = reserved 223 cwr 224 ece 225 urg 226 ack 227 psh 228 rst 229 syn 230 fin 232 reserved = C(STATIC(90%)) | IRREGULAR(4,10%) 234 cwr = VALUE(1,0,80%) | VALUE(1,1,20%) 236 ece = VALUE(1,0,80%) | VALUE(1,1,20%) 238 urg = VALUE(1,0,99%) | VALUE(1,1,1%) 240 ack = VALUE(1,1,99%) | VALUE(1,0,1%) 242 psh = IRREGULAR(1,100%) 244 rst = VALUE(1,0,99%) | VALUE(1,1,1%) 246 syn = VALUE(1,0,99%) | VALUE(1,1,1%) 248 fin = VALUE(1,0,95%) | VALUE(1,1,5%) 250 4. The concept and framework of TAROC-C 252 This section first describes the concept of the TCP-aware robust 253 header compression control (TAROC-C) mechanism and then discusses how 254 this concept leads to a better performance when used over unreliable 255 links. 257 To design suitable mechanisms for efficient compression of all TCP/IP 258 header fields, it would be important to analyze their change patterns 259 first. It is known that the change patterns of several TCP fields 260 (for example, Sequence Number, Acknowledgement Number, Window, etc.) 261 are completely different from the ones of RTP, which had already 262 discussed in detail in [ROHC], and are very hard to predict. Thus, it 263 is hard to encode these fields with k-LSB both efficiently and 265 Price et al. [PAGE 5] 266 robustly. On the other hand, Window-based LSB encoding [ROHC], which 267 does not assume the linear changing pattern of the target header 268 fields, is more suitable to encode those TCP fields both efficiently 269 and robustly. 271 The main idea of TAROC-C, the control mechanism of TAROC, is the 272 combination of the Window-based LSB encoding (W-LSB encoding) and 273 dynamically TCP congestion window tracking. In W-LSB encoding, a 274 sliding window (VSW), which equals to value r mentioned in Section 275 6.4, is maintained on the compressor side. The compressor gets 276 inconsistent with the decompressor only when the reference value on 277 the decompressor side is out of this VSW. By keeping the sliding 278 window large enough, the compressor rarely gets out of 279 synchronization with the decompressor. 281 However, the larger the sliding window is, the less the header 282 compression gains. To shrink the window size, the compressor needs 283 some form of feedback to get sufficient confidence that a certain 284 value will not be used as a reference by the decompressor. Then the 285 window can be advanced by removing that value and all other values 286 older than it. Obviously, when a feedback channel is available, 287 confidence can be achieved by proactive feedback in the form of ACKs 288 from the decompressor. A feedback channel, however, is unavailable or 289 expensive in some environments. In this Internet draft, a mechanism 290 based on dynamically tracking TCP congestion window is proposed to 291 explore such feedbacks from the nature feedback-loop of TCP protocol 292 itself. 294 Since TCP is a window-based protocol, a new segment cannot be 295 transmitted without getting the acknowledgment of segment in the 296 previous window. Upon receiving the new segment, the compressor can 297 get enough confidence that the decompressor has received the segment 298 in the previous window and then shrink the sliding window by removing 299 all the values older than that segment. 301 As originally outlined in [CONG1] and specified in [CONG2], TCP is 302 incorporated with four congestion control algorithms: slow-start, 303 congestion-avoidance, fast retransmit, and fast recovery. The 304 effective window of TCP is mainly controlled by the congestion window 305 and may change during the entire connection life. TAROC-C designs a 306 mechanism to track the dynamics of TCP congestion window, and control 307 the sliding window of W-LSB encoding by the estimated congestion 308 window. By combining the W-LSB encoding and TCP congestion window 309 tracking, TAROC can achieve better performance over high bit-error- 310 rate links. 312 Note that in one-way TCP traffic, only the information about sequence 313 number or acknowledgment number is available for tracking TCP 314 congestion window. TAROC-C does not require that all one-way TCP 315 traffics must cross the same compressor. The detail will be described 316 in the following sections. 318 The TAROC scheme achieves its compression gain by establishing state 319 information at both ends of the link, i.e., at the compressor and at 321 Price et al. [PAGE 6] 322 the decompressor. Header compression with TAROC can be characterized 323 as an interaction between two state machines, one compressor machine 324 and one decompressor machine, each instantiated once per context. 326 In the rest of this session, the TCP congestion window tracking 327 algorithm, the state machines in the TCP/IP header compression 328 framework, and the logics of the compressor/decompressor, are 329 described in detail. 331 4.1. TCP congestion window tracking 333 4.1.1. General principle of congestion window tracking 335 The general principle of congestion window tracking is as follows. 336 The compressor imitates the congestion control behavior of TCP upon 337 receiving each segment, in the meantime, estimates the congestion 338 window (cwnd) and the slow start threshold (ssthresh). Besides the 339 requirement of accuracy, there are also some other requirements for 340 the congestion window tracking algorithms: 342 - Simplex link. The tracking algorithm SHOULD always only take 343 Sequence Number or Acknowledgment Number of a one-way TCP 344 traffic into consideration. It SHOULD NOT use Sequence Number 345 and Acknowledgment Number of that traffic simultaneously. 347 - Misordering resilience. The tracking algorithm SHOULD work 348 well while receiving misordered segments. 350 - Multiple-links. The tracking algorithm SHOULD work well when 351 not all the one-way TCP traffics are crossing the same link. 353 - Slightly overestimation. If the tracking algorithm cannot 354 guarantee the accuracy of the estimated cwnd and ssthresh, it is 355 RECOMMANDED that it produces a slightly overestimated one. 357 The following sections will describe two congestion window tracking 358 algorithms, which use Sequence Number and Acknowledgment Number of a 359 one-way TCP traffic, respectively. 361 4.1.2. Congestion window tracking based on Sequence Number 363 This algorithm (Algorithm SEQ) contains 3 states: SLOW-START, 364 CONGESTION-AVOIDANCE, and FAST-RECOVERY, which are equivalent to the 365 states in TCP congestion control algorithms. It maintains 2 variables: 366 cwnd and ssthresh. 368 +-------------+ 369 | | 370 ---------------->| CONGESTION- | 371 | | AVOIDANCE | 372 | ----| |<--- 373 +------------+ | +-------------+ | 374 | | | | 376 Price et al. [PAGE 7] 377 | SLOW-START | | | 378 | | | +-------------+ | 379 +------------+ | | | | 380 | |-->| FAST- |---- 381 | | RECOVERY | 382 ---------------->| | 383 +-------------+ 385 Initially, this algorithm starts in state SLOW-START with ssthresh 386 set to ISSTHRESH and cwnd set to IW. 388 Upon receiving a segment, if it is the first segment, which is not 389 necessary to be the SYN segment, the algorithm sets the current 390 maximum Sequence Number (CMAXSN) and the current minimum Sequence 391 Number (CMINSN) to this segment's sequence number; otherwise, the 392 algorithm takes a procedure according to the current state. 394 - SLOW-START 396 * If the new Sequence Number (NSN) is larger than CMAXSN, 397 increase cwnd by the distance between NSN and CMAXSN, and 398 update CMAXSN and CMINSN based on the following rules: 399 CMAXSN = NSN 400 if (CMAXSN - CMINSN) > cwnd) 401 CMINSN = cwnd - CMAXSN; 402 If the cwnd is larger than ssthresh, the algorithm transits to 403 CONGESTION-AVOIDANCE state; 405 * If the distance between NSN and CMAXSN is less than or equal 406 to 3*MSS, ignore it; 408 * If the distance is larger than 3*MSS, halve the cwnd and set 409 ssthresh to MAX(cwnd, 2*MSS). After that, the algorithm 410 transits into FAST-RECOVERY state. 412 - CONGESTION-AVOIDANCE 414 * If NSN is larger than CMAXSN, increase cwnd by ((NSN- 415 CMAXSN)*MSS)/cwnd and then update CMAXSN and CMINSN based on 416 the following rules: 417 CMAXSN = NSN 418 if (CMAXSN - CMINSN) > cwnd) 419 CMINSN = cwnd - CMAXSN; 421 * If the distance between NSN and CMAXSN is less than or equal 422 to 3*MSS, ignore it; 424 * If the distance is larger than 3*MSS, halve the cwnd and set 425 ssthresh to MAX(cwnd, 2*MSS). After that, the algorithm 426 transits into FAST-RECOVERY state. 428 - FAST-RECOVERY 430 Price et al. [PAGE 8] 431 * If NSN is larger than or equal to CMAXSN + cwnd, the algorithm 432 transits into CONGESTION-AVOIDANCE state; 434 * Otherwise, ignore it. 436 In this algorithm, MSS is denoted as the estimated maximum segment 437 size. The implementation can use the MTU of the link as an 438 approximation of this value. ISSHRESH and IW are the initial values 439 of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily high. 440 IW SHOULD be set to 4*MSS. 442 4.1.3. Congestion window tracking based on Acknowledgment Number 444 This algorithm (Algorithm ACK) maintains 3 states: SLOW-START, 445 CONGESTION-AVOIDANCE and FAST-RECOVERY, which are equivalent to the 446 states in TCP congestion control algorithms. It also maintains 2 447 variables: cwnd and ssthresh. 449 +-------------+ 450 | | 451 ---------------->| CONGESTION- | 452 | | AVOIDANCE | 453 | ----| |<--- 454 +------------+ | +-------------+ | 455 | | | | 456 | SLOW-START | | | 457 | | | +-------------+ | 458 +------------+ | | | | 459 | |-->| FAST- |---- 460 | | RECOVERY | 461 ---------------->| | 462 +-------------+ 464 Initially, this algorithm starts in state SLOW-START with ssthresh 465 set to ISSTHRESH and cwnd set to IW. 467 Upon receiving a segment, if it is the first segment, which is not 468 necessary to be the SYN segment, the algorithm sets the current 469 maximum Acknowledgment Number (CMAXACK) to this segment's 470 acknowledgment number; otherwise, the algorithm takes a procedure 471 according to the current state. 473 - SLOW-START 475 * If the new Acknowledgment Number (NEWACK) is larger than 476 CMAXACK, increase cwnd by the distance between NEWACK and 477 CMAXACK, set duplicate ack counter (NDUPACKS) to 0, and update 478 CMAXACK accordingly; If the cwnd is larger than ssthresh, the 479 algorithm transits to CONGESTION-AVOIDANCE state; 481 * If NEWACK is equal to CMAXACK, increase the NDUPACKS by 1. If 482 NDUPACKS is greater than 3, halve the cwnd and set ssthresh to 484 Price et al. [PAGE 9] 485 MAX(cwnd, 2*MSS). Consequently, the algorithm transits into 486 FAST-RECOVERY state; 488 * Otherwise, set NDUPACKS to 0. 490 - CONGESTION-AVOIDANCE 492 * If NEWACK is larger than CMAXACK, increase cwnd by ((NEWACK- 493 CMAXACK)*MSS)/cwnd, set NDUPACKS to 0 and update CMAXACK 494 accordingly; 496 * If NEWACK is equal to CMAXACK, increase NDUPACKS by 1. If 497 NDUPACKS is greater than 3, halve the cwnd and set ssthresh to 498 MAX(cwnd, 2*MSS). After that, the algorithm transits into 499 FAST-RECOVERY state; 501 * Otherwise, set NDUPACKS to 0. 503 - FAST-RECOVERY 505 * If NEWACK is larger than CMAXACK, set NDUPACKS to 0. 506 Consequently, the algorithm transits into CONGESTION-AVOID 507 state; 509 * Otherwise, ignore it. 511 In this algorithm, MSS is denoted as the estimated maximum segment 512 size. The implementation can use the MTU of the link as an 513 approximation of this value. ISSHRESH and IW are the initial values 514 of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily high. 515 IW SHOULD be set to 4*MSS. 517 4.1.4. Further discussion on congestion window tracking 519 In some cases, it is inevitable for the tracking algorithms to 520 overestimate the TCP congestion window. Also, it SHOULD be avoided 521 that the estimated congestion window gets significantly smaller that 522 the actual one. For all of these cases, TAROC simply applies two 523 boundaries on the estimated congestion window size. One of the two 524 boundaries is the MIN boundary, which is the minimum congestion 525 window size and whose value is determined according to the [INITWIN]; 526 the other boundary is the MAX boundary, which is the maximum 527 congestion window size. There are two possible approaches to setting 528 this MAX boundary. One is to select a commonly used maximum TCP 529 socket buffer size. The other one is to use the simple equation 530 W=sqrt(8/3*l), where W is the maximum window size and l is the 531 typical packet loss rate. 533 If ECN mechanism is deployed, according to [RFC-2481] and [ECN], the 534 TCP sender will set the CWR (Congestion Window Reduced) flag in the 535 TCP header of the first new data packet sent after the window 536 reduction, and the TCP receiver will reset the ECN-Echo flag back to 537 0 after receiving a packet with CWR flag set. Thus, the CWR flag and 538 the ECN-Echo flag's transition from 1 to 0 can be used as another 540 Price et al. [PAGE 10] 541 indication of congestion combined with other mechanisms mentioned in 542 the tracking algorithm. 544 4.2. Compressor/decompressor state machine with TAROC-C 546 4.2.1. Compressor states 548 There are three compressor states in TAROC: Initialization and 549 Refresh (IR) state, First Order (FO), and Second Order (SO) states. 550 The compressor starts in the lowest compression state (IR) and 551 transits gradually to the higher compression state. The compressor 552 will always operate in the highest possible compression state, under 553 the constraint that the compressor is sufficiently confident that the 554 decompressor has the information necessary to decompress a header, 555 which is compressed according to the state. 557 +----------+ 558 | | 559 +----------+ | FO State | +----------+ 560 | | <--------> | | <--------> | | 561 | IR State | +----------+ | SO State | 562 | | <----------------------------------> | | 563 +----------+ +----------+ 565 4.2.1.1. Initialization and Refresh (IR) state 567 The purpose of IR state is to initialize or refresh the static parts 568 of the context at the decompressor. In this state, the compressor 569 sends full header periodically with an exponentially increasing 570 period, which is so-called compression slow-start [RFC-2507]. The 571 compressor leaves the IR state only when it is confident that the 572 decompressor has correctly received the static information. 574 To compress short-lived TCP transfers more efficiently, the 575 compressor should speed up the initial process. The compressor enters 576 the IR state when it receives the packet with SYN bit set and sends 577 IR packet. When it receives the first data packet of the transfer, it 578 should transit to FO state because that means the decompressor has 579 received the packet with SYN bit set and established the context 580 successfully at its side. Using this mechanism can significantly 581 reduce the number of context initiation headers. 583 4.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 operating 587 in this state, the compressor and the decompressor should have the 588 same context. Only compressed packet is transmitted from the 589 compressor to the decompressor in this state. The compressor transits 590 back to IR state only when it finds that the context of decompressor 592 Price et al. [PAGE 11] 593 may be inconsistent, or there are remarkable changes in the TCP/IP 594 header. 596 4.2.1.3. Second Order (SO) State 598 The purpose of SO state is to efficiently transmit the fixed-payload 599 data. The compressor enters this state when it is sufficiently 600 confident that the decompressor has got the constant payload size of 601 the data transferring. 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 4.2.2. Decompressor states 611 The decompressor starts in its lowest compression state, "No Context" 612 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 4.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 will 624 describe the logic for each compressor sate in detail. 626 4.3.1. IR state 628 The operations of compressor in IR state can be summarized as follows: 630 a) Upon receiving a packet, the compressor sends IR or IR-DYN packet 631 on the following conditions: 1) if it is the turn to send full 632 header packet according to compression slow-start, i.e. after 633 sending F_PERIOD compressed packets; 2) if the packet to be sent 634 is a retransmission of the packet in VSW and it was sent as IR or 635 IR-DYN packet previously. Otherwise, the compressor compresses 636 the packet using W-LSB encoding. If the compressor enters the IR 637 state for the first time or the static part of the TCP flow has 638 changed, it will send IR packet. Otherwise, it will send IR-DYN 639 packet because the decompressor has known the static part. 641 b) The packet is added into VSW as a potential reference after it 642 has been sent out. The compressor then invokes the Algorithm SEQ 643 and Algorithm ACK to track the congestion windows of the two one- 644 way traffics with different directions in a TCP connection. 645 Suppose that the estimated congestion windows are cwnd_seq and 646 cwnd_ack, while the estimated slow start thresholds are 648 Price et al. [PAGE 12] 649 ssthresh_seq and ssthresh_ack, respectively. Let W(cwnd_seq, 650 ssthresh_seq, cwnd_ack, ssthresh_ack) = K*MAX(MAX(cwnd_seq, 651 2*ssthresh_seq), MAX(cwnd_ack, 2*ssthresh_ack)). If the size of 652 VSW is larger than W(cwnd_seq, ssthresh_seq, cwnd_ack, 653 ssthresh_ack), the VSW can be shrunk. K is an implementation 654 parameter that will be further discussed in Section 5.6. 656 c) After sending F_PERIOD compressed packets, F_PERIOD SHOULD be 657 doubled. If it gets larger than W(cwnd_seq, ssthresh_seq, 658 cwnd_ack, ssthresh_ack), the compressor transits to FO or SO 659 state. If the compressor finds that the payload size of 660 consecutive packets is a constant value and one of such packets 661 is removed from the VSW, which means the decompressor has known 662 the exact value of the constant size, it may transit to SO state. 663 Otherwise it will transit to the FO state. 665 4.3.2. FO state 667 The operations of the compressor in the FO state can be summarized as 668 follows: 670 a) Upon receiving a packet, if it falls behind the VSW, i.e. it is 671 older than all the packets in VSW; the compressor transits to IR 672 state. Otherwise, the compressor compresses it using W-LSB encoding 673 and sends it. 675 b) The packet is added into VSW as a potential reference after it has 676 been sent out. The compressor then invokes the Algorithm SEQ and 677 Algorithm ACK to track the congestion windows of the two one-way 678 traffics with different directions in a TCP connection. Suppose 679 that the estimated congestion windows are cwnd_seq and cwnd_ack, 680 while the estimated slow start thresholds are ssthresh_seq and 681 ssthresh_ack, respectively. Let W(cwnd_seq, ssthresh_seq, cwnd_ack, 682 ssthresh_ack) = K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack, 683 2*ssthresh_ack)). If the size of VSW is larger than W(cwnd_seq, 684 ssthresh_seq, cwnd_ack, ssthresh_ack), the VSW can be shrunk. K is 685 also an implementation parameter, which can be set to the same 686 value as in the IR state. 688 c) If the VSW contains only one packet, which means there is a long 689 jump in the packet sequence number or acknowledge number, the 690 compressor will transit to the IR state and re-initialize the 691 algorithm for tracking TCP congestion window. Here, a segment 692 causes a long jump when the distance between its sequence number 693 (or acknowledgment number) and CMAXSN (or CMAXACK) is larger than 694 the estimated congestion window size, i.e., 695 |sequence number (acknowledgement number) � CMAXSN (CMAXACK)| > 696 estimated congestion window size. 698 d) If the compressor finds that the payload size of consecutive 699 packets is a constant value and one of such packets has been 700 removed from the VSW, which means the decompressor has known the 701 exact value of the constant size, it may transit to the SO state. 703 Price et al. [PAGE 13] 704 e) If the static context of transfers changed, the compressor will 705 transit to the IR state and re-initialize the algorithms for 706 tracking TCP congestion window. 708 4.3.3. SO state 710 The operations of the compressor in the SO state can be summarized as 711 follows: 713 a) Upon receiving a packet, if it falls behind the VSW, i.e. it is 714 older than all the packets in VSW; the compressor transits to IR 715 state. Otherwise, the compressor compresses it using fixed-payload 716 encoding and sends it. 718 b) The packet is added into VSW as a potential reference after it has 719 been sent out. The compressor then invokes the Algorithm SEQ and 720 Algorithm ACK to track the congestion windows of the two one-way 721 traffics with different directions in a TCP connection. Suppose 722 that the estimated congestion windows are cwnd_seq and cwnd_ack, 723 while the estimated slow start thresholds are ssthresh_seq and 724 ssthresh_ack, respectively. Let W(cwnd_seq, ssthresh_seq, cwnd_ack, 725 ssthresh_ack) = K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack, 726 2*ssthresh_ack)). If the size of VSW is larger than W(cwnd_seq, 727 ssthresh_seq, cwnd_ack, ssthresh_ack), the VSW can be shrunk. K is 728 an implementation parameter, which can be set to the same value as 729 in the IR state. 731 c) If the VSW contains only one packet, which means there is a long 732 jump in the packet sequence number or acknowledge number, the 733 compressor will transit to the IR state and re-initialize the 734 algorithms for tracking TCP congestion window. 736 d) If the payload size of the packets in VSW doesn't keep constant, 737 the compressor transits to the FO state. 739 e) If the static context of transfers changed, the compressor will 740 transit to the IR state and re-initialize the algorithms for 741 tracking TCP congestion window. 743 4.4. Decompressor logic in TAROC-C 745 The logic of the decompressor is simpler compared to the compressor. 747 4.4.1. No Context State 749 The decompressor starts in this state. Upon receiving an IR or IR-DYN 750 packet, the decompressor should verify the correctness of its header 751 by TCP checksum. If the verification succeeds, the decompressor will 752 update the context and use this packet as the reference packet. After 753 that, the decompressor will pass it to the system's network layer and 754 transit to Full Context State. Conformed to ROHC framework [ROHC], 755 only IR or IR-DYN packets may be decompressed in No Context state. 757 Price et al. [PAGE 14] 758 4.4.2. Full Context State 760 The operations of decompressor in Full Context state can be 761 summarized as follows: 763 a) Upon receiving an IR or IR-DYN packet, the decompressor should 764 verify the correctness of its header by TCP checksum. If the 765 verification succeeds, the decompressor will update the context and 766 use this packet as the reference packet. Consequently, the 767 decompressor will convert the packet into the original packet and 768 pass it to the network layer of the system. 770 b) Upon receiving the other type of packet, the decompressor will 771 decompress it. After that, the decompressor MUST verify the 772 correctness of the decompressed packet by the TCP checksum. If the 773 verification succeeds, the decompressor passes it to the system's 774 network layer. Then the decompressor will use it as the reference 775 value if this packet is not older than the current reference packet. 777 c) If consequent N packets fail to be decompressed, the decompressor 778 should transit downwards to No Context State. N is an implementation 779 parameter that will be further discussed in Section 8.6. 781 4.5. Modes of operation 783 There are three modes in ROHC framework, called Unidirectional, Bi- 784 directional Optimistic, and Bi-directional Reliable mode, 785 respectively. The mode transitions are conformed to ROHC framework. 786 However, the operations of each mode are different. 788 4.5.1. Unidirectional mode -- U-mode 790 When in U-mode, packets are sent in one direction only: from 791 compressor to decompressor. Therefore, feedbacks from decompressor to 792 the compressor are unavailable under this mode. 794 In the U-mode, the compressor and decompressor logic is the same as 795 the discussion in section 8.3 and 8.4. 797 4.5.2. Bi-directional Optimistic mode -- O-mode 799 When in O-mode, a feedback channel is used to send error recovery 800 requests and (optionally) acknowledgments of significant context 801 updates from the decompressor to the compressor. In this mode, the 802 VSW will be shrunk more efficiently. 804 4.5.2.1. Compressor states and logic (O-mode) 806 Following rules should be combined with the action defined in section 807 8.3. 809 In the IR state, the compressor can transit to the FO or SO state 810 once it receives a valid ACK(O) for an IR packet sent (an ACK(O) can 812 Price et al. [PAGE 15] 813 only be valid if it refers to a packet sent earlier). If the packet 814 referred by the feedback is in the VSW, the compressor will remove 815 the packets older than the referred packet from the VSW window. 816 Because ACK(O) means that the packet referred by ACK(O) has been the 817 reference of the decompressor, the compressor doesn't need to keep 818 older packets. 820 If the compressor is in the FO or SO state, it will remove the 821 packets older than the referred packet from the VSW window. 823 Upon receiving an NACK(O), the compressor transits back to IR state. 825 4.5.2.2. Decompressor states and logic (O-mode) 827 The decompression states and the state transition logic are the same 828 as in the Unidirectional case (see section 8.5.1.). What differs is 829 the feedback logic. 831 Below, rules are defined stating which feedback to use when. 833 When an IR packet passes the verification, send an ACK(O). When an 834 IR-DYN packet or other packet is correctly decompressed, optionally 835 send an ACK(O). When any packet fails the verification, send an 836 NACK(O). 838 4.5.3. Bi-directional Reliable mode -- R-mode 840 The R-mode are a more intensive usage of the feedback channel and a 841 stricter logic at both the compressor and the decompressor that 842 prevents loss of context synchronization between the compressor and 843 decompressor except for very high residual bit error rates. Feedback 844 is sent to acknowledge all context updates. In this mode, the VSW 845 will be shrunk with the highest efficiency. 847 4.5.3.1. Compressor states and logic (R-mode) 849 Following rules should be reparation to the action defined in section 850 8.3. 852 In IR state, the compressor should transit to the FO or SO state only 853 when it receives a valid ACK(R) for an IR or IR-DYN packet sent (an 854 ACK(R) can only be valid if it refers to an packet sent earlier). If 855 the packet referred by the feedback is in the VSW, the compressor 856 will remove the packets older than the referred packet from the VSW 857 window. Because ACK(R) means that the packet referred by ACK(R) has 858 been the reference of the decompressor; the compressor doesn't need 859 to keep older packets. 861 If the compressor is in the FO or SO state, when it receives a valid 862 ACK(R), it will remove the packets older than the referred packet 863 from the VSW window. In this mode, the compressor need not use window 864 tracking, because feedback can shrink VSW efficiently and robustly. 866 Upon receiving an NACK(O), the compressor transits back to IR state. 868 Price et al. [PAGE 16] 869 4.5.3.2. Decompressor states and logic (R-mode) 871 Below, rules are defined stating which feedback to use when. 873 @When a packet is correctly decompressed and updates the context, 874 send an ACK(R). 876 @When any packet fails the verification, send a NACK(R). 878 The frequency of updating context will be discussed in section 8.6. 880 4.6. Implementation issues 882 4.6.1. Determine the value K 884 As mentioned above, the VSW SHOULD be shrunk when its size gets 885 larger than K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack, 886 2*ssthresh_ack)). Since the Fast Recovery algorithm was introduced in 887 TCP, several TCP variants had been proposed, which are different only 888 in the behaviors of Fast Recovery. Some of them need several RTTs to 889 be recovered from multiple losses in a window. Ideally, they may send 890 L*W/2 packets in this stage, where L is the number of lost packets 891 and W is the size of the congestion window where error occurs. Some 892 recent work [TCPREQ] on improving TCP performance allows to transmit 893 packets even when receiving duplicate acknowledgments. Due to the 894 above concerns, it'd better keep K large enough so as to prevent 895 shrinking VSW without enough confidence that corresponding packets 896 had been successfully received. 898 Considering the bandwidth-limited environments and the limited 899 receiver buffer, a practical range of K is around 1~2. From the 900 simulation results, K=1 is good enough for most cases. 902 4.6.2. Determine the value N 904 We should distinguish out of synchronization from the packet errors 905 cause by the link. So considering the error condition of the link, N 906 should be higher than the packet burst error length, a practical 907 range of N is around 8~10. 909 4.6.3. Determine the frequency of updating context 911 The choice of the frequency of updating context, ACK(R), is a balance 912 between the efficiency and robustness, i.e. sending ACK(R) more 913 frequently improves the compression robustness but adds more system 914 overhead, and the vice versa. From a practical view, the ACK(R) 915 SHOULD be sent for every 4~8 successfully decompressed packets. 917 4.7. Performance of TAROC-C 919 Price et al. [PAGE 17] 920 The Simulations results (see Appendix B in [TAROC-3]) demonstrate the 921 effectiveness of control mechanism TAROC-C and corresponding header 922 compression scheme. 924 5. Security considerations 926 EPIC-LITE generates compressed header formats for direct use in ROHC 927 profiles. Consequently the security considerations for EPIC-LITE 928 match those of [ROHC]. 930 6. Acknowledgements 932 Header compression schemes from [ROHC] have been important sources of 933 ideas and knowledge. Basic Huffman encoding [HUFF] was enhanced for 934 the specific tasks of robust, efficient header compression. 936 Thanks to 938 Carsten Bormann (cabo@tzi.org) 939 Christian Schmidt (christian.schmidt@icn.siemens.de) 940 Max Riegel (maximilian.riegel@icn.siemens.de) 942 for valuable input and review. 944 7. References 946 [ROHC] "RObust Header Compression (ROHC)", Carsten Bormann et 947 al, RFC3095, Internet Engineering Task Force, July 2001 949 [EPIC] "Framework for EPIC-LITE", Richard Price et al, 950 , Internet 951 Engineering Task Force, October 23, 2001 953 [HUFF] "The Data Compression Book", Mark Nelson and Jean-Loup 954 Gailly, M&T Books, 1995 956 [RFC-1144] "Compressing TCP/IP Headers for Low-Speed Serial 957 Links", V. Jacobson, Internet Engineering Task Force, 958 February 1990 960 [RFC-1951] "DEFLATE Compressed Data Format Specification version 961 1.3", P. Deutsch, Internet Engineering Task Force, May 962 1996 964 [RFC-2026] "The Internet Standards Process - Revision 3", Scott 965 Bradner, Internet Engineering Task Force, October 1996 967 [RFC-2119] "Key words for use in RFCs to Indicate Requirement 968 Levels", Scott Bradner, Internet Engineering Task 969 Force, March 1997 971 Price et al. [PAGE 18] 973 [RFC-2507] M. Degermark, B. Nordgren, and S. Pink, "IP Header 974 Compression", Internet Engineering Task Force, February 975 1999 977 [CONG1] "Congestion avoidance and control", V. Jacobson, In ACM 978 SIGCOMM '88, 1988 980 [CONG2] "TCP Congestion Control", M. Allman, V. Paxson, and W. 981 R. Stevens, RFC 2581, April 1999 983 [RFC-2481] "A Proposal to add Explicit Congestion Notification 984 (ECN) to IP", K. Ramakrishnan, S. Floyd, Internet 985 Engineering Task Force, January 1999 987 [ECN] "The Addition of Explicit Congestion Notification (ECN) 988 to IP", K. K. RamaKrishnan, Sally Floyd, D. Black, 989 Internet Draft (work in progress), June, 2001. 992 [TCPREQ] "Requirements for ROHC IP/TCP header compression", L-E. 993 Jonsson, Internet Draft (work in progress), June 20, 994 2001 996 [INITWIN] "Increasing TCP's Initial Window", M. Allman, S. Floyd, 997 and C. Partridge, Internet Draft (work in progress), 998 May 2001. 1000 [TAROC-4] H. Liao, Q. Zhang, W. Zhu, and Y.-Q. Zhang, �TCP-Aware 1001 RObust Header Compression (TAROC)�, Internet Draft 1002 (work in progress), Nov. 2001. 1005 8. Authors' addresses 1007 Richard Price Tel: +44 1794 833681 1008 Email: richard.price@roke.co.uk 1010 Robert Hancock Tel: +44 1794 833601 1011 Email: robert.hancock@roke.co.uk 1013 Stephen McCann Tel: +44 1794 833341 1014 Email: stephen.mccann@roke.co.uk 1016 Mark A West Tel: +44 1794 833311 1017 Email: mark.a.west@roke.co.uk 1019 Abigail Surtees Tel: +44 1794 833131 1020 Email: abigail.surtees@roke.co.uk 1022 Paul Ollis Tel: +44 1794 833168 1023 Email: paul.ollis@roke.co.uk 1025 Roke Manor Research Ltd 1026 Romsey, Hants, SO51 0ZN 1028 Price et al. [PAGE 19] 1029 United Kingdom 1031 Qian Zhang Tel: +86 10 62617711-3135 1032 Email: qianz@microsoft.com 1034 HongBin Liao Tel: +86 10 62617711-3156 1035 Email: i-hbliao@microsoft.com 1037 Wenwu Zhu Tel: +86 10 62617711-5405 1038 Email: wwzhu@microsoft.com 1040 Ya-Qin Zhang Tel: +86 10 62617711 1041 Email: yzhang@microsoft.com 1043 Microsoft Research Asia 1044 Beijing Sigma Center 1045 No.49, Zhichun Road, Haidian District 1046 Beijing 100080, P.R.C. 1048 Price et al. [PAGE 20] 1049 Appendix A. Packet types provided by ROHC framework 1051 In addition to the standard CO (compressed) packets, the [ROHC] 1052 framework contains two special packet types designed to help 1053 synchronize the context at the compressor and decompressor. An IR 1054 (Initialization and Refresh) packet associates a context with a 1055 certain ROHC profile, and transmits the value of all fields including 1056 those which remain constant throughout the lifetime of the context. 1058 An IR-DYN (Dynamic Initialization and Refresh) packet associates a 1059 context with a ROHC profile, and additionally transmits the value of 1060 any fields except those that remain constant for the lifetime of the 1061 context. An IR-DYN packet cannot be used to completely initialize a 1062 new context, but it is usually smaller than a full IR packet. 1064 [ROHC] also defines a general compressed packet that can be used to 1065 encapsulate CO, IR and IR-DYN packets. The general packet format 1066 includes a CID (Context Identifier) to indicate the context to which 1067 the compressed packet belongs. It also includes a packet type 1068 indicator to specify whether the packet is a feedback, initialization 1069 or general compressed packet, whether it is segmented, and whether it 1070 contains padding. 1072 The following packet type indicators are reserved in the overall 1073 [ROHC] framework: 1075 1110: Padding or Add-CID octet 1076 11110: Feedback 1077 11111000: IR-DYN packet 1078 1111110: IR packet 1079 1111111: Segment 1081 Any packet types not indicated by the bit pattern 111XXXXX can be 1082 used by individual [ROHC] profiles such as the TCP/IP profile. 1084 A.1. CO packet 1086 The compressed (CO) packet type is the basic compressed packet 1087 offered by EPIC-LITE. CO packets can be used to transmit data between 1088 the compressor and decompressor with a high level of efficiency, and 1089 can cope with most irregularities in the packet stream. 1091 The location of an EPIC-LITE CO packet within the general ROHC packet 1092 is shown below: 1094 0 7 1095 --- --- --- --- --- --- --- --- 1096 | Add-CID octet | if for CID 1-15 and small CIDs 1097 +---+--- --- --- ---+--- --- ---+ 1098 | EPIC-LITE CO packet | 1 octet 1099 +---+--- ---+---+---+--- --- ---+ 1100 | | 1101 / 0, 1, or 2 octets of CID / 1 or 2 octets if large CIDs 1102 | | 1104 Price et al. [PAGE 21] 1105 +---+---+---+---+---+---+---+---+ 1106 / EPIC-LITE CO packet / variable 1107 +---+---+---+---+---+---+---+---+ 1109 Figure 1 : Format of CO packet generated by EPIC-LITE 1111 Note that CO packets are decompressed relative to the context stored 1112 at the decompressor. If the compressor has not yet initialized this 1113 context, or suspects that it has become invalidated, then a CO packet 1114 cannot be sent. 1116 A.2. IR-DYN packet 1118 The structure of the IR-DYN packet used by EPIC-LITE is shown below: 1120 0 1 2 3 4 5 6 7 1121 --- --- --- --- --- --- --- --- 1122 : Add-CID octet : if for CID 1-15 and small CIDs 1123 +---+---+---+---+---+---+---+---+ 1124 | 1 1 1 1 1 0 0 | 0 | IR-DYN type octet 1125 +---+---+---+---+---+---+---+---+ 1126 : : 1127 / 0-2 octets of CID / 1-2 octets if for large CIDs 1128 : : 1129 +---+---+---+---+---+---+---+---+ 1130 | Profile | 1 octet 1131 +---+---+---+---+---+---+---+---+ 1132 | CRC | 1 octet 1133 +---+---+---+---+---+---+---+---+ 1134 | | 1135 / EPIC-LITE IR-DYN packet / variable length 1136 | | 1137 +---+---+---+---+---+---+---+---+ 1139 Figure 2 : Format of IR-DYN packet generated by EPIC-LITE 1141 The Profile field associates the context with a certain profile. It 1142 transmits the 8 least significant bits of the EPIC-LITE 1143 profile_identifier parameter described in Section 7.1. Furthermore, 1144 the polynomial used to calculate the CRC is defined in Section 6.12. 1146 A.3. IR packet 1148 The structure of the IR packet used by EPIC-LITE is shown below: 1150 0 1 2 3 4 5 6 7 1151 --- --- --- --- --- --- --- --- 1152 : Add-CID octet : if for CID 1-15 and small CIDs 1153 +---+---+---+---+---+---+---+---+ 1154 | 1 1 1 1 1 1 0 | D | IR type octet 1155 +---+---+---+---+---+---+---+---+ 1156 : : 1157 / 0-2 octets of CID / 1-2 octets if for large CIDs 1158 : : 1160 Price et al. [PAGE 22] 1161 +---+---+---+---+---+---+---+---+ 1162 | Profile | 1 octet 1163 +---+---+---+---+---+---+---+---+ 1164 | CRC | 1 octet 1165 +---+---+---+---+---+---+---+---+ 1166 | | 1167 / EPIC-LITE IR packet / variable length 1168 | | 1169 +---+---+---+---+---+---+---+---+ 1171 Figure 3 : Format of IR packet generated by EPIC-LITE 1173 Note that the D bit is currently always set to 1 (as specified in 1174 [ROHC]), since the IR packet generated by EPIC-LITE always compresses 1175 every field in the header. A version of the IR packet that only 1176 compresses static fields may be introduced in future. 1178 Price et al. [PAGE 23]