RObust Header Compression (ROHC) WG HongBin Liao Internet Draft Qian Zhang Document: Wenwu Zhu Expires: September 2001 Ya-Qin Zhang Microsoft Research, China March 01, 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 highly 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 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, feedback channel is not required in our scheme. Liao, Zhang, Zhu, Zhang [Page 1] draft-ietf-rohc-tcp-taroc-01.txt Table of Contents Status of this Memo................................................1 1. Abstract........................................................1 2. Conventions used in this document...............................4 3. Introduction....................................................4 4. The concept of TCP-aware robust header compression (TAROC)......5 4.1. Packet types...............................................6 4.2. Compression states.........................................6 4.2.1. Initialization and Refresh (IR) state.................6 4.1.2. COmpression (CO) state................................7 5. Window-based LSB encoding (W-LSB encoding)......................7 6. TCP congestion window tracking..................................7 6.1. General principle of congestion window tracking............7 6.2. Congestion window tracking based on Sequence Number........8 6.3. Congestion window tracking based on Acknowledgment Number..9 6.4. Further discussion on congestion window tracking..........11 7. Protocol definition............................................11 7.1. Compressor logic..........................................11 7.1.1. IR state.............................................11 7.1.2. CO state.............................................12 7.2. Decompressor logic........................................13 7.3. Compressed packet formats.................................13 7.3.1. UNCOMPRESSED_TCP packet..............................13 7.3.2. COMPRESSED_TCP packet................................13 7.3.2.1. WAS.............................................14 7.3.2.2. Options.........................................15 8. Implementation issues..........................................17 8.1. Choose the K..............................................17 9. Conclusions....................................................18 10. Acknowledgments...............................................18 11. Security considerations.......................................18 12. Authors' addresses............................................19 13. References....................................................19 14. Intellectual property considerations..........................21 Appendix A - Window-based LSB encoding (W-LSB encoding)...........21 Appendix B - Simulation results...................................23 B.1. Simulation topology.......................................23 B.2. Tested header compression schemes.........................23 B.3. Simulations and results...................................24 B.3.1. 384kb................................................24 B.3.2. 114kb................................................26 B.3.3. 64kb.................................................27 B.3.4. 9.6kb................................................28 Liao, Zhang, Zhu, Zhang [Page 2] draft-ietf-rohc-tcp-taroc-01.txt Document History 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 3] draft-ietf-rohc-tcp-taroc-01.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]. 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. 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 case. 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 undesired or impossible in some circumstances. Even when the feedback channel is available, this mechanism still cannot perform well enough if the roundtrip time of this channel is very long. Once a packet is corrupted on the noisy link, there are still lots of 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 performs better over wireless links. For conciseness, the general background information on header compression has not been discussed in detail in this draft. Much of the information can be found in RFC2507 [3]. Liao, Zhang, Zhu, Zhang [Page 4] draft-ietf-rohc-tcp-taroc-01.txt 4. The concept of TCP-aware robust header compression (TAROC) This section describes the concept of the TCP-aware robust header compression (TAROC) proposal as well as 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 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 is achieved by proactive feedback in the form of ACKs from the decompressor. A feedback channel, however, is undesired, impossible, 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 once the decompressor has received the segment in the previous window and then shrink the sliding window by removing all older values of 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 manage 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 needed to track TCP congestion window. TAROC does not impose that all one-way TCP traffic 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 5] draft-ietf-rohc-tcp-taroc-01.txt 4.1. Packet types Similar to the one used in [2] and [3], our compression method uses the following packet types in addition to the IPv4 and IPv6 packet types. 1) UNCOMPRESSIBLE PACKET - includes the Non-TCP packets and "uncompressible" TCP packets. 2) COMPRESSIBLE PACKET - this can be further divided into: * UNCOMPRESSED_TCP - indicates a packet with an uncompressed header including a CID. It establishes or refreshes the context for the packet stream identified by the CID. * COMPRESSED_TCP - indicates a packet with a compressed TCP header containing a CID, a flag octet identifying which fields have changed, and the changed fields encoded as the difference to the previous value. In addition to the packet types used for compression, regular IPv4 and IPv6 packets are used whenever a compressor decides not to compress a packet. 4.2. Compression states There are two compression states in TAROC: Initialization and Refresh (IR) state, as well as COmpression (CO) state. The compressor starts in the lowest compression state (IR) and transits gradually to the higher compression state (CO). 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 sate. +------------+ OUT OF SYNC +------------+ | |<------------| | | IR State | | CO State | | |------------>| | +------------+ SYNC +------------+ 4.2.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 (UNCOMPRESSED_TCP) 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 part information. Liao, Zhang, Zhu, Zhang [Page 6] draft-ietf-rohc-tcp-taroc-01.txt 4.1.2. COmpression (CO) state The purpose of CO 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_TCP packet is transmitted from the compressor to the decompressor in this state. No full header information is needed. The compressor leaves the CO state only when it finds that the context of decompressor may be inconsistent, or there are remarkable changes in the TCP/IP header. 5. Window-based LSB encoding (W-LSB encoding) The 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. - 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 will be applied to IP-ID, Sequence Number, Acknowledgment Number, Window fields and TCP Timestamp option. For bulk data transferring, the payload size of each packet is usually a constant, e.g., 1460 bytes. The sequence number and acknowledgment number can be represented as the following equation: SEQ (or ACK) = m * MTU + n. If all packets in VSW have the same 'n', only 'm' need be transmitted to the decompressor. The decompressor can decode 'm' into the sequence number or acknowledgment number, 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, and 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: Liao, Zhang, Zhu, Zhang [Page 7] draft-ietf-rohc-tcp-taroc-01.txt - Simplex link. The tracking algorithm SHOULD always take only Sequence Number or only 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 one-way TCP traffics are crossing a single 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 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 also 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, the algorithm takes a procedure according to the current state. - SLOW-START * If the new Sequence Number (NSN) is larger than the current maximum Sequence Number (CMAXSN), increase cwnd by the distance between NSN and CMAXSN, and update CMAXSN and the Liao, Zhang, Zhu, Zhang [Page 8] draft-ietf-rohc-tcp-taroc-01.txt current minimum Sequence Number (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 * 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 can use 2 times of multiplication of bandwidth and delay of the link (2*bandwidth*delay) as an approximation value. IW SHOULD be set to 4*MSS. 6.3. Congestion window tracking based on Acknowledgment Number Liao, Zhang, Zhu, Zhang [Page 9] draft-ietf-rohc-tcp-taroc-01.txt +-------------+ | | ---------------->| 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. Upon receiving a segment, the algorithm takes a procedure according to the current state. - SLOW-START * If the new Acknowledgment Number (NEWACK) is larger than the current maximum Acknowledgement Number (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). After that, 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; Liao, Zhang, Zhu, Zhang [Page 10] draft-ietf-rohc-tcp-taroc-01.txt * Otherwise, set NDUPACKS to 0. - FAST-RECOVERY * If NEWACK is larger than CMAXACK, set NDUPACKS to 0. After that, 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 can use 2 times of multiplication of bandwidth and delay of the link (2*bandwidth*delay) as an approximation value. IW SHOULD be set to 4*MSS. 6.4. Further discussion on congestion window tracking In the above congestion-window-tracking approach, packet retransmission or three duplicate acknowledgments are used as the indications of congestion. The size of sliding window will be shrunk upon receiving those indications. However, under some certain circumstances, such as multiple links, losses of retransmission packet or duplicated acknowledgements, those congestion indications can not be captured by the congestion tracking algorithm, and the congestion window size grows larger than the expected value. To prevent from such events, some other control schemes are needed. It is known that, due to the increase of the RTT as the window size grows, the window increment is either sub-linear, or a combination of linear and sub-linear in the congestion-avoidance phase. If the variations of estimated congestion-window size break those behaviors, we can infer that there should be some congestion occurred. In this way, we can reduce the impact of the loss of congestion indications. 7. Protocol definition 7.1. Compressor logic The compressor logic is similar to procedures defined in IPHC. For uncompressible packets, the compressor marks both Non-TCP packet and "uncompressible" TCP packet (also see [2, 3]) as TYPE_IP and let them pass by. For compressible packets, the compressor marks them as COMPRESSED_TCP or UNCOMPRESSED_TCP, but performs different logic from IPHC. In TAROC, the compressor will start in the IR state and perform different logics in different states. The following sections will describe the logic for each compression sate. 7.1.1. IR state Liao, Zhang, Zhu, Zhang [Page 11] draft-ietf-rohc-tcp-taroc-01.txt The operations of compressor in IR state can be summarized as follows: a) Upon receiving a compressible packet, the compressor sends UNCOMPRESSED_TCP 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 UNCOMPRESSED_TCP previously. Otherwise, the compressor compresses the packet using W-LSB encoding and sends it as a COMPRESSED_TCP packet. b) After sending the UNCOMPRESSED_TCP or COMPRESSED_TCP packet, it is added into VSW as a potential reference. 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, respectively. Suppose that the estimated congestion windows are cwnd_seq and cwnd_ack, while the estimated slow start thresholds are ssthresh_seq and ssthresh_ack. 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_TCP packets, F_PERIOD SHOULD be doubled. If it gets larger than W(cwnd_seq, ssthresh_seq, cwnd_ack, ssthresh_ack), the compressor transits to CO state. 7.1.2. CO state The operations of compressor in CO state can be summarized as follows: a) Upon receiving a compressible packet, if it falls behind the VSW, i.e. it is older than all packets in VSW, the compressor clears the VSW and transits to IR state. Otherwise, the compressor compresses it using W-LSB encoding and sends it as COMPRESSED_TCP. b) After sending the COMPRESSED_TCP packet, it is added into VSW as a potential reference. 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, respectively. Suppose that the estimated congestion windows are cwnd_seq and cwnd_ack, while the estimated slow start thresholds are ssthresh_seq and ssthresh_ack. 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, Liao, Zhang, Zhu, Zhang [Page 12] draft-ietf-rohc-tcp-taroc-01.txt 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) If the VSW contains only one packet, which means there is a long jump in the packet sequence, the compressor will transit to IR state. 7.2. Decompressor logic The logic of the decompressor is simpler compared to the one of the compressor. a) Upon receiving a COMPRESSED_TCP packet, the decompressor will decompress it. After that, the decompressor MUST verify the decompressed packet by the TCP checksum. If the verification is succeeded, 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. b) Upon receiving a UNCOMPRESSED_TCP packet, the decompressor will update the context and use this packet as the reference packet. After that, the decompressor will convert the UNCOMPRESSED_TCP packet into the original packet and pass it to the system's network layer. 7.3. Compressed packet formats 7.3.1. UNCOMPRESSED_TCP packet The UNCOMPRESSED_TCP is sent at IR state to establish a valid context on the decompressor side. The format of this packet header is quite similar to the original TCP/IP header, except that, as describe in [4], the LSB of the length field is replaced by the CID number. This enables us to use these fields to signal the context identifier (CID) of header compression specific session as follows. 0 15 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSB of pkt nr | CID | First length field +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 15 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(MSB of pkt nr)| 0 | Second length field +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The second length field of pkt nr (stands for packet sequence number) is not used in our scheme in this release. 7.3.2. COMPRESSED_TCP packet Liao, Zhang, Zhu, Zhang [Page 13] draft-ietf-rohc-tcp-taroc-01.txt The format of COMPRESSED_TCP packet header follows [3], but with different definitions in the Window, Acknowledgment Number, Sequence Number and Options fields. The basic format of COMPRESSED_TCP packet is defined as follows. 0 7 +-+-+-+-+-+-+-+-+ | CID | +-+-+-+-+-+-+-+-+ |R|O|F|P|S|A|W|U| +-+-+-+-+-+-+-+-+ | | + TCP Checksum + | | +-+-+-+-+-+-+-+-+ | RANDOM Fields, if any (see [4], section 7) (implied) - - - - - - - - | R-octet | (if R=1) - - - - - - - - | Urgent Pointer| (if U=1) - - - - - - - - | | | WAS | (if W=1 or A=1 | | or S=1) - - - - - - - - | Options | (if O=1) - - - - - - - - | TCP Data | The format of COMPRESSED_TCP packet in TAROC is almost the same as the one in IPHC except for Window, Acknowledgment Number, Sequence Number and Options fields. Among them, Window, Acknowledgment Number, Sequence Number fields in TCP header, TS value, and TS echo reply fields in TCP Timestamp option are compressed using W-LSB encoding in TAROC. The Fixed field (F) combined with the PT field in the WAS field (as defined below) indicates that Window, Acknowledgment Number, Sequence Number fields are encoded by fixed-payload encoding as described in Section 5. The following sections will describe the formats of these fields. 7.3.2.1. WAS The bits, W, A, S and I, are set if the corresponding fields are transmitted. The bits, W, A, and S are clear if the corresponding compressed fields are zero and don't need to be transmitted. Note that bit I is never clear since IP-ID always changes. These compressed fields are packed into a single field, called WAS, to achieve high compression ratio. The format of WAS field is defined as follows. Liao, Zhang, Zhu, Zhang [Page 14] draft-ietf-rohc-tcp-taroc-01.txt +----+:::::::::+:::::::::+:::::::::+:::::::::+:::::::::+ | PT | C_WIN | C_ACK | C_SEQ | C_IP_ID | PADDING | +----+:::::::::+:::::::::+:::::::::+:::::::::+:::::::::+ PT: 2 bits C_WIN, C_ACK, C_SEQ, C_IP_ID: Variable Length, W-LSB encoding PADDING: tailing zero (if any) for keeping WAS align to 8-bit +---+---------+---------+---------+---------+---------+-----------+ | | PT | C_WIN | C_ACK | C_SEQ | C_IP_ID | Length of | | F | Value | Length | Length | Length | Length | WAS | | | | (bits) | (bits) | (bits) | (bits) | (bytes) | +---+---------+---------+---------+---------+---------+-----------+ | 1 | xxx | 3 | 4 | 4 | 3 | 1 ~ 2 | +---+---------+---------+---------+---------+---------+-----------+ | 0 | 010 | 5 | 6 | 6 | 5 | 2 ~ 4 | +---+---------+---------+---------+---------+---------+-----------+ | 0 | 011 | 8 | 9 | 9 | 8 | 3 ~ 5 | +---+---------+---------+---------+---------+---------+-----------+ | 0 | 100 | 13 | 14 | 14 | 13 | 4 ~ 8 | +---+---------+---------+---------+---------+---------+-----------+ | 0 | 00x | 10 | 11 | 11 | 3 | 2 ~ 5 | +---+---------+---------+---------+---------+---------+-----------+ | 0 | 101 | 13 | 14 | 14 | 6 | 3 ~ 7 | +---+---------+---------+---------+---------+---------+-----------+ | 0 | 110 | 17 | 18 | 18 | 10 | 4 ~ 9 | +---+---------+---------+---------+---------+---------+-----------+ | 0 | 111 | 21 | 22 | 22 | 14 | 5 ~ 11 | +---+---------+---------+---------+---------+---------+-----------+ Fixed-payload encoding is used in the first four entries in the above table. 7.3.2.2. Options In TAROC, the TCP Timestamp and SACK options are compressed. Hence, the Options field is different from the definition in IPHC. Its format is defined as follows. 0 7 +-+-+-+-+-+-+-+-+ | |V|E| SA| +-+-+-+-+-+-+-+-+ | TS_VAL | - - - - - - - - | TS ECHO | - - - - - - - - | SACK[SA] | - - - - - - - - | Other Options | - - - - - - - - Liao, Zhang, Zhu, Zhang [Page 15] draft-ietf-rohc-tcp-taroc-01.txt V: This bit indicates whether the TS value field in TCP Timestamp option of TCP header is transmitted in the COMPRESSED_TCP packet. If it is set to 1, one of the following fields are used in the compressed TS_VAL field: 0 7 +-+-+-+-+-+-+-+-+ |0| TS value | +-+-+-+-+-+-+-+-+ 0 7 +-+-+-+-+-+-+-+-+ |1|0| | +-+-+TS value + | | +-+-+-+-+-+-+-+-+ 0 7 +-+-+-+-+-+-+-+-+ |1|1|0| | +-+-+-+ + | TS value | + + | | +-+-+-+-+-+-+-+-+ 0 7 +-+-+-+-+-+-+-+-+ |1|1|1|0| | +-+-+-+-+ + | | + TS value + | | + + | | +-+-+-+-+-+-+-+-+ 0 7 +-+-+-+-+-+-+-+-+ |1|1|1|1|0|- - -| +-+-+-+-+-+-+-+-+ | | + + | | + TS value + | | + + | | +-+-+-+-+-+-+-+-+ Liao, Zhang, Zhu, Zhang [Page 16] draft-ietf-rohc-tcp-taroc-01.txt E: This bit indicates whether the TS reply echo field in TCP Timestamp option in TCP header is transmitted in the COMPRESSED_TCP packet. The format for the compressed TS reply echo field is the same as the one in the compressed TS value field. SA: These two bits indicate whether the original SACK option in TCP header is transmitted in the COMPRESSED_TCP packet. SA=0: No SACK option SA=1: 1 SACK block SA=2: 2 SACK block SA=3: 3 SACK block The format of each SACK block is defined as follows. SACK: These fields are used for compressed SACK blocks in TCP SACK option. 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. 8. Implementation issues 8.1. Choose the 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 RTTs to be recovered from multiple losses in a window. Ideally, they may send N*W/2 packets in this stage, where N is the number of lost packets and W is the size of the congestion window where error occurs. Some recent works [13] on improving TCP performance may allow transmitting packets even receiving duplicate acknowledgments. Due to the above concerns, it'd better to keep K large enough so as to prevent shrinking VSW without enough confidence that corresponding packets had been successfully received. Liao, Zhang, Zhu, Zhang [Page 17] draft-ietf-rohc-tcp-taroc-01.txt Considering the bandwidth-limited environments and the limited receiver buffer, a practical range of K is around 2~4. From the simulation results, K=2 is good for most cases. 9. Conclusions Based on the requirements proposed in [14], 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 compressor and 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 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 18] draft-ietf-rohc-tcp-taroc-01.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)", Internet Draft (work in progress), October 23, 2000. 11 V. Jacobson, "Congestion avoidance and control", In ACM SIGCOMM '88, 1988. Liao, Zhang, Zhu, Zhang [Page 19] draft-ietf-rohc-tcp-taroc-01.txt 12 M. Allman, V. Paxson, and W. R. Stevens, "TCP Congestion Control", RFC 2581, April 1999. 13 M. Allman, H. Balakrishnan, and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", Internet Draft (work in progress), August 2000. 14 M. Degermark, "Requirements for robust IP/UDP/RTP header compression", Internet Draft (work in progress), June 7, 2000. Liao, Zhang, Zhu, Zhang [Page 20] 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 be to 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 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 LSBs equal the compressed value that has been received. It is obvious that we need 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. The current VSW window is {279, 283}. Liao, Zhang, Zhu, Zhang [Page 21] draft-ietf-rohc-tcp-taroc-01.txt 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 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 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 header to use might be indicated by the presence of a checksum in Liao, Zhang, Zhu, Zhang [Page 22] draft-ietf-rohc-tcp-taroc-01.txt 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 23] draft-ietf-rohc-tcp-taroc-01.txt TAROC It refers to the scheme proposed in this Internet Draft. It assumes that the compressed header size is 7. 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-7, 3e-7, 1e-6, 3e-6, 1e-5, 3e-5, 1e-4, 3e-4, 1e-3 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-7|576 |Throughput |24650| 24246| 23702|24732|24753| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | -1.64| -3.85| 0.33| 0.42| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-7|576 |Throughput |22300| 21339| 20362|22497|22522| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | -4.31| -8.69| 0.88| 1 | | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 24] draft-ietf-rohc-tcp-taroc-01.txt +----+------+-----------+-----+------+------+-----+-----+ |BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-6|576 |Throughput |16710| 14725| 13755|17148|17183| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-11.88|-17.68| 2.62| 2.83| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-6|576 |Throughput | 9639| 7532 | 7704 |10022|10038| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-21.86|-20.07| 3.97| 4.14| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-5|296 |Throughput | 3548| 2750 | 2927 | 3820| 3835| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-22.49|-17.50| 7.67| 8.09| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-5|296 |Throughput | 1744| 1237 | 1348 | 1915| 1926| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-29.07|-22.71| 9.81|10.44| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-4|168 |Throughput | 493 | 324 | 363 | 625| 636| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-34.28|-26.37|26.77|29.01| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-4| 96 |Throughput | 92 | 85| 89 | 184| 195| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | -7.61| -3.26| 100 |111.9| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-3| 96 |Throughput | 1 | 1 | 2 | 9 | 11| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | 0 | 100| 800 | 1000| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 25] draft-ietf-rohc-tcp-taroc-01.txt B.3.2. 114kb Sack +----+------+-----------+-----+------+------+-----+-----+ |BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-7|576 |Throughput |12004| 12291| 12127|12515|12557| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | 2.39| 1.02 | 4.26| 4.61| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-7|576 |Throughput |11833| 11649| 11337|12376|12419| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | -1.55| -4.19| 4.59| 4.95| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-6|576 |Throughput |11204| 9806 | 9160 |11724|11760| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-12.48|-18.24| 4.64| 4.96| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-6|576 |Throughput | 9126| 6337 | 6016 | 9563| 9593| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-30.56|-34.08| 4.79| 5.12| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-5|296 |Throughput | 3936| 2611 | 2599 | 4225| 4239| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-33.66|-33.97| 7.34| 7.70| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-5|296 |Throughput | 1806| 1167 | 1254 | 2013| 2035| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-35.38|-30.56|11.46|12.68| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-4|168 |Throughput | 492 | 308 | 339 | 645| 657| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 |-37.40|-31.10|31.10|33.54| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 26] draft-ietf-rohc-tcp-taroc-01.txt +----+------+-----------+-----+------+------+-----+-----+ |BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |3e-4| 96 |Throughput | 93 | 84| 89 | 183| 196| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | -9.68| -4.39|96.77|110.7| | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ |1e-3| 96 |Throughput | 1 | 1 | 2 | 9 | 10| | | | (Byte/s) | | | | | | | | |-----------+-----+------+------+-----+-----+ | | |Improvement| 0 | 0 | 100| 800 | 900 | | | | (%s) | | | | | | +----+------+-----------+-----+------+------+-----+-----+ B.3.3. 64kb Reno +----+------+-----------+----+------+------+-----+-----+ |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-7|576 |Throughput |7274| 7573 | 7483 | 7642| 7704| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 4.11| 2.87 | 5.06| 5.91| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-7|576 |Throughput |7211| 7344 | 7216 | 7576| 7631| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 1.84| 0.07 | 5.06| 5.82| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-6|576 |Throughput |6962| 6577 | 6343 | 7316| 7389| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| -5.53| -8.89| 5.08| 6.13| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-6|576 |Throughput |6168| 4889 | 4627 | 6452| 6525| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-20.74|-24.98| 4.60| 5.79| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 27] draft-ietf-rohc-tcp-taroc-01.txt +----+------+-----------+----+------+------+-----+-----+ |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-5|296 |Throughput |3399| 2461 | 2297 | 3636| 3665| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| -27.6|-32.42| 6.97| 7.83| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-5|296 |Throughput |1601| 1110 | 1149 | 1801| 1815| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-30.67|-28.23|12.49|13.37| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-4|168 |Throughput | 455| 300 | 322 | 595| 607| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-34.07|-29.23|30.77|33.41| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-4| 96 |Throughput | 91| 84| 85 | 176| 186| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| -7.69| -6.59|93.41|104.4| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-3| 96 |Throughput | 1| 1 | 1 | 9 | 10 | | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 0 | 0 | 800 | 900 | | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ B.3.4. 9.6kb Sack +----+------+-----------+----+------+------+-----+-----+ |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-7|576 |Throughput |1115| 1176 | 1175 | 1184| 1190| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 5.47| 5.38 | 6.19| 6.73| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 28] draft-ietf-rohc-tcp-taroc-01.txt +----+------+-----------+----+------+------+-----+-----+ |BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL| | |(Byte)| | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-7|576 |Throughput |1115| 1169 | 1171 | 1183| 1190| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 4.84| 5.02 | 6.10| 6.73| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-6|576 |Throughput |1112| 1131 | 1140 | 1179| 1185| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 1.71| 2.52 | 6.03| 6.56| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-6|576 |Throughput |1094| 1038 | 1064 | 1160| 1167| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| -5.12|-2.74 | 6.03| 6.67| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-5|296 |Throughput | 976| 859 | 929 | 1100| 1122| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-11.99|-4.82 | 12.7|14.96| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-5|296 |Throughput | 757| 504 | 596 | 883| 908| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-33.42|-21.27|16.64|19.95| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-4|168 |Throughput | 342| 218| 250 | 459| 470| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0|-36.26|-26.93|34.21|37.43| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |3e-4| 96 |Throughput | 78| 71| 78 | 153| 168| | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| -8.97| 0 |96.15|115.3| | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ |1e-3| 96 |Throughput | 1| 1 | 1 | 7 | 9 | | | | (Byte/s) | | | | | | | | |-----------+----+------+------+-----+-----+ | | |Improvement| 0| 0 | 0 | 600 | 800 | | | | (%s) | | | | | | +----+------+-----------+----+------+------+-----+-----+ Liao, Zhang, Zhu, Zhang [Page 29]