Internet Engineering Task Force J. Border INTERNET-DRAFT Hughes Network Systems M. Kojo University of Helsinki Jim Griner NASA Glenn Research Center G. Montenegro Sun Microsystems, Inc. June 25, 1999 Performance Enhancing Proxies draft-ietf-pilc-pep-00.txt Status of This Memo The document is an Internet-Draft and is in full conformance with all of the provisions of Section 10 of RFC 2026. 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 Intenet-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. Distribution of this draft is unlimited. Comments on this draft should be sent to the authors or to the PILC mailing list at pilc@grc.nasa.gov. This draft expires on December 21, 1999. Abstract This document provides a high level overview of Performance Enhancing Proxies. Motivations for their development and use are described as well as some of the consequences of using them. Expires December 25, 1999 [Page 1] INTERNET DRAFT Performance Enhancing Proxies June 1999 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Types of Performance Enhancing Proxies . . . . . . . . . . . . . . 4 2.1 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1 TCP Performance Enhancing Proxies . . . . . . . . . . . . . . 4 2.1.2 Application Layer Proxies . . . . . . . . . . . . . . . . . . 4 2.2 Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Split Connections . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Transparency . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5 Tunnelling . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6 ACK Handling . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6.1 ACK Spacing . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6.2 Local Acknowledgements . . . . . . . . . . . . . . . . . . . . 8 2.6.3 Local Retransmissions . . . . . . . . . . . . . . . . . . . . 8 2.7 Compression . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.8 Handling Periods of Link Disconnection . . . . . . . . . . . . . 9 2.9 Other Link Specific Enhancements . . . . . . . . . . . . . . . . 10 3 Implications of Using PEP . . . . . . . . . . . . . . . . . . . . 10 3.1 The End-to-end Argument . . . . . . . . . . . . . . . . . . . . 10 3.1.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.2 Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.3 End-to-end Acknowledgements . . . . . . . . . . . . . . . . . 12 3.2 Other Implications . . . . . . . . . . . . . . . . . . . . . . . 13 4 PEP Environment Examples . . . . . . . . . . . . . . . . . . . . . 13 4.1 VSAT Environments . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1 VSAT Network Characteristics . . . . . . . . . . . . . . . . . 13 4.1.2 VSAT Network PEP Implementations . . . . . . . . . . . . . . . 15 4.1.3 VSAT Network PEP Motivation . . . . . . . . . . . . . . . . . 16 4.2 W-WAN Environments . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1 W-WAN Network Characteristics . . . . . . . . . . . . . . . . 16 4.2.2 W-WAN PEP Implementations . . . . . . . . . . . . . . . . . . 17 4.3 W-LAN Environments . . . . . . . . . . . . . . . . . . . . . . . 17 4.3.1 W-LAN Network Characteristics . . . . . . . . . . . . . . . . 17 4.3.2 W-LAN PEP Implementations: Snoop . . . . . . . . . . . . . . . 18 5 Security Considerations . . . . . . . . . . . . . . . . . . . . . 20 6 Appendix - PEP Terminology Summary . . . . . . . . . . . . . . . . 20 6.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 23 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 26 Expires December 25, 1999 [Page 2] INTERNET DRAFT Performance Enhancing Proxies June 1999 1 Introduction The Transmission Control Protocol [RFC0793] (TCP) is used as the transport layer protocol by many Internet and intranet applications. However, in certain environments, TCP and other higher layer protocol performance is limited by the link characteristics of the environment. [Karn99] discusses various link layer design considerations that should be taken into account when designing a link layer service that is intended to support the Internet protocols. Such design choices may have a significant influence on the performance and efficiency of the Internet. However, not all link characteristics, for example, high latency, can be compensated for by such choices in the link design. And, the cost of compensating for some link characteristics may be prohibitive for some technologies. A Performance Enhancing Proxy (PEP) is used to improve the performance of the Internet protocols in environments where native performance suffers for some reason, usually a characteristic of the environment. This document does not intend to advocate use of PEPs in general. On the contrary, the end-to-end principle in designing Internet protocols must be retained the prevailing approach and PEPs should be used only in specific environments and circumstances. In any environment where one might consider employing PEP for improved performance, an end user must be aware of the proxy and the choice of employing PEP must be under the control of the end user at all times. This also means that the end user must always be able to choose end-to-end IP service. The remainder of this document is organized as follows. Section 2 provides an overview of different kinds of PEP implementations. Section 3 discusses some of the implications with respect to using PEP, especially in the context of the global Internet. Finally, Section 4 discusses some example environments where PEPs are used, satellite very small aperture terminal (VSAT) environments, mobile wireless WAN (W-WAN) environments and wireless LAN (W-LAN) environments. A summary of PEP terminology is included in an appendix (Section 5). NOTE: As this is the first version of this draft it may fail to cover many important aspects related to PEPs. In particular, this version does not list all the possible implications of using PEPs nor does the included text on each of the implications cover all the aspects related to the particular implication. Expires December 25, 1999 [Page 3] INTERNET DRAFT Performance Enhancing Proxies June 1999 2 Types of Performance Enhancing Proxies There are many types of Performance Enhancing Proxies. Different types of proxies are used in different environments to overcome different link characteristics which affect protocol performance. Note that enhancing performance is not necessarily limited in scope to throughput. Other performance aspects may also be addressed. For example, [M-TCP] addresses the issue of keeping TCP connections alive during periods of disconnection in wireless networks. The following sections describe some of the key characteristics which differentiate different types of proxies. 2.1 Layering A PEP implementation may function at the TCP layer or at the application layer. 2.1.1 TCP Performance Enhancing Proxies Most PEP implementations operate at the TCP layer. Such an implementation is called a TCP Performance Enhancing Proxy (TCP PEP). For example, in an environment where ACKs may bunch together, a TCP proxy may be used to simply modify the ACK spacing in order to improve performance. On the other hand, in an environment with a large delay*bandwidth product, a TCP proxy may be used to alter the behaviour of the TCP connection in order to improve its throughput. TCP PEP implementations may be aware of the type of application being carried by a TCP connection but, at most, only use this information to influence their behaviour at the TCP layer. The term TCP spoofing is sometimes used synonymously for TCP PEP. However, the term TCP spoofing more accurately applies to only the subset of TCP PEP implementations which transparently attempt to alter the behaviour of a TCP connection to improve performance. 2.1.2 Application Layer Proxies Application layer proxies, on the other hand, operate above the TCP layer. Today, such proxies are widely used in the Internet and include Web caches and relay Mail Transfer Agents. Application layer proxies can be implemented for the purpose of improving application protocol as well as TCP performance with respect to a particular application being used with a particular type Expires December 25, 1999 [Page 4] INTERNET DRAFT Performance Enhancing Proxies June 1999 of link. Some application protocols employ plenty of (unnecessary) round trips, lots of headers and/or inefficient encoding which may have a significant impact on performance, in particular, with long delay and slow links. In some cases, this unnecessary overhead can be reduced, in general or for a particular type of link, by using an application level proxy in an intermediate node. Some examples of application layer proxies which have been shown to improve performance in wireless environments are described in [CTC+97] and [LHKR96]. 2.2 This document provides a high level overview of Performance Enhancing Proxies. Motivations for their development and use are described as well as some of the consequences of using them. Expires December 25, 1999 [Page 1] INTERNET DRAFT Performance Enhancing Proxies June 1999 1 Introduction The Transmission Control Protocol [RFC0793] (TCP) is used as the transport layer protocol by many Internet and intranet applications. However, in certain environments, TCP and other higher layer protocol performance is limited by the link characteristics of the environment. [Karn99] discusses various link layer design considerations that should be taken into account when designing a link layer service that is intended to support the Internet protocols. Such design choices may have a significant influence on the performance and efficiency of the Internet. However, not all link characteristics, for example, high latency, can be compensated for by such choices in the link design. And, the cost of compensating for some link characteristics may be prohibitive for some technologies. A Performance Enhancing Proxy (PEP) is used to improve the performance of the Internet protocols in environments where native performance suffers for some reason, usually a characteristic of the environment. This document does not intend to advocate use of PEPs in general. On the contrary, the end-to-end principle in designing Internet protocols must be retained the prevailing approach and PEPs should be used only in specific environments and circumstances. In any environment where one might consider employing PEP for improved performance, an end user must be aware of the proxy and the choice of employing PEP must be under the control of the end user at all times. This also means that the end user must always be able to choose end-to-end IP service. The remainder of this document is organized as follows. Section 2 provides an overview of different kinds of PEP implementations. Section 3 discusses some of the implications with respect to using PEP, especially in the context of the global Internet. Finally, Section 4 discusses some example environments where PEPs are used, satellite very small aperture terminal (VSAT) environments, mobile wireless WAN (W-WAN) environments and wireless LAN (W-LAN) environments. A summary of PEP terminology is included in an appendix (Section 5). NOTE: As this is the first version of this draft it may fail to cover many important aspects related to PEPs. In particular, this version does not list all the possible implications of using PEPs nor does the included text on each of the implications cover all the aspects related to the particular implication. Expires December 25, 1999 [Page 3] INTERNET DRAFT Performance Enhancing Proxies June 1999 2 Types of Performance Enhancing Proxies There are many types of Performance Enhancing Proxies. Different types of proxies are used in different environments to overcome different link characteristics which affect protocol performance. Note that enhancing performance is not necessarily limited in scope to throughput. Other performance aspects may also be addressed. For example, [M-TCP] addresses the issue of keeping TCP connections alive during periods of disconnection in wireless networks. The following sections describe some of the key characteristics which differentiate different types of proxies. 2.1 Layering A PEP implementation may function at the TCP layer or at the application layer. 2.1.1 TCP Performance Enhancing Proxies Most PEP implementations operate at the TCP layer. Such an implementation is called a TCP Performance Enhancing Proxy (TCP PEP). For example, in an environment where ACKs may bunch together, a TCP proxy may be used to simply modify the ACK spacing in order to improve performance. On the other hand, in an environment with a large delay*bandwidth product, a TCP proxy may be used to alter the behaviour of the TCP connection in order to improve its throughput. TCP PEP implementations may be aware of the type of application being carried by a TCP connection but, at most, only use this information to influence their behaviour at the TCP layer. The term TCP spoofing is sometimes used synonymously for TCP PEP. However, the term TCP spoofing more accurately applies to only the subset of TCP PEP implementations which transparently attempt to alter the behaviour of a TCP connection to improve performance. 2.1.2 Application Layer Proxies Application layer proxies, on the other hand, operate above the TCP layer. Today, such proxies are widely used in the Internet and include Web caches and relay Mail Transfer Agents. Application layer proxies can be implemented for the purpose of improving application protocol as well as TCP performance with respect to a particular application being used with a particular type Expires December 25, 1999 [Page 4] INTERNET DRAFT Performance Enhancing Proxies June 1999 of link. Some application protocols employ plenty of (unnecessary) round trips, lots of headers and/or inefficient encoding which may have a significant impact on performance, in particular, with long delay and slow links. In some cases, this unnecessary overhead can be reduced, in general or for a particular type of link, by using an application level proxy in an intermediate node. Some examples of application layer proxies which have been shown to improve performance in wireless environments are described in [CTC+97] and [LHKR96]. 2.2 Distribution A PEP implementation may be integrated, i.e. implemented within a single node, or distributed, i.e. implemented in multiple nodes. An integrated implementation represents a single point at which performance enhancement is applied. For example, a proxy might be implemented to provide impedence matching at the point where wired and wireless links meet. A distributed implementation is generally used to surround a particular link for which performance enhancement is desired. For example, a PEP implementation for a satellite connection may be distributed between two proxies located at each end of the satellite link. A distributed implementation may be symmetric or asymmetric. A symmetric implementation uses two proxies with essentially identical behaviour at each end of the link. An asymmetric implementation is generally used with an asymmetric link and uses two proxies which behave differently depending on which side of the link they are on. 2.3 Split Connections A split connection TCP implementation terminates the TCP connection received from an end system and establishes a corresponding TCP connection to the other end system. In a distributed implementation, this is typically done to allow the use of a connection between the two proxies optimized for the link. This might be a TCP connection optimized for the link or it might be another protocol, for example, a proprietary protocol running on top of UDP. Also, the distributed implementation might use a separate connection between the proxies for each TCP connection or it might multiplex the data from multiple TCP connections across a single connection between the proxies. In an integrated proxy split connection implementation, the proxy again terminates the connection from one end system and originates a separate connection to the other end system. [I-TCP] documents an example of a single proxy split connection implementation. Expires December 25, 1999 [Page 5] INTERNET DRAFT Performance Enhancing Proxies June 1999 In general, an integrated proxy uses a split connection implementation in order to address a mismatch in TCP capabilities between two end systems. For example, the scaled TCP windows option [RFC1323] can be used to extend the maximum amount of TCP data which can be "in flight" (i.e. sent and awaiting acknowledgement). This is useful for filling a link which has a high delay*bandwidth product. If one end system is capable of using scaled TCP windows but the other is not, the end system which is not capable can set up its connection with a proxy on its side of the high delay*bandwidth link. The split connection proxy then sets up a scaled TCP window connection over the link to the other end system. Split connection TCP implementations can effectively leverage TCP performance enhancements optimal for a particular link but which cannot necessarily be employed safely over the global Internet. Note that using split connection proxies does not necessarily exclude simultaneous use of IP for end-to-end connectivity. When employed on a last hop link, the correct use of a split connection should be managed per application or per connection and should be under the control of the end user, allowing the user to decide whether a particular TCP connection or application makes use of the split connection proxy or operates end-to-end directly over IP. In effect, application layer proxies are split connection proxies with end systems using the proxies as a service related to a particular application. Therefore, all TCP layer enhancements that are available with split connection implementations can also be employed in conjunction with application layer enhancements. 2.4 Transparency Another key characteristic of a proxy is its degree of transparency. A proxy may operate totally transparently to the end systems and/or applications involved (in a connection), requiring no modifications to the end systems or applications. On the other hand, a proxy implementation may require modifications to both ends in order to be used. (This is known as an opaque implementation.) In between, a proxy implementation may require modifications to only one of the end systems or applications involved. (This is known as a translucent implementation.) It is sometimes useful to think of the degree of transparency of a PEP implementation at three levels, transparency with respect to the end systems, transparency with respect to the applications and transparency with respect to the users. For example, a user who subscribes to a satellite Internet access service may be aware that Expires December 25, 1999 [Page 6] INTERNET DRAFT Performance Enhancing Proxies June 1999 the satellite terminal is providing a performance enhancing service even though the TCP stack and the applications in the user's PC are not aware of the proxy which implements it. Note that the issue of transparency is not the same as the issue of maintaining the end-to-end semantics of a TCP connection. (The implications of not maintaining the end-to-end semantics of TCP connections are discussed in Section 3.) A proxy which simply uses an ACK spacing mechanism maintains the end-to-end semantics of the TCP connection while a proxy which uses a split connection implementation may not. Yet, both can be implemented transparently to the end systems. Application layer proxies are usually (but not always) non-transparent to the end systems and applications (and are almost always, if not always, non-transparent to the user). To enable end-to-end IP service at all times, an appropriate practice when using proxies is to allow the decision of employing a proxy to be under user control. 2.5 Tunnelling A proxy may encapsulate TCP messages to carry the messages across a particular link. A proxy at the other end of the encapsulation tunnel removes the tunnel wrappers before final delivery to the receiving end system. A tunnel might be used by a distributed split connection TCP implementation as the means for connecting the split connection proxies. A tunnel might also be used to support forcing TCP connections which use asymmetric routing to go through the end points of a distributed PEP implementation. 2.6 ACK Handling The handling of TCP acknowledgements can differ significantly between different TCP PEP implementations. The following subsections describe various ACK handling mechanisms. 2.6.1 ACK Spacing In some TCP PEP implementations the manipulation of TCP acknowledgements is the entire implementation. ACK spacing is used to smooth out the flow of TCP acknowledgements traversing a link in order to improve performance by eliminating bursts of TCP data segments [Part98]. Expires December 25, 1999 [Page 7] INTERNET DRAFT Performance Enhancing Proxies June 1999 2.6.2 Local Acknowledgements In some PEP implementations, TCP data segments received by a proxy are locally acknowledged by the proxy. This speeds up TCP slow start and allows the sending end system to quickly open up its transmit window. Local acknowledgements are automatically used with split connection implementations. 2.6.3 Local Retransmissions When local acknowledgements are used, the burden falls upon the TCP proxy to recover any data which is dropped after the proxy acknowledges it. The TCP proxy receives the acknowledgements from the end system receiving the TCP data segments and uses them, along with appropriate timeouts, to determine when to retransmit lost data. Some PEP implementations perform local retransmissions even though they do not use local acknowledgements to alter TCP connection performance. Snoop (without SACK) [SNOOP] is a well know example of such a PEP implementation. Snoop caches TCP data segments it receives and forwards and then monitors the acknowledgements coming from the receiving TCP end system for duplicate acknowledgements (DUPACKs). When DUPACKs are received, Snoop locally retransmits the lost TCP data segments from its cache, suppressing the acknowledgement stream flowing to the sending TCP end system until acknowledgements for new data start being received. 2.7 Compression Many PEP implementations include support for one or more forms of compression. (In some PEP implementations, compression may even be the only mechanism used for performance improvement.) Compression reduces the number of bytes which need to be sent across a link. This is useful in general and can be very important for bandwidth limited links. Some of the benefits of using compression include: - Improved link efficiency; - Higher effective link utilization; - Reduced latency; - Improved interactive response time; - Decreased overhead; Expires December 25, 1999 [Page 8] INTERNET DRAFT Performance Enhancing Proxies June 1999 - Reduced packet loss rate over lossy links. Where appropriate, link layer compression is used. [TBD] documents an example of link layer compression used in conjunction with PEP. TCP and IP header compression are also frequently used with PEP implementations. [RFC1144] describes a widely deployed method for compressing TCP headers. Other header compression algorithms are described in [RFC2507], [RFC2508] and [RFC2509]. Payload compression is also desirable and is increasing in importance with today's increased emphasis on Internet security. IP layer (and above) security mechanisms convert IP payloads into random bit streams which defeat applicable link layer compression mechanisms by removing or hiding redundant "information." Therefore, compression of the payload needs to be applied before security mechanisms are applied. [RFC2393] defines a framework where common compression algorithms can be applied to arbitrary IP segment payloads. However, [RFC2393] compression is not always applicable. Many types of IP payloads (e.g. images, audio, video and "zipped" files being FTPed) are already compressed. And, security mechanisms such as SSL and TLS are applied above the IP layer. With application layer proxies one can employ application-specific compression. In particular, with slow links any compression that effectively reduces transfer volume over is tremendously useful. Typically an application-specific (or content-specific) compression mechanism is much more efficient than any generic compression mechanism. For example, a distributed Web proxy implementation may implement more efficient binary encoding of HTTP headers, or a single proxy can employ lossy compression that reduces the image quality of inline-images on Web pages according to end user instructions, thus reducing the number of bytes transferred over the slow link and consequently the response time perceived by the user. 2.8 Handling Periods of Link Disconnection Periods of link disconnection or link outage are very common with wireless links. During these periods, a TCP sender does not receive the expected acknowledgements. Upon expiration of the retransmit timer, this causes TCP to close its congestion window with all of the related drawbacks. A TCP proxy may monitor the traffic coming from the TCP sender towards the TCP receiver behind the disconnected link. The proxy retains the last ACK, so that it can shut down the TCP sender's window by sending the last ACK with a window set to zero. Thus, the TCP sender will go into persist mode. To make this work in both directions, the TCP receiver behind the Expires December 25, 1999 [Page 9] INTERNET DRAFT Performance Enhancing Proxies June 1999 disconnected link must be aware of the current state of the connection and, in the event of a disconnection, it must be capable of freezing all timers. [M-TCP] implements such operation. Another possibility is that the disconnected link is surrounded by a distributed proxy pair. In split TCP connection implementations, a period of link disconnection can easily be hidden from the world on the other side of the proxy. Consequently, the proxy and its counterpart behind the disconnected link can employ a modified TCP version which retains the state and all unacknowledged data segments across the period of disconnection and then performs local recovery as the link is reconnected. 2.9 Other Link Specific Enhancements - Implementing priority-based multiplexing of data (on a slow link); - Other possible enhancements. 3 Implications of Using PEP The following sections describe some of the implications of using PEP. 3.1 The End-to-end Argument As indicated in [RFC1958], the end-to-end argument is one of the architectural principles of the Internet. The basic argument is that, as a first principle, certain required end-to-end functions can only be correctly performed by the end systems themselves. Most of the negative implications associated with using PEP are related to breaking the end-to-end semantics of connections. This is one of the main reasons why PEPs are not recommended for general use. As indicated in Section 2.4, not all PEP implementations break the end-to-end sematics of connections. However, split connection PEP implementations, especially transparent split connection PEP implementations, often do. Expires December 25, 1999 [Page 10] INTERNET DRAFT Performance Enhancing Proxies June 1999 3.1.1 Security The most detrimental negative implication of breaking the end-to-end semantics of a connection is that it disables end-to-end use of IP layer security (IPsec). If, on the other hand, IPsec is employed end-to-end, encryption of IP packets via IPSEC's ESP header (in either transport or tunnel mode) renders the TCP header and payload unintelligible to intermediate PEPs. This precludes PEPs from working, because they need to examine the TCP headers in both directions. However, if the end user can select end-to-end IP service for the IPSEC traffic, the encrypted traffic is not subject to the possible performance enhancements but the other traffic is. With a non-transparent PEP implementation, if the end systems trust the proxy, IPsec can be used separately between each end system and the proxy. However, in most cases this is an undesireable or unacceptable alternative as the end systems can not trust the proxy. In addition, this is not as secure as end-to-end security. And, it can lead to potentially misleading security level assumptions by the end systems. If the two end systems negotiate different levels of security with the proxy, the end system which negotiated the stronger level of security may not be aware that a lower level of security is being provided for part of the connection. (The proxy could be implemented to prevent this from happening by being smart enough to force the same level of security to each end system.) With a transparent PEP implementation, it is difficult for the end systems to trust the proxy because they are not aware of its existence. However, IPsec can be implemented between the two proxies of a distributed implementation. And, if the PEP implementation is non-transparent to the users, the users could configure their end systems to use the proxies as the end points of an IPsec tunnel. In any case, the authors are currently not aware of any PEP implementations, transparent or non-transparent, which provide support for IPsec. Note that even when a PEP implementation does not break the end-to-end sematics of a connection, the PEP implementation may not be able to function in the presence of IPsec. For example, it is difficult to do ACK spacing if the proxy cannot reliably determine which IP packets contain ACKs. In most cases, security applied above the TCP layer can be used with PEP, especially TCP PEP. 3.1.2 Fate Sharing Another important aspect of the end-to-end argument is fate sharing. If a failure occurs in the network, the ability of the connection to Expires December 25, 1999 [Page 11] INTERNET DRAFT Performance Enhancing Proxies June 1999 survive the failure depends upon how much state is being maintained on behalf of the connection in the network. If no connection specific state resides in the network as in case of regular end-to-end operation, then a failure in the network will only break the connection if there is no alternate path through the network between the end systems. And, if there is no path, both end systems can detect this. However, if the connection depends upon some state being stored in the network (e.g. in a proxy), then a failure in the network (e.g. the node containing the proxy crashes) causes this state to be lost, forcing the connection to terminate even if an alternate path through the network exists. The importance of this aspect of the end-to-end argument with respect to PEP is very PEP implementation dependent. Sometimes coincidentally but more often by design, PEP is used in environments where there is no alternate path between the end systems and, therefore, a failure of the intermediate node containing the proxy would result in the termination of the connection in any case. And, even when this is not the case, the users may choose to accept the risk of the proxy crashing in order to take advantage of the performance gains offered by the PEP implementation. Note that accepting the risk must be under the control of the user and the user must always have the option to choose end-to-end IP service. 3.1.3 End-to-end Acknowledgements Another aspect of the end-to-end argument is that of acknowledging the receipt of data end-to-end. Breaking the end-to-end semantics of a TCP connection prevents TCP acknowledgements from being used for this purpose by an application. If an application uses TCP acknowledgements as its indication of successful end-to-end delivery of data, the application may not be a good candidate for use with PEP. Using TCP acknowledgements as an indication of reliable delivery at the application layer is not necessarily a good idea. First, the TCP implementation may not provide TCP acknowledgement information to the application. Second, the TCP acknowledgement only indicates that data was delivered to the TCP implementation on the other end system. It does not guarantee that the data was delivered to the application layer on the other end system. Therefore, also according to the end-to-end argument, a well designed application must use an application layer acknowledgement to ensure end-to-end delivery of application layer data. PEP implementations generally do not interfere with end-to-end application layer acknowledgements, and, if they do, they must take full responsibility for delivering the application data to its ultimate destination. For example, Expires December 25, 1999 [Page 12] INTERNET DRAFT Performance Enhancing Proxies June 1999 that is how relay MTAs operate when delivering Internet mail messages. 3.2 Other Implications TBD in later versions: - breaking the end-to-end failure diagnostics - problems with mobile environments where the PEP related state information with should be transferred to the new PEP node during a handoff. - other possible implications 4 PEP Environment Examples The following sections describe examples of environments where PEP is currently used to improve performance. 4.1 VSAT Environments Today, VSAT networks are implemented with geosynchronous satellites. VSAT data networks are typically implemented using a star topology. A large hub earth station is located at the center of the star with VSATs used at the remote sites of the network. Data is sent from the hub to the remote sites via an outroute. Data is sent from the remote sites to the hub via one or more inroutes. An outroute is typically much larger than an inroute. However, multiple inroutes can be used with each outroute. VSAT networks are generally used to implement private networks (i.e. intranets) for enterprises (e.g. corporations) with geographically dispursed sites. VSAT networks are rarely, if ever, used to implement Internet connectivity except at the edge (i.e. as the last hop). Connection to the Internet for the VSAT network is usually implemented at the VSAT network hub site using appropriate firewall and (when appropriate) NAT [NAT] devices. 4.1.1 VSAT Network Characteristics With respect to TCP performance, VSAT networks exhibit the following subset of the satellite characteristics documented in [RFC2488]: Expires December 25, 1999 [Page 13] INTERNET DRAFT Performance Enhancing Proxies June 1999 Long feedback loops Propagation delay from a sender to a receiver in a geosynchronous satellite network can range from 240 to 280 milliseconds, depending on where the sending and receiving sites are in the satellite footprint. This makes the round trip time just due to propagation delay at least 480 milliseconds. Queueing delay and delay due to shared channel access methods can sometimes increase the total delay up to on the order of a few seconds. Large delay*bandwidth products VSAT networks can support capacity ranging from a few kilobits per second up to multiple megabits per second. When combined with the relatively long round trip time, TCP needs to keep a large number of packets "in flight" in order to fully utilize the satellite link. Asymmetric capacity As indicated above, the outroute of a VSAT network is usually significantly larger than an inroute. Even though multiple inroutes can be used within a network, a given VSAT can only access one inroute at a time. Therefore, the incoming (outroute) and outgoing (inroute) capacity for a VSAT is often very asymmetric. As outroute capacity has increased in recent years, ratios of 400 to 1 or greater are becoming more and more common. With a TCP maximum segment size of 1460 bytes and delayed acknowledgements [RFC1122] in use, the ratio of IP packet bytes for data to IP packet bytes for ACKs is only (3000 to 40) 75 to 1. Thus, inroute capacity for carrying ACKs can have a significant impact on TCP performance. With respect to the other satellite characteristics listed in [RFC2488], VSAT networks typically do not suffer from intermittent connectivity or variable round trip times. Also, VSAT networks generally include a significant amount of error correction coding. This makes the bit error rate very low during clear sky conditions, approaching the bit error rate of a typical terrestrial network. In severe weather, the bit error rate may increase significantly but such conditions are rare (when looked at from a network availability point of view) and VSAT networks are generally engineered to work during these conditions but not to optimize performance during these conditions. Expires December 25, 1999 [Page 14] INTERNET DRAFT Performance Enhancing Proxies June 1999 4.1.2 VSAT Network PEP Implementations Performance Enhancing Proxies implemented for VSAT networks generally focus on improving throughput (for applications such as FTP and HTTP web page retrievals). To a lesser degree, PEP implementations also work to improve interactive response time for small transactions. There is no one dominant PEP implementation used with VSAT networks. Each VSAT network vendor tends to implement their own version of PEP, integrated with the other features of their VSAT product. [HNS] and [SPACENET] describe VSAT products with integrated PEP capabilities. There are also third party PEP implementations designed to be used with VSAT networks. These products run on nodes external to the VSAT network at the hub and remote sites. SatBooster [FLASH] and Venturi [FOURELLE] are examples of such products. VSAT network PEP implementations generally share the following characteristics: - They focus on improving TCP performance; - They use an asymmetric distributed implementation; - They use a split connection approach with local acknowledgements and local retransmissions; - They support some form of compression to reduce the amount of bandwidth required (with emphasis on saving inroute bandwidth). The key differentiators between VSAT network PEP implementations are: - The maximum throughput they attempt to support (mainly a function of the amount of buffer space they use); - The protocol used over the satellite link. Some implementations use a modified version of TCP while others use a proprietary protocol running on top of UDP; - The type of compression used. Third party VSAT network PEP implementations generally focus on application (e.g. HTTP) specific compression algorithms while PEP implementations integrated into the VSAT network generally focus on link specific compression. PEP implementations integrated into a VSAT product are generally transparent to the end systems. Third party PEP implementations used with VSAT networks are usually translucent, requiring a configuration change in the remote site end system to route TCP packets to the Expires December 25, 1999 [Page 15] INTERNET DRAFT Performance Enhancing Proxies June 1999 remote site proxy. In some cases, the PEP implementation is actually integrated transparently into the end system node itself, using a "bump in the stack" approach. 4.1.3 VSAT Network PEP Motivation TBD (in later versions): - Intranet versus Internet - Highly asymmetric links - Support for "non-modern" TCP stacks 4.2 W-WAN Environments TBD (in later versions): [ text covering W-WAN example(s) is intended to include at least the following issues: ] 4.2.1 W-WAN Network Characteristics - low bandwidth - high latency - high BER, or long variable delays due to local link-layer error recovery - some W-WAN links have a lot internal buffers which tend to accumulate data, thus resulting in increased round-trip delay - unexpected link disconnections may occur frequently (or intermittent link outages) - (re)setting link-connection up takes long time - typically last-hop link to the end user - W-WAN network typically takes care of terminal mobility: the connection point to the Internet is retained while the user moves with the mobile host Expires December 25, 1999 [Page 16] INTERNET DRAFT Performance Enhancing Proxies June 1999 4.2.2 W-WAN PEP Implementations - Mowgli approach [MOWGLI]: Split TCP together with application layer proxies and W-WAN link specific protocol [KRLKA97] or with corresponding protocol modifications, compression in various forms, reduction of round trips, priority-based multiplexing of data over the W-WAN link, link-level flow control to prevent data from accumulating into the W-WAN link internal buffers, ... - transfer volume must be reduced to make Internet access usable, (long) link disconnections must not abort active (bulk data) transfers, slow W-WAN link should be efficiently shielded from excess traffic and the global (wired) Internet congestion, (all) applications can not be made mobility/W-WAN aware in short time frame or maybe ever, interactive traffic must be transmitted in timely manner even if there are other simultaneous bandwidth intensive (background) transfers... 4.3 W-LAN Environments Wireless LANs (W-LAN) are typically organized in a cellular topology where a base station with a W-LAN transceiver is controlling a single cell. A cell is defined in terms of the coverage area of the base station. The base stations are directly connected to the wired network. The base station in each of the cells is responsible for forwarding packets to and from the hosts located in the cell. Often the hosts with W-LAN tranceivers are mobile. When such a mobile host moves from one cell to another cell, the responsibility for forwarding packets between the wired network and the mobile host must be transferred to the base station of the new cell. This is known as a handoff. 4.3.1 W-LAN Network Characteristics Current wireless LANs typically provide link bandwidth from 1 Mbps to 10 Mbps, most typically bandwidth being 1 or 2 Mbps. In the future, wide deployment of higher bandwidths up to 20 Mbps or even higher can be expected. The round-trip delay with wireless LANs is on the order of a few milliseconds or tens of milliseconds. Examples of W-LANs include ... . Expires December 25, 1999 [Page 17] INTERNET DRAFT Performance Enhancing Proxies June 1999 Wireless LANs are error-prone due to wireless link corruption. TCP performance over wireless LANs or a network path involving a W-LAN link suffers as packet losses due to wireless bit errors tend to occur in bursts. In addition, consecutive packet losses may occur also during handoffs. As TCP wrongly interprets these packet losses to be network congestion, the TCP sender reduces its congestion window and is often forced to timeout in order to recover from the consecutive losses. The result is often unacceptably poor end-to-end performance. 4.3.2 W-LAN PEP Implementations: Snoop Berkeley's Snoop protocol [SNOOP] is a TCP-specific approach in which a TCP-aware module, a Snoop agent, is deployed at the W-LAN base station that acts as the last-hop router to the mobile host. Snoop aims at retaining the TCP end-to-end semantics. The Snoop agent monitors every packet that passes through the base station in either direction and maintains soft state per each TCP connection. For a data transfer to a mobile host, the Snoop agent caches unacknowledged TCP data which it forwards to the (wired network) receiver and monitors the corresponding ACKs. It does two things: 1. Retransmits any lost packets locally by using local timers and duplicate ACKs to identify packet loss, instead of waiting for the TCP sender to do so end-to-end. 2. Suppresses the duplicate acks on their way from the mobile host back to the sender, thus avoiding fast retransmit and congestion avoidance at the latter. Thus, the Snoop protocol is designed to avoid unnecessary fast retransmits by the TCP sender, when the Snoop agent retransmits a packet locally. Consider a system that employs the Snoop agent and a TCP sender S that sends packets to receiver R via a base station BS. Assume that the sender sends packets A, B, C, D, E (in that order) which are forwarded by BS to the wireless receiver R. Assume the first transmission of packet B is lost due to errors on the wireless link. In this case, receiver R receives packets A, C, D, E and B (in that order). Receipt of packets C, D and E triggers duplicate acknowledgement. When the TCP sender receives three duplicate acknowledgements, it triggers fast retransmit (which results in a retransmission, as well as reduction of the congestion window). The Snoop agent also retransmits B locally, when it receives three duplicate acknowledgements. The fast retransmit at the TCP sender occurs despite the local retransmit on the wireless link, degrading Expires December 25, 1999 [Page 18] INTERNET DRAFT Performance Enhancing Proxies June 1999 throughput. Snoop deals with this problem by dropping TCP dupacks appropriately (at the base station). For a data transfer from a mobile host, the Snoop agent detects the packet losses on the wireless link by monitoring the data segments it forwards. It then employs either Negative Acknowledgements (NAK) locally or Explicit Loss Notifications (ELN) to inform the mobile sender that the packet loss was not related to congestion, thus allowing the sender to retransmit without triggering normal congestion control procedures. To implement this, changes at the mobile host are required. When a Snoop agent uses NAKs to inform th TCP sender of the packet losses on the wireless link, one possibility to implement them is using the Selective Acknowledgment (SACK) option of the TCP [RFC2018]. This requires enabling SACK processing at the mobile host. The Snoop agent sends a TCP SACK, when it detects a hole in the transmission sequence from the mobile host or when it has not received any new packets from the mobile host for a certain time period. This approach relies on the advisory nature of the SACKs: the mobile sender is adviced to retransmit the missing segments indicated by SACK, but it must not assume successful end-to-end delivery of the segments acknowledged with SACK as these segments might get lost in the later path to the receiver. Instead, the sender must wait for a cumulative ACK to arrive. When the ELN mechanism is used to inform the mobile sender of the packet losses, one of the unreserved bits in the TCP header is suggested to be used for ELN [SNOOPELN]. The Snoop agent keeps track of the holes that correspond to segments lost over the wireless link. When (duplicate) ACK corresponding to a hole in the sequence space arrives from the TCP receiver, the Snoop agent sets the ELN bit on the ACK to indicate that the loss is unrelated to congestion and then forwards the ACK to the TCP sender. When the sender receives a certain number of (duplicate) ACKs with ELN (a configurable variable at the mobile host, e.g., two), it retransmit the missing segment without performing any congestion control measures. A scheme such as Snoop is needed only if the possibility of a fast retransmit due to wireless errors is non-negligible. In particular, if the wireless link uses a stop-and-go protocol (or otherwise delivers packets in-order), then this scheme is not very beneficial. Also, if the bandwidth*delay product of the wireless link is smaller than four segments, the probability that the snoop agent will have an opportunity to send three new packets before a lost packet is retransmitted is small. Since at least three dupacks are needed to trigger a fast retransmit, with a wireless bandwidth*delay product of less than four packets, schemes such as Snoop would not be necessary Expires December 25, 1999 [Page 19] INTERNET DRAFT Performance Enhancing Proxies June 1999 (unless the link layer is not designed properly). Conversely, when the wireless bandwidth*delay product is large enough, Snoop can provide significant performance improvement (compared with standard TCP). [ TBD: some text how Snoop tries to alleviate the problem with small windows ] Snoop requires the base station to examine and operate on the traffic between the mobile host and the TCP server on the wired Internet. Snoop does not work if the IP traffic is encrypted. Possible solutions involve: - making the Snoop agent a party to the security association between the client and the server; - IPSEC tunneling mode, terminated at the Snooping base station. However, these techniques require that users trust base stations. SNOOP also requires that both the data and the corresponding ACKs traverse the same base station. Furthermore, if the SNOOP agent retransmits the TCP data segments ("at the transport layer") across the wireless link, this may duplicate efforts by the link layer. SNOOP has been described by its designers as a TCP-aware link layer. This is the right approach: the link and network layers can be much more aware of each other than strict layering suggests. - to alleviate local link pkt drops due to high-BER (wireless) link 5 Security Considerations The security implications of using PEP are discussed in Section 3.1.1. 6 Appendix - PEP Terminology Summary This appendix provides a summary of terminology frequently used during discussion of Performance Enhancing Proxies. (In some cases, these terms have different meanings from their non-PEP related usage.) Expires December 25, 1999 [Page 20] INTERNET DRAFT Performance Enhancing Proxies June 1999 6.1 Definitions ACK spacing Delayed forwarding of acknowledgements in order to space them out. application layer PEP Performance enhancement operating above the TCP layer. May be aimed at improving TCP or application protocol performance (or both). asymmetric link A link which has different rates for the forward channel (used for data segements) and the back (or return) channel (used for ACKs). available bandwidth The total capacity of a link available to carry information at any given time. May be lower than the raw bandwidth due to competing traffic. bandwidth utilization The actual amount of information delivered over a link in a given period, expressed as a percent of the raw bandwidth of the link. gateway Has several meanings depending on context: - An access point to a particular link; - A device capable of initiating and terminating connections on behalf of a user or end system (e.g. a firewall or proxy). Not necessarily, but could be, a router. in flight (data) Data sent but not yet acknoledged. More precisely, data sent for which the sender has not yet received the acknowledgement. local acknowledgement The generation of acknowledgements by an entity in the path Expires December 25, 1999 [Page 21] INTERNET DRAFT Performance Enhancing Proxies June 1999 between two end systems in order to allow the sending end system to transmit more data without waiting for end-to-end acknowledgements. opaque Requires changes to be made to both end systems of a connection. proxy An entity in the network acting on behlaf of an end system or user (with or without the knowledge of the end system or user). raw bandwidth The total capacity of an unloaded link available to carry information. Snoop A TCP-aware link layer developed for wireless packet radio and cellular networks. It works by caching segments at a wireless base station. If the base station sees duplicate acknowledgements for a segment that it has cached, it retransmits the missing segment while suppressing the duplicate acknowledgement stream being forwarded back to the sender until the wireless receiver starts to acknowledge new data. Described in detail in [SNOOP]. split connection A connection that has been terminated before reaching the destination end system in order to initiate a second connection towards the end system. TCP PEP Performance enhancement operating at the TCP layer. Aimed at improving TCP performance. TCP splitting Using one or more split connections to improve TCP performance. TCP spoofing Sometimes used as a synonym for TCP PEP but more accurately refers to using transparent mechanisms to improve TCP performance. Expires December 25, 1999 [Page 22] INTERNET DRAFT Performance Enhancing Proxies June 1999 translucent Requires changes to be made at only one end system of a connection. transparent Requires no changes to be made to either end system of a connection. tunnelling The process of wrapping a packet received from an end system inside of another packet to transition a particular link. 7 Acknowledgements This document grew out of the Internet-Drafts "TCP Performance Enhancing Proxy Terminology" and "Long Thin Networks" and the work done in the IETF TCPSAT working group. 8 References [CTC+97] H. Chang, C. Tait, N. Cohen, M. Shapiro, S. Mastrianni, R. Floyd, B. Housel, D. Lindquist, "Web Browsing in a Wireless Environment: Disconnected and Asynchronous Operation in ARTour Web Express," in proceedings of MobiCom'97, Budapest, Hungary, September 1997. [FLASH] http://www.flash-networks.com/ [FOURELLE] http://www.fourelle.com/ [HNS] http://www.hns.com/ [I-TCP] A. Bakre, B.R. Badrinath, "I-TCP: Indirect TCP for Mobile Hosts," in proceedings of the 15th International Conference on Distributed Computing Systems (ICDCS), May 1995. [Karn99] P. Karn, "Advice for Internet Subnetwork Designers," Internet-Draft http://people.qualcomm.com/karn/pilc.txt (work in progress). [KRLKA97] Kojo, M., Raatikainen, K., Liljeberg, M., Kiiskinen, J., Alanko, T., "An Efficient Transport Service for Slow Wireless Telephone Links," in IEEE Journal on Selected Areas of Expires December 25, 1999 [Page 23] INTERNET DRAFT Performance Enhancing Proxies June 1999 Communication, volume 15, number 7, September 1997. [LHKR96] M. Liljeberg, H. Helin, M. Kojo, K. Raatikainen, "Mowgli WWW Software: Improved Usability of WWW in Mobile WAN Environments," in proceedings of IEEE Global Internet 1996 Conference, London, UK, November 1996. [MOWGLI] Kojo, M., Raatikainen, K., Alanko, T., "Connecting Mobile Workstations to the Internet over a Digital Cellular Telephone Network," in Proc. Workshop on Mobile and Wireless Information Systems (MOBIDATA), Rutgers University, NJ, November 1994. Available at: http://www.cs.Helsinki.FI/research/mowgli/. Revised version published in Mobile Computing, pp. 253-270, Kluwer, 1996. [M-TCP] K. Brown, S. Singh, "M-TCP: TCP for Mobile Cellular Networks," ACM Computer Communications Review Volume 27(5), 1997. Available at ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz. [NAT] P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations," Internet-Draft draft-ietf-nat-terminology-03.txt, June 1999 (work in progress). [Part98] C. Partridge, "ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering," September 1998. Internet-Draft draft-rfced-info-partridge-01.txt (work in progress). [RFC0793] J. Postel, "Transmission Control Protocol," STD 7, RFC 793, September 1981. [RFC1122] R. Braden, "Requirements for Internet Hosts -- Communications Layers," STD 3, RFC 1122, October 1989. [RFC1144] V. Jacobson, "Compressiing TCP/IP Headers for Low-Speed Serial Links," RFC 1144, February 1990. [RFC1323] V. Jacobson, R. Braden, D. Borman, "TCP Extensions for High Performance," RFC 1323, May 1992. [RFC1958] B. Carpenter, "Architectural Principles of the Internet," RFC 1958, June 1996. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A., "TCP Selective Acknowledgment Options," RFC 2018, October, 1996. [RFC2393] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload Compression Protocol (IPcomp)," RFC 2393, December 1998. [RFC2488] M. Allman, D. Glover, L. Sanchez, "Enhancing TCP Over Expires December 25, 1999 [Page 24] INTERNET DRAFT Performance Enhancing Proxies June 1999 Satellite Channels using Standard Mechanisms," BCP 28, RFC 2488, January 1999. [RFC2507] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression," RFC 2507, February 1999. [RFC2508] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links," RFC 2508, February 1999. [RFC2509] M. Engan, S. Casner, C. Bormann, "IP Header Compression over PPP," RFC 2509, February 1999. [SNOOP] H. Balakrishnan, S. Seshan, E. Amir, R. Katz, "Improving TCP/IP Performance over Wireless Networks," in proceedings of the 1st ACM Conference on Mobile Communications and Networking (Mobicom), Berkeley, CA, November 1995. [SNOOPELN] H. Balakrishnan, R. Katz, "Explicit Loss Notification and Wireless Web Performance," In Proc. IEEE Globecom 1998, Internet Mini-Conference, Sydney, Australia, November 1998. [SPACENET] http://www.spacenet.com/ 9 Authors' Addresses Questions about this document may be directed at: Expires December 25, 1999 [Page 25] INTERNET DRAFT Performance Enhancing Proxies June 1999 John Border Hughes Network Systems 11717 Exploration Lane Germantown, Maryland 20876 Voice: +1-301-601-4099 Fax: +1-301-601-4275 E-Mail: border@hns.com Markku Kojo University of Helsinki/Department of Computer Science P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland Voice: +358-9-7084-4179 Fax: +358-9-7084-4441 E-Mail: kojo@cs.helsinki.fi Jim Griner NASA Glenn Research Center MS: 54-2 21000 Brookpark Orad Cleveland, Ohio 44135-3191 Voice: +1-216-433-5787 Fax: +1-216-433-8705 E-Mail: jgriner@grc.nasa.gov Gabriel E. Montenegro Sun Labs Networking and Security Group Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303 Voice: +1-650-786-6288 Fax: +1-650-786-6445 E-Mail: gab@sun.com 10 Full Copyright Statement Copyright (C) The Internet Society (1999). 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 Expires December 25, 1999 [Page 26] INTERNET DRAFT Performance Enhancing Proxies June 1999 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires December 25, 1999 [Page 27]