[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
EPIC profile for TCP/IP
Hello,
I apologise for sending another large file
to the mailing list, but this is the only way I can
distribute this material before our presentation
later this morning.
Kind regards
Stephen McCann
Siemens (Roke Manor Research Ltd)
Southampton
UK
Network Working Group Richard Price, Siemens/Roke Manor
INTERNET-DRAFT Robert Hancock, Siemens/Roke Manor
Expires: May 2001 Stephen McCann, Siemens/Roke Manor
Mark West, Siemens/Roke Manor
Abigail Surtees, Siemens/Roke Manor
Christian Schmidt, Siemens
December 13, 2000
TCP/IP Profile For EPIC
<draft-price-rohc-epic-tcp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
This document is a submission to the IETF ROHC WG. Comments should be
directed to the mailing list of ROHC, rohc@cdt.luth.se.
Abstract
The Efficient Protocol Independent Compression [EPIC] scheme is a
general mechanism for providing additional profiles for use within
the [ROHC6] framework. The EPIC inputset is a list of fields from the
protocol stack to be compressed, and for each field a choice of
encoding techniques together with the probabilities that they will be
used. The output of EPIC is a set of optimally efficient compressed
header formats for the chosen protocol stack, and an automatic
mechanism for translating between compressed and uncompressed packet
formats.
This document describes an EPIC inputset for TCP. The resulting
header formats are extremely efficient (for FTP and HTTP data
transfers around 90% of the headers can be compressed down to 1 byte
plus CID and TCP checksum). Moreover the scheme has the same level of
robustness as the [ROHC6] profile for RTP/UDP/IP.
Price et al. [PAGE 1]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
1. Introduction
The robust compression of TCP/IP headers is greatly simplified by the
EPIC scheme. Several of the fields in a TCP header have complex
behavior; for example the Window field might remain static, might
alternate between a limited number of values or may even require LSB
encoding. EPIC allows these behaviors to be specified in the form of
an inputset, and then uses this information to automatically build an
optimally efficient set of compressed header formats for use in a
[ROHC6] TCP profile. EPIC also specifies how to use these header
formats to compress and decompress headers.
2. General TCP/IPv4 Profile
The EPIC inputset for a general TCP/IPv4 profile is given below.
Further information on how to construct and process an inputset can
be found in [EPIC].
Note that exactly the same TCP encoding can be used with IPv6. Only
the IP encoding need be changed in this case.
TCP/IPv4-ENCODING:
+------------------------+----------------------------+-------------+
| Field Name(s) | Encoding Method | Probability |
+------------------------+----------------------------+-------------+
| CRC | IRREGULAR(3) | 99% |
| +----------------------------+-------------+
| | IRREGULAR(7) | 1% |
+------------------------+----------------------------+-------------+
| Master Sequence Number | LSB(4,0) | 99% |
| +----------------------------+-------------+
| | LSB(7,112) | 1% |
+------------------------+----------------------------+-------------+
| TCP Header | TCP-ENCODING | 100% |
+------------------------+----------------------------+-------------+
| Inner IPv4 Header | IPv4-ENCODING | 100% |
+------------------------+----------------------------+-------------+
| Optional IP Extensions | EXTENSION-ENCODING | 100% |
+------------------------+----------------------------+-------------+
Notes:
The IPv4-ENCODING and EXTENSION-ENCODING are the same as for
RTP/UDP/IPv4 compression, and can be found in [EPIC].
The Inner IPv4 header is the mandatory IPv4 header below the TCP
header. An optional IP header (known as the Outer IP header) may also
be present for IP tunneling. This optional header is included as part
of the EXTENSION-ENCODING.
The TCP/IPv4 profile offers a minimum of 3 bits of CRC protection for
every decompressed header, as well as a minimum 4-bit sequence number
to protect against up to 14 consecutive missing packets. This is an
Price et al. [PAGE 2]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
identical level of protection to the UO-mode compression of
RTP/UDP/IP in [ROHC6]. The CRC and Master Sequence Number fields are
defined in [EPIC].
Static and dynamic context-initializing and updating packets will be
required to convey context information. The framework for the use of
these packets is defined within [ROHC6].
2.1. Handling the TCP Sequence Number
The TCP Sequence Number behaves very differently from the RTP
Sequence Number. Most obviously, for each new header the TCP Sequence
Number does not increase by 1 but instead by the payload length of
the preceding packet. Another problem is that TCP retransmits
packets, and so it is possible for the sequence number to remain
constant or even jump backwards compared to the previous received
packet.
Fortunately, the TCP Sequence Number can be compressed in a similar
manner to the RTP Timestamp. It can usually be inferred by adding the
previous payload length to the TCP Sequence Number stored in the
context. This is not possible if one or more packets have been lost
or reordered, so the TCP profile includes a Master Sequence Number to
count the number of missing packets. A minimum of 4 LSBs of the
Master Sequence Number are included in every compressed header.
Even when packets have been lost or reordered, it is still possible
to infer the TCP Sequence Number by filling in the missing payload
sizes with a value known as the Expected Payload Size. The
decompressor can use a constant Expected Payload Size for every
missing packet (e.g. 1460 bytes is a common payload size for IP over
Ethernet), or it can cycle through a table of up to 16 different
Expected Payload Sizes. This latter behavior is extremely useful for
FTP data transfer, because the data flow often consists of 1460 byte
payloads interspersed with a smaller payload size at regular
intervals.
The only problem with this method occurs when a missing packet does
not have the Expected Payload Size. This can be accommodated by
transmitting LSBs of the TCP Sequence Number value just as for an RTP
Timestamp jump. The decompressor estimates the TCP Sequence Number by
giving every missing packet the Expected Payload Size, and then
refines this estimate using as many Sequence Number LSBs as it has
received in the compressed header. In general the compressor must
transmit Sequence Number LSBs in the compressed header immediately
following a packet with an unexpected payload size, and in as many
subsequent packets as needed to ensure robustness. It may happen that
the packet with irregular payload size is not lost, in which case the
decompressor will calculate the TCP Sequence Number exactly and the
Sequence Number LSBs will merely confirm that correct decompression
has occurred.
Note that in contrast to RTP, it is perfectly acceptable for the
Master Sequence Number to remain constant or even jump backwards in
Price et al. [PAGE 3]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
the case of packet retransmission. For this reason it may be
necessary to include extra LSBs of the Master Sequence Number in a
compressed header. To provide robustness against up to 14 consecutive
missing packets, the decompressor MUST allow the Master Sequence
Number to increase by at most 15, with any other change interpreted
as no change or a decrease. For example, if 7 LSBs are included in a
compressed header then at the decompressor the Master Sequence Number
may increase by at most 15 or it may decrease by at most 112. See
[ROHC6] Section 4.5.1 for further details on offset LSB encoding.
The TCP Acknowledgement Number is compressed in a similar manner to
the TCP Sequence Number. The only difference is that the
Acknowledgement Number cannot be inferred from the previous header;
it must always be estimated from the Expected Acknowledgement Size
and refined by Acknowledgment Number LSBs transmitted in the
compressed header.
2.2. Encoding method for a general TCP header
An encoding method for a general TCP header is described below. The
notation used in this section is described in more detail in [EPIC].
TCP-ENCODING: PAYLOAD{"1460","1460",...,"1460"} (16 entries)
ACK{"1460","1460",..."1460"} (16 entries)
PRIMARY{""}
SECONDARY{""}
+------------------------+----------------------------+-------------+
| Field Name(s) | Encoding Method | Probability |
+------------------------+----------------------------+-------------+
| Source Port | STATIC | 100% |
| Destination Port | | |
+------------------------+----------------------------+-------------+
| ACK Flag | VALUE("1") | 100% |
+------------------------+----------------------------+-------------+
| SYN Flag | VALUE("0") | 100% |
+------------------------+----------------------------+-------------+
| RST Flag | VALUE("0") | 99.9% |
| URG Flag +----------------------------+-------------+
| | VALUE("1") | 0.1% |
+------------------------+----------------------------+-------------+
| Data Offset | INFERRED | 100% |
| Sequence Number | | |
| Acknowledgement Number | | |
+------------------------+----------------------------+-------------+
| FIN Flag | VALUE("0") | 95% |
| +----------------------------+-------------+
| | VALUE("1") | 5% |
+------------------------+----------------------------+-------------+
| PSH Flag | IRREGULAR(1) | 100% |
+------------------------+----------------------------+-------------+
| TCP Checksum | IRREGULAR(16) | 100% |
+------------------------+----------------------------+-------------+
Price et al. [PAGE 4]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
+------------------------+----------------------------+-------------+
| Sequence Number LSBs | IRREGULAR(0) | 77% |
| Ack Number LSBs +----------------------------+-------------+
| | IRREGULAR(11) | 22% |
| +----------------------------+-------------+
| | IRREGULAR(16) | 0.9% |
| +----------------------------+-------------+
| | IRREGULAR(23) | 0.09% |
| +----------------------------+-------------+
| | IRREGULAR(32) | 0.01% |
+------------------------+----------------------------+-------------+
| Reserved | VALUE("000000") | 100% |
+------------------------+----------------------------+-------------+
| Window | READ(PRIMARY,1) | 89% |
| +----------------------------+-------------+
| | READ(SECONDARY,1) | 10% |
| +----------------------------+-------------+
| | LSB(11,2^11) | 0.8% |
| +----------------------------+-------------+
| | WRITE(16,PRIMARY,1) | 0.1% |
| +----------------------------+-------------+
| | WRITE(16,SECONDARY,1) | 0.1% |
+------------------------+----------------------------+-------------+
| Urgent Pointer | STATIC | 99.9% |
| +----------------------------+-------------+
| | IRREGULAR(16) | 0.1% |
+------------------------+----------------------------+-------------+
| Expected Payload Size | STATIC | 99.9% |
| +----------------------------+-------------+
| | WRITE(16,PAYLOAD,16) | 0.1% |
+------------------------+----------------------------+-------------+
| Expected Ack Size | STATIC | 99.9% |
| +----------------------------+-------------+
| | WRITE(16,ACK,16) | 0.1% |
+------------------------+----------------------------+-------------+
| TCP Options | TCP-OPTIONS | 100% |
+------------------------+----------------------------+-------------+
Notes:
The Window field has two lookup tables each containing one entry,
which are used to store the most common and the second most common
value of the Window field. This is a very efficient encoding for the
Window field, as it usually remains constant or alternates between
two principal values. If the Window field does not take one of these
values then it can be sent using LSB encoding.
The encoding methods for TCP options are described in Chapter 4.
2.3. Miscellaneous Information fields:
The Miscellaneous Information fields are used by EPIC to carry
control information from the compressor to the decompressor. These
Price et al. [PAGE 5]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
fields are not present in the decompressed header. The following TCP-
specific Miscellaneous Information fields are required:
Sequence Number LSBs: Whenever a header does not have the Expected
Payload Size, it is necessary to send LSBs of the TCP Sequence Number
in subsequent packets in case the header with unexpected payload size
is lost. The LSBs are used to refine the estimate of the TCP Sequence
Number at the decompressor. In general the compressor must send
enough LSBs to ensure that the decompressor will correctly
reconstruct the TCP Sequence Number.
Acknowledgement Number LSBs: This field carries the LSBs of the TCP
Acknowledgement Number whenever a packet does not have the Expected
Acknowledgement Size.
Expected Payload Size: If packets are dropped then the decompressor
infers the TCP Sequence Number on the assumption that the dropped
packets have a certain Expected Payload Size. The Sequence Number
LSBs are used to refine this assumption if necessary.
A maximum of 16 Expected Payload Sizes can be specified, and they are
stored in a lookup table named PAYLOAD. The value "-1" (or
1111111111111111 in binary since the lookup table holds 16-bit
values) is used to indicate the number of Expected Payload Sizes
stored in the table. Suppose that there are N items in the lookup
table up to (but not including) the first "-1" entry, and that the
decompressor wishes to estimate the payload size of a packet with
Master Sequence Number M. The Expected Payload Size for this packet
is found from the lookup table named PAYLOAD, indexed by M modulo N.
It is very useful to specify multiple Expected Payload Sizes since a
TCP flow often alternates between a small number of well known
payload sizes. For example an FTP data transfer might send 5 packets
with a payload of 1460 bytes followed by a packet with a payload of
892 bytes (giving a total of 8192 bytes, which is the buffer size for
the source of the FTP data transfer). In this case the lookup table
should be filled with the following entries:
PAYLOAD{1460,1460,1460,1460,1460,892,-1,...}
Provided that the FTP data transfer follows this pattern, no extra
information need be sent to infer the TCP Sequence Number.
Expected Acknowledgement Size: If packets are dropped then the
decompressor infers the TCP Acknowledgement Number on the assumption
that the dropped packets acknowledge this amount of data.
A maximum of 16 Expected Acknowledgement Sizes can be specified. They
are stored in the ACK lookup table in exactly the same manner as the
Expected Payload Sizes.
Price et al. [PAGE 6]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
2.4. INFERRED encodings:
The Data Offset is inferred by summing the length of the basic TCP
header plus the lengths of all the TCP options present in the stack.
The TCP Sequence Number field is inferred by examining the Master
Sequence Number of the compressed header, and choosing the TCP
Sequence Number of the packet with the closest Master Sequence
Number that has been successfully decompressed (and is still present
in the context). Usually this will be the preceding packet, unless
packets have been dropped or reordered.
Any packets with Master Sequence Number between the successfully
decompressed packet up to the header waiting to be decompressed have
their payload sizes added to this TCP Sequence Number (or subtracted
in the case that the header waiting to be decompressed has a smaller
Master Sequence Number than the successfully decompressed packet).
Missing packets are assumed to have the Expected Payload Size as
explained in Section 2.3. If Sequence Numbers LSBs are sent then
they are used to replace the LSBs of the estimated TCP Sequence
Number.
Note that to cope effectively with retransmitted or reordered
packets, it is useful for the decompressor to store multiple
decompressed headers in the context (or at least their TCP Sequence
Numbers and payload sizes). It is not necessary to store all of the
previously received headers since their payload sizes can be
estimated from the Expected Payload Size table; however this often
requires LSBs of the TCP Sequence Number to be transmitted in the
compressed header to refine the estimate.
The TCP Acknowledgement Number field is inferred in the same manner
as the TCP Sequence Number. The only difference is that the amount
of data acknowledged by a packet cannot be inferred from the
previous packet, and so it must always be estimated by the Expected
Acknowledgment Size and refined by Acknowledgement Number LSBs if
necessary.
2.5. IR and IR-DYN packets
This draft currently only defines the profile in terms of the
generation of compressed packet formats. In addition, static (IR)
and dynamic (IR-DYN) packet formats will need to be defined. These
should be structured in the same way as the equivalent packets for
RTP/UDP/IP in [ROHC6].
Generally, the classification of fields within the profile can be
used to guide this process. Those fields that are solely 'STATIC'
belong in the IR packet and the remainder need to be collated within
the IR-DYN packet.
Price et al. [PAGE 7]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
3. Special Header Formats for Well-Behaved TCP/IPv4
The compressed header formats produced by the general TCP/IPv4
inputset are efficient for almost any TCP stream. However, it is
possible to obtain even better efficiency by constructing a reduced
inputset for well-behaved TCP/IPv4.
Note that the following inputsets assume that certain field behaviors
are not possible. This improves the efficiency of the compression
when the TCP stream obeys the assumptions but reduces the efficiency
when the assumptions are not followed (since the information must be
sent in a IR or IR-DYN packet).
3.1. Unidirectional data transfer (data direction)
A unidirectional data transfer (for example an FTP file download) has
the following simplifications in the data download direction:
- No Acknowledgement Number change
- No Window change
- No URG Flag change
Consequently it is possible to code the Acknowledgement Number,
Window and URG Flag fields as STATIC with 100% probability. Also, the
Ack Number LSBs and Expected Ack Size fields are no longer needed.
3.2. Unidirectional data transfer (acknowledgement direction)
The acknowledgement for the unidirectional data transfer has the
following simplifications:
- No Sequence Number change
- No URG Flag change
Consequently it is possible to code the Sequence Number and URG Flag
fields as STATIC with 100% probability. Also, the Sequence Number
LSBs and Expected Payload Size fields are no longer needed.
3.3. Static PSH Flag
The PSH Flag is transmitted in full for the general TCP inputset,
since it is possible for this flag to behave in an irregular manner
for certain TCP implementations. However, in many implementations the
PSH flag is usually static. In this case it can be more efficiently
encoded as follows:
+------------------------+----------------------------+-------------+
| PSH Flag | STATIC | 99% |
| +----------------------------+-------------+
| | IRREGULAR(1) | 1% |
+------------------------+----------------------------+-------------+
Price et al. [PAGE 8]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
4. Optional TCP Extensions
This chapter lists the EPIC inputsets for two optional TCP
extensions: the SACK and the Timestamp. In general the TCP options
are encoded as follows:
TCP-OPTIONS:
+------------------------+----------------------------+-------------+
| Field Name(s) | Encoding Method | Probability |
+------------------------+----------------------------+-------------+
| SACK | IRREGULAR(0) | 95% |
| +----------------------------+-------------+
| | SACK-PRESENT | 5% |
+------------------------+----------------------------+-------------+
| Timestamp | IRREGULAR(0) | 80% |
| +----------------------------+-------------+
| | TIMESTAMP-PRESENT | 20% |
+------------------------+----------------------------+-------------+
| Padding | INFERRED | 100% |
+------------------------+----------------------------+-------------+
Notes:
The IRREGULAR(0) encoding method is used to indicate that the SACK or
the Timestamp option is not present in the uncompressed header.
The Padding field is inferred by adding sufficient "0" bits to ensure
that the decompressed header is a multiple of 32 bits long.
The encoding method for an optional SACK extension is given below:
SACK-PRESENT:
+------------------------+----------------------------+-------------+
| Field Name(s) | Encoding Method | Probability |
+------------------------+----------------------------+-------------+
| SACK Kind | VALUE("00000101") | 100% |
+------------------------+----------------------------+-------------+
| SACK Length | INFERRED | 100% |
| SACK Edges | | |
+------------------------+----------------------------+-------------+
| Block 1 Offset LSBs | 1-BLOCKS | 80% |
| ... +----------------------------+-------------+
| Block 4 Offset LSBs | 2-BLOCKS | 15% |
| Block 1 Size LSBs +----------------------------+-------------+
| ... | 3-BLOCKS | 4.9% |
| Block 4 Size LSBs +----------------------------+-------------+
| | 4-BLOCKS | 0.1% |
+------------------------+----------------------------+-------------+
Price et al. [PAGE 9]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
Notes:
The SACK Length field is inferred from the number of SACK blocks
present in the SACK option.
At most 4 SACK blocks can be present in the SACK option. Consequently
there are 8 SACK Edges fields, namely the Left Edge and Right Edge
for each of the SACK blocks present in the extension. Each of these
fields is inferred from the Block Offset LSBs and the Block Size LSBs
as described below.
The Block Offset LSBs and Block Size LSBs fields are all
Miscellaneous Information fields.
The Block Offset LSBs measure the distance between the
Acknowledgement Number in the TCP header and the Left Edge of the
SACK block. The Block Size LSBs measure the distance between the Left
Edge and the Right Edge of the SACK block.
The encoding method for n SACK blocks is as follows (1 <= n <= 4).
Note that if the 1-BLOCKS encoding method is selected then there is 1
SACK block present in the uncompressed header etc.
n-BLOCKS:
+------------------------+----------------------------+-------------+
| Field Name(s) | Encoding Method | Probability |
+------------------------+----------------------------+-------------+
| Block 1 Offset LSBs | IRREGULAR(12) | 30% |
| ... +----------------------------+-------------+
| Block n Offset LSBs | IRREGULAR(16) | 50% |
| +----------------------------+-------------+
| | IRREGULAR(24) | 19% |
| +----------------------------+-------------+
| | IRREGULAR(32) | 1% |
+------------------------+----------------------------+-------------+
| Block 1 Size LSBs | IRREGULAR(12) | 10% |
| ... +----------------------------+-------------+
| Block n Size LSBs | IRREGULAR(16) | 70% |
| +----------------------------+-------------+
| | IRREGULAR(24) | 19% |
| +----------------------------+-------------+
| | IRREGULAR(32) | 1% |
+------------------------+----------------------------+-------------+
| Block n+1 Offset LSBs | IRREGULAR(0) | 100% |
| ... | | |
| Block 4 Offset LSBs | | |
| Block n+1 Size LSBs | | |
| ... | | |
| Block 4 Size LSBs | | |
+------------------------+----------------------------+-------------+
The encoding method for an optional Timestamp extension is given
below:
Price et al. [PAGE 10]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
TIMESTAMP-PRESENT:
+------------------------+----------------------------+-------------+
| Field Name(s) | Encoding Method | Probability |
+------------------------+----------------------------+-------------+
| TS Kind | VALUE("00001000") | 100% |
+------------------------+----------------------------+-------------+
| TS Length | VALUE("00001010") | 100% |
+------------------------+----------------------------+-------------+
| TS Value | LSB(8,-1) | 90% |
| +----------------------------+-------------+
| | LSB(16,-1) | 9% |
| +----------------------------+-------------+
| | LSB(24,-1) | 0.9% |
| +----------------------------+-------------+
| | IRREGULAR(32) | 0.1% |
+------------------------+----------------------------+-------------+
| TS Echo Reply | LSB(8,-1) | 90% |
| +----------------------------+-------------+
| | LSB(16,-1) | 9% |
| +----------------------------+-------------+
| | LSB(24,-1) | 0.9% |
| +----------------------------+-------------+
| | IRREGULAR(32) | 0.1% |
+------------------------+----------------------------+-------------+
5. Performance results
A reference implementation of EPIC is available from [IMPL]. The TCP
inputset has been programmed into the reference implementation and
sets of compressed header formats have been generated for different
types of TCP data.
To ensure a fair comparison between each set of results, a constant 3
bits of CRC protection and 4 bits of sequence number are included in
every packet to provide robustness. The TCP checksum adds a constant
2 bytes. The profile is run in O-mode, and the STATIC and DYNAMIC
packets are not included in the compressed header size.
The average compressed header sizes for different types of TCP data
are listed below (including the 2 byte TCP checksum and a 1 byte CID
for the Mixed flow):
+-------------------------+----------------------------------------+
| Type of TCP Flow | Average Compressed Header Size (bytes) |
+-------------------------+----------------------------------------+
| HTTP (data direction) | 3.21 |
| HTTP (ack. direction) | 3.60 |
| | |
| FTP (data direction) | 3.40 |
| FTP (ack. direction) | 3.52 |
| | |
| Mixed | 5.04 |
+-------------------------+----------------------------------------+
Price et al. [PAGE 11]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
Note that in the data direction, the HTTP flow achieves a smaller
average compressed header size than the FTP flow. This is because the
HTTP flow tested is relatively well-behaved, with over 90% of the
packets containing 1460 bytes of payload. In contrast the FTP flow
alternates between two common payload sizes (1460 and 892 bytes) on a
fairly random basis.
In the acknowledgement direction the FTP flow compresses more
efficiently than the HTTP flow. This is largely because the FTP flow
has a constant Window field but the HTTP flow does not.
The Mixed TCP data includes HTTP, FTP, XWIN and Telnet traffic. Mixed
TCP data requires a larger average compressed header size because the
fields such as the Sequence Number and Acknowledgement Number behave
in a more random manner than for HTTP or FTP alone.
These results are preliminary: it should be possible to achieve
greater compression by refining the TCP/IPv4 inputset to better
reflect an actual TCP flow. Moreover it may be possible to utilize
the bi-directionality of TCP, for example by storing all of the
recent TCP Sequence Numbers in a lookup table at the compressor and
then transmitting the TCP Acknowledgement Numbers for the reverse
flow using this lookup table. This enhancement should reduce the
average size of an acknowledgement header even further.
Another important issue is the trade-off between the number of
contexts and the amount of static data. It is likely that the TCP
flows to be compressed will contain mixed types of data (HTTP, FTP,
XWIN, Telnet etc.) with the same IP addresses but different source
and destination ports. In this case it might be useful to introduce
the notion of contexts and sub-contexts, where all of the TCP flows
with fixed IP addresses are treated as part of the same context but
divided into different sub-contexts based on ports. The advantage of
this scheme is that fields in the IP header (such as the IP ID) can
be most efficiently compressed on a per-context basis but fields in
the TCP header are more efficiently compressed on a per-flow basis.
6. Security Considerations
EPIC generates compressed header formats for direct use in ROHC
profiles. Consequently the security considerations for EPIC match
those of [ROHC6].
7. Acknowledgements
Header compression schemes from [ROHC6] have been important sources
of ideas and knowledge. Basic Huffman encoding [HUFF] was enhanced
for the specific tasks of robust, efficient header compression.
Price et al. [PAGE 12]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
Thanks to
Carsten Bormann (cabo@tzi.org)
Max Riegel (maximilian.riegel@icn.siemens.de)
for valuable input and review.
8. Intellectual Property Considerations
This proposal in is full conformity with [RFC-2026].
Siemens may have patent rights on technology described in this
document which employees of Siemens contribute for use in IETF
standards discussions. In relation to any IETF standards
incorporating any such technology, Siemens hereby agrees to license
on fair, reasonable and non-discriminatory terms, based on
reciprocity, any patent claims it owns covering such technology, to
the extent such technology is essential to comply with such
standard.
9. References
[EPIC] "Efficient Protocol Independent Compression (EPIC)",
Price et al, <draft-price-rohc-epic-00.txt>, Internet
Engineering Task Force, November 17, 2000
[ROHC6] "RObust Header Compression (ROHC)", Carsten Bormann et
al, <draft-ietf-rohc-rtp-06.txt>, Internet Engineering
Task Force, November 24, 2000
[HUFF] "The Data Compression Book", Mark Nelson and Jean-Loup
Gailly, M&T Books, 1995
[IMPL] http://www.roke.co.uk/networks/epic/epic.html
[RFC-2026] "The Internet Standards Process - Revision 3", Scott
Bradner, Internet Engineering Task Force, October 1996
10. Authors' Addresses
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
Price et al. [PAGE 13]
INTERNET-DRAFT TCP/IP Profile For EPIC December 11, 2000
Abigail Surtees Tel: +44 1794 833131
Email: abigail.surtees@roke.co.uk
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
Christian Schmidt Tel: +49 89 722 27822
Email: christian.schmidt@icn.siemens.de
Siemens ICM N MR MA1
Munich
Germany
Price et al. [PAGE 14]