Network Working Group Richard Price, Siemens/Roke Manor INTERNET-DRAFT Robert Hancock, Siemens/Roke Manor Expires: August 2001 Stephen McCann, Siemens/Roke Manor Mark West, Siemens/Roke Manor Abigail Surtees, Siemens/Roke Manor Paul Ollis, Siemens/Roke Manor Christian Schmidt, Siemens February 23, 2001 Robust TCP/IP Compression Using EPIC 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 [ROHC8] 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 [ROHC8] profile for RTP/UDP/IP. Price et al. [PAGE 1] INTERNET-DRAFT TCP/IP Compression February 23, 2001 Revision history WG submission: -00: Document submitted as WG draft Sequence number compression modified to handle retransmission or reordering of packets up to 100 places out of sequence PSH flag now transmitted in full for general TCP/IP compression (with optional profile for handling of well-behaved PSH flag) Encoding of other flags modified for improved compression Probabilities modified for enhanced compression ratio Individual submission: -00: Document created for robust TCP/IP compression Table of contents 1. Introduction.................................................2 2. General TCP/IP Profile.......................................2 2.1. Handling the TCP Sequence Number...........................3 2.2. Encoding method for a general TCP header...................5 2.3. Miscellaneous Information fields...........................6 2.4. INFERRED encodings.........................................7 2.5. IR and IR-DYN packets......................................8 3. Special Header Formats for Well-Behaved TCP/IP...............8 3.1. Unidirectional data transfer (data direction)..............8 3.2. Unidirectional data transfer (acknowledgement direction)....9 3.3. Static PSH Flag............................................9 4. Optional TCP Extensions......................................9 5. Performance results..........................................12 6. Security considerations......................................13 7. Acknowledgements.............................................13 8. Intellectual Property Considerations.........................13 9. References...................................................13 10. Authors' Addresses..........................................14 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 [ROHC8] TCP profile. EPIC also specifies how to use these header formats to compress and decompress headers. 2. General TCP/IP Profile The EPIC inputset for a general TCP/IP profile is given below. Further information on how to construct and process an inputset can be found in [EPIC]. Price et al. [PAGE 2] INTERNET-DRAFT TCP/IP Compression February 23, 2001 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 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/IP profile offers a minimum of 3 bits of CRC protection for every decompressed header, as well as a 4-bit sequence number to protect against up to 14 consecutive missing packets. This is an identical level of protection to the UO-mode compression of RTP/UDP/IP in [ROHC8]. 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 [ROHC8]. 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. Price et al. [PAGE 3] INTERNET-DRAFT TCP/IP Compression February 23, 2001 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 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 [ROHC8] 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. Price et al. [PAGE 4] INTERNET-DRAFT TCP/IP Compression February 23, 2001 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{"2920","2920",..."2920"} (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% | +------------------------+----------------------------+-------------+ | 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% | +------------------------+----------------------------+-------------+ | Urgent Pointer | STATIC | 99.9% | | +----------------------------+-------------+ | | IRREGULAR(16) | 0.1% | +------------------------+----------------------------+-------------+ Price et al. [PAGE 5] INTERNET-DRAFT TCP/IP Compression February 23, 2001 +------------------------+----------------------------+-------------+ | 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% | +------------------------+----------------------------+-------------+ | 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 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 Price et al. [PAGE 6] INTERNET-DRAFT TCP/IP Compression February 23, 2001 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 65535 (or FFFF in hex 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 65535 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,65535,...} 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. 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. Price et al. [PAGE 7] INTERNET-DRAFT TCP/IP Compression February 23, 2001 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 [ROHC8]. 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. 3. Special Header Formats for Well-Behaved TCP/IP The compressed header formats produced by the general TCP/IP 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/IP. 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 an 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 Price et al. [PAGE 8] INTERNET-DRAFT TCP/IP Compression February 23, 2001 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% | +------------------------+----------------------------+-------------+ 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% | +------------------------+----------------------------+-------------+ Price et al. [PAGE 9] INTERNET-DRAFT TCP/IP Compression February 23, 2001 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% | +------------------------+----------------------------+-------------+ 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: Price et al. [PAGE 10] INTERNET-DRAFT TCP/IP Compression February 23, 2001 +------------------------+----------------------------+-------------+ | 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: 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% | +------------------------+----------------------------+-------------+ Price et al. [PAGE 11] INTERNET-DRAFT TCP/IP Compression February 23, 2001 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 | +-------------------------+----------------------------------------+ 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. Price et al. [PAGE 12] INTERNET-DRAFT TCP/IP Compression February 23, 2001 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 [ROHC8]. 7. Acknowledgements Header compression schemes from [ROHC8] have been important sources of ideas and knowledge. Basic Huffman encoding [HUFF] was enhanced for the specific tasks of robust, efficient header compression. 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 standard 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, , Internet Engineering Task Force, February 23, 2001 [ROHC8] "RObust Header Compression (ROHC)", Carsten Bormann et Price et al. [PAGE 13] INTERNET-DRAFT TCP/IP Compression February 23, 2001 al, , Internet Engineering Task Force, February 7, 2001 [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 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 Christian Schmidt Tel: +49 89 722 27822 Email: christian.schmidt@icn.siemens.de Siemens ICM N MR ST1 Munich Germany Price et al. [PAGE 14]