RObust Header Compression (ROHC) WG HongBin Liao
Internet Draft Qian Zhang
Document: <draft-ietf-rohc-tcp-taroc-00.txt> Wenwu Zhu
Expires: May 2001 Ya-Qin Zhang
Microsoft Research, China
November 17, 2000
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-00.txt
Table of Contents
Status of this Memo................................................1
1. Abstract........................................................1
2. Conventions used in this document...............................3
3. Introduction....................................................3
4. The concept of TCP-aware robust header compression (TAROC)......4
4.1. Packet types...............................................5
4.2. Compression states.........................................5
4.2.1. Initialization and Refresh (IR) state.................5
4.1.2. COmpression (CO) state................................6
5. Window-based LSB encoding (W-LSB encoding)......................6
6. TCP congestion window tracking..................................6
6.1. General principle of congestion window tracking............6
6.2. Congestion window tracking based on Sequence Number........7
6.3. Congestion window tracking based on Acknowledgment Number..8
7. Protocol definition............................................10
7.1. Compressor logic..........................................10
7.1.1. IR state.............................................10
7.1.2. CO state.............................................11
7.2. Decompressor logic........................................11
7.3. Compressed packet formats.................................11
7.3.1. UNCOMPRESSED_TCP packet..............................11
7.3.2. COMPRESSED_TCP packet................................12
7.3.2.1. WASI............................................13
7.3.2.2. Options.........................................13
8. Implementation issues..........................................15
8.1. Choose the K..............................................15
9. Conclusions....................................................16
10. Acknowledgments...............................................16
11. Security considerations.......................................16
12. Authors' addresses............................................17
13. References....................................................17
14. Intellectual property considerations..........................19
Appendix A - Window-based LSB encoding (W-LSB encoding)...........19
Appendix B - Simulation results...................................21
B.1. Simulation topology.......................................21
B.2. Tested header compression schemes.........................21
B.3. Simulations and results...................................22
B.3.1. 384kb................................................22
B.3.2. 114kb................................................24
B.3.3. 64kb.................................................25
B.3.4. 9.6kb................................................26
Document History
00 November 17, 2000 First release.
Liao, Zhang, Zhu, Zhang [Page 2]
draft-ietf-rohc-tcp-taroc-00.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 3]
draft-ietf-rohc-tcp-taroc-00.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 4]
draft-ietf-rohc-tcp-taroc-00.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 5]
draft-ietf-rohc-tcp-taroc-00.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.
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:
- 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.
Liao, Zhang, Zhu, Zhang [Page 6]
draft-ietf-rohc-tcp-taroc-00.txt
- 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
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;
Liao, Zhang, Zhu, Zhang [Page 7]
draft-ietf-rohc-tcp-taroc-00.txt
* 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
+-------------+
| |
---------------->| CONGESTION- |
| | AVOIDANCE |
| ----| |<---
+------------+ | +-------------+ |
| | | |
| SLOW-START | | |
| | | +-------------+ |
+------------+ | | | |
| |-->| FAST- |----
| | RECOVERY |
---------------->| |
+-------------+
Liao, Zhang, Zhu, Zhang [Page 8]
draft-ietf-rohc-tcp-taroc-00.txt
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;
* 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.
Liao, Zhang, Zhu, Zhang [Page 9]
draft-ietf-rohc-tcp-taroc-00.txt
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
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.
Liao, Zhang, Zhu, Zhang [Page 10]
draft-ietf-rohc-tcp-taroc-00.txt
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,
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
Liao, Zhang, Zhu, Zhang [Page 11]
draft-ietf-rohc-tcp-taroc-00.txt
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
The format of COMPRESSED_TCP packet header follows [3], but with
different definitions in the Window, Acknowledgment Number, Sequence
Number, IP-ID and Options fields. The basic format of COMPRESSED_TCP
packet is defined as follows.
0 7
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
|R|O|I|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)
- - - - - - - -
| |
| WASI | (if W=1 or A=1
| | or S=1 or I=1)
- - - - - - - -
| Options | (if O=1)
- - - - - - - -
| TCP Data |
Liao, Zhang, Zhu, Zhang [Page 12]
draft-ietf-rohc-tcp-taroc-00.txt
The format of COMPRESSED_TCP packet in TAROC is almost the same as
the one in IPHC except for Window, Acknowledgment Number, Sequence
Number, IP-ID 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 following sections will describe the formats
of these fields.
7.3.2.1. WASI
The bits, W, A, S and I, are set if the corresponding fields are
transmitted. The bits, W, A, S and I 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 WASI, to
achieve high compression ratio. The format of WASI field is defined
as follows.
+----+:::::::::+:::::::::+:::::::::+:::::::::+:::::::::+
| 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 WASI align to 8-bit
+---------+---------+---------+---------+---------+-----------+
| PT | C_WIN | C_ACK | C_SEQ | C_IP_ID | Length of |
| Value | Length | Length | Length | Length | WASI |
| | (bits) | (bits) | (bits) | (bits) | (bytes) |
+---------+---------+---------+---------+---------+-----------+
| 00 | 10 | 11 | 11 | 3 | 2 ~ 5 |
+---------+---------+---------+---------+---------+-----------+
| 01 | 14 | 15 | 15 | 7 | 3 ~ 7 |
+---------+---------+---------+---------+---------+-----------+
| 10 | 16 | 19 | 19 | 11 | 4 ~ 9 |
+---------+---------+---------+---------+---------+-----------+
| 11 | 16 | 23 | 23 | 15 | 5 ~ 11 |
+---------+---------+---------+---------+---------+-----------+
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.
Liao, Zhang, Zhu, Zhang [Page 13]
draft-ietf-rohc-tcp-taroc-00.txt
0 7
+-+-+-+-+-+-+-+-+
| |V|E| SA|
+-+-+-+-+-+-+-+-+
| TS_VAL |
- - - - - - - -
| TS ECHO |
- - - - - - - -
| SACK[SA] |
- - - - - - - -
| Other Options |
- - - - - - - -
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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+
Liao, Zhang, Zhu, Zhang [Page 14]
draft-ietf-rohc-tcp-taroc-00.txt
0 7
+-+-+-+-+-+-+-+-+
|1|1|1|0|- - - -|
+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ TS value +
| |
+ +
| |
+-+-+-+-+-+-+-+-+
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
Liao, Zhang, Zhu, Zhang [Page 15]
draft-ietf-rohc-tcp-taroc-00.txt
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.
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 16]
draft-ietf-rohc-tcp-taroc-00.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.
<draft-ietf-rohc-rtp-05.txt>
Liao, Zhang, Zhu, Zhang [Page 17]
draft-ietf-rohc-tcp-taroc-00.txt
11 V. Jacobson, "Congestion avoidance and control", In ACM SIGCOMM
'88, 1988.
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. <draft-ietf-tsvwg-limited-xmit-00.txt>
14 M. Degermark, "Requirements for robust IP/UDP/RTP header
compression", Internet Draft (work in progress), June 7, 2000.
<draft-ietf-rohc-rtp-requirements-02.txt>
Liao, Zhang, Zhu, Zhang [Page 18]
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 19]
draft-ietf-rohc-tcp-taroc-00.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 20]
draft-ietf-rohc-tcp-taroc-00.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 21]
draft-ietf-rohc-tcp-taroc-00.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 22]
draft-ietf-rohc-tcp-taroc-00.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 23]
draft-ietf-rohc-tcp-taroc-00.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 24]
draft-ietf-rohc-tcp-taroc-00.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 25]
draft-ietf-rohc-tcp-taroc-00.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 26]
draft-ietf-rohc-tcp-taroc-00.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 27]