RObust Header Compression (ROHC) WG HongBin Liao Internet Draft Qian Zhang Document: Wenwu Zhu Expires: May 2002 Ya-Qin Zhang Microsoft Research, China November 2, 2001 TCP-Aware RObust Header Compression (TAROC) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract As a major transport protocol of current Internet, TCP has the problem of the large header overhead on bandwidth-limited links. Header compression has been proven to be efficient for using TCP over bandwidth-limited reliable links. Unfortunately, existing TCP/IP header compression schemes do not work well on noisy links, especially the one with high bit error rate and long roundtrip time. In addition, existing schemes [2,3] have not addressed some TCP options such as SACK [4,5] and Timestamps [6]. A robust and efficient header compression scheme for TCP/IP is presented in this document. The window-based LSB encoding is introduced in our scheme for compressing redundant fields and reducing error propagation. The key point of our scheme is to propose a TCP congestion window tracking approach to improve the efficiency of the window-based encoding. With the dynamical congestion window tracking, our scheme can achieve good performance even when the feedback channel is not available. Liao, Zhang, Zhu, Zhang [Page 1] draft-ietf-rohc-tcp-taroc-03.txt Table of Contents Status of this Memo................................................1 1. Abstract........................................................1 2. Conventions used in this document...............................5 3. Introduction....................................................5 4. The concept and framework of TCP-Aware RObust Header compression6 4.1. Compressor states..........................................7 4.1.1. Initialization and Refresh (IR) state.................7 4.1.2. First Order (FO) State................................7 4.1.3. Second Order (SO) State...............................8 4.2. Decompressor states........................................8 5. Window-based LSB encoding and fixed-payload encoding............8 6. TCP congestion window tracking..................................9 6.1. General principle of congestion window tracking............9 6.2. Congestion window tracking based on Sequence Number........9 6.3. Congestion window tracking based on Acknowledgment Number.11 6.4. Further discussion on congestion window tracking..........12 7. Protocol definition............................................13 7.1. Compressed packet formats.................................13 7.1.1. Packet types............................................13 7.1.2. Feedback.............................................14 7.1.3. IR packet............................................15 7.1.4. IR-DYN packet........................................16 7.1.5. TCP/IPv4 format......................................16 7.1.5.1. Packet type: (IP-ID+SEQ)........................16 7.1.5.2. Packet type: (IP-ID+ACK)........................16 7.1.5.3. Packet type: (IP-ID+SEQ+PUSH)...................16 7.1.5.4. Packet type: (FLAG including extension bit).....17 7.1.6. TCP/IPv6 format......................................17 7.1.6.1. Packet type: (SEQ)..............................17 7.1.6.2. Packet type: (ACK)..............................17 7.1.6.3. Packet type: (SEQ+PUSH).........................18 7.1.6.4. Packet type: (FLAG including extension bit).....18 7.1.7. IP-ID formats........................................18 7.1.8. SEQ (ACK) formats....................................19 7.1.9. WND formats..........................................20 7.1.10. Extension format....................................20 7.1.10.1. Encoded TCP options............................21 7.1.10.2. Sack...........................................22 7.1.10.3. Timestamp......................................22 7.1.10.4. CRC............................................23 7.2. Compressor logic..........................................23 7.2.1. IR state.............................................23 7.2.2. FO state.............................................24 7.2.3. SO state.............................................25 7.3. Decompressor logic........................................26 7.3.1. No Context State.....................................26 7.3.2. Full Context State...................................26 7.4. Modes of operation........................................26 7.4.1. Unidirectional mode -- U-mode........................27 7.4.2. Bi-directional Optimistic mode -- O-mode............27 7.4.2.1. Compressor states and logic (O-mode)...........27 Liao, Zhang, Zhu, Zhang [Page 2] draft-ietf-rohc-tcp-taroc-03.txt 7.4.2.2. Decompressor states and logic (O-mode).........27 7.4.3. Bi-directional Reliable mode -- R-mode..............27 7.4.3.1. Compressor states and logic (R-mode)...........28 7.4.3.2. Decompressor states and logic (R-mode).........28 8. Implementation issues..........................................28 8.1. Determine the value K.....................................28 8.2. Determine the value N.....................................29 8.3. Determine the frequency of updating context...............29 9. Conclusions....................................................29 10. Acknowledgments...............................................30 11. Security considerations.......................................30 12. Authors' addresses............................................31 13. References....................................................31 14. Intellectual property considerations..........................33 Appendix A - Window-based LSB encoding (W-LSB encoding)...........33 Appendix B - Simulation results...................................35 B.1. Simulation topology.......................................35 B.2. Tested header compression schemes.........................35 B.3. Simulations and results...................................36 B.3.1. 384kb................................................36 B.3.2. 114kb................................................38 B.3.3. 64kb.................................................39 B.3.4. 9.6kb................................................41 Liao, Zhang, Zhu, Zhang [Page 3] draft-ietf-rohc-tcp-taroc-03.txt Document History 03 Oct 26, 2001 Modify our TCP congestion window estimation scheme with the MAX and MIN boundary; Clarify the initialization and state transition process in compressor state management; Add the CRC option in our compressed header. 02 July 20, 2001 Integrate TAROC with ROHC framework; Add a second order (SO) state on compressor side for fixed-payload packets compression; Modify the coding method for type identification and adjust corresponding packet format to improve compression efficiency; Update the simulation results. 01 March 01, 2001 Improve congestion window tracking algorithm to handle the special cases where congestion indications are lost; Improve the compression efficiency by adding fixed-payload encoding; Change in header format accordingly. 00 November 17, 2000 First release. Liao, Zhang, Zhu, Zhang [Page 4] draft-ietf-rohc-tcp-taroc-03.txt 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7]. 3. Introduction The necessity and importance of doing TCP/IP header compression on low- or medium-speed links have been discussed in [3]. For conciseness, the general background information on header compression has not been discussed in detail in this draft. Detailed information can be found in RFC2507 [3]. Existing header compression schemes, such as VJHC [2] and IPHC [3], rely on transmitting only the difference from the previous header in order to reduce the large overhead of TCP/IP header. Although VJHC works well over reliable links, when used over unreliable link, such as wireless links, it induces many additional errors due to inconsistent contexts between the compressor and the decompressor. Considering the high bit error rate in wireless channel, if a packet gets lost, the compressed header of next packet cannot be correctly decompressed. Then the decompressor must send the request for resynchronization and in the meanwhile discard all compressed header. A fatal result of this effect is that it prevents TCP Fast Retransmit algorithm [8] from being fired and always causes TCP retransmission timeout. This effect is shown in detail in [9]. IPHC proposes two simple mechanisms, the TWICE algorithm and the full header request mechanism, to reduce the errors due to the inconsistent contexts between the compressor and the decompressor. The TWICE algorithm assumes that only the Sequence Number field of TCP segments are changing during the connection and the deltas among consecutive packets are constant in most cases. However, these assumptions are not always true, especially when TCP Timestamp and SACK options are used. The full header request mechanism needs a feedback channel, which is unavailable in some circumstances. Even when the feedback channel is available, this mechanism still cannot perform well enough if the roundtrip time of this link is very long. Once a packet is corrupted on the noisy link, there are still several consecutive packets dropped due to the inconsistency between the compressor and the decompressor. This Internet draft describes a new header compression scheme (TAROC, or TCP-Aware RObust header Compression), which is more robust against packet loss and hence achieves better performance over wireless links. Liao, Zhang, Zhu, Zhang [Page 5] draft-ietf-rohc-tcp-taroc-03.txt 4. The concept and framework of TCP-Aware RObust Header compression This section first describes the concept of the TCP-aware robust header compression (TAROC) proposal and discusses how this concept leads to a better performance when used over unreliable links. The main idea of this proposal is the combination of the Window- based LSB encoding (W-LSB encoding) [10] and dynamically TCP congestion window tracking. A sliding window (VSW) is maintained on the compressor side. In W-LSB encoding, the compressor gets inconsistent with the decompressor only when the reference value on the decompressor side is out of this VSW. By keeping the sliding window large enough, the compressor rarely gets out of synchronization with the decompressor. However, the larger the sliding window is, the less the header compression gains. To shrink the window size, the compressor needs some form of feedback to get sufficient confidence that a certain value will not be used as a reference by the decompressor. Then the window can be advanced by removing that value and all other values older than it. Obviously, when a feedback channel is available, confidence can be achieved by proactive feedback in the form of ACKs from the decompressor. A feedback channel, however, is unavailable or expensive in some environments. In this Internet draft, a mechanism based on dynamically tracking TCP congestion window is proposed to explore such feedbacks from the nature feedback-loop of TCP protocol itself. Since TCP is a window-based protocol, a new segment cannot be transmitted without getting the acknowledgment of segment in the previous window. Upon receiving the new segment, the compressor can get enough confidence that the decompressor has received the segment in the previous window and then shrink the sliding window by removing all the values older than that segment. As originally outlined in [11] and specified in [12], TCP is incorporated with four congestion control algorithms: slow-start, congestion-avoidance, fast retransmit, and fast recovery. The effective window of TCP is mainly controlled by the congestion window and may change during the entire connection life. TAROC designs a mechanism to track the dynamics of TCP congestion window, and control the sliding window of W-LSB encoding by the estimated congestion window. By combining the W-LSB encoding and TCP congestion window tracking, TAROC can achieve better performance over high bit-error-rate links. Note that in one-way TCP traffic, only the information about sequence number or acknowledgment is available for tracking TCP congestion window. TAROC does not require that all one-way TCP traffics must cross the same compressor. The detail will be described in the following sections. The topology assumption of TAROC is the same as the one in VJHC. Liao, Zhang, Zhu, Zhang [Page 6] draft-ietf-rohc-tcp-taroc-03.txt In the rest of this section, the header compression framework is described. The TAROC scheme achieves its compression gain by establishing state information at both ends of the link, i.e., at the compressor and at the decompressor. Header compression with TAROC can be characterized as an interaction between two state machines, one compressor machine and one decompressor machine, each instantiated once per context. 4.1. Compressor states There are three compressor states in TAROC: Initialization and Refresh (IR) state, First Order (FO), and Second Order (SO) states. The compressor starts in the lowest compression state (IR) and transits gradually to the higher compression state. The compressor will always operate in the highest possible compression state, under the constraint that the compressor is sufficiently confident that the decompressor has the information necessary to decompress a header, which is compressed according to the state. +----------+ | | +----------+ | FO State | +----------+ | | <--------> | | <--------> | | | IR State | +----------+ | SO State | | | <----------------------------------> | | +----------+ +----------+ 4.1.1. Initialization and Refresh (IR) state The purpose of IR state is to initialize or refresh the static parts of the context at the decompressor. In this state, the compressor sends full header periodically with an exponentially increasing period, which is so-called compression slow-start [3]. The compressor leaves the IR state only when it is confident that the decompressor has correctly received the static information. To compress short-lived TCP transfers more efficiently, the compressor should speed up the initial process. The compressor enters the IR state when it receives the packet with SYN bit set and sends IR packet. When it receives the first data packet of the transfer, it should transit to FO state because that means the decompressor has received the packet with SYN bit set and established the context successfully at its side. Using this mechanism can significantly reduce the number of context initiation headers. 4.1.2. First Order (FO) State Liao, Zhang, Zhu, Zhang [Page 7] draft-ietf-rohc-tcp-taroc-03.txt The purpose of FO state is to efficiently transmit the difference between the two consecutive packets in the TCP stream. When operating in this state, the compressor and the decompressor should have the same context. Only compressed packet is transmitted from the compressor to the decompressor in this state. The compressor transits back to IR state only when it finds that the context of decompressor may be inconsistent, or there are remarkable changes in the TCP/IP header. 4.1.3. Second Order (SO) State The purpose of SO state is to efficiently transmit the fixed-payload data. The compressor enters this state when it is sufficiently confident that the decompressor has got the constant payload size of the data transferring. The compressor leaves this state and transits to the FO state when the current payload size no longer conforms to the constant payload. The compressor transits back to IR state only when it finds that the context of decompressor may be inconsistent, or there are remarkable changes in the TCP/IP header. 4.2. Decompressor states The decompressor starts in its lowest compression state, "No Context" and gradually transits to higher state, "Full Context". The decompressor state machine normally never leaves the "Full Context" state once it has entered this state. +--------------+ +--------------+ | No Context | <---> | Full Context | +--------------+ +--------------+ 5. Window-based LSB encoding and fixed-payload encoding Since the changing patterns of several TCP fields (for example, Sequence Number, Acknowledgement Number, Window, etc.) is completely different from the ones of RTP, and are very hard to predict, thus, it is hard to encode these fields in k-LSB both efficiently and robustly. On the other hand, Window-based LSB encoding, which does not assume the linear changing pattern of the header fields, is more suitable to encode those TCP fields both efficiently and robustly. The Window-based LSB encoding (W-LSB encoding) used in TAROC is a slightly modified version of [10] (Appendix A). The major modifications can be summarized as follows: - For reference selection, the decompressor always choose the one which is the last received non-retransmission value or uncompressed value that had passed the TCP checksum successfully. Liao, Zhang, Zhu, Zhang [Page 8] draft-ietf-rohc-tcp-taroc-03.txt - After sending a value v (compressed or uncompressed), the compressor always adds v into the VSW since each TCP segment is protected by the TCP checksum. The W-LSB encoding will be applied to several fields, such as IP-ID, Sequence Number, Acknowledgment Number, Window fields, TCP Timestamp option, etc. For some applications, such as bulk data transferring, etc., the payload size of each packet is usually a constant value, e.g. 1460 bytes. In such a case, the sequence number and acknowledgment number can be represented as the following equation: SEQ (or ACK) = m * MTU + n. If all the packets in VSW have the same 'n', only 'm' need be transmitted to the decompressor. The decompressor can obtain the sequence number or acknowledgment number after correctly decoding 'm', and use them as the reference values. This encoding method is called fixed-payload encoding. 6. TCP congestion window tracking 6.1. General principle of congestion window tracking The general principle of congestion window tracking is as follows. The compressor imitates the congestion control behavior of TCP upon receiving each segment, in the meantime, estimates the congestion window (cwnd) and the slow start threshold (ssthresh). Besides the requirement of accuracy, there are also some other requirements for the congestion window tracking algorithms: - Simplex link. The tracking algorithm SHOULD always only take Sequence Number or Acknowledgment Number of a one-way TCP traffic into consideration. It SHOULD NOT use Sequence Number and Acknowledgment Number of that traffic simultaneously. - Misordering resilience. The tracking algorithm SHOULD work well while receiving misordered segments. - Multiple-links. The tracking algorithm SHOULD work well when not all the one-way TCP traffics are crossing the same link. - Slightly overestimation. If the tracking algorithm cannot guarantee the accuracy of the estimated cwnd and ssthresh, it is RECOMMANDED that it produces a slightly overestimated one. The following sections will describe two congestion window tracking algorithms, which use Sequence Number and Acknowledgment Number of a one-way TCP traffic, respectively. 6.2. Congestion window tracking based on Sequence Number Liao, Zhang, Zhu, Zhang [Page 9] draft-ietf-rohc-tcp-taroc-03.txt This algorithm (Algorithm SEQ) contains 3 states: SLOW-START, CONGESTION-AVOIDANCE, and FAST-RECOVERY, which are equivalent to the states in TCP congestion control algorithms. It maintains 2 variables: cwnd and ssthresh. +-------------+ | | ---------------->| CONGESTION- | | | AVOIDANCE | | ----| |<--- +------------+ | +-------------+ | | | | | | SLOW-START | | | | | | +-------------+ | +------------+ | | | | | |-->| FAST- |---- | | RECOVERY | ---------------->| | +-------------+ Initially, this algorithm starts in state SLOW-START with ssthresh set to ISSTHRESH and cwnd set to IW. Upon receiving a segment, if it is the first segment, which is not necessary to be the SYN segment, the algorithm sets the current maximum Sequence Number (CMAXSN) and the current minimum Sequence Number (CMINSN) to this segment's sequence number; otherwise, the algorithm takes a procedure according to the current state. - SLOW-START * If the new Sequence Number (NSN) is larger than CMAXSN, increase cwnd by the distance between NSN and CMAXSN, and update CMAXSN and CMINSN based on the following rules: CMAXSN = NSN if (CMAXSN - CMINSN) > cwnd) CMINSN = cwnd - CMAXSN; If the cwnd is larger than ssthresh, the algorithm transits to CONGESTION-AVOIDANCE state; * If the distance between NSN and CMAXSN is less than or equal to 3*MSS, ignore it; * If the distance is larger than 3*MSS, halve the cwnd and set ssthresh to MAX(cwnd, 2*MSS). After that, the algorithm transits into FAST-RECOVERY state. - CONGESTION-AVOIDANCE Liao, Zhang, Zhu, Zhang [Page 10] draft-ietf-rohc-tcp-taroc-03.txt * If NSN is larger than CMAXSN, increase cwnd by ((NSN- CMAXSN)*MSS)/cwnd and then update CMAXSN and CMINSN based on the following rules: CMAXSN = NSN if (CMAXSN - CMINSN) > cwnd) CMINSN = cwnd - CMAXSN; * If the distance between NSN and CMAXSN is less than or equal to 3*MSS, ignore it; * If the distance is larger than 3*MSS, halve the cwnd and set ssthresh to MAX(cwnd, 2*MSS). After that, the algorithm transits into FAST-RECOVERY state. - FAST-RECOVERY * If NSN is larger than or equal to CMAXSN + cwnd, the algorithm transits into CONGESTION-AVOIDANCE state; * Otherwise, ignore it. In this algorithm, MSS is denoted as the estimated maximum segment size. The implementation can use the MTU of the link as an approximation of this value. ISSHRESH and IW are the initial values of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily high. IW SHOULD be set to 4*MSS. 6.3. Congestion window tracking based on Acknowledgment Number +-------------+ | | ---------------->| CONGESTION- | | | AVOIDANCE | | ----| |<--- +------------+ | +-------------+ | | | | | | SLOW-START | | | | | | +-------------+ | +------------+ | | | | | |-->| FAST- |---- | | RECOVERY | ---------------->| | +-------------+ This algorithm (Algorithm ACK) maintains 3 states: SLOW-START, CONGESTION-AVOIDANCE and FAST-RECOVERY, which are equivalent to the states in TCP congestion control algorithms. It also maintains 2 variables: cwnd and ssthresh. Initially, this algorithm starts in state SLOW-START with ssthresh set to ISSTHRESH and cwnd set to IW. Liao, Zhang, Zhu, Zhang [Page 11] draft-ietf-rohc-tcp-taroc-03.txt Upon receiving a segment, if it is the first segment, which is not necessary to be the SYN segment, the algorithm sets the current maximum Acknowledgment Number (CMAXACK) to this segment's acknowledgment number; otherwise, the algorithm takes a procedure according to the current state. - SLOW-START * If the new Acknowledgment Number (NEWACK) is larger than CMAXACK, increase cwnd by the distance between NEWACK and CMAXACK, set duplicate ack counter (NDUPACKS) to 0, and update CMAXACK accordingly; If the cwnd is larger than ssthresh, the algorithm transits to CONGESTION-AVOIDANCE state; * If NEWACK is equal to CMAXACK, increase the NDUPACKS by 1. If NDUPACKS is greater than 3, halve the cwnd and set ssthresh to MAX(cwnd, 2*MSS). Consequently, the algorithm transits into FAST-RECOVERY state; * Otherwise, set NDUPACKS to 0. - CONGESTION-AVOIDANCE * If NEWACK is larger than CMAXACK, increase cwnd by ((NEWACK- CMAXACK)*MSS)/cwnd, set NDUPACKS to 0 and update CMAXACK accordingly; * If NEWACK is equal to CMAXACK, increase NDUPACKS by 1. If NDUPACKS is greater than 3, halve the cwnd and set ssthresh to MAX(cwnd, 2*MSS). After that, the algorithm transits into FAST-RECOVERY state; * Otherwise, set NDUPACKS to 0. - FAST-RECOVERY * If NEWACK is larger than CMAXACK, set NDUPACKS to 0. Consequently, the algorithm transits into CONGESTION-AVOID state; * Otherwise, ignore it. In this algorithm, MSS is denoted as the estimated maximum segment size. The implementation can use the MTU of the link as an approximation of this value. ISSHRESH and IW are the initial values of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily high. IW SHOULD be set to 4*MSS. 6.4. Further discussion on congestion window tracking Liao, Zhang, Zhu, Zhang [Page 12] draft-ietf-rohc-tcp-taroc-03.txt In some cases, it is inevitable for the tracking algorithms to overestimate the TCP congestion window. Also, it SHOULD be avoided that the estimated congestion window gets significantly smaller that the actual one. For all of these cases, TAROC simply applies two boundaries on the estimated congestion window size. One of the two boundaries is the MIN boundary, which is the minimum congestion window size and whose value is determined according to the [18]; the other boundary is the MAX boundary, which is the maximum congestion window size. There are two possible approaches to setting this MAX boundary. One is to select a commonly used maximum TCP socket buffer size. The other one is to use the simple equation W=sqrt(8/3*l), where W is the maximum window size and l is the typical packet loss rate. If ECN mechanism is deployed, according to [13] and [14], the TCP sender will set the CWR (Congestion Window Reduced) flag in the TCP header of the first new data packet sent after the window reduction, and the TCP receiver will reset the ECN-Echo flag back to 0 after receiving a packet with CWR flag set. Thus, the CWR flag and the ECN-Echo flag's transition from 1 to 0 can be used as another indication of congestion combined with other mechanisms mentioned in the tracking algorithm. 7. Protocol definition 7.1. Compressed packet formats 7.1.1. Packet types Following the requirement of TCP/IP header compression [15], TAROC should fit into the ROHC framework. Thus, TAROC will conform to the general format and the reserved packet types defined in [10]. A TAROC packet has the following general format: --- --- --- --- --- --- --- --- : Padding : variable length --- --- --- --- --- --- --- --- : Feedback : 0 or more feedback elements --- --- --- --- --- --- --- --- : Header : variable, with CID information --- --- --- --- --- --- --- --- : Payload : --- --- --- --- --- --- --- --- As stated in [10], all Header packet types have the following format: 0 x-1 x 7 --- --- --- --- --- --- --- --- : Add-CID octet : if (CID 1-15) and (small CIDs) +---+--- --- --- ---+--- --- ---+ | type indication | body | 1 octet (8-x bits of body) +---+--- ---+---+---+--- --- ---+ Liao, Zhang, Zhu, Zhang [Page 13] draft-ietf-rohc-tcp-taroc-03.txt : : / 0, 1, or 2 octets of CID / 1 or 2 octets if (large CIDs) : : +---+---+---+---+---+---+---+---+ / body / variable length +---+---+---+---+---+---+---+---+ The following packet types are reserved at the framework level in the ROHC scheme: 1110: Padding or Add-CID octet 11110: Feedback 11111000: IR-DYN packet 1111110: IR packet 1111111: Segment Other header packet types defined for TCP/IP compression will be discussed in the following. The following notation is introduced as [10]: bits(X) = the number of bits for field X present in the compressed header (including extension). value(X) = field(X) if X is present in the compressed header; = context(X) otherwise. 7.1.2. Feedback Feedback carries information from the decompressor to the compressor. TAROC adopts the following types of feedback defined in ROHC framework. ACK : Acknowledges successful decompression of a packet, which means that the context is up-to-date with a high probability. NACK : Indicates that the dynamic context of the decompressor is out of sync. Generated when several successive packets have failed to be decompressed correctly. TAROC adopts FEEDBACK-2 format in ROHC framework and defines profile-specific feedback information in order to identify the latest packet that the decompressor has decompressed successfully. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ |Acktype| Mode | | C | +---+---+-------+---+---+---+---+ : IP-ID : 2 octets if inner IP is IPv4 Liao, Zhang, Zhu, Zhang [Page 14] draft-ietf-rohc-tcp-taroc-03.txt +---+---+---+---+---+---+---+---+ : SEQ : +---+---+---+---+---+---+---+---+ 8 octets if inner IP is IPv6 : ACK : +---+---+---+---+---+---+---+---+ : CRC : 1 octet if C = 1 +---+---+---+---+---+---+---+---+ Acktype: 0 = ACK 1 = NACK 2 = STATIC-NACK (does not used in TAROC) 3 is reserved Mode: 0 is reserved 1 = Unidirectional mode 2 = Bidirectional Optimistic mode 3 = Bidirectional Reliable mode 7.1.3. IR packet The static part and dynamic part for TCP header are listed as follows. Static Part: +---+---+---+---+---+---+---+---+ / source port / 2 octets +---+---+---+---+---+---+---+---+ / destination port / 2 octets +---+---+---+---+---+---+---+---+ Dynamic Part: +---+---+---+---+---+---+---+---+ / sequence number / 4 octets +---+---+---+---+---+---+---+---+ / acknowledgment number / 4 octets +---+---+---+---+---+---+---+---+ | Header Length | Reserved | +---+---+---+---+---+---+---+---+ | Res. |URG|ACK|PSH|RST|SYN|FIN| +---+---+---+---+---+---+---+---+ / advertised window / 2 octets +---+---+---+---+---+---+---+---+ / TCP checksum / 2 octets +---+---+---+---+---+---+---+---+ : Urgent pointer : if U = 1 +---+---+---+---+---+---+---+---+ : Encoded TCP options : +---+---+---+---+---+---+---+---+ The static part and dynamic part for IP header are the same as the one defined in [10]. Liao, Zhang, Zhu, Zhang [Page 15] draft-ietf-rohc-tcp-taroc-03.txt 7.1.4. IR-DYN packet The dynamic part of IR-DYN packet is the same as the one of IR packet. 7.1.5. TCP/IPv4 format If the inner IP header is IPv4, the TCP/IP header should be compressed as described in this section. 7.1.5.1. Packet type: (IP-ID+SEQ) 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | IP-ID + SEQ | +===+===+===+===+===+===+===+===+ / IP-ID + SEQ / variable (byte alignment) +---+---+---+---+---+---+---+---+ | | + TCP Checksum + | | +---+---+---+---+---+---+---+---+ Note: IP-ID+SEQ packet type SHOULD be used if only the compressed sequence number field and IP-ID field need to transmit. 7.1.5.2. Packet type: (IP-ID+ACK) 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 0 | 0 | IP-ID + ACK | +===+===+===+===+===+===+===+===+ / IP-ID + ACK / variable (byte alignment) +---+---+---+---+---+---+---+---+ | | + TCP Checksum + | | +---+---+---+---+---+---+---+---+ Note: IP-ID+ACK packet type SHOULD be used if only the compressed acknowledgment number field and IP-ID field need to transmit. 7.1.5.3. Packet type: (IP-ID+SEQ+PUSH) 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 0 | 1 | IP-ID + SEQ | +===+===+===+===+===+===+===+===+ / IP-ID + SEQ / variable (byte alignment) +---+---+---+---+---+---+---+---+ | | + TCP Checksum + | | Liao, Zhang, Zhu, Zhang [Page 16] draft-ietf-rohc-tcp-taroc-03.txt +---+---+---+---+---+---+---+---+ Note: IP-ID+SEQ+PUSH packet type SHOULD be used if only the compressed sequence number field and IP-ID field need to transmit while the PUSH flag is present. 7.1.5.4. Packet type: (FLAG including extension bit) 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 0 | S | A | W | P | X | +===+===+===+===+===+===+===+===+ / IP-ID + SEQ + ACK + WND / variable (byte alignment) +---+---+---+---+---+---+---+---+ / Extension / variable +---+---+---+---+---+---+---+---+ | | + TCP Checksum + | | +---+---+---+---+---+---+---+---+ S: S=1 indicates SEQ is present A: A=1 indicates ACK is present W: W=1 indicates WND is present P: P=1 indicates PUSH is present X: X=1 indicates extension is present 7.1.6. TCP/IPv6 format If the inner IP header is IPv6, the TCP/IP header should be compressed as described in this section. 7.1.6.1. Packet type: (SEQ) 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | SEQ | +===+===+===+===+===+===+===+===+ / SEQ / variable (byte alignment) +---+---+---+---+---+---+---+---+ | | + TCP Checksum + | | +---+---+---+---+---+---+---+---+ Note: SEQ packet type SHOULD be used if only the compressed sequence number field needs to transmit. 7.1.6.2. Packet type: (ACK) 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 1 | ACK | Liao, Zhang, Zhu, Zhang [Page 17] draft-ietf-rohc-tcp-taroc-03.txt +===+===+===+===+===+===+===+===+ / ACK / variable (byte alignment) +---+---+---+---+---+---+---+---+ | | + TCP Checksum + | | +---+---+---+---+---+---+---+---+ Note: ACK packet type SHOULD be used if only the compressed acknowledgment number field needs to transmit. 7.1.6.3. Packet type: (SEQ+PUSH) 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 0 | SEQ | +===+===+===+===+===+===+===+===+ / SEQ / variable (byte alignment) +---+---+---+---+---+---+---+---+ | | + TCP Checksum + | | +---+---+---+---+---+---+---+---+ Note: SEQ packet type SHOULD be used if only the compressed sequence number field needs to transmit while the PUSH flag is present. 7.1.6.4. Packet type: (FLAG including extension bit) 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 0 | S | A | W | P | X | +===+===+===+===+===+===+===+===+ / SEQ + ACK + WND / variable (byte alignment) +---+---+---+---+---+---+---+---+ / Extension / variable (byte alignment) +---+---+---+---+---+---+---+---+ | | + TCP Checksum + | | +---+---+---+---+---+---+---+---+ S: S=1 indicates SEQ is present A: A=1 indicates ACK is present W: W=1 indicates WND is present P: P=1 indicates PUSH is present X: X=1 indicates extension is present 7.1.7. IP-ID formats This format is used only when the inner IP header is IPv4 and value(RND) equals to 0. Liao, Zhang, Zhu, Zhang [Page 18] draft-ietf-rohc-tcp-taroc-03.txt +---+---+---+---+---+---+---+ | 0 | IP-ID | SEQ | +---+---+---+---+---+---+---+ Note: This is a special format designed for IP-ID+SEQ packet type while the sequence number field changes as fixed-payload. +---+---+... ... ... ... | 1 | 0 | IP-ID | bits(IP-ID) = 4 +---+---+... ... ... ... +---+---+---+... ... ... ... | 1 | 1 | 0 | IP-ID | bits(IP-ID) = 6 +---+---+---+... ... ... ... +---+---+---+---+... ... ... ... | 1 | 1 | 1 | 0 | IP-ID | bits(IP-ID) = 9 +---+---+---+---+... ... ... ... +---+---+---+---+... ... ... ... | 1 | 1 | 1 | 1 | IP-ID | bits(IP-ID) = 16 +---+---+---+---+... ... ... ... 7.1.8. SEQ (ACK) formats +---+---+... ... ... ... | 0 | F | SEQ (ACK) | +---+---+... ... ... ... If F = 1, bits(SEQ) = 4 with fixed-payload; if F = 0, bits(SEQ) = 14 with variable payload. +---+---+---+... ... ... ... | 1 | 0 | F | SEQ (ACK) | +---+---+---+... ... ... ... If F = 1, bits(SEQ) = 6 with fixed-payload; if F = 0, bits(SEQ) = 16 with variable payload. +---+---+---+---+... ... ... ... | 1 | 1 | 0 | F | SEQ (ACK) | +---+---+---+---+... ... ... ... If F = 1, bits(SEQ) = 9 with fixed-payload; if F = 0, bits(SEQ) = 19 with variable payload. +---+---+---+---+... ... ... ... | 1 | 1 | 1 | 0 | SEQ (ACK) | +---+---+---+---+... ... ... ... bits(SEQ) = 12 with fixed-payload. Liao, Zhang, Zhu, Zhang [Page 19] draft-ietf-rohc-tcp-taroc-03.txt +---+---+---+---+---+... ... ... ... | 1 | 1 | 1 | 1 | 0 | SEQ (ACK) | +---+---+---+---+---+... ... ... ... bits(SEQ) = 22 with variable payload. +---+---+---+---+---+... ... ... ... | 1 | 1 | 1 | 1 | 1 | SEQ (ACK) | +---+---+---+---+---+... ... ... ... bits(SEQ) = 32 with variable payload. 7.1.9. WND formats +---+... ... ... | 0 | WND | bits(WND) = 4 +---+... ... ... +---+---+... ... ... | 1 | 0 | WND | bits(WND) = 6 +---+---+... ... ... +---+---+---+... ... ... | 1 | 1 | 0 | WND | bits(WND) = 9 +---+---+---+... ... ... +---+---+---+... ... ... | 1 | 1 | 1 | WND | bits(WND) = 12 +---+---+---+... ... ... 7.1.10. Extension format Note: the term extension as used for additional information contained in the ROHC headers does not bear any relationship to the term extension header used in IP. The general extension format is organized as follows. +---+---+---+---+---+---+---+---+ | | / extra TCP information / | | +---+---+---+---+---+---+---+---+ | | / extra inner IP information / | | +---+---+---+---+---+---+---+---+ | | / extra outer IP information / | | +---+---+---+---+---+---+---+---+ Liao, Zhang, Zhu, Zhang [Page 20] draft-ietf-rohc-tcp-taroc-03.txt Extra TCP information includes FIN, URG, ECN & reserved flags, and TCP options. Extra IP information includes TOS, TTL, DF, PR, IPX, NBO, RND and IP options. The extension format is defined as follows. +----+----+----+----+----+----+----+----+ | FIN| URG| RC | O | ECN bits | IP | +----+----+----+----+----+----+----+----+ | TOS| TTL|_DF |_PR |IPX | NBO| RND| IP2| if IP = 1 +....+....+....+....+....+....+....+....+ |TOS2|TTL2|_DF2|_PR2|IPX2|NBO2|RND2| I2 | if IP2 = 1 +....+....+....+....+....+....+....+....+ / Urgent Pointer / if URG = 1 +....+....+....+....+....+....+....+....+ / R | CRC| TCP Reserved bits (r) / if R=1 and ECT is 1, r = 4, +....+....+....+....+....+....+....+....+ otherwise if R=1, r = 6 / NC | CRC code (c) / if CRC=1, c = 3 if NC = 0 +....+....+....+....+....+....+....+....+ and c = 7 if NC = 1 | | / TCP options / variable, if O = 1 | | +....+....+....+....+....+....+....+....+ | | / Inner IP header fields / variable, if IP = 1 | | +....+....+....+....+....+....+....+....+ | | / Outer IP header fields / variable, if IP2 = 1 | | +....+....+....+....+....+....+....+....+ The decompressor only interprets ECN bits when ECT bit in the context is 1. The format of ECN bits is defined as follows. +---+---+---+ | CE|CWR|ECE| +---+---+---+ The inner and outer IP header fields are encoded as described in the ROHC framework [10]. 7.1.10.1. Encoded TCP options TCP options are encoded one by one in the format defined in this section and concentrated in the original order in the TCP header. For each TCP option, it will be encoded as the following format: +---+---+---+... ... ... | OPT | VAL | +---+---+---+... ... ... Liao, Zhang, Zhu, Zhang [Page 21] draft-ietf-rohc-tcp-taroc-03.txt OPT: 000 EOL, End of options, no VAL field; 001 NOP, No operation option, no VAL field; 010 MSS, Maximum Segment Size, the VAL field is the MSS; 011 WINDOW, Window Scale, the VAL field is the scale factor; 100 SACK_PERMIT, Sack-Permitted option, no VAL field; 101 SACK, Sack option, the VAL field is described in section 7.1.10.2 110 TIMESTAMP, Timestamp option, the VAL field is described in section 7.1.10.3 111 other TCP options, the VAL field is the corresponding TCP option 7.1.10.2. Sack The format of compressed SACK option is defined as follows. +---+---+... ... ... | SA |SACK Blocks| +---+---+... ... ... SA: the number of SACK blocks SA == 00 1 SACK block SA == 01 2 SACK blocks SA == 10 3 SACK blocks SA == 11 4 SACK blocks The format of each SACK block is defined as follows. +-+-+-+-+-+-+-+-+ | Offset | - - - - - - - - | Size | - - - - - - - - The Offset field in SACK block is delta encoded, as defined in VJHC, from Left Edge of this SACK Block to the Acknowledgment Number in TCP header. The Size field in SACK is delta encoded from Right Edge to Left Edge of this SACK block. 7.1.10.3. Timestamp The format of compressed Timestamp option is defined as follows. +----+... ... ... ... ... ... | TE | TS Value | TS Echo | +----+... ... ... ... ... ... TE: if TE = 1, TS Echo is present, otherwise, there is no TS Echo. Liao, Zhang, Zhu, Zhang [Page 22] draft-ietf-rohc-tcp-taroc-03.txt Both TS Value and TS Echo are encoded using the W-LSB, the format is defined as follows. 0 7 +-+-+-+-+-+-+-+-+ |0| TS value | +-+-+-+-+-+-+-+-+ 0 7 +-+-+-+-+-+-+-+-+ |1|0| | +-+-+TS value + | | +-+-+-+-+-+-+-+-+ 0 7 +-+-+-+-+-+-+-+-+ |1|1|0| | +-+-+-+ + | TS value | + + | | +-+-+-+-+-+-+-+-+ 0 7 +-+-+-+-+-+-+-+-+ |1|1|1| | +-+-+-+ + | | + + | TS value | + + | | + +-+-+-+-+-+ | | +-+-+-+ 7.1.10.4. CRC All types of packets in TAROC have CRC option. The format and computation for these CRC options are the same as the one defined in [10]. 7.2. Compressor logic In TAROC, the compressor will start in the IR state and perform different logics in different states. The following sub-sections will describe the logic for each compressor sate in detail. 7.2.1. IR state Liao, Zhang, Zhu, Zhang [Page 23] draft-ietf-rohc-tcp-taroc-03.txt The operations of compressor in IR state can be summarized as follows: a) Upon receiving a packet, the compressor sends IR or IR-DYN packet on the following conditions: 1) if it is the turn to send full header packet according to compression slow-start, i.e. after sending F_PERIOD compressed packets; 2) if the packet to be sent is a retransmission of the packet in VSW and it was sent as IR or IR-DYN packet previously. Otherwise, the compressor compresses the packet using W-LSB encoding. If the compressor enters the IR state for the first time or the static part of the TCP flow has changed, it will send IR packet. Otherwise, it will send IR-DYN packet because the decompressor has known the static part. b) The packet is added into VSW as a potential reference after it has been sent out. The compressor then invokes the Algorithm SEQ and Algorithm ACK to track the congestion windows of the two one- way traffics with different directions in a TCP connection. Suppose that the estimated congestion windows are cwnd_seq and cwnd_ack, while the estimated slow start thresholds are ssthresh_seq and ssthresh_ack, respectively. Let W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack) = K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack, 2*ssthresh_ack)). If the size of VSW is larger than W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack), the VSW can be shrunk. K is an implementation parameter that will be further discussed in Section 8. c) After sending F_PERIOD compressed packets, F_PERIOD SHOULD be doubled. If it gets larger than W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack), the compressor transits to FO or SO state. If the compressor finds that the payload size of consecutive packets is a constant value and one of such packets is removed from the VSW, which means the decompressor has known the exact value of the constant size, it may transit to SO state. Otherwise it will transit to the FO state. 7.2.2. FO state The operations of the compressor in the FO state can be summarized as follows: a) Upon receiving a packet, if it falls behind the VSW, i.e. it is older than all the packets in VSW; the compressor transits to IR state. Otherwise, the compressor compresses it using W-LSB encoding and sends it. b) The packet is added into VSW as a potential reference after it has been sent out. The compressor then invokes the Algorithm SEQ and Algorithm ACK to track the congestion windows of the two one-way traffics with different directions in a TCP connection. Suppose that the estimated congestion windows are cwnd_seq and cwnd_ack, while the estimated slow start thresholds are ssthresh_seq and ssthresh_ack, respectively. Let W(cwnd_seq, ssthresh_seq, cwnd_ack, Liao, Zhang, Zhu, Zhang [Page 24] draft-ietf-rohc-tcp-taroc-03.txt ssthresh_ack) = K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack, 2*ssthresh_ack)). If the size of VSW is larger than W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack), the VSW can be shrunk. K is also an implementation parameter, which can be set to the same value as in the IR state. c) If the VSW contains only one packet, which means there is a long jump in the packet sequence number or acknowledge number, the compressor will transit to the IR state and re-initialize the algorithm for tracking TCP congestion window. Here, a segment causes a long jump when the distance between its sequence number (or acknowledgment number) and CMAXSN (or CMAXACK) is larger than the estimated congestion window size, i.e., |sequence number (acknowledgement number) û CMAXSN (CMAXACK)| > estimated congestion window size. d) If the compressor finds that the payload size of consecutive packets is a constant value and one of such packets has been removed from the VSW, which means the decompressor has known the exact value of the constant size, it may transit to the SO state. e) If the static context of transfers changed, the compressor will transit to the IR state and re-initialize the algorithms for tracking TCP congestion window. 7.2.3. SO state The operations of the compressor in the SO state can be summarized as follows: a) Upon receiving a packet, if it falls behind the VSW, i.e. it is older than all the packets in VSW; the compressor transits to IR state. Otherwise, the compressor compresses it using fixed-payload encoding and sends it. b) The packet is added into VSW as a potential reference after it has been sent out. The compressor then invokes the Algorithm SEQ and Algorithm ACK to track the congestion windows of the two one-way traffics with different directions in a TCP connection. Suppose that the estimated congestion windows are cwnd_seq and cwnd_ack, while the estimated slow start thresholds are ssthresh_seq and ssthresh_ack, respectively. Let W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack) = K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack, 2*ssthresh_ack)). If the size of VSW is larger than W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack), the VSW can be shrunk. K is an implementation parameter, which can be set to the same value as in the IR state. c) If the VSW contains only one packet, which means there is a long jump in the packet sequence number or acknowledge number, the compressor will transit to the IR state and re-initialize the algorithms for tracking TCP congestion window. Liao, Zhang, Zhu, Zhang [Page 25] draft-ietf-rohc-tcp-taroc-03.txt d) If the payload size of the packets in VSW doesn't keep constant, the compressor transits to the FO state. e) If the static context of transfers changed, the compressor will transit to the IR state and re-initialize the algorithms for tracking TCP congestion window. 7.3. Decompressor logic The logic of the decompressor is simpler compared to the compressor. 7.3.1. No Context State The decompressor starts in this state. Upon receiving an IR or IR- DYN packet, the decompressor should verify the correctness of its header by TCP checksum. If the verification succeeds, the decompressor will update the context and use this packet as the reference packet. After that, the decompressor will pass it to the system's network layer and transit to Full Context State. Conformed to ROHC framework [10], only IR or IR-DYN packets may be decompressed in No Context state. 7.3.2. Full Context State The operations of decompressor in Full Context state can be summarized as follows: a) Upon receiving an IR or IR-DYN packet, the decompressor should verify the correctness of its header by TCP checksum. If the verification succeeds, the decompressor will update the context and use this packet as the reference packet. Consequently, the decompressor will convert the packet into the original packet and pass it to the network layer of the system. b) Upon receiving the other type of packet, the decompressor will decompress it. After that, the decompressor MUST verify the correctness of the decompressed packet by the TCP checksum. If the verification succeeds, the decompressor passes it to the system's network layer. Then the decompressor will use it as the reference value if this packet is not older than the current reference packet. c) If consequent N packets fail to be decompressed, the decompressor should transit downwards to No Context State. N is an implementation parameter that will be further discussed in Section 8. 7.4. Modes of operation There are three modes in ROHC framework, called Unidirectional, Bi- directional Optimistic, and Bi-directional Reliable mode, Liao, Zhang, Zhu, Zhang [Page 26] draft-ietf-rohc-tcp-taroc-03.txt respectively. The mode transitions are conformed to ROHC framework. However, the operations of each mode are different. 7.4.1. Unidirectional mode -- U-mode When in U-mode, packets are sent in one direction only: from compressor to decompressor. Therefore, feedbacks from decompressor to the compressor are unavailable under this mode. In the U-mode, the compressor and decompressor logic is the same as the discussion in section 7.2 and 7.3. 7.4.2. Bi-directional Optimistic mode -- O-mode When in O-mode, a feedback channel is used to send error recovery requests and (optionally) acknowledgments of significant context updates from the decompressor to the compressor. In this mode, the VSW will be shrunk more efficiently. 7.4.2.1. Compressor states and logic (O-mode) Following rules should be combined with the action defined in section 7.2. In the IR state, the compressor can transit to the FO or SO state once it receives a valid ACK(O) for an IR packet sent (an ACK(O) can only be valid if it refers to a packet sent earlier). If the packet referred by the feedback is in the VSW, the compressor will remove the packets older than the referred packet from the VSW window. Because ACK(O) means that the packet referred by ACK(O) has been the reference of the decompressor, the compressor doesn't need to keep older packets. If the compressor is in the FO or SO state, it will remove the packets older than the referred packet from the VSW window. Upon receiving an NACK(O), the compressor transits back to IR state. 7.4.2.2. Decompressor states and logic (O-mode) The decompression states and the state transition logic are the same as in the Unidirectional case (see section 7.4.1.). What differs is the feedback logic. Below, rules are defined stating which feedback to use when. When an IR packet passes the verification, send an ACK(O). When an IR-DYN packet or other packet is correctly decompressed, optionally send an ACK(O). When any packet fails the verification, send an NACK(O). 7.4.3. Bi-directional Reliable mode -- R-mode Liao, Zhang, Zhu, Zhang [Page 27] draft-ietf-rohc-tcp-taroc-03.txt The R-mode are a more intensive usage of the feedback channel and a stricter logic at both the compressor and the decompressor that prevents loss of context synchronization between the compressor and decompressor except for very high residual bit error rates. Feedback is sent to acknowledge all context updates. In this mode, the VSW will be shrunk with the highest efficiency. 7.4.3.1. Compressor states and logic (R-mode) Following rules should be reparation to the action defined in section 7.2. In IR state, the compressor should transit to the FO or SO state only when it receives a valid ACK(R) for an IR or IR-DYN packet sent (an ACK(R) can only be valid if it refers to an packet sent earlier). If the packet referred by the feedback is in the VSW, the compressor will remove the packets older than the referred packet from the VSW window. Because ACK(R) means that the packet referred by ACK(R) has been the reference of the decompressor; the compressor doesn't need to keep older packets. If the compressor is in the FO or SO state, when it receives a valid ACK(R), it will remove the packets older than the referred packet from the VSW window. In this mode, the compressor need not use window tracking, because feedback can shrink VSW efficiently and robustly. Upon receiving an NACK(O), the compressor transits back to IR state. 7.4.3.2. Decompressor states and logic (R-mode) Below, rules are defined stating which feedback to use when. . When a packet is correctly decompressed and updates the context, send an ACK(R). . When any packet fails the verification, send a NACK(R). The frequency of updating context will be discussed in section 8. 8. Implementation issues 8.1. Determine the value K As mentioned in section 7.1, the VSW SHOULD be shrunk when its size gets larger than K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack, 2*ssthresh_ack)). Since the Fast Recovery algorithm was introduced in TCP, several TCP variants had been proposed, which are different only in the behaviors of Fast Recovery. Some of them need several Liao, Zhang, Zhu, Zhang [Page 28] draft-ietf-rohc-tcp-taroc-03.txt RTTs to be recovered from multiple losses in a window. Ideally, they may send L*W/2 packets in this stage, where L is the number of lost packets and W is the size of the congestion window where error occurs. Some recent work [16] on improving TCP performance allows to transmit packets even when receiving duplicate acknowledgments. Due to the above concerns, it'd better keep K large enough so as to prevent shrinking VSW without enough confidence that corresponding packets had been successfully received. Considering the bandwidth-limited environments and the limited receiver buffer, a practical range of K is around 1~2. From the simulation results, K=1 is good enough for most cases. 8.2. Determine the value N We should distinguish out of synchronization from the packet errors cause by the link. So considering the error condition of the link, N should be higher than the packet burst error length, a practical range of N is around 8~10. 8.3. Determine the frequency of updating context The choice of the frequency of updating context, ACK(R), is a balance between the efficiency and robustness, i.e. sending ACK(R) more frequently improves the compression robustness but adds more system overhead, and the vice versa. From a practical view, the ACK(R) SHOULD be sent for every 4~8 successfully decompressed packets. 9. Conclusions Based on the requirements proposed in [17] and [15], a robust header compression scheme should be of transparency, ubiquity, and efficiency. It must be able to support both IPv4 and Ipv6 packet and tolerate error propagation. Different types of link delay and the misordering of packets should be addressed. In addition, multiple links and unidirectional link should be supported in the proposed header compression scheme. Particularly for TCP/IP, the header compression scheme should compress TCP SACK and Timestamp options. From the above analysis, it can be seen that all these requirements can be satisfied in our proposed TAROC. Considering the behavior of TCP protocol itself, even the packets misordering occurs between the compressor and the decompressor, a good performance can still be achieved in TAROC. Note that in our scheme, we need to select a packet with correct checksum of the whole packet as a reference. In this way, it does Liao, Zhang, Zhu, Zhang [Page 29] draft-ietf-rohc-tcp-taroc-03.txt not require link layer to treat the header and payload of the packet separately. Simulations results (Appendix B) demonstrate effectiveness of TAROC. 10. Acknowledgments When designing this protocol, earlier header compression ideas described in [2], [3] and [10] have been import sources of knowledge. 11. Security considerations Security issues are not considered in this memo. Liao, Zhang, Zhu, Zhang [Page 30] draft-ietf-rohc-tcp-taroc-03.txt 12. Authors' addresses HongBin Liao Email: hbl@msrchina.research.microsoft.com Qian Zhang Email: qianz@microsoft.com Wenwu Zhu Email: wwzhu@microsoft.com Ya-Qin Zhang Email: yzhang@microsoft.com Microsoft Research China Beijing Sigma Center No.49, Zhichun Road, Haidian District Beijing 100080, P.R.C. 13. References 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 V. Jacobson, "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990. 3 M. Degermark, B. Nordgren, and S. Pink, "IP Header Compression", RFC 2507, February 1999. 4 M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996. 5 S. Floyd, J. Mahdavi, M. Mathis, and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000. 6 V. Jacobson, R. Braden, and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8 V. Jacobson, "Fast Retransmit", Message to the end2end-interest mailing list, April 1990. 9 M. Degermark, M. Engan, B. Nordgren, and Stephen Pink, " Low-loss TCP/IP header compression for wireless networks ", In the Proceedings of MobiCom, 1996. 10 C. Bormann (ed.), et al., "RObust Header Compression (ROHC)", RFC 3095, July 2001. 11 V. Jacobson, "Congestion avoidance and control", In ACM SIGCOMM '88, 1988. Liao, Zhang, Zhu, Zhang [Page 31] draft-ietf-rohc-tcp-taroc-03.txt 12 M. Allman, V. Paxson, and W. R. Stevens, "TCP Congestion Control", RFC 2581, April 1999. 13 K. Ramakrishnan, S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999. 14 K. K. RamaKrishnan, Sally Floyd, D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", Internet Draft (work in progress), June, 2001. 15 L-E. Jonsson, "Requirements for ROHC IP/TCP header compression", Internet Draft (work in progress), June 20, 2001. 16 M. Allman, H. Balakrishnan, and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", Internet Draft (work in progress), August 2000. 17 M. Degermark, "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001. 18 M. Allman, S. Floyd, and C. Partridge, "Increasing TCP's Initial Window", Internet Draft (work in progress), May 2001. Liao, Zhang, Zhu, Zhang [Page 32] 14. Intellectual property considerations Microsoft is filing patent applications that might possibly have technical relation to this contribution. Appendix A - Window-based LSB encoding (W-LSB encoding) Basic concepts of W-LSB encoding are: * The decompressor uses one of the decompressed header values as a reference value, v_ref. The reference may be chosen by various means. One might select only headers whose correct reconstruction is verified by inclusion of a checksum with the compressed header ("secure" reference). * The compressor maintains a sliding window of the values (VSW), which may be chosen as a reference by the decompressor. It also maintains the maximum value (v_max) and the minimum value (v_min) of VSW. * When the compressor has to compress a value v, it calculates the range r = max(|v - v_max|, |v - v_min|). The value of k needed to be delivered is k = ceiling(log2(2 * r + 1)), i.e., the compressor sends the ceiling(log2(2 * r +1)) LSBs of v as the encoded value. * The compressor adds v into the VSW and updates the v_min and v_max if the value v could potentially be used as a reference by the decompressor. * The decompressor chooses the one as the decompressed value, which is closest to v_ref and whose k LSB equals the compressed value that has been received. It is obvious that we need to move forward (or shrink) the sliding window to prevent k from increasing too much. To do that, the compressor only needs to know which values in VSW have been received by the decompressor. The examples below illustrate the operation of W-LSB encoding under various scenarios. The field values used in the examples could correspond to any fields that we want to compress. The examples illustrate the scenario where the compressed field has resolution of one bit. Example 1: Normal operation (no packet loss prior to compressor, no reodering prior to compressor). Suppose packets with header fields 279, 280, 281, 282, and 283 have been sent, and 279 and 283 are fields of potential reference packets. Liao, Zhang, Zhu, Zhang [Page 33] draft-ietf-rohc-tcp-taroc-03.txt The current VSW window is {279, 283}. If a packet with field value = 284 is received next, W-LSB encoding computes the following values: New Value VMax VMin r # LSBs 284 283 279 max[|284-279|,|284-283|]=5 4 The window is unmodified if we assume the new packet {284} is not a potential reference. The field is encoded using 4 bits in this case, and the actual encoded value is the four least significant bits of 284 (10011100), which is equal to 1100. Example 2: Packet Loss prior to the compressor. Suppose packets with header fields 279, 280, 281, 282, and 283 have been sent, and 279 and 283 are fields of potential reference packets such that the VSW is {279, 283}. If a packet with field value = 290 is received next, VLE computes the following values. New Value VMax VMin r # LSBs 290 283 279 max[|290-283|,|290-279|]=11 5 So the field is encoded using 5 bits. Actual encoded value is the five LSBs of 290 (100100010), which is equal to 00010. If we assume the new value is a potential reference, the new VSW is {279, 283, 290}. Example 3: Packet Misordering prior to the compressor. Suppose packets with header fields 279, 280, 281, 282, and 283 have been sent, and 279 and 283 are fields of potential reference packets so that the VSW is {279, 283}. If a packet with field value = 278 is received next, VLE computes the following values. New Value VMax VMin r # LSBs 278 283 279 max[|278-283|,|278-279|]=5 4 So the field is encoded using 4 bits. Actual encoded value is the four LSBs of 278 (10010110), which is equal to 0110. If we assume the new value is a potential reference, the new VSW is {283, 290, 278}. The decompressor behavior in all the example cases is the same. It uses a specific decompressed header-field value as a reference. The Liao, Zhang, Zhu, Zhang [Page 34] draft-ietf-rohc-tcp-taroc-03.txt header to use might be indicated by the presence of a checksum in the compressed header packet, or by other means. It must by definition be one of the values in the compressor's window. For example let's assume that the last correctly decompressed packet, which qualifies as a reference, was the packet with header field equal to 291. Now suppose the encoded field value of 303 (10001111) is received, which is equal to 01111. The two closest values to 291, which have LSBs equal to 01111, are 271 and 303. 303 is closest, therefore, it is correctly selected as the uncompressed field value. Appendix B - Simulation results To study the performance of various TCP/IP header compression schemes, we have simulated VJHC, IPHC and TAROC schemes on NS-2 network simulator. B.1. Simulation topology +------------+ +--------+ +-------------+ | |------------>| |------------>| | | Fixed Host | 8Mb 100ms | Router |Wireless link| Mobile Host | | |<------------| |<------------| | +------------+ +--------+ +-------------+ In this scenario, a fixed host is connected to the router with a WAN link (8Mb, 100ms). The queue size on the router is 6. The communication channel between the mobile host and the router simulates the wireless link, which has a wide range of bandwidth from 384kb to 9.6kb and a delay of 100ms. The bit error rate (BER) on this wireless link is from 1e-7 to 1e-3. TCP traffic is conveyed from the fixed host to the mobile host. It is known that, in wireless link under a high bit-error-rate situation, a smaller MTU is better in terms of the increasing chance of successful transmission. So different MTUs are selected under different BER conditions in our simulation. B.2. Tested header compression schemes Five header compression schemes in our simulation: NONE This scheme refers to the situation when no header compression is employed on the wireless link. VJHC This scheme employs RFC1144 on the wireless link. It assumes that the compressed header size is 4. IPHC This scheme employs RFC2507 on the wireless link, but without TWICE algorithm. The characteristics of the feedback channel are the same as the forward wireless link. It assumes that the compressed header size is 5. Liao, Zhang, Zhu, Zhang [Page 35] draft-ietf-rohc-tcp-taroc-03.txt TAROC It refers to the scheme proposed in this Internet Draft. The compressed header size is determined by the scheme described in this draft. IDEAL This scheme simulates the situation where header compression does not introduce additional errors. It assumes that the compressed header size is 4, the same one as in the VJHC. B.3. Simulations and results Based upon these configurations, enormous simulations have been tested. The followings are the results of several TCP variants, Tahoe, Reno and Sack on the wireless link with wide range of bandwidth, BER and MTU. Wireless link characteristics: * Bandwidth: 384kb, 114kb, 64kb, 9.6kb * Delay: 100ms * BER: 1e-8, 3e-8, 1e-7, 3e-7, 1e-6, 3e-6, 1e-5, 3e-5, 1e-4, 3e-4 TCP Variants: Tahoe, Reno, Sack Header compression schemes: NONE, VJHC, IPHC, TAROC, IDEAL The following lists some of the results: 384kb for Tahoe, 114kb for Sack, 64kb for Reno, and 9.6kb for Sack. B.3.1. 384kb Tahoe +----+------+-----------+-----+------+------+-----+-----+ |BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-8|576 |Throughput |25470| 25457| 25179|25587|25603| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-0.05 |-1.14 |0.46 |0.52 | | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-8|576 |Throughput |25770| 25764| 25696|25819|25839| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | -0.02| -0.29| 0.19|0.27 | | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 36] draft-ietf-rohc-tcp-taroc-03.txt +----+------+-----------+-----+------+------+-----+-----+ |BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-7|576 |Throughput |24564| 24185| 23550|24687|24717| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | -1.54| -4.12| 0.50| 0.62| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-7|576 |Throughput |22256| 21240| 20216|22365|22407| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | -4.56| -9.17| 0.50| 0.68| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-6|576 |Throughput |16703| 14638| 13840|16930|17027| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-12.36|-17.14| 1.36| 1.94| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-6|576 |Throughput | 9895| 7987 | 8086 |10255|10266| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-19.04|-18.03| 3.95| 4.06| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-5|296 |Throughput | 3531| 2803 | 2950 | 3825| 3826| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-20.62|-16.45| 8.33| 8.35| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-5|296 |Throughput | 1731| 1181 | 1317 | 1900| 1901| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-31.77|-23.92| 9.76| 9.82| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-4|168 |Throughput | 504 | 342 | 366| 635| 636| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-32.14|-27.38|25.99|26.19| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-4| 96 |Throughput | 97 | 80 | 91 | 202| 203| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-17.53| -6.19|108.2|109.3| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 37] draft-ietf-rohc-tcp-taroc-03.txt B.3.2. 114kb Sack +----+------+-----------+-----+------+------+-----+-----+ |BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-8|576 |Throughput |12105| 12636| 12605|12660|12662| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | 4.39| 4.13 | 4.58| 4.60| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-8|576 |Throughput |12083| 12565|12474 |12642|12643| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | 3.99 | 3.24 | 4.63| 4.63| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-7|576 |Throughput |12030| 12329| 12165|12582|12587| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | 2.49 | 1.12 | 4.59| 4.63| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-7|576 |Throughput |11856| 11687|11326 |12392|12411| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | -1.43| -4.47| 4.52| 4.68| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-6|576 |Throughput |11213| 9871 | 9177 |11737|11740| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-11.97|-18.16| 4.63| 4.70| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-6|576 |Throughput | 9258| 6578 | 6206 | 9719| 9784| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-28.95|-32.97| 4.98| 5.68| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-5|296 |Throughput | 3883| 2622 | 2587 | 4236| 4239| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-32.47|-33.38| 9.09| 9.17| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 38] draft-ietf-rohc-tcp-taroc-03.txt +----+------+-----------+-----+------+------+-----+-----+ |BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-5|296 |Throughput | 1786| 1111 | 1214 | 2000| 2012| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-37.79|-32.03|11.98|12.65| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-4|168 |Throughput | 489 | 325 | 361 | 640| 652| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-33.54|-26.18|30.88|33.33| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-4| 96 |Throughput | 92 | 81 | 88 | 202 | 203 | | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-11.96| -4.35|119.6|120.7| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ B.3.3. 64kb Reno +----+------+-----------+----+------+------+-----+-----+ |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-8|576 |Throughput |7317| 7743 | 7698 | 7763| 7764| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 5.82 | 5.21 | 6.10| 6.11| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-8|576 |Throughput |7312| 7716 | 7672 | 7756| 7757| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 5.53| 4.92 | 6.07| 6.09| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-7|576 |Throughput |7288| 7615 | 7556 | 7727| 7728| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 4.49| 3.68 | 6.02| 6.04| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 39] draft-ietf-rohc-tcp-taroc-03.txt +----+------+-----------+----+------+------+-----+-----+ |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-7|576 |Throughput |7213| 7351 | 7222 | 7648| 7649| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 1.91| 0.12 | 6.03| 6.04| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-6|576 |Throughput |6966| 6612 | 6286 | 7387| 7398| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| -5.08| -9.76| 6.04| 6.20| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-6|576 |Throughput |6206| 5070 | 4746 | 6562| 6580| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-18.30|-23.53| 5.74| 6.03| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-5|296 |Throughput |3377| 2470 | 2312 | 3633| 3667| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-26.86|-31.54| 7.58| 8.59| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-5|296 |Throughput |1576| 1065 | 1122 | 1755| 1773| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-32.42|-28.81|11.36|12.50| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-4|168 |Throughput | 465| 319 | 340 | 595| 597| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-31.40|-26.88|27.96|28.39| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-4| 96 |Throughput | 87| 79| 86 | 190| 194| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| -9.20| -1.15|118.4|123.0| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 40] draft-ietf-rohc-tcp-taroc-03.txt B.3.4. 9.6kb Sack +----+------+-----------+----+------+------+-----+-----+ |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-8|576 |Throughput |1116| 1187 | 1185 | 1190| 1191| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 6.36| 6.18 | 6.63| 6.72| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-8|576 |Throughput |1116| 1188 | 1186 | 1191| 1192| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 6.45| 6.27 | 6.72| 6.81| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-7|576 |Throughput |1116| 1183 | 1181 | 1190| 1191| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 6.00| 5.82 | 6.63| 6.72| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-7|576 |Throughput |1114| 1173 | 1172 | 1188| 1190| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 5.30 | 5.21 | 6.64| 6.82| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-6|576 |Throughput |1110| 1133 | 1144 | 1183| 1184| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 2.07| 3.06 | 6.58| 6.67| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-6|576 |Throughput |1089| 1036 | 1070 | 1164| 1167| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| -4.87|-1.74 | 6.89| 7.16| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-5|296 |Throughput | 979| 855 | 935 | 1122| 1123| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-12.67|-4.49 |14.61|14.71| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 41] draft-ietf-rohc-tcp-taroc-03.txt +----+------+-----------+----+------+------+-----+-----+ |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-5|296 |Throughput | 759| 500 | 600 | 900 | 908 | | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-34.12|-20.95|18.58|19.63| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-4|168 |Throughput | 341| 224| 252 | 455| 465| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-34.31|-26.10|33.43|36.36| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-4| 96 |Throughput | 78| 67| 72 | 172| 173| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-14.10|-7.69 |120.5|121.8| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 42]