ROHC WG HongBin Liao, Microsoft Research Asia
Internet Draft Qian Zhang, Microsoft Research Asia
Expires: May 2002 Wenwu Zhu, Microsoft Research Asia
Ya-Qin Zhang, Microsoft Research Asia
Richard Price, Siemens/Roke Manor
Robert Hancock, Siemens/Roke Manor
Stephen McCann, Siemens/Roke Manor
Mark A West, Siemens/Roke Manor
Abigail Surtees, Siemens/Roke Manor
Paul Ollis, Siemens/Roke Manor
November 21, 2001
TCP-Aware RObust Header Compression (TAROC)
draft-ietf-rohc-tcp-taroc-04.txt
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 obsolete 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].
Liao, et al. [Page 1]
draft-ietf-rohc-tcp-taroc-04.txt
A robust and efficient header compression scheme for TCP/IP, called
TAROC, is presented in this document. TAROC is composed of a
behavior-aware control mechanism, called TAROC-C, and a detailed
header encoding scheme. In this draft, the Efficient Protocol
Independent Compression (EPIC-LITE) scheme is used as the compressed
header encoding framework. The window-based LSB encoding is
introduced in our scheme for compressing redundant fields and
reducing error propagation. The key point of TAROC-C is the TCP
congestion window tracking approach, which can be used to improve
the efficiency of the window-based encoding and the performance of
the overall header compression scheme. With the dynamical congestion
window tracking, our scheme can achieve good performance even when
the feedback channel is not available.
Liao, et al. [Page 2]
draft-ietf-rohc-tcp-taroc-04.txt
Table of Contents
Status of this Memo................................................1
1. Abstract........................................................1
2. Conventions used in this document...............................6
3. Introduction....................................................6
4. The concept and components of TCP-Aware RObust Header compression
and Efficient Protocol Independent Compression (EPIC-LITE) scheme..8
5. The framework of TAROC-C........................................9
5.1. TCP congestion window tracking.............................9
5.1.1. General principle of congestion window tracking.......9
5.1.2. Congestion window tracking based on Sequence Number..10
5.1.3. Congestion window tracking based on Acknowledgment
Number......................................................11
5.1.4. Further discussion on congestion window tracking.....13
5.2. Compressor/decompressor state management with TAROC-C.....13
5.2.1. Compressor states....................................13
5.2.1.1. Initialization and Refresh (IR) state...........14
5.2.1.2. First Order (FO) State..........................14
5.2.1.3. Second Order (SO) State.........................14
5.2.2. Decompressor states..................................15
5.3. Compressor logic in TAROC-C...............................15
5.3.1. IR state.............................................15
5.3.2. FO state.............................................16
5.3.3. SO state.............................................16
5.4. Decompressor logic in TAROC-C.............................17
5.4.1. No Context State.....................................17
5.4.2. Full Context State...................................17
5.5. Modes of operation........................................18
5.5.1. Unidirectional mode -- U-mode........................18
5.5.2. Bi-directional Optimistic mode -- O-mode............18
5.5.2.1. Compressor states and logic (O-mode)...........18
5.5.2.2. Decompressor states and logic (O-mode).........19
5.5.3. Bi-directional Reliable mode -- R-mode..............19
5.5.3.1. Compressor states and logic (R-mode)...........19
5.5.3.2. Decompressor states and logic (R-mode).........20
5.6. Implementation issues.....................................20
5.6.1. Determine the value K................................20
5.6.2. Determine the value N................................20
5.6.3. Determine the frequency of updating context..........20
6. Coding scheme and compressed packet header format..............21
6.1. Window-based LSB encoding and fixed-payload encoding......21
6.2. The framework of EPIC-LITE scheme.........................21
6.3. ROHC Profile for compression of TCP/IP....................22
7. Conclusions....................................................24
8. Acknowledgments................................................25
9. Security considerations........................................25
10. Authors' addresses............................................26
11. References....................................................26
12. Intellectual property considerations..........................29
Appendix A - Simulation results...................................29
A.1. Simulation topology.......................................29
A.2. Tested header compression schemes.........................29
Liao, et al. [Page 3]
draft-ietf-rohc-tcp-taroc-04.txt
A.3. Simulations and results...................................30
A.3.1. 384kb................................................30
A.3.2. 114kb................................................32
A.3.3. 64kb.................................................33
A.3.4. 9.6kb................................................35
Liao, et al. [Page 4]
draft-ietf-rohc-tcp-taroc-04.txt
Document History
04 Nov. 21, 2001 Separate the control mechanism, TAROC-C, with
the detailed compressed packet formats
generation approach;
TAROC-C does not have an IPR-statement;
Introduce the simple TCP/IP profile;
Use EPIC-LITE as coding framework to simplify
the creation of new TCP/IP compressed header
format.
03 Oct. 26, 2001 Modify our TCP congestion window estimation
scheme with the MAX and MIN boundary;
Clarify the initialization and state
transition process in compressor state
management;
Add the CRC option in our compressed header.
02 July 20, 2001 Integrate TAROC with ROHC framework;
Add a second order (SO) state on compressor
side for fixed-payload packets compression;
Modify the coding method for type
identification and adjust corresponding packet
format to improve compression efficiency;
Update the simulation results.
01 March 01, 2001 Improve congestion window tracking algorithm
to handle the special cases where congestion
indications are lost;
Improve the compression efficiency by adding
fixed-payload encoding;
Change in header format accordingly.
00 November 17, 2000 First release.
Liao, et al. [Page 5]
draft-ietf-rohc-tcp-taroc-04.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].
Other terminologies, such as Profile, Context, Compressed header
format, Encoding method, Indicator flags, Set of compressed header
formats, Library of encoding methods, Input language, Control field,
are defined in [19].
3. Introduction
The necessity and importance of doing TCP/IP header compression on
low- or medium-speed links have been discussed in [3]. For
conciseness, the general background information on header
compression has not been discussed in detail in this draft. Detailed
information can be found in RFC2507 [3]. Existing header compression
schemes, such as VJHC [2] and IPHC [3], rely on transmitting only
the difference from the previous header in order to reduce the large
overhead of TCP/IP header.
Although VJHC works well over reliable links, when used over
unreliable link, such as wireless links, it induces many additional
errors due to inconsistent contexts between the compressor and the
decompressor. Considering the high bit error rate in wireless
channel, if a packet gets lost, the compressed header of next packet
cannot be correctly decompressed. Then the decompressor must send
the request for resynchronization and in the meanwhile discard all
compressed header. A fatal result of this effect is that it prevents
TCP Fast Retransmit algorithm [8] from being fired and always causes
TCP retransmission timeout. This effect is shown in detail in [9].
IPHC proposes two simple mechanisms, the TWICE algorithm and the
full header request mechanism, to reduce the errors due to the
inconsistent contexts between the compressor and the decompressor.
The TWICE algorithm assumes that only the Sequence Number field of
TCP segments are changing during the connection and the deltas among
consecutive packets are constant in most cases. However, these
assumptions are not always true, especially when TCP Timestamp and
SACK options are used. The full header request mechanism needs a
feedback channel, which is unavailable in some circumstances. Even
when the feedback channel is available, this mechanism still cannot
perform well enough if the roundtrip time of this link is very long.
Once a packet is corrupted on the noisy link, there are still
several consecutive packets dropped due to the inconsistency between
the compressor and the decompressor.
This Internet draft describes a new header compression scheme (TAROC,
or TCP-Aware RObust header Compression), which consists of two
components, TAROC-C (TCP-Aware RObust Header Compression Control
mechanism) and EPIC-LITE (Efficient Protocol Independent Compression
Liao, et al. [Page 6]
draft-ietf-rohc-tcp-taroc-04.txt
scheme). By combining them together, our scheme is more robust
against packet loss and hence achieves better performance over
wireless links.
Liao, et al. [Page 7]
draft-ietf-rohc-tcp-taroc-04.txt
4. The concept and components of TCP-Aware RObust Header compression
and Efficient Protocol Independent Compression (EPIC-LITE) scheme
This section first describes the concept of the TCP-aware robust
header compression (TAROC) proposal and then discusses how this
concept leads to a better performance when used over unreliable
links.
To design suitable mechanisms for efficient compression of all
TCP/IP header fields, it would be important to analyze their change
patterns first. It is known that the change patterns of several TCP
fields (for example, Sequence Number, Acknowledgement Number, Window,
etc.) are completely different from the ones of RTP, which had
already discussed in detail in [10], and are very hard to predict.
Thus, it is hard to encode these fields with k-LSB both efficiently
and robustly. On the other hand, Window-based LSB encoding [10],
which does not assume the linear changing pattern of the target
header fields, is more suitable to encode those TCP fields both
efficiently and robustly.
The main idea of TAROC-C, the control mechanism of TAROC, is the
combination of the Window-based LSB encoding (W-LSB encoding) and
dynamically TCP congestion window tracking. In W-LSB encoding, a
sliding window (VSW), which equals to the value r mentioned in the
Section 6.4 in EPIC-LITE [19], is maintained on the compressor side.
The compressor gets inconsistent with the decompressor only when the
reference value on the decompressor side is out of this VSW. By
keeping the sliding window large enough, the compressor rarely gets
out of synchronization with the decompressor.
However, the larger the sliding window is, the less the header
compression gains. To shrink the window size, the compressor needs
some form of feedback to get sufficient confidence that a certain
value will not be used as a reference by the decompressor. Then the
window can be advanced by removing that value and all other values
older than it. Obviously, when a feedback channel is available,
confidence can be achieved by proactive feedback in the form of ACKs
from the decompressor. A feedback channel, however, is unavailable
or expensive in some environments. In this Internet draft, a
mechanism based on dynamically tracking TCP congestion window is
proposed to explore such feedbacks from the nature feedback-loop of
TCP protocol itself.
Since TCP is a window-based protocol, a new segment cannot be
transmitted without getting the acknowledgment of segment in the
previous window. Upon receiving the new segment, the compressor can
get enough confidence that the decompressor has received the segment
in the previous window and then shrink the sliding window by
removing all the values older than that segment.
As originally outlined in [11] and specified in [12], TCP is
incorporated with four congestion control algorithms: slow-start,
congestion-avoidance, fast retransmit, and fast recovery. The
Liao, et al. [Page 8]
draft-ietf-rohc-tcp-taroc-04.txt
effective window of TCP is mainly controlled by the congestion
window and may change during the entire connection life. TAROC-C
designs a mechanism to track the dynamics of TCP congestion window,
and control the sliding window of W-LSB encoding by the estimated
congestion window. By combining the W-LSB encoding and TCP
congestion window tracking, TAROC can achieve better performance
over high bit-error-rate links.
Note that in one-way TCP traffic, only the information about
sequence number or acknowledgment number is available for tracking
TCP congestion window. TAROC-C does not require that all one-way TCP
traffics must cross the same compressor. The detail will be
described in the following sections. The topology assumption of
TAROC is the same as the one in VJHC.
The TAROC scheme achieves its compression gain by establishing state
information at both ends of the link, i.e., at the compressor and at
the decompressor. Header compression with TAROC can be characterized
as an interaction between two state machines, one compressor machine
and one decompressor machine, each instantiated once per context.
The Efficient Protocol Independent Compression (EPIC-LITE) scheme,
which had been discussed in detail in [19], is used to generate new
ROHC profiles. This scheme takes as its input a list of fields in the
protocol stack to be compressed, and for each field a choice of one
or more compression techniques. Using this input EPIC-LITE derives a
set of compressed header formats that can be used to quickly and
efficiently compress and decompress headers.
A TCP/IP profile is proposed to describe the behaviors of each field
in TCP/IP header.
In the rest of this draft, the control mechanism, TAROC-C, and the
detailed compressed packet header format will be discussed in detail
respectively. More specifically, the TCP congestion window tracking
algorithm, the state machines in the header compression framework,
and the logics of the compressor/decompressor, are described in
TAROC-C.
5. The framework of TAROC-C
5.1. TCP congestion window tracking
5.1.1. General principle of congestion window tracking
The general principle of congestion window tracking is as follows.
The compressor imitates the congestion control behavior of TCP upon
receiving each segment, in the meantime, estimates the congestion
window (cwnd) and the slow start threshold (ssthresh). Besides the
Liao, et al. [Page 9]
draft-ietf-rohc-tcp-taroc-04.txt
requirement of accuracy, there are also some other requirements for
the congestion window tracking algorithms:
- Simplex link. The tracking algorithm SHOULD always only take
Sequence Number or Acknowledgment Number of a one-way TCP
traffic into consideration. It SHOULD NOT use Sequence Number
and Acknowledgment Number of that traffic simultaneously.
- Misordering resilience. The tracking algorithm SHOULD work
well while receiving misordered segments.
- Multiple-links. The tracking algorithm SHOULD work well when
not all the one-way TCP traffics are crossing the same link.
- Slightly overestimation. If the tracking algorithm cannot
guarantee the accuracy of the estimated cwnd and ssthresh, it is
RECOMMANDED that it produces a slightly overestimated one.
The following sections will describe two congestion window tracking
algorithms, which use Sequence Number and Acknowledgment Number of a
one-way TCP traffic, respectively.
5.1.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 maintains 2
variables: cwnd and ssthresh.
+-------------+
| |
---------------->| CONGESTION- |
| | AVOIDANCE |
| ----| |<---
+------------+ | +-------------+ |
| | | |
| SLOW-START | | |
| | | +-------------+ |
+------------+ | | | |
| |-->| FAST- |----
| | RECOVERY |
---------------->| |
+-------------+
Initially, this algorithm starts in state SLOW-START with ssthresh
set to ISSTHRESH and cwnd set to IW.
Upon receiving a segment, if it is the first segment, which is not
necessary to be the SYN segment, the algorithm sets the current
maximum Sequence Number (CMAXSN) and the current minimum Sequence
Number (CMINSN) to this segment's sequence number; otherwise, the
algorithm takes a procedure according to the current state.
Liao, et al. [Page 10]
draft-ietf-rohc-tcp-taroc-04.txt
- SLOW-START
* If the new Sequence Number (NSN) is larger than CMAXSN,
increase cwnd by the distance between NSN and CMAXSN, and
update CMAXSN and CMINSN based on the following rules:
CMAXSN = NSN
if (CMAXSN - CMINSN) > cwnd)
CMINSN = cwnd - CMAXSN;
If the cwnd is larger than ssthresh, the algorithm transits to
CONGESTION-AVOIDANCE state;
* If the distance between NSN and CMAXSN is less than or equal
to 3*MSS, ignore it;
* If the distance is larger than 3*MSS, halve the cwnd and set
ssthresh to MAX(cwnd, 2*MSS). After that, the algorithm
transits into FAST-RECOVERY state.
- CONGESTION-AVOIDANCE
* If NSN is larger than CMAXSN, increase cwnd by ((NSN-
CMAXSN)*MSS)/cwnd and then update CMAXSN and CMINSN based on
the following rules:
CMAXSN = NSN
if (CMAXSN - CMINSN) > cwnd)
CMINSN = cwnd - CMAXSN;
* If the distance between NSN and CMAXSN is less than or equal
to 3*MSS, ignore it;
* If the distance is larger than 3*MSS, halve the cwnd and set
ssthresh to MAX(cwnd, 2*MSS). After that, the algorithm
transits into FAST-RECOVERY state.
- FAST-RECOVERY
* If NSN is larger than or equal to CMAXSN + cwnd, the algorithm
transits into CONGESTION-AVOIDANCE state;
* Otherwise, ignore it.
In this algorithm, MSS is denoted as the estimated maximum segment
size. The implementation can use the MTU of the link as an
approximation of this value. ISSHRESH and IW are the initial values
of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily
high. IW SHOULD be set to 4*MSS.
5.1.3. Congestion window tracking based on Acknowledgment Number
Liao, et al. [Page 11]
draft-ietf-rohc-tcp-taroc-04.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, if it is the first segment, which is not
necessary to be the SYN segment, the algorithm sets the current
maximum Acknowledgment Number (CMAXACK) to this segment's
acknowledgment number; otherwise, the algorithm takes a procedure
according to the current state.
- SLOW-START
* If the new Acknowledgment Number (NEWACK) is larger than
CMAXACK, increase cwnd by the distance between NEWACK and
CMAXACK, set duplicate ack counter (NDUPACKS) to 0, and update
CMAXACK accordingly; If the cwnd is larger than ssthresh, the
algorithm transits to CONGESTION-AVOIDANCE state;
* If NEWACK is equal to CMAXACK, increase the NDUPACKS by 1. If
NDUPACKS is greater than 3, halve the cwnd and set ssthresh to
MAX(cwnd, 2*MSS). Consequently, the algorithm transits into
FAST-RECOVERY state;
* Otherwise, set NDUPACKS to 0.
- CONGESTION-AVOIDANCE
* If NEWACK is larger than CMAXACK, increase cwnd by ((NEWACK-
CMAXACK)*MSS)/cwnd, set NDUPACKS to 0 and update CMAXACK
accordingly;
* If NEWACK is equal to CMAXACK, increase NDUPACKS by 1. If
NDUPACKS is greater than 3, halve the cwnd and set ssthresh to
Liao, et al. [Page 12]
draft-ietf-rohc-tcp-taroc-04.txt
MAX(cwnd, 2*MSS). After that, the algorithm transits into
FAST-RECOVERY state;
* Otherwise, set NDUPACKS to 0.
- FAST-RECOVERY
* If NEWACK is larger than CMAXACK, set NDUPACKS to 0.
Consequently, the algorithm transits into CONGESTION-AVOID
state;
* Otherwise, ignore it.
In this algorithm, MSS is denoted as the estimated maximum segment
size. The implementation can use the MTU of the link as an
approximation of this value. ISSHRESH and IW are the initial values
of ssthresh and cwnd, respectively. ISSTHRESH MAY be arbitrarily
high. IW SHOULD be set to 4*MSS.
5.1.4. Further discussion on congestion window tracking
In some cases, it is inevitable for the tracking algorithms to
overestimate the TCP congestion window. Also, it SHOULD be avoided
that the estimated congestion window gets significantly smaller that
the actual one. For all of these cases, TAROC simply applies two
boundaries on the estimated congestion window size. One of the two
boundaries is the MIN boundary, which is the minimum congestion
window size and whose value is determined according to the [18]; the
other boundary is the MAX boundary, which is the maximum congestion
window size. There are two possible approaches to setting this MAX
boundary. One is to select a commonly used maximum TCP socket buffer
size. The other one is to use the simple equation W=sqrt(8/3*l),
where W is the maximum window size and l is the typical packet loss
rate.
If ECN mechanism is deployed, according to [13] and [14], the TCP
sender will set the CWR (Congestion Window Reduced) flag in the TCP
header of the first new data packet sent after the window reduction,
and the TCP receiver will reset the ECN-Echo flag back to 0 after
receiving a packet with CWR flag set. Thus, the CWR flag and the
ECN-Echo flag's transition from 1 to 0 can be used as another
indication of congestion combined with other mechanisms mentioned in
the tracking algorithm.
5.2. Compressor/decompressor state management with TAROC-C
5.2.1. Compressor states
There are three compressor states in TAROC: Initialization and
Refresh (IR) state, First Order (FO), and Second Order (SO) states.
The compressor starts in the lowest compression state (IR) and
Liao, et al. [Page 13]
draft-ietf-rohc-tcp-taroc-04.txt
transits gradually to the higher compression state. The compressor
will always operate in the highest possible compression state, under
the constraint that the compressor is sufficiently confident that
the decompressor has the information necessary to decompress a
header, which is compressed according to the state.
+----------+
| |
+----------+ | FO State | +----------+
| | <--------> | | <--------> | |
| IR State | +----------+ | SO State |
| | <----------------------------------> | |
+----------+ +----------+
5.2.1.1. Initialization and Refresh (IR) state
The purpose of IR state is to initialize or refresh the static parts
of the context at the decompressor. In this state, the compressor
sends full header periodically with an exponentially increasing
period, which is so-called compression slow-start [3]. The
compressor leaves the IR state only when it is confident that the
decompressor has correctly received the static information.
To compress short-lived TCP transfers more efficiently, the
compressor should speed up the initial process. The compressor
enters the IR state when it receives the packet with SYN bit set and
sends IR packet. When it receives the first data packet of the
transfer, it should transit to FO state because that means the
decompressor has received the packet with SYN bit set and
established the context successfully at its side. Using this
mechanism can significantly reduce the number of context initiation
headers.
5.2.1.2. First Order (FO) State
The purpose of FO state is to efficiently transmit the difference
between the two consecutive packets in the TCP stream. When
operating in this state, the compressor and the decompressor should
have the same context. Only compressed packet is transmitted from
the compressor to the decompressor in this state. The compressor
transits back to IR state only when it finds that the context of
decompressor may be inconsistent, or there are remarkable changes in
the TCP/IP header.
5.2.1.3. Second Order (SO) State
The purpose of SO state is to efficiently transmit the fixed-payload
data. The compressor enters this state when it is sufficiently
confident that the decompressor has got the constant payload size of
the data transferring.
Liao, et al. [Page 14]
draft-ietf-rohc-tcp-taroc-04.txt
The compressor leaves this state and transits to the FO state when
the current payload size no longer conforms to the constant payload.
The compressor transits back to IR state only when it finds that the
context of decompressor may be inconsistent, or there are remarkable
changes in the TCP/IP header.
5.2.2. Decompressor states
The decompressor starts in its lowest compression state, "No
Context" and gradually transits to higher state, "Full Context". The
decompressor state machine normally never leaves the "Full Context"
state once it has entered this state.
+--------------+ +--------------+
| No Context | <---> | Full Context |
+--------------+ +--------------+
5.3. Compressor logic in TAROC-C
In TAROC-C, the compressor will start in the IR state and perform
different logics in different states. The following sub-sections
will describe the logic for each compressor sate in detail.
5.3.1. IR state
The operations of compressor in IR state can be summarized as
follows:
a) Upon receiving a packet, the compressor sends IR or IR-DYN packet
on the following conditions: 1) if it is the turn to send full
header packet according to compression slow-start, i.e. after
sending F_PERIOD compressed packets; 2) if the packet to be sent
is a retransmission of the packet in VSW and it was sent as IR or
IR-DYN packet previously. Otherwise, the compressor compresses
the packet using W-LSB encoding. If the compressor enters the IR
state for the first time or the static part of the TCP flow has
changed, it will send IR packet. Otherwise, it will send IR-DYN
packet because the decompressor has known the static part.
b) The packet is added into VSW as a potential reference after it
has been sent out. The compressor then invokes the Algorithm SEQ
and Algorithm ACK to track the congestion windows of the two one-
way traffics with different directions in a TCP connection.
Suppose that the estimated congestion windows are cwnd_seq and
cwnd_ack, while the estimated slow start thresholds are
ssthresh_seq and ssthresh_ack, respectively. Let W(cwnd_seq,
ssthresh_seq, cwnd_ack, ssthresh_ack) = K*MAX(MAX(cwnd_seq,
2*ssthresh_seq), MAX(cwnd_ack, 2*ssthresh_ack)). If the size of
VSW is larger than W(cwnd_seq, ssthresh_seq, cwnd_ack,
ssthresh_ack), the VSW can be shrunk. K is an implementation
parameter that will be further discussed in Section 5.6.
Liao, et al. [Page 15]
draft-ietf-rohc-tcp-taroc-04.txt
c) After sending F_PERIOD compressed packets, F_PERIOD SHOULD be
doubled. If it gets larger than W(cwnd_seq, ssthresh_seq,
cwnd_ack, ssthresh_ack), the compressor transits to FO or SO
state. If the compressor finds that the payload size of
consecutive packets is a constant value and one of such packets
is removed from the VSW, which means the decompressor has known
the exact value of the constant size, it may transit to SO state.
Otherwise it will transit to the FO state.
5.3.2. FO state
The operations of the compressor in the FO state can be summarized
as follows:
a) Upon receiving a packet, if it falls behind the VSW, i.e. it is
older than all the packets in VSW; the compressor transits to IR
state. Otherwise, the compressor compresses it using W-LSB
encoding and sends it.
b) The packet is added into VSW as a potential reference after it has
been sent out. The compressor then invokes the Algorithm SEQ and
Algorithm ACK to track the congestion windows of the two one-way
traffics with different directions in a TCP connection. Suppose
that the estimated congestion windows are cwnd_seq and cwnd_ack,
while the estimated slow start thresholds are ssthresh_seq and
ssthresh_ack, respectively. Let W(cwnd_seq, ssthresh_seq, cwnd_ack,
ssthresh_ack) = K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack,
2*ssthresh_ack)). If the size of VSW is larger than W(cwnd_seq,
ssthresh_seq, cwnd_ack, ssthresh_ack), the VSW can be shrunk. K is
also an implementation parameter, which can be set to the same
value as in the IR state.
c) If the VSW contains only one packet, which means there is a long
jump in the packet sequence number or acknowledge number, the
compressor will transit to the IR state and re-initialize the
algorithm for tracking TCP congestion window. Here, a segment
causes a long jump when the distance between its sequence number
(or acknowledgment number) and CMAXSN (or CMAXACK) is larger than
the estimated congestion window size, i.e.,
|sequence number (acknowledgement number) CMAXSN (CMAXACK)| >
estimated congestion window size.
d) If the compressor finds that the payload size of consecutive
packets is a constant value and one of such packets has been
removed from the VSW, which means the decompressor has known the
exact value of the constant size, it may transit to the SO state.
e) If the static context of transfers changed, the compressor will
transit to the IR state and re-initialize the algorithms for
tracking TCP congestion window.
5.3.3. SO state
Liao, et al. [Page 16]
draft-ietf-rohc-tcp-taroc-04.txt
The operations of the compressor in the SO state can be summarized
as follows:
a) Upon receiving a packet, if it falls behind the VSW, i.e. it is
older than all the packets in VSW; the compressor transits to IR
state. Otherwise, the compressor compresses it using fixed-payload
encoding and sends it.
b) The packet is added into VSW as a potential reference after it has
been sent out. The compressor then invokes the Algorithm SEQ and
Algorithm ACK to track the congestion windows of the two one-way
traffics with different directions in a TCP connection. Suppose
that the estimated congestion windows are cwnd_seq and cwnd_ack,
while the estimated slow start thresholds are ssthresh_seq and
ssthresh_ack, respectively. Let W(cwnd_seq, ssthresh_seq, cwnd_ack,
ssthresh_ack) = K*MAX(MAX(cwnd_seq, 2*ssthresh_seq), MAX(cwnd_ack,
2*ssthresh_ack)). If the size of VSW is larger than W(cwnd_seq,
ssthresh_seq, cwnd_ack, ssthresh_ack), the VSW can be shrunk. K is
an implementation parameter, which can be set to the same value as
in the IR state.
c) If the VSW contains only one packet, which means there is a long
jump in the packet sequence number or acknowledge number, the
compressor will transit to the IR state and re-initialize the
algorithms for tracking TCP congestion window.
d) If the payload size of the packets in VSW doesn't keep constant,
the compressor transits to the FO state.
e) If the static context of transfers changed, the compressor will
transit to the IR state and re-initialize the algorithms for
tracking TCP congestion window.
5.4. Decompressor logic in TAROC-C
The logic of the decompressor is simpler compared to the compressor.
5.4.1. No Context State
The decompressor starts in this state. Upon receiving an IR or IR-
DYN packet, the decompressor should verify the correctness of its
header by TCP checksum. If the verification succeeds, the
decompressor will update the context and use this packet as the
reference packet. After that, the decompressor will pass it to the
system's network layer and transit to Full Context State. Conformed
to ROHC framework [10], only IR or IR-DYN packets may be
decompressed in No Context state.
5.4.2. Full Context State
Liao, et al. [Page 17]
draft-ietf-rohc-tcp-taroc-04.txt
The operations of decompressor in Full Context state can be
summarized as follows:
a) Upon receiving an IR or IR-DYN packet, the decompressor should
verify the correctness of its header by TCP checksum. If the
verification succeeds, the decompressor will update the context and
use this packet as the reference packet. Consequently, the
decompressor will convert the packet into the original packet and
pass it to the network layer of the system.
b) Upon receiving the other type of packet, the decompressor will
decompress it. After that, the decompressor MUST verify the
correctness of the decompressed packet by the TCP checksum. If the
verification succeeds, the decompressor passes it to the system's
network layer. Then the decompressor will use it as the reference
value if this packet is not older than the current reference packet.
c) If consequent N packets fail to be decompressed, the decompressor
should transit downwards to No Context State. N is an implementation
parameter that will be further discussed in Section 5.6.
5.5. Modes of operation
There are three modes in ROHC framework, called Unidirectional, Bi-
directional Optimistic, and Bi-directional Reliable mode,
respectively. The mode transitions are conformed to ROHC framework.
However, the operations of each mode are different.
5.5.1. Unidirectional mode -- U-mode
When in U-mode, packets are sent in one direction only: from
compressor to decompressor. Therefore, feedbacks from decompressor
to the compressor are unavailable under this mode.
In the U-mode, the compressor and decompressor logic is the same as
the discussion in section 5.3 and 5.4.
5.5.2. Bi-directional Optimistic mode -- O-mode
When in O-mode, a feedback channel is used to send error recovery
requests and (optionally) acknowledgments of significant context
updates from the decompressor to the compressor. In this mode, the
VSW will be shrunk more efficiently.
5.5.2.1. Compressor states and logic (O-mode)
Following rules should be combined with the action defined in
section 5.3.
In the IR state, the compressor can transit to the FO or SO state
once it receives a valid ACK(O) for an IR packet sent (an ACK(O) can
only be valid if it refers to a packet sent earlier). If the packet
Liao, et al. [Page 18]
draft-ietf-rohc-tcp-taroc-04.txt
referred by the feedback is in the VSW, the compressor will remove
the packets older than the referred packet from the VSW window.
Because ACK(O) means that the packet referred by ACK(O) has been the
reference of the decompressor, the compressor doesn't need to keep
older packets.
If the compressor is in the FO or SO state, it will remove the
packets older than the referred packet from the VSW window.
Upon receiving an NACK(O), the compressor transits back to IR state.
5.5.2.2. Decompressor states and logic (O-mode)
The decompression states and the state transition logic are the same
as in the Unidirectional case (see section 5.5.1.). What differs is
the feedback logic.
Below, rules are defined stating which feedback to use when.
When an IR packet passes the verification, send an ACK(O). When an
IR-DYN packet or other packet is correctly decompressed, optionally
send an ACK(O). When any packet fails the verification, send an
NACK(O).
5.5.3. Bi-directional Reliable mode -- R-mode
The R-mode are a more intensive usage of the feedback channel and a
stricter logic at both the compressor and the decompressor that
prevents loss of context synchronization between the compressor and
decompressor except for very high residual bit error rates. Feedback
is sent to acknowledge all context updates. In this mode, the VSW
will be shrunk with the highest efficiency.
5.5.3.1. Compressor states and logic (R-mode)
Following rules should be reparation to the action defined in
section 5.3.
In IR state, the compressor should transit to the FO or SO state
only when it receives a valid ACK(R) for an IR or IR-DYN packet sent
(an ACK(R) can only be valid if it refers to an packet sent earlier).
If the packet referred by the feedback is in the VSW, the compressor
will remove the packets older than the referred packet from the VSW
window. Because ACK(R) means that the packet referred by ACK(R) has
been the reference of the decompressor; the compressor doesn't need
to keep older packets.
If the compressor is in the FO or SO state, when it receives a valid
ACK(R), it will remove the packets older than the referred packet
from the VSW window. In this mode, the compressor need not use
window tracking, because feedback can shrink VSW efficiently and
robustly.
Liao, et al. [Page 19]
draft-ietf-rohc-tcp-taroc-04.txt
Upon receiving an NACK(O), the compressor transits back to IR state.
5.5.3.2. Decompressor states and logic (R-mode)
Below, rules are defined stating which feedback to use when.
. When a packet is correctly decompressed and updates the context,
send an ACK(R).
. When any packet fails the verification, send a NACK(R).
The frequency of updating context will be discussed in section 5.6.
5.6. Implementation issues
5.6.1. Determine the value K
As mentioned above, 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 L*W/2 packets in this stage, where L is the number of lost
packets and W is the size of the congestion window where error
occurs. Some recent work [15] on improving TCP performance allows to
transmit packets even when receiving duplicate acknowledgments. Due
to the above concerns, it'd better keep K large enough so as to
prevent shrinking VSW without enough confidence that corresponding
packets had been successfully received.
Considering the bandwidth-limited environments and the limited
receiver buffer, a practical range of K is around 1~2. From the
simulation results, K=1 is good enough for most cases.
5.6.2. Determine the value N
We should distinguish out of synchronization from the packet errors
cause by the link. So considering the error condition of the link, N
should be higher than the packet burst error length, a practical
range of N is around 8~10.
5.6.3. Determine the frequency of updating context
The choice of the frequency of updating context, ACK(R), is a
balance between the efficiency and robustness, i.e. sending ACK(R)
more frequently improves the compression robustness but adds more
system overhead, and the vice versa. From a practical view, the
ACK(R) SHOULD be sent for every 4~8 successfully decompressed
packets.
Liao, et al. [Page 20]
draft-ietf-rohc-tcp-taroc-04.txt
6. Coding scheme and compressed packet header format
Following the requirement of TCP/IP header compression [15], TAROC
should fit into the ROHC framework. Thus, TAROC will conform to the
general format and the reserved packet types defined in [10]. A
compressed header format had been discussed in [20] in our past work.
As stated in [19], EPIC-LITE is a generic encoding scheme which can
automatically generate efficient packet format for the compressed
header. In this draft, TAROC adopts EPIC-LITE as the coding
framework. To use the EPIC-LITE coding framework, a suitable TCP/IP
profile is also needed as the input. In the following of this
section, we will discuss that in detail.
6.1. Window-based LSB encoding and fixed-payload encoding
As stated above, the change patterns of several TCP fields (for
example, Sequence Number, Acknowledgement Number, Window, etc.) are
completely different from the ones of RTP, and are very hard to
predict. Thus, Window-based LSB encoding, which does not assume the
linear changing pattern of the target header fields, is used in
TAROC to encode those TCP fields both efficiently and robustly.
The Window-based LSB encoding (W-LSB encoding) used in TAROC is a
slightly modified version of [10]. 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 encoding will be applied to several fields, such as IP-ID,
Sequence Number, Acknowledgment Number, Window fields, TCP Timestamp
option, etc.
For some applications, such as bulk data transferring, etc., the
payload size of each packet is usually a constant value, e.g. 1460
bytes. In such a case, the sequence number and acknowledgment number
can be represented as the following equation:
SEQ (or ACK) = m * MTU + n.
If all the packets in VSW have the same 'n', only 'm' need be
transmitted to the decompressor. The decompressor can obtain the
sequence number or acknowledgment number after correctly decoding
'm', and use them as the reference values. This encoding method is
called fixed-payload encoding.
6.2. The framework of EPIC-LITE scheme
Liao, et al. [Page 21]
draft-ietf-rohc-tcp-taroc-04.txt
The detailed information about EPIC-LITE, include the structure of
the EPIC-LITE compressed headers, the overview of the input language
for EPIC-LITE, the packet types available to EPIC-LITE, the library
of EPIC-LITE encoding methods, and how to create a new ROHC profile,
are described in [19].
6.3. ROHC Profile for compression of TCP/IP
This session describes a ROHC profile for the compression of TCP/IP.
Note that the probabilities listed for each encoding method are
initial estimates only. These need to be refined with more accurate
values from genuine TCP/IP streams.
The profile for TCP/IP compression is given below:
only uses the following toolbox methods:
- STATIC-KNOWN
- STATIC-UNKNOWN
- STATIC
- IRREGULAR
- LSB
- VALUE
- MSN-IRREGULAR
- MSN-LSB
- C
profile_identifier 0xFFFF
max_formats 200
max_sets 1
bit_alignment 8
npatterns 224
CO_packet TCP-IP
TCP-IP = IPv4-header
TCP-header
msn
msn = C(MSN-LSB(4,-1,90%)) | C(MSN-LSB(7,-1,9%)) |
MSN-IRREGULAR(16,1%)
IPv4-header = version
header_len
tos
ecn
length
ip-id
rf_flag
df_flag
Liao, et al. [Page 22]
draft-ietf-rohc-tcp-taroc-04.txt
mf_flag
offset
ttl
protocol
ip_chksum
src_address
dst_address
version = STATIC-KNOWN(4,4)
header_len = STATIC-KNOWN(4,5)
tos = C(STATIC(99%)) | IRREGULAR(6,1%)
ecn = IRREGULAR(2,100%)
length = IRREGULAR(16)
ip-id = C(LSB(4,-1,90%)) | C(LSB(6,-1,8%)) |
C(LSB(8,-1,1%)) | IRREGULAR(16,1%)
rf_flag = VALUE(1,0,100%)
df_flag = IRREGULAR(1,100%)
mf_flag = VALUE(1,0,99%) | VALUE(1,1,1%)
offset = C(STATIC(99%)) | IRREGULAR(13,1%)
ttl = C(STATIC(99%)) | IRREGULAR(8,1%)
protocol = STATIC-KNOWN(8,6)
ip_chksum = IRREGULAR(16,100%)
src_address = STATIC-UNKNOWN(32)
dst_address = STATIC-UNKNOWN(32)
TCP-header = source_port
dest_port
seqno
ackno
data_offset
flags
window
tcp_chksum
urg_ptr
source_port = STATIC-UNKNOWN(16)
dest_port = STATIC-UNKNOWN(16)
Liao, et al. [Page 23]
draft-ietf-rohc-tcp-taroc-04.txt
seqno = C(LSB(8,63,80%)) | C(LSB(14,127,10%)) |
C(LSB(20,1023,5%)) | IRREGULAR(32,5%)
ackno = C(LSB(8,-1,80%)) | C(LSB(14,-1,10%)) |
C(LSB(20,-1,5%)) | IRREGULAR(32,5%)
data_offset = IRREGULAR(4,100%)
window = C(STATIC(80%)) | C(LSB(12,63,10%)) |
IRREGULAR(16,10%)
tcp_chksum = IRREGULAR(16,100%)
urg_ptr = C(STATIC(99%)) | IRREGULAR(16,1%)
flags = reserved
cwr
ece
urg
ack
psh
rst
syn
fin
reserved = C(STATIC(90%)) | IRREGULAR(4,10%)
cwr = VALUE(1,0,80%) | VALUE(1,1,20%)
ece = VALUE(1,0,80%) | VALUE(1,1,20%)
urg = VALUE(1,0,99%) | VALUE(1,1,1%)
ack = VALUE(1,1,99%) | VALUE(1,0,1%)
psh = IRREGULAR(1,100%)
rst = VALUE(1,0,99%) | VALUE(1,1,1%)
syn = VALUE(1,0,99%) | VALUE(1,1,1%)
fin = VALUE(1,0,95%) | VALUE(1,1,5%)
7. Conclusions
Based on the requirements proposed in [16] and [17], 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
Liao, et al. [Page 24]
draft-ietf-rohc-tcp-taroc-04.txt
misordering of packets should be addressed. In addition, multiple
links and unidirectional link should be supported in the proposed
header compression scheme. Particularly for TCP/IP, the header
compression scheme should compress TCP SACK and Timestamp options.
From the above analysis, it can be seen that all these requirements
can be satisfied in our proposed TAROC.
Considering the behavior of TCP protocol itself, even the packets
misordering occurs between the compressor and the decompressor, a
good performance can still be achieved in TAROC.
Note that in our scheme, we need to select a packet with correct
checksum of the whole packet as a reference. In this way, it does
not require link layer to treat the header and payload of the packet
separately.
Simulations results (Appendix A) demonstrate the effectiveness of
control mechanism TAROC-C and corresponding header compression
scheme, TAROC of TAROC.
8. Acknowledgments
When designing this protocol, earlier header compression ideas
described in [2], [3] and [10] have been import sources of knowledge.
This draft also benefited from discussion on the ROHC mailing list
about the TAROC-C mechanism.
9. Security considerations
Security issues are not considered in this memo.
Liao, et al. [Page 25]
draft-ietf-rohc-tcp-taroc-04.txt
10. Authors' addresses
HongBin Liao Tel: +86 10 62617711-3156
Email: i-hbliao@microsoft.com
Qian Zhang Tel: +86 10 62617711-3135
Email: qianz@microsoft.com
Wenwu Zhu Tel: +86 10 62617711-5405
Email: wwzhu@microsoft.com
Ya-Qin Zhang Tel: +86 10 62617711
Email: yzhang@microsoft.com
Microsoft Research Asia
Beijing Sigma Center
No.49, Zhichun Road, Haidian District
Beijing 100080, P.R.C.
Richard Price Tel: +44 1794 833681
Email: richard.price@roke.co.uk
Robert Hancock Tel: +44 1794 833601
Email: robert.hancock@roke.co.uk
Stephen McCann Tel: +44 1794 833341
Email: stephen.mccann@roke.co.uk
Mark A West Tel: +44 1794 833311
Email: mark.a.west@roke.co.uk
Abigail Surtees Tel: +44 1794 833131
Email: abigail.surtees@roke.co.uk
Paul Ollis Tel: +44 1794 833168
Email: paul.ollis@roke.co.uk
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
11. 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.
Liao, et al. [Page 26]
draft-ietf-rohc-tcp-taroc-04.txt
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 Bormann (ed.), et al., "RObust Header Compression (ROHC)", RFC
3095, July 2001.
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 K. Ramakrishnan, S. Floyd, "A Proposal to add Explicit Congestion
Notification (ECN) to IP", RFC 2481, January 1999.
14 K. K. RamaKrishnan, Sally Floyd, D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", Internet Draft
(work in progress), June, 2001. <draft-ietf-tsvwg-ecn-04.txt>
15 L-E. Jonsson, "Requirements for ROHC IP/TCP header compression",
Internet Draft (work in progress), June 20, 2001.
16 M. Allman, H. Balakrishnan, and S. Floyd, "Enhancing TCP's Loss
Recovery Using Limited Transmit", Internet Draft (work in
progress), August 2000. <draft-ietf-tsvwg-limited-xmit-00.txt>
17 M. Degermark, "Requirements for robust IP/UDP/RTP header
compression", RFC 3096, July 2001.
18 M. Allman, S. Floyd, and C. Partridge, "Increasing TCP's Initial
Window", Internet Draft (work in progress), May 2001. <draft-
ietf-tsvwg-initwin-00.txt>
19 Richard Price et al, "Framework for EPIC-LITE", <draft-ietf-rohc-
epic-lite-00.txt>, Internet Draft (work in progress), Oct. 2001.
Liao, et al. [Page 27]
draft-ietf-rohc-tcp-taroc-04.txt
20 H. Liao, Q. Zhang, W. Zhu, and Y.-Q. Zhang, TCP-Aware RObust
Header Compression (TAROC)÷, Internet Draft (work in progress),
Nov. 2001. <draft-ietf-rohc-taroc-03.txt>
Liao, et al. [Page 28]
12. Intellectual property considerations
The TCP-Aware Robust header Compression Control mechanism, TAROC-C,
and the Efficient Protocol Independent Compression scheme, EPIC-LITE,
do not have an IPR statement.
Appendix A - 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. The simulation result in gained by the TAROC
coding scheme discussed in [20].
A.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.
A.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, et al. [Page 29]
draft-ietf-rohc-tcp-taroc-04.txt
TAROC It refers to the scheme proposed in this Internet Draft.
The compressed header size is determined by the scheme
described in this draft.
IDEAL This scheme simulates the situation where header
compression does not introduce additional errors. It
assumes that the compressed header size is 4, the same one
as in the VJHC.
A.3. Simulations and results
Based upon these configurations, enormous simulations have been
tested. The followings are the results of several TCP variants,
Tahoe, Reno and Sack on the wireless link with wide range of
bandwidth, BER and MTU.
Wireless link characteristics:
* Bandwidth: 384kb, 114kb, 64kb, 9.6kb
* Delay: 100ms
* BER: 1e-8, 3e-8, 1e-7, 3e-7, 1e-6, 3e-6, 1e-5, 3e-5, 1e-4, 3e-4
TCP Variants: Tahoe, Reno, Sack
Header compression schemes: NONE, VJHC, IPHC, TAROC, IDEAL
The following lists some of the results: 384kb for Tahoe, 114kb for
Sack, 64kb for Reno, and 9.6kb for Sack.
A.3.1. 384kb
Tahoe
+----+------+-----------+-----+------+------+-----+-----+
|BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL|
| |(Byte)| | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|1e-8|576 |Throughput |25470| 25457| 25179|25587|25603|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-0.05 |-1.14 |0.46 |0.52 |
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|3e-8|576 |Throughput |25770| 25764| 25696|25819|25839|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 | -0.02| -0.29| 0.19|0.27 |
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
Liao, et al. [Page 30]
draft-ietf-rohc-tcp-taroc-04.txt
+----+------+-----------+-----+------+------+-----+-----+
|BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL|
| |(Byte)| | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|1e-7|576 |Throughput |24564| 24185| 23550|24687|24717|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 | -1.54| -4.12| 0.50| 0.62|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|3e-7|576 |Throughput |22256| 21240| 20216|22365|22407|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 | -4.56| -9.17| 0.50| 0.68|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|1e-6|576 |Throughput |16703| 14638| 13840|16930|17027|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-12.36|-17.14| 1.36| 1.94|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|3e-6|576 |Throughput | 9895| 7987 | 8086 |10255|10266|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-19.04|-18.03| 3.95| 4.06|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|1e-5|296 |Throughput | 3531| 2803 | 2950 | 3825| 3826|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-20.62|-16.45| 8.33| 8.35|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|3e-5|296 |Throughput | 1731| 1181 | 1317 | 1900| 1901|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-31.77|-23.92| 9.76| 9.82|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|1e-4|168 |Throughput | 504 | 342 | 366| 635| 636|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-32.14|-27.38|25.99|26.19|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|3e-4| 96 |Throughput | 97 | 80 | 91 | 202| 203|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-17.53| -6.19|108.2|109.3|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
Liao, et al. [Page 31]
draft-ietf-rohc-tcp-taroc-04.txt
A.3.2. 114kb
Sack
+----+------+-----------+-----+------+------+-----+-----+
|BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL|
| |(Byte)| | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|1e-8|576 |Throughput |12105| 12636| 12605|12660|12662|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 | 4.39| 4.13 | 4.58| 4.60|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|3e-8|576 |Throughput |12083| 12565|12474 |12642|12643|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 | 3.99 | 3.24 | 4.63| 4.63|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|1e-7|576 |Throughput |12030| 12329| 12165|12582|12587|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 | 2.49 | 1.12 | 4.59| 4.63|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|3e-7|576 |Throughput |11856| 11687|11326 |12392|12411|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 | -1.43| -4.47| 4.52| 4.68|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|1e-6|576 |Throughput |11213| 9871 | 9177 |11737|11740|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-11.97|-18.16| 4.63| 4.70|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|3e-6|576 |Throughput | 9258| 6578 | 6206 | 9719| 9784|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-28.95|-32.97| 4.98| 5.68|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|1e-5|296 |Throughput | 3883| 2622 | 2587 | 4236| 4239|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-32.47|-33.38| 9.09| 9.17|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
Liao, et al. [Page 32]
draft-ietf-rohc-tcp-taroc-04.txt
+----+------+-----------+-----+------+------+-----+-----+
|BER |MTU |Performance|NONE | VJHC | IPHC |TAROC|IDEAL|
| |(Byte)| | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|3e-5|296 |Throughput | 1786| 1111 | 1214 | 2000| 2012|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-37.79|-32.03|11.98|12.65|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|1e-4|168 |Throughput | 489 | 325 | 361 | 640| 652|
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-33.54|-26.18|30.88|33.33|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
|3e-4| 96 |Throughput | 92 | 81 | 88 | 202 | 203 |
| | | (Byte/s) | | | | | |
| | |-----------+-----+------+------+-----+-----+
| | |Improvement| 0 |-11.96| -4.35|119.6|120.7|
| | | (%s) | | | | | |
+----+------+-----------+-----+------+------+-----+-----+
A.3.3. 64kb
Reno
+----+------+-----------+----+------+------+-----+-----+
|BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL|
| |(Byte)| | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|1e-8|576 |Throughput |7317| 7743 | 7698 | 7763| 7764|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| 5.82 | 5.21 | 6.10| 6.11|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|3e-8|576 |Throughput |7312| 7716 | 7672 | 7756| 7757|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| 5.53| 4.92 | 6.07| 6.09|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|1e-7|576 |Throughput |7288| 7615 | 7556 | 7727| 7728|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| 4.49| 3.68 | 6.02| 6.04|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
Liao, et al. [Page 33]
draft-ietf-rohc-tcp-taroc-04.txt
+----+------+-----------+----+------+------+-----+-----+
|BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL|
| |(Byte)| | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|3e-7|576 |Throughput |7213| 7351 | 7222 | 7648| 7649|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| 1.91| 0.12 | 6.03| 6.04|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|1e-6|576 |Throughput |6966| 6612 | 6286 | 7387| 7398|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| -5.08| -9.76| 6.04| 6.20|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|3e-6|576 |Throughput |6206| 5070 | 4746 | 6562| 6580|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0|-18.30|-23.53| 5.74| 6.03|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|1e-5|296 |Throughput |3377| 2470 | 2312 | 3633| 3667|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0|-26.86|-31.54| 7.58| 8.59|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|3e-5|296 |Throughput |1576| 1065 | 1122 | 1755| 1773|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0|-32.42|-28.81|11.36|12.50|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|1e-4|168 |Throughput | 465| 319 | 340 | 595| 597|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0|-31.40|-26.88|27.96|28.39|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|3e-4| 96 |Throughput | 87| 79| 86 | 190| 194|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| -9.20| -1.15|118.4|123.0|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
Liao, et al. [Page 34]
draft-ietf-rohc-tcp-taroc-04.txt
A.3.4. 9.6kb
Sack
+----+------+-----------+----+------+------+-----+-----+
|BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL|
| |(Byte)| | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|3e-8|576 |Throughput |1116| 1187 | 1185 | 1190| 1191|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| 6.36| 6.18 | 6.63| 6.72|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|1e-8|576 |Throughput |1116| 1188 | 1186 | 1191| 1192|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| 6.45| 6.27 | 6.72| 6.81|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|1e-7|576 |Throughput |1116| 1183 | 1181 | 1190| 1191|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| 6.00| 5.82 | 6.63| 6.72|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|3e-7|576 |Throughput |1114| 1173 | 1172 | 1188| 1190|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| 5.30 | 5.21 | 6.64| 6.82|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|1e-6|576 |Throughput |1110| 1133 | 1144 | 1183| 1184|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| 2.07| 3.06 | 6.58| 6.67|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|3e-6|576 |Throughput |1089| 1036 | 1070 | 1164| 1167|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0| -4.87|-1.74 | 6.89| 7.16|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|1e-5|296 |Throughput | 979| 855 | 935 | 1122| 1123|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0|-12.67|-4.49 |14.61|14.71|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
Liao, et al. [Page 35]
draft-ietf-rohc-tcp-taroc-04.txt
+----+------+-----------+----+------+------+-----+-----+
|BER |MTU |Performance|NONE| VJHC | IPHC |TAROC|IDEAL|
| |(Byte)| | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|3e-5|296 |Throughput | 759| 500 | 600 | 900 | 908 |
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0|-34.12|-20.95|18.58|19.63|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|1e-4|168 |Throughput | 341| 224| 252 | 455| 465|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0|-34.31|-26.10|33.43|36.36|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
|3e-4| 96 |Throughput | 78| 67| 72 | 172| 173|
| | | (Byte/s) | | | | | |
| | |-----------+----+------+------+-----+-----+
| | |Improvement| 0|-14.10|-7.69 |120.5|121.8|
| | | (%s) | | | | | |
+----+------+-----------+----+------+------+-----+-----+
Liao, et al. [Page 36]
