Robust Header Compression Tom Hiller Internet Draft Pete McCann Document: draft-hiller-rohc-gehco-00.txt Lucent Technologies Category: Standards Track August 2000 Good Enough Header COmpression (GEHCO) Status of this Memo This document is an Internet-Draft and is in full conformance withall provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 1. Abstract The Robust Header Compression Working Group has embarked upon the development and standardization of header compression schemes that perform well over links with high error rates and long round-trip times. The goal is that the schemes must perform well for cellular links built using technologies such as WCDMA, EDGE, and CDMA-2000. One way the group plans to achieve this is by maintaining connections with other standardization organizations developing cellular technology for IP, such as 3GPP and 3GPP-2, to ensure that its output fulfills their requirements and will be put to good use. Of particular importance to the 3GPP2 community is the spectral efficiency of IP/UDP/RTP header compression for the voice over IP application to mobiles. Currently, the ROHC Working Group is focusing on compression schemes where the uncompressed header is identical to the original header seen by the compressor. This may be categorized as transparent compression. Transparent compression results in additional header bytes being transported over-the-air. 3GPP2 carriers have indicated that no additional bytes may be transported over-the-air for voice over IP, that is, that voice over IP must have spectral efficiency comparable to legacy circuit Hiller, McCann Standards Track - January 2000 1 Good Enough Header Compression (GEHCO) August 2000 transport over-the-air. This draft proposes a specific scheme, Good Enough Header Compression (GEHCO) that does not exactly reproduce the IP/UDP/RTP header, but is otherwise "good enough" for voice over IP applications over cellular links found in 3GPP2 3G wireless networks. This particular scheme is applicable to certain cellular links that synchronously transport vocoded or other multimedia payloads so that the compressor may be certain that the compressed frame will be delivered with a fixed and predictable delay. One example of such a cellular link is the cdma2000 air interface with cdma2000 vocoders. A summary of the cdma2000 link characteristics is provided herein. 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 [2]. 3. Introduction With the development of SIP [3], it is likely that new services will be created that require support of SIP in mobile endpoints. In concert, a need will then arise to support the transport of RTP packets to and from an endpoint. Voice sessions transmit short frames of data, usually on a continuous basis according to known activity factors. The frequency and length of the voice packets requires compression of RTP packet overhead in order to justify such service relative to not using VOIP (or IP based multimedia) at all. Such compression schemes rely on a lower data link layer for framing (e.g. to provide a length) and while they can reduce the impact of header overhead, they still require some additional bandwidth compared to the existing circuit voice channel to carry the compressed header bytes and feedback packets. The Robust Header Compression Working Group has embarked upon the development and standardization of header compression schemes that perform well over links with high error rates and long round-trip times. The goal is that the schemes must perform well for cellular links built using technologies such as WCDMA, EDGE, and cdma2000. The ROHC group plans to achieve its goals by maintaining connections with other standardization organizations developing cellular technology for IP, such as 3GPP and 3GPP2. Of particular importance to the 3GPP2 community is the spectral efficiency of IP/UDP/RTP header compression for voice-over-IP application to mobiles. Hiller, McCann January 2000 - Expiration 2 Good Enough Header Compression (GEHCO) August 2000 A number of RTP compression algorithms have emerged recently in the IETF. A few are: * Enhanced CRTP [3] * ROCCO [4] * ACE [5] This list is not exhaustive. These algorithms are able to reduce the IP/UDP/RTP overhead to one or two bytes. They are also able to tolerate some loss of packets and still maintain local decompression state without complete retransmission of a new IP/UDP/RTP header. In addition to the one or two bytes of header overhead some amount of bandwidth is necessary for feedback between decompressor and compressor to retransmit a partial or complete header when the local state cannot be repaired. Transparent compression results in additional header bytes being transported over-the-air. 3GPP2 carriers have indicated that voice over IP must have spectral efficiency comparable to legacy circuit transport over-the-air in order for them to deploy voice-over-IP to mobiles. To achieve such spectral efficiency, IP/UDP/RTP header compression must not transport any additional bytes over-the-air. Such a scheme will not exactly reproduce all bits of the IP/UDP/RTP header, however, the behavior of the reproduced header is "good enough" for voice-over-IP applications over cellular links. Such header compression may be categorized as non-transparent header compression. This draft first discusses the characteristics of the cdma2000 link layer that makes GEHCO possible. It then reviews the impact of other proposed IP/UDP/RTP header compression schemes on the spectral capacity in the context of low bit rate vocoders. The additional impact of the data link layer such as PPP is also considered. . Finally, the draft discusses a particular approach for non-transparent header compression called Good Enough Header COmpression (GEHCO). 4 cdma2000 Link Characteristics The cdma2000 link synchronously transports physical frames every 20ms. The number of bytes in a physical frame varies based on signaling negotiation between the user and the radio network as well as other criteria, such as backlog (for the forward direction of the network to mobile). The physical frames are sent in over- the-air connections. Currently, six such connections may exist simultaneously. The connections feature two modes, one in which the physical frames are subject to retransmission, and another in which they are not. The over-the-air connections are referred to as Radio Link Protocol (RLP) instances. The mode with retransmission serves to improve the error rate and thereby improve the throughput of TCP. It has variable delay. The one without retransmission behaves Hiller, McCann January 2000 - Expiration 3 Good Enough Header Compression (GEHCO) August 2000 synchronously and each 20ms frame has a fixed number of bits such that the physical frame will be delivered in 20ms. There are four types of physical frames: full rate (172 bits), half rate (80 bits), quarter rate (40 bits) and eighth rate (16 bits). One reason for these different "rate" frames is variable vocoding. Depending on speech activity and patterns, the vocoder puts out a number of bytes that exactly fits one of these four physical frame sizes. The over-the-air connections have priority. Voice payloads are sent in over-the-air connections with high priority in the mode without any retransmission. It is possible to say with certainty for these kinds of frames that if a physical frame is transmitted it will be delivered 20ms later, if it is received at all. We consider the frame to not be "received" if it has uncorrectable errors. 5. Transparent Compression and Spectral Efficiency 3GPP2 vendors and service providers are developing a vocoder referred to as Selectable-Mode-Vocoder (SMV) which outputs encoded voice frames every 20ms. Like other low bit rate vocoders, this one does not output constant bit rate. Table 1 [7] shows the percentages of times that the vocoder is outputting various payloads (measured in terms of numbers of bits in a given payload). (Note that the activities sum to 100% so that the vocoder outputs a voice frame every 20ms). Rate Activity % Payload (bits) Full 20 172 Half 20 80 Quarter 10 40 Eighth 50 16 Table 1: Activity of a 3GPP-2 Vocoder As can be seen, even one or two bytes of data per vocoded frame represents a considerable taxation on the spectral capacity of the system. In the current 3GPP2 wireless packet data architecture, byte oriented HDLC framing provides packet delimitation. 3GPP2 selected byte oriented HDLC [8] and PPP [9] due to its wide deployment in operating systems commonly found in laptops and other portable devices, as well as its ability to flexibly negotiate data link configurations. PPP overhead may be compressed by having the mobile negotiate the address/control/protocol fields to one byte, and negotiate no CRC via RFC 1570 [10]. This reduces PPP overhead to two bytes of overhead per vocoder frame, that is one protocol ID byte and one flag between frames. Hiller, McCann January 2000 - Expiration 4 Good Enough Header Compression (GEHCO) August 2000 Assuming one overhead byte for IP/UDP/RTP transparent compression schemes, and two bytes for PPP, the compressed overhead header bytes will exceed the payload 50% of the time. Even at peak vocoder output, the compressed headers amount to a 16% spectral tax [11]. If two bytes of IP/UDP/RTP compression control bytes are needed, the overhead is even worse. This quick analysis assumes that there is no need for IP packets to be synchronized with the physical frame. It also ignores payload expansion due to HDLC escaping. Since the taxation is a result of the shortness of the vocoded voice frame, one might try to aggregate voice frames into a single IP/UDP/RTP packet. If more vocoded frames could be combined within one RTP packet, then loss of spectrum capacity would correspondingly decrease. Given that many of the packets are very short, aggregating more vocoder frames (20ms frames) does not necessarily create PPP frames larger than the basic rate, 172-bit payload. This approach does imply additional delay end to end. The number of voice frames aggregated into a VOIP packet should be adjusted dynamically based on the coding rate. Dynamic aggregation requires a scheme for delimiting the vocoded frames within the RTP payload which might consume three to five bits per packet. This approach also requires more study to determine if users can, for example, tolerate the added 20ms delay incurred by aggregating two short vocoder frames into one PPP frame. Such an analysis should probably consider the case when there is an IP multimedia conference bridge involved. For this case, each direction then requires two voice encodes and decodes so that the bridge can sum the speech from the call participants, which gives rise to additional delay. 6. Non-Transparent Header Compression A different method to improve spectral efficiency may be to simply not transmit the RTP or PPP headers with the vocoded frames, but instead construct IP/UDP/RTP headers at the decompressor based on state context information forwarded to the decompressor by the compressor. The IP/UDP/RTP header reconstructed by the decompressor does not match the original IP/UDP/RTP sent packet bit for bit. Some fields such as RTP sequence counts and UDP CRC may be altered from an end-to-end point of view. Non-transparent header compression results in no loss of spectrum capacity (except for a couple of control packets involved in arranging the non-transparent compression). This form of compression has also been called _header stripping and regeneration._ The compressor removes headers before transmitting and the decompressor creates IP/UDP/RTP header information including RTP sequence counts. Static header information such as IP address and UDP port will exactly match those sent by the transmitter. Other header information such as RTP sequence counts may not, hence the category _non transparent compression". Hiller, McCann January 2000 - Expiration 5 Good Enough Header Compression (GEHCO) August 2000 There are a variety of methods to implement non-transparent header compression. This contribution will focus upon header compression using link (PPP) control mechanisms we refer to as _Good Enough Header COmpression (GEHCO)". Compressed voice (e.g. SMV) is sent with no headers (i.e. no PPP, IP, UDP, or RTP) over-the-air in physical frames and the decompressor regenerates all IP/UDP/RTP headers. This includes RTP sequence counts and UDP checksum. The compressor's job is simply to delete the various IP/UDP/RTP headers and pass the compressed voice to air framing hardware for transmission over the air interface. The decompressor's job is to wrap the compressed voice in an IP/UDP/RTP packet, creating sequence numbers and checksums as necessary. Depending on the vocoder used, the decompressor may wrap and forward erred data in RTP packets. Regardless, the decompressor increments a sequence count for each received physical frame. The receiver may then use the payload bits or the sequence numbers to detect missing packets and possibly mask the error. The compressor and decompressor communicate via an over-the-air connection established to transport the voice frames. As explained above, the cdma2000 link can support an over-the air connection that transports payloads synchronously in physical frames every 20ms. The type of over-the-air connection for voice has priority and the vocoder output will dictate the size of the physical frame. This connection inherently provides framing for the vocoder voice frames, that is,we are not using a transparent data link layer like byte HDLC for framing. This connection is separate from the over- the-air connection over which usual PPP frames flow. That connection has lower priority and the physical frames on that connection will be subject to retransmission. There will be one RTP flow per over-the-air connection, since otherwise it is impossible to distinguish flows given no headers exist with the payloads. The physical basis and control (e.g. establishment and release) of connections for the usual PPP frames and for the voice frames is outside the scope of this document. In Section 7, we refer to the over-the-air connection that transports voice payloads as the "vocoder connection" and the one that transports PPP frames as the "PPP connection". In the network to mobile station direction (forward direction), the RTP packets received from the IP network will experience variable delays. The gateway (PPP termination point) will buffer some packets to compensate for jitter in the IP network. Because the over-the air connection that transports the RTP payloads is synchronous, does not feature retransmission, and has high priority, the gateway can simply play out the payloads of the RTP packets over the vocoder connection. These physical frames will be delivered exactly 20ms later. The decompressor in the mobile then Hiller, McCann January 2000 - Expiration 6 Good Enough Header Compression (GEHCO) August 2000 will assign timestamps that increment by 20ms each frame and deliver the packets to the IP layer in the mobile station. The loss of RTP packets in the network, or possibly significant delays due to transient congestion, could cause buffer under-run at the gateway. In this case the compressor has no frame to output on the over-the-air link used to carry the voice frames. One solution is to have the compressor output a "NO DATA" frame over-the-air to the decompressor. This would be part of the air interface definition and would be analogous to an approach pursued in 3GPP [12] for this same purpose. The decompressed IP/UDP/RTP packets are not bit for bit identical end-to-end but there is no impact to the service. The term _good enough_ means that the compression/decompression scheme is adequate for transport of voice sessions even though the headers are not reconstructed exactly. For example, RTP sequence counts sent by the mobile can differ from those sent by the network to other endpoints involved in a given multimedia call if the receiver does not start counting physical frames precisely at the same time the transmitter begins to send physical frames. While different RTP sequence counts and time stamps will imply different UDP checksums, the receiver will be able to make use of all generated RTP sequence counts and time stamps. The IP Identification field is generated from information supplied to the decompressor by the compressor, and with proper engineering of the sender's IP stack it will maintain the uniqueness property that is important for proper functioning of IP fragmentation, ICMP processing, and multi-path routing. However, even without such engineering, duplicate Identification fields will be rare and those that cause problems even more rare. This is especially true since voice RTP packets will be quite small and should never be fragmented. 7. Good Enough Header Compression (GEHCO) The next two sections consider the identification of an end-to-end bit flow between link (e.g. PPP) entities and the actual GEHCO procedures. The establishment of the over-the-air connection is properly not a GEHCO function and is dependent on the particular link layer protocol in use. GEHCO only requires an abstraction that allows link entities to determine the identity of a bit flow. 7.1 Link Layer Connections In order to make use of a connection that carries compressed voice or other multimedia without any link or higher layer headers Hiller, McCann January 2000 - Expiration 7 Good Enough Header Compression (GEHCO) August 2000 between mobile station and a PPP peer in the network, the mobile station and network PPP peer must agree upon a connection identifier. This is so that both ends are able to identify a given bit flow with a given RTP flow. We assume that the network and mobile will use separate over-the- air connections for purposes of transporting PPP, and for transporting compressed voice. Typically in a cellular environment, the connection for the PPP frames will feature improved error rates via retransmission at the physical layer. However, due to latency requirements, the connection that transports the vocoded frames will not feature such retransmission. In the mobile station, the PPP implementation must have separate service access points for each connection (i.e. PPP frame connection and vocoder frame connection). This will allow the PPP implementation to direct compressed IP/UDP/RTP packets to the vocoder frame connection and normal data traffic to the PPP frame connection. In a relay model phone connected to a laptop, these connections are accessed via multiple access points, possibly supported by advanced modem interface protocols such as V.80. Similarly, the PPP implementation in the network side PPP peer must have separate service access points for each such connection. 7.2 Compression and Decompression Operation This section describes how the mobile station and network (i.e. the radio gateway) agree to use GEHCO and establish auxiliary connections as described above. The mobile station and network must negotiate GEHCO as part of PPP establishment (e.g. as an extension to PPP's IPCP or IPv6CP). This negotiation would be carried out over the PPP frame connection. Once negotiated, the two PPP implementations could dynamically establish and delete compression contexts for VOIP sessions. These contexts could be sent as "full headers" [13] over PPP frame connection, and the CID (i.e. Connection ID from [13]) should be set equal to some identifier that identifies the over-the-air connection that will be used to transport the compressed packets for the session. The full headers need to be sent using a new PPP Protocol Type to distinguish them from ordinary (transparent) header compression that may be taking place over the same PPP session. Below we refer to this new protocol type as GEHCO_FULL_HEADER. No additional compression (i.e., PPP payload compression) or transformation would be performed on the compressed RTP packets. The vocoder frame connection would carry voice frames exactly as for normal circuit voice. This implies that the vocoder has a real-time relationship to the physical frame rate just as in circuit voice, and the mobile host must be properly engineered to deliver voice traffic to the physical layer at the physical frame rate. For now we assume that this will be in the form of IP/UDP/RTP packets delivered to PPP, although some architectures may provide a direct link between the Hiller, McCann January 2000 - Expiration 8 Good Enough Header Compression (GEHCO) August 2000 vocoder and the physical layer. Similarly, the network side PPP peer must be able to guarantee that compressed voice frames are delivered in a way that enables real-time transmission over the air. The GEHCO compressor and decompressor are part of the PPP layer in both the mobile station and network side gateway. The compressor maintains a table of active RTP sessions that consists of source and destination IP address, source and destination UDP port, current RTP sequence number, and connection ID. When the compressor receives an IP/UDP/RTP packet from the IP layer, it scans a table of entries to find a match based the packet's source and destination addresses and ports. If the compressor does not find a matching entry, and if an appropriate over-the-air connection exists to carry the compressed voice, the compressor sends a PPP control frame of type GEHCO_FULL_HEADER to the decompressor over the PPP frame connection. If an appropriate over-the-air connection does not exist the peer may take steps to create one. For future packets that match, the compressor removes the IP/UDP/RTP headers and places the compressed voice in the RTP payload onto the vocoder frame connection associated with this RTP flow. As explained above, the network side compressor will maintain a buffer to compensate for to incoming packet jitter from the IP network. The mobile decompressor then creates timestamps per the 20ms physical frame rate and delivers packets to the IP layer. For the compressor on the mobile side, we do not expect any real jitter from the mobile's vocoder since the vocoder is integral to the mobile station. If there is a small level of jitter (perhaps due to small variable delays in the mobile station) the compressor could likewise maintain a small buffer to compensate. At the network side the decompressor assigns timestamps that increment very 20ms. If a compressor buffer underruns (perhaps due to uncorrectable errors or significant delays in the IP network), the compressor outputs a radio frame that has "NULL DATA". The decompressor would not produce an RTP frame for such NULL DATA frames. The GEHCO_FULL_HEADER message contains a complete IP/UDP/RTP packet, including: * IP source and destination address * Initial RTP sequence number * UDP source and destination port * Initial IP Identification field * CID (Connection ID) By way of an example, a convenient and trivial Connection ID for the case of cdma2000 is the Radio Link Protocol (RLP) instance. However, there is no real constraint other than that the system is Hiller, McCann January 2000 - Expiration 9 Good Enough Header Compression (GEHCO) August 2000 able to identify a particular radio connection with a bit flow received by a link layer entity on the network side. The GEHCO_FULL_HEADER is distinct from the RFC2509 FULL_HEADER to keep the space of CIDs used here which correspond to vocoder frame connection CIDs separate from RFC2509 CIDs. The decompressor in the PPP link layer stores the above information in a similar table. The mobile station and network side PPP peer use the CIDs as indices to the table. The decompressor sends a GEHCO_FULL_HEADER_ACK in response with the CID. The decompressor will then access the RTP payload and wrap the compressed voice in an IP/UDP/RTP packet and pass it to the IP layer for further processing or transport. The initial starting RTP sequence number is equal to that in the GEHCO_FULL_HEADER control frame, and is incremented by 1 for each decompressed frame. The IP address and UDP port are determined from the table. The decompressor also inserts an RTP timestamp according to the value of a local clock at the time the frame was received. Any other fields such as the IP Identification field and any Checksums are set to appropriate values by the decompressor. The initial IP Identification field is determined from the GEHCO_FULL_HEADER and is incremented by 1 for each decompressed frame. To ensure uniqueness of IP Identification values, the RTP sender should assign IDs in increasing order on a per-flow basis. This might mean that the sender allocates a certain range of IDs for use by a flow; when the range is exhausted the sender will start a new range and the compressor will optionally send a new GEHCO_FULL_HEADER with the new start value. The compressor is specifically NOT REQUIRED to do so, however, as duplicate IDs are expected to be rare even when the initial range is exhausted. While the compressor waits for the GEHCO_FULL_HEADER_ACK, the compressor places RTP payloads into the designated physical connection. This allows the decompressor to create RTP packets as soon as it receives the GEHCO_FULL_HEADER control frame. The compressor periodically sends a GEHCO_FULL_HEADER frame until it receives a GEHCO_FULL_HEADER_ACK. The mobile station or network may reclaim the UDP port and IP address for a new RTP flow that happens to use the same IP address and UDP port. Reclaiming could happen long after a given call has terminated or perhaps even during a call if the SIP control so determines to use the same parameters for a different call. If this happens the compressor need only send a new GEHCO_FULL_HEADER frame with the new information for the new call. The compressor and decompressor physically will have a maximum number of table entries. When the table size is exceeded, the oldest table entry is overwritten. Hiller, McCann January 2000 - Expiration 10 Good Enough Header Compression (GEHCO) August 2000 7.3 Protocol GEHCO uses the Configuration Option of Section 2.1 of RFC 2509 [13] and requires a new field for the RTP-compression sub-option of Section 2.2 of RFC 2509. That is, we propose that the RTP- compression sub-option be extended with additional bytes indicating which RTP compression schemes are in use. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Scheme ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length Variable Scheme Sequence of CRTP, ROHC, GEHCO (values TBD) Section 3.3.1 of RFC 2508 [14] specifies that a FULL_HEADER packet is a PPP frame with a full header and the context ID placed in the IP and UDP length field. Two context formats are specified, one an 8 bit and the other a 16 bit length ID. Section 3.3.1 specifies the placement of the Context ID in those length fields. The GEHCO_FULL_HEADER carries only one RTP flow in a given connection. Therefore, the connection ID we propose above fulfills a similar function as the Context ID does in RFC 2508. We propose that the connection ID be placed in the IP and UDP fields, that there be two such connection ID options, and that the placement of the connection ID be the same as that of the Context ID as specified in RFC 2508. GEHCO does not require that a sequence number be carried in the GEHCO_FULL_HEADER. 7.4 RTCP RTP has a control protocol that occasionally sends control packets. In GEHCO, these would be transported over the PPP frame connection in PPP frames. The taxation is negligible because very few packets are sent. 7.5 GEHCO and Cell Phones The decompressor was depicted above as recreating RTP packets from the compressed voice (or IP multimedia) and passing that packet up the IP stack. In an integrated cell phone, actual creation of Hiller, McCann January 2000 - Expiration 11 Good Enough Header Compression (GEHCO) August 2000 these packets may not be required because there would be no need to add IP/UDP/RTP headers to pass up an IP stack just to be taken off again before delivery to a vocoder. In a laptop or palmtop, etc., the story is different because of an existing IP stack with applications that must be accommodated. Cell phones in general will have an IP stack to support the integral browser and SIP (and RTCP) protocols. The compressed voice need not be placed into RTP format within the phone. 7.6 Simultaneous Use of Transparent and Non-Transparent Compression This section would not apply to VOIP header compression in cell phones since non-transparent compression alone will suffice. Usually one would expect only one RTP compression scheme to be active on a given mobile (i.e. a laptop) at any time. For laptops, if it is necessary to allow transparent and non-transparent header compression methods to be simultaneously active, then the PPP layer would not know whether to use a transparent scheme (like ROCCO, ACE, CRTP, etc.) or GEHCO for a given flow. There are a couple of solutions. One would be to for the mobile application to have an API to the PPP layer that indicates the type on a per flow basis. The mobile would then negotiate with the PPP peer the appropriate type of compression to use for the flow. The other approach would be for ROHC to agree upon RTP Payload types to be used with non- transparent compression. The mobile and network PPP peers then just use this to determine when to use GEHCO. 8. Security Considerations Non transparent compression will be used over radio links that feature strong encryption; such encryption is optional and users who defer it are more susceptible to attack. The identity of users of these radio links will be authenticated via a private key in both the radio realm and the IETF based AAA realm. In general, it is very difficult in inject frames onto the radio links; as other drafts on compression have pointed out, if a hacker is able to inject frames onto the radio links, the problems this creates far exceed just those associated with compression and decompression. 9. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] RFC 2543, SIP: Session Initiation Protocol, Handley, Schulzrinne, Schooler, Rosenberg, March 1999 Hiller, McCann January 2000 - Expiration 12 Good Enough Header Compression (GEHCO) August 2000 [4] Enhancements to IP/UDP/RTP Header Compression (draft-koren-avt- crtp-enhance-01.txt), Koren, Casner, Ruddy, Thompson, Tweedly, Geevarghese, March, 2000 (IETF draft) [5] Robust Checksum-based header COmpression (ROCCO) (draft- jonsson-robust-hc-04.txt), Lars-Erik Jonsson, Mikael Degermark, Hans Hannu,Krister Svanbro, March 10, 2000 (IETF draft) [6] Adaptive Header ComprEssion (ACE) for Real-Time Multimedia (draft-ace-robust-hc-01.txt), Le, Clanton, Liu, Zheng, March 2000 (IETF draft) [7] Over-the-Air Voice over IP (VoIP) Issues and Recommended Phases (ALLIP-20000323-006_QUA_VoIP_Issues), Hsu, Odenwalder, Chen, Tiedemann, 3GPP2 All IP, March 2000 [8] RFC 1661, The Point-to-Point Protocol (PPP), W. Simpson, July 1994 [9] RFC 1662, PPP in HDLC-like Framing, W. Simpson, July 1994 [10] RFC 1570, PPP LCP Extensions, W. Simpson, January 1994 [11] End-to-End QoS for VOIP and Multimedia in 3GPP2 ALL IP Networks (SC-ALLIP-20000426-009_LUC_End-to_End), Tom Hiller, Pete McCann, 3GPP2 All IP, April 2000 [12] Tdoc SMG2 981/00, Voice Over GERAN/UTRAN PS Domain, Nortel Networks, ETSI SMG2 #36, see Table 3 [13] RFC2509, IP Header Compression over PPP, Engan, Casner, Bormann, February 1999 [14] RFC2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, Casner, Jacobson, February 1999 10. Acknowledgments The author wish to acknowledge the input of Qualcomm's Ray Hsu et al who initially identified the spectral tax associated with IP/UDP/RTP transparent compression schemes, and Mark Lipford of SPCS and Mark Munson of Verizon for their business insights on spectral capacity, and encouragement to pursue non transparent compression. 11. Author's Addresses Tom Hiller Lucent Technologies 263 Shuman Drive Hiller, McCann January 2000 - Expiration 13 Good Enough Header Compression (GEHCO) August 2000 Naperville, IL. USA 60137 Phone: 630-979-7673 Email: tom.hiller@lucent.com Pete McCann Lucent Technologies 263 Shuman Drive Naperville, IL. USA 60137 Phone: 630-713-9359 Email: mccap@lucent.com Hiller, McCann January 2000 - Expiration 14 Good Enough Header Compression (GEHCO) August 2000 Full Copyright Statement "Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into other languages._ Hiller, McCann January 2000 - Expiration 15 Good Enough Header Compression (GEHCO) August 2000 Hiller, McCann January 2000 - Expiration 16