Network Working Group                                          J. Border
Request for Comments: 3135                        Hughes Network Systems
Category: Informational                                          M. Kojo
                                                  University of Helsinki
                                                               J. Griner
                                              NASA Glenn Research Center
                                                           G. Montenegro
                                                  Sun Microsystems, Inc.
                                                               Z. Shelby
                                                      University of Oulu
                                                               June 2001
Network Working Group                                          J. Border
Request for Comments: 3135                        Hughes Network Systems
Category: Informational                                          M. Kojo
                                                  University of Helsinki
                                                               J. Griner
                                              NASA Glenn Research Center
                                                           G. Montenegro
                                                  Sun Microsystems, Inc.
                                                               Z. Shelby
                                                      University of Oulu
                                                               June 2001

Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations


Status of this Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (C) The Internet Society (2001). All Rights Reserved.




This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. Different types of Performance Enhancing Proxies are described as well as the mechanisms used to improve performance. Emphasis is put on proxies operating with TCP. In addition, motivations for their development and use are described along with some of the consequences of using them, especially in the context of the Internet.


Table of Contents


   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Types of Performance Enhancing Proxies  . . . . . . . . . . . .  4
   2.1 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.1.1 Transport Layer PEPs . . . . . . . . . . . . . . . . . . . .  5
   2.1.2 Application Layer PEPs . . . . . . . . . . . . . . . . . . .  5
   2.2 Distribution . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.3 Implementation Symmetry  . . . . . . . . . . . . . . . . . . .  6
   2.4 Split Connections  . . . . . . . . . . . . . . . . . . . . . .  7
   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Types of Performance Enhancing Proxies  . . . . . . . . . . . .  4
   2.1 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.1.1 Transport Layer PEPs . . . . . . . . . . . . . . . . . . . .  5
   2.1.2 Application Layer PEPs . . . . . . . . . . . . . . . . . . .  5
   2.2 Distribution . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.3 Implementation Symmetry  . . . . . . . . . . . . . . . . . . .  6
   2.4 Split Connections  . . . . . . . . . . . . . . . . . . . . . .  7
   2.5 Transparency . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3. PEP Mechanisms  . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.1 TCP ACK Handling . . . . . . . . . . . . . . . . . . . . . . .  9
   3.1.1 TCP ACK Spacing  . . . . . . . . . . . . . . . . . . . . . .  9
   3.1.2 Local TCP Acknowledgements . . . . . . . . . . . . . . . . .  9
   3.1.3 Local TCP Retransmissions  . . . . . . . . . . . . . . . . .  9
   3.1.4 TCP ACK Filtering and Reconstruction . . . . . . . . . . . . 10
   3.2 Tunneling  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.3 Compression  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.4 Handling Periods of Link Disconnection with TCP  . . . . . . . 11
   3.5 Priority-based Multiplexing  . . . . . . . . . . . . . . . . . 12
   3.6 Protocol Booster Mechanisms  . . . . . . . . . . . . . . . . . 13
   4. Implications of Using PEPs  . . . . . . . . . . . . . . . . . . 14
   4.1 The End-to-end Argument  . . . . . . . . . . . . . . . . . . . 14
   4.1.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Security Implications  . . . . . . . . . . . . . . . . . . 15 Security Implication Mitigations . . . . . . . . . . . . . 16 Security Research Related to PEPs  . . . . . . . . . . . . 16
   4.1.2 Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . 16
   4.1.3 End-to-end Reliability . . . . . . . . . . . . . . . . . . . 17
   4.1.4 End-to-end Failure Diagnostics . . . . . . . . . . . . . . . 19
   4.2 Asymmetric Routing . . . . . . . . . . . . . . . . . . . . . . 19
   4.3 Mobile Hosts . . . . . . . . . . . . . . . . . . . . . . . . . 20
   4.4 Scalability  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   4.5 Other Implications of Using PEPs . . . . . . . . . . . . . . . 21
   5. PEP Environment Examples  . . . . . . . . . . . . . . . . . . . 21
   5.1 VSAT Environments  . . . . . . . . . . . . . . . . . . . . . . 21
   5.1.1 VSAT Network Characteristics . . . . . . . . . . . . . . . . 22
   5.1.2 VSAT Network PEP Implementations . . . . . . . . . . . . . . 23
   5.1.3 VSAT Network PEP Motivation  . . . . . . . . . . . . . . . . 24
   5.2 W-WAN Environments . . . . . . . . . . . . . . . . . . . . . . 25
   5.2.1 W-WAN Network Characteristics  . . . . . . . . . . . . . . . 25
   5.2.2 W-WAN PEP Implementations  . . . . . . . . . . . . . . . . . 26 Mowgli System  . . . . . . . . . . . . . . . . . . . . . . 26 Wireless Application Protocol (WAP)  . . . . . . . . . . . 28
   5.2.3 W-WAN PEP Motivation . . . . . . . . . . . . . . . . . . . . 29
   5.3 W-LAN Environments . . . . . . . . . . . . . . . . . . . . . . 30
   5.3.1 W-LAN Network Characteristics  . . . . . . . . . . . . . . . 30
   5.3.2 W-LAN PEP Implementations: Snoop . . . . . . . . . . . . . . 31
   5.3.3 W-LAN PEP Motivation . . . . . . . . . . . . . . . . . . . . 33
   6. Security Considerations . . . . . . . . . . . . . . . . . . . . 34
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 34
   8. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 34
   9. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 35
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
   Appendix A - PEP Terminology Summary . . . . . . . . . . . . . . . 41
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 45
   2.5 Transparency . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3. PEP Mechanisms  . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.1 TCP ACK Handling . . . . . . . . . . . . . . . . . . . . . . .  9
   3.1.1 TCP ACK Spacing  . . . . . . . . . . . . . . . . . . . . . .  9
   3.1.2 Local TCP Acknowledgements . . . . . . . . . . . . . . . . .  9
   3.1.3 Local TCP Retransmissions  . . . . . . . . . . . . . . . . .  9
   3.1.4 TCP ACK Filtering and Reconstruction . . . . . . . . . . . . 10
   3.2 Tunneling  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.3 Compression  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.4 Handling Periods of Link Disconnection with TCP  . . . . . . . 11
   3.5 Priority-based Multiplexing  . . . . . . . . . . . . . . . . . 12
   3.6 Protocol Booster Mechanisms  . . . . . . . . . . . . . . . . . 13
   4. Implications of Using PEPs  . . . . . . . . . . . . . . . . . . 14
   4.1 The End-to-end Argument  . . . . . . . . . . . . . . . . . . . 14
   4.1.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Security Implications  . . . . . . . . . . . . . . . . . . 15 Security Implication Mitigations . . . . . . . . . . . . . 16 Security Research Related to PEPs  . . . . . . . . . . . . 16
   4.1.2 Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . 16
   4.1.3 End-to-end Reliability . . . . . . . . . . . . . . . . . . . 17
   4.1.4 End-to-end Failure Diagnostics . . . . . . . . . . . . . . . 19
   4.2 Asymmetric Routing . . . . . . . . . . . . . . . . . . . . . . 19
   4.3 Mobile Hosts . . . . . . . . . . . . . . . . . . . . . . . . . 20
   4.4 Scalability  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   4.5 Other Implications of Using PEPs . . . . . . . . . . . . . . . 21
   5. PEP Environment Examples  . . . . . . . . . . . . . . . . . . . 21
   5.1 VSAT Environments  . . . . . . . . . . . . . . . . . . . . . . 21
   5.1.1 VSAT Network Characteristics . . . . . . . . . . . . . . . . 22
   5.1.2 VSAT Network PEP Implementations . . . . . . . . . . . . . . 23
   5.1.3 VSAT Network PEP Motivation  . . . . . . . . . . . . . . . . 24
   5.2 W-WAN Environments . . . . . . . . . . . . . . . . . . . . . . 25
   5.2.1 W-WAN Network Characteristics  . . . . . . . . . . . . . . . 25
   5.2.2 W-WAN PEP Implementations  . . . . . . . . . . . . . . . . . 26 Mowgli System  . . . . . . . . . . . . . . . . . . . . . . 26 Wireless Application Protocol (WAP)  . . . . . . . . . . . 28
   5.2.3 W-WAN PEP Motivation . . . . . . . . . . . . . . . . . . . . 29
   5.3 W-LAN Environments . . . . . . . . . . . . . . . . . . . . . . 30
   5.3.1 W-LAN Network Characteristics  . . . . . . . . . . . . . . . 30
   5.3.2 W-LAN PEP Implementations: Snoop . . . . . . . . . . . . . . 31
   5.3.3 W-LAN PEP Motivation . . . . . . . . . . . . . . . . . . . . 33
   6. Security Considerations . . . . . . . . . . . . . . . . . . . . 34
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 34
   8. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 34
   9. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 35
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
   Appendix A - PEP Terminology Summary . . . . . . . . . . . . . . . 41
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction
1. 介绍

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.


This document is a survey of Performance Enhancing Proxy (PEP) performance migitigation techniques. A PEP is used to improve the performance of the Internet protocols on network paths where native performance suffers due to characteristics of a link or subnetwork on the path. This document is informational and does not make recommendations about using PEPs or not using them. Distinct standards track recommendations for the performance mitigation of TCP over links with high error rates, links with low bandwidth, and so on, have been developed or are in development by the Performance Implications of Link Characteristics WG (PILC) [PILCWEB].


Link 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 choices in the link layer design. And, the cost of compensating for some link characteristics may be prohibitive for some technologies. The techniques surveyed here are applied to existing link technologies. When new link technologies are designed, they should be designed so that these techniques are not required, if at all possible.


This document does not advocate the use of PEPs in any general case. On the contrary, we believe that the end-to-end principle in designing Internet protocols should be retained as the prevailing approach and PEPs should be used only in specific environments and circumstances where end-to-end mechanisms providing similar performance enhancements are not available. In any environment where one might consider employing a PEP for improved performance, an end user (or, in some cases, the responsible network administrator) should be aware of the PEP and the choice of employing PEP functionality should be under the control of the end user, especially if employing the PEP would interfere with end-to-end usage of IP layer security mechanisms or otherwise have undesirable implications in some circumstances. This would allow the user to choose end-to-end IP at all times but, of course, without the performance enhancements that employing the PEP may yield.


This survey does not make recommendations, for or against, with respect to using PEPs. Standards track recommendations have been or are being developed within the IETF for individual link


characteristics, e.g., links with high error rates, links with low bandwidth, links with asymmetric bandwidth, etc., by the Performance Implications of Link Characteristics WG (PILC) [PILCWEB].


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 mechanisms which PEPs may employ in order to improve performance. Section 4 discusses some of the implications with respect to using PEPs, especially in the context of the global Internet. Finally, Section 5 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 (Appendix A).


2. Types of Performance Enhancing Proxies
2. 性能增强代理的类型

There are many types of Performance Enhancing Proxies. Different types of PEPs 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 related aspects, like usability of a link, 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 PEPs.


2.1 Layering
2.1 分层

In principle, a PEP implementation may function at any protocol layer but typically it functions at one or two layers only. In this document we focus on PEP implementations that function at the transport layer or at the application layer as such PEPs are most commonly used to enhance performance over links with problematic characteristics. A PEP implementation may also operate below the network layer, that is, at the link layer, but this document pays only little attention to such PEPs as link layer mechanisms can be and typically are implemented transparently to network and higher layers, requiring no modifications to protocol operation above the link layer. It should also be noted that some PEP implementations operate across several protocol layers by exploiting the protocol information and possibly modifying the protocol operation at more than one layer. For such a PEP it may be difficult to define at which layer(s) it exactly operates on.


2.1.1 Transport Layer PEPs
2.1.1 传输层PEPs

Transport layer PEPs operate at the transport level. They may be aware of the type of application being carried by the transport layer but, at most, only use this information to influence their behavior with respect to the transport protocol; they do not modify the application protocol in any way, but let the application protocol operate end-to-end. Most transport layer PEP implementations interact with TCP. Such an implementation is called a TCP Performance Enhancing Proxy (TCP PEP). For example, in an environment where ACKs may bunch together causing undesirable data segment bursts, a TCP PEP may be used to simply modify the ACK spacing in order to improve performance. On the other hand, in an environment with a large bandwidth*delay product, a TCP PEP may be used to alter the behavior of the TCP connection by generating local acknowledgments to TCP data segments in order to improve the connection's throughput.

传输层PEP在传输层运行。他们可能知道传输层承载的应用程序的类型,但最多只使用此信息来影响他们关于传输协议的行为;它们不以任何方式修改应用程序协议,而是让应用程序协议端到端地运行。大多数传输层PEP实现都与TCP交互。这种实现称为TCP性能增强代理(TCP PEP)。例如,在ACK可能聚集在一起导致不希望的数据段突发的环境中,可以使用TCP PEP来简单地修改ACK间隔以提高性能。另一方面,在具有大带宽*延迟乘积的环境中,TCP PEP可用于通过生成对TCP数据段的本地确认来改变TCP连接的行为,以提高连接的吞吐量。

The term TCP spoofing is sometimes used synonymously for TCP PEP functionality. However, the term TCP spoofing more accurately describes the characteristic of intercepting a TCP connection in the middle and terminating the connection as if the interceptor is the intended destination. While this is a characteristic of many TCP PEP implementations, it is not a characteristic of all TCP PEP implementations.

术语TCP欺骗有时与TCP PEP功能同义。然而,术语TCP欺骗更准确地描述了截取TCP连接在中间的特性,并终止连接,就好像拦截器是预期的目的地一样。虽然这是许多TCP PEP实现的特征,但并非所有TCP PEP实现的特征。

2.1.2 Application Layer PEPs
2.1.2 应用层PEPs

Application layer PEPs operate above the transport layer. Today, different kinds of application layer proxies are widely used in the Internet. Such proxies include Web caches and relay Mail Transfer Agents (MTA) and they typically try to improve performance or service availability and reliability in general and in a way which is applicable in any environment but they do not necessarily include any optimizations that are specific to certain link characteristics.


Application layer PEPs, on the other hand, can be implemented to improve application protocol as well as transport layer performance with respect to a particular application being used with a particular type of link. An application layer PEP may have the same functionality as the corresponding regular proxy for the same application (e.g., relay MTA or Web caching proxy) but extended with link-specific optimizations of the application protocol operation.


Some application protocols employ extraneous round trips, overly verbose headers and/or inefficient header encoding which may have a significant impact on performance, in particular, with long delay and slow links. This unnecessary overhead can be reduced, in general or


for a particular type of link, by using an application layer PEP in an intermediate node. Some examples of application layer PEPs which have been shown to improve performance on slow wireless WAN links are described in [LHKR96] and [CTC+97].


2.2 Distribution
2.2 分配

A PEP implementation may be integrated, i.e., it comprises a single PEP component implemented within a single node, or distributed, i.e., it comprises two or more PEP components, typically implemented in multiple nodes. An integrated PEP implementation represents a single point at which performance enhancement is applied. For example, a single PEP component might be implemented to provide impedance matching at the point where wired and wireless links meet.


A distributed PEP 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 PEPs located at each end of the satellite link.


2.3 Implementation Symmetry
2.3 实现对称性

A PEP implementation may be symmetric or asymmetric. Symmetric PEPs use identical behavior in both directions, i.e., the actions taken by the PEP occur independent from which interface a packet is received. Asymmetric PEPs operate differently in each direction. The direction can be defined in terms of the link (e.g., from a central site to a remote site) or in terms of protocol traffic (e.g., the direction of TCP data flow, often called the TCP data channel, or the direction of TCP ACK flow, often called the TCP ACK channel). An asymmetric PEP implementation is generally used at a point where the characteristics of the links on each side of the PEP differ or with asymmetric protocol traffic. For example, an asymmetric PEP might be placed at the intersection of wired and wireless networks or an asymmetric application layer PEP might be used for the request-reply type of HTTP traffic. A PEP implementation may also be both symmetric and asymmetric at the same time with regard to different mechanisms it employs. (PEP mechanisms are described in Section 3.)

PEP实现可以是对称的,也可以是非对称的。对称PEP在两个方向上使用相同的行为,即PEP采取的动作独立于接收数据包的接口。不对称政治公众人物在每个方向上的运作方式不同。可以根据链路(例如,从中心站点到远程站点)或协议流量(例如,TCP数据流的方向,通常称为TCP数据通道,或TCP ACK流的方向,通常称为TCP ACK通道)来定义方向。非对称PEP实现通常用于PEP每侧链路的特性不同或具有非对称协议流量的点。例如,非对称PEP可以放置在有线和无线网络的交叉点,或者非对称应用层PEP可以用于HTTP通信的请求-应答类型。就PEP采用的不同机制而言,PEP实现也可能同时是对称和非对称的。(第3节介绍了政治公众人物机制。)

Whether a PEP implementation is symmetric or asymmetric is independent of whether the PEP implementation is integrated or distributed. In other words, a distributed PEP implementation might operate symmetrically at each end of a link (i.e., the two PEPs function identically). On the other hand, a distributed PEP implementation might operate asymmetrically, with a different PEP implementation at each end of the link. Again, this usually is used with asymmetric links. For example, for a link with an asymmetric


amount of bandwidth available in each direction, the PEP on the end of the link forwarding traffic in the direction with a large amount of bandwidth might focus on locally acknowledging TCP traffic in order to use the available bandwidth. At the same time, the PEP on the end of the link forwarding traffic in the direction with very little bandwidth might focus on reducing the amount of TCP acknowledgement traffic being forwarded across the link (to keep the link from congesting).


2.4 Split Connections
2.4 分离连接

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 PEP implementation, this is typically done to allow the use of a third connection between two PEPs 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 PEPs.


In an integrated PEP split connection TCP implementation, the PEP 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 PEP split connection implementation.


Many integrated PEPs use a split connection implementation in order to address a mismatch in TCP capabilities between two end systems. For example, the TCP window scaling 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 bandwidth*delay 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 PEP on its side of the high bandwidth*delay link. The split connection PEP then sets up a TCP connection with window scaling 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 PEPs does not necessarily exclude simultaneous use of IP for end-to-end connectivity. If a split connection is managed per application or per connection and is under the control of the end user, the user can decide whether a particular


TCP connection or application makes use of the split connection PEP or whether it operates end-to-end. When a PEP is employed on a last hop link, the end user control is relatively easy to implement.


In effect, application layer proxies for TCP-based applications are split connection TCP implementations with end systems using PEPs as a service related to a particular application. Therefore, all transport (TCP) layer enhancements that are available with split connection TCP implementations can also be employed with application layer PEPs in conjunction with application layer enhancements.


2.5 Transparency
2.5 透明度

Another key characteristic of a PEP is its degree of transparency. PEPs may operate totally transparently to the end systems, transport endpoints, and/or applications involved (in a connection), requiring no modifications to the end systems, transport endpoints, or applications.


On the other hand, a PEP implementation may require modifications to both ends in order to be used. In between, a PEP implementation may require modifications to only one of the ends involved. Either of these kind of PEP implementations is non-transparent, at least to the layer requiring modification.


It is sometimes useful to think of the degree of transparency of a PEP implementation at four levels, transparency with respect to the end systems (network-layer transparent PEP), transparency with respect to the transport endpoints (transport-layer transparent PEP), transparency with respect to the applications (application-layer transparent PEP) and transparency with respect to the users. For example, a user who subscribes to a satellite Internet access service may be aware that the satellite terminal is providing a performance enhancing service even though the TCP/IP stack and the applications in the user's PC are not aware of the PEP which implements it.


Note that the issue of transparency is not the same as the issue of maintaining end-to-end semantics. For example, a PEP implementation which simply uses a TCP ACK spacing mechanism maintains the end-to-end semantics of the TCP connection while a split connection TCP PEP implementation may not. Yet, both can be implemented transparently to the transport endpoints at both ends. The implications of not maintaining the end-to-end semantics, in particular the end-to-end semantics of TCP connections, are discussed in Section 4.

请注意,透明度的问题与维护端到端语义的问题不同。例如,简单使用TCP ACK间隔机制的PEP实现保持TCP连接的端到端语义,而拆分连接TCP PEP实现可能不这样做。然而,这两种方法都可以对两端的传输端点透明地实现。第4节讨论了不维护端到端语义,特别是TCP连接的端到端语义的含义。

3. PEP Mechanisms
3. 政治公众人物机制

An obvious key characteristic of a PEP implementation is the mechanism(s) it uses to improve performance. Some examples of PEP mechanisms are described in the following subsections. A PEP implementation might implement more than one of these mechanisms.


3.1 TCP ACK Handling
3.1 TCP确认处理

Many TCP PEP implementations are based on TCP ACK manipulation. The handling of TCP acknowledgments can differ significantly between different TCP PEP implementations. The following subsections describe various TCP ACK handling mechanisms. Many implementations combine some of these mechanisms and possibly employ some additional mechanisms as well.

许多TCP PEP实现都基于TCP ACK操作。TCP确认的处理在不同的TCP PEP实现之间可能会有很大的不同。以下小节描述了各种TCP ACK处理机制。许多实现结合了这些机制中的一些,还可能采用一些附加机制。

3.1.1 TCP ACK Spacing
3.1.1 TCP确认间隔

In environments where ACKs tend to bunch together, ACK spacing is used to smooth out the flow of TCP acknowledgments traversing a link. This improves performance by eliminating bursts of TCP data segments that the TCP sender would send due to back-to-back arriving TCP acknowledgments [BPK97].


3.1.2 Local TCP Acknowledgements
3.1.2 本地TCP确认

In some PEP implementations, TCP data segments received by the PEP are locally acknowledged by the PEP. This is very useful over network paths with a large bandwidth*delay product as it speeds up TCP slow start and allows the sending TCP to quickly open up its congestion window. Local (negative) acknowledgments are often also employed to trigger local (and faster) error recovery on links with significant error rates. (See Section 3.1.3.)


Local acknowledgments are automatically employed with split connection TCP implementations. When local acknowledgments are used, the burden falls upon the TCP PEP to recover any data which is dropped after the PEP acknowledges it.

本地确认自动用于拆分连接TCP实现。当使用本地确认时,TCP PEP有责任恢复PEP确认后丢弃的任何数据。

3.1.3 Local TCP Retransmissions
3.1.3 本地TCP重传

A TCP PEP may locally retransmit data segments lost on the path between the TCP PEP and the receiving end system, thus aiming at faster recovery from lost data. In order to achieve this the TCP PEP may use acknowledgments arriving from the end system that receives the TCP data segments, along with appropriate timeouts, to determine

TCP PEP可以本地重新传输在TCP PEP和接收端系统之间的路径上丢失的数据段,从而旨在更快地从丢失的数据中恢复。为了实现这一点,TCP PEP可以使用接收TCP数据段的终端系统发出的确认以及适当的超时来确定

when to locally retransmit lost data. TCP PEPs sending local acknowledgments to the sending end system are required to employ local retransmissions towards the receiving end system.

何时本地重新传输丢失的数据。向发送端系统发送本地确认的TCP PEP需要向接收端系统进行本地重传。

Some PEP implementations perform local retransmissions even though they do not use local acknowledgments to alter TCP connection performance. Basic Snoop [SNOOP] is a well know example of such a PEP implementation. Snoop caches TCP data segments it receives and forwards and then monitors the end-to-end acknowledgments coming from the receiving TCP end system for duplicate acknowledgments (DUPACKs). When DUPACKs are received, Snoop locally retransmits the lost TCP data segments from its cache, suppressing the DUPACKs flowing to the sending TCP end system until acknowledgments for new data are received. The Snoop system also implements an option to employ local negative acknowledgments to trigger local TCP retransmissions. This can be achieved, for example, by applying TCP selective acknowledgments locally on the error-prone link. (See Section 5.3 for details.)


3.1.4 TCP ACK Filtering and Reconstruction
3.1.4 TCP确认过滤与重构

On paths with highly asymmetric bandwidth the TCP ACKs flowing in the low-speed direction may get congested if the asymmetry ratio is high enough. The ACK filtering and reconstruction mechanism addresses this by filtering the ACKs on one side of the link and reconstructing the deleted ACKs on the other side of the link. The mechanism and the issue of dealing with TCP ACK congestion with highly asymmetric links are discussed in detail in [RFC2760] and in [BPK97].

在带宽高度不对称的路径上,如果不对称率足够高,则低速方向上流动的TCP ACK可能会拥塞。ACK过滤和重构机制通过过滤链路一侧的ACK并重构链路另一侧的已删除ACK来解决此问题。[RFC2760]和[BPK97]详细讨论了利用高度不对称链路处理TCP ACK拥塞的机制和问题。

3.2 Tunneling
3.2 隧道

A Performance Enhancing Proxy may encapsulate messages to carry the messages across a particular link or to force messages to traverse a particular path. A PEP 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 carrying the connection between the distributed PEPs. 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.


3.3 Compression
3.3 压缩

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. Benefits of using compression include improved link efficiency and higher effective link utilization, reduced latency and improved interactive response time, decreased overhead and reduced packet loss rate over lossy links.


Where appropriate, link layer compression is used. 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. Network (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 transferred) are already compressed. And, when security mechanisms such as TLS [RFC2246] are applied above the network (IP) layer, the data is already encrypted (and possibly also compressed), again removing or hiding any redundancy in the payload. The resulting additional transport or network layer compression will compact only headers, which are small, and possibly already covered by separate compression algorithms of their own.


With application layer PEPs one can employ application-specific compression. Typically an application-specific (or content-specific) compression mechanism is much more efficient than any generic compression mechanism. For example, a distributed Web PEP implementation may implement more efficient binary encoding of HTTP headers, or a PEP can employ lossy compression that reduces the image quality of online-images on Web pages according to end user instructions, thus reducing the number of bytes transferred over a slow link and consequently the response time perceived by the user [LHKR96].

使用应用层PEP,可以使用特定于应用程序的压缩。通常,特定于应用程序(或特定于内容)的压缩机制比任何通用压缩机制都要高效得多。例如,分布式Web PEP实现可以实现更高效的HTTP报头二进制编码,或者PEP可以采用有损压缩,根据最终用户指令降低网页上在线图像的图像质量,从而减少通过慢速链路传输的字节数,从而减少用户感知的响应时间[LHKR96]。

3.4 Handling Periods of Link Disconnection with TCP
3.4 TCP链路断开的处理周期

Periods of link disconnection or link outages are very common with some wireless links. During these periods, a TCP sender does not receive the expected acknowledgments. Upon expiration of the retransmit timer, this causes TCP to close its congestion window with all of the related drawbacks. A TCP PEP may monitor the traffic coming from the TCP sender towards the TCP receiver behind the

链路断开或链路中断的周期在某些无线链路中非常常见。在这些期间,TCP发送方不会收到预期的确认。当重传计时器过期时,这会导致TCP关闭其拥塞窗口,并具有所有相关的缺点。TCP PEP可以监控从TCP发送方到TCP接收方的流量

disconnected link. The TCP PEP 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.

断开连接。TCP PEP保留最后一个ACK,因此它可以通过发送窗口设置为零的最后一个ACK来关闭TCP发送方的窗口。因此,TCP发送方将进入持久模式。

To make this work in both directions with an integrated TCP PEP implementation, the TCP receiver behind the 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 PEP pair.

为了通过集成的TCP PEP实现在两个方向上都能工作,断开连接后的TCP接收器必须知道连接的当前状态,并且在断开连接的情况下,必须能够冻结所有计时器。[M-TCP]实现了这样的操作。另一种可能性是断开的链路被分布式PEP对包围。

In split connection TCP implementations, a period of link disconnection can easily be hidden from the end host on the other side of the PEP thus precluding the TCP connection from breaking even if the period of link disconnection lasts a very long time; if the TCP PEP cannot forward data due to link disconnection, it stops receiving data. Normal TCP flow control then prevents the TCP sender from sending more than the TCP advertised window allowed by the PEP. Consequently, the PEP 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. The period of link disconnection may or may not be hidden from the application and user, depending upon what application the user is using the TCP connection for.

在分离连接TCP实现中,链路断开的周期可以很容易地对PEP另一侧的终端主机隐藏,从而防止TCP连接中断,即使链路断开的周期持续很长时间;如果TCP PEP由于链路断开而无法转发数据,它将停止接收数据。然后,正常的TCP流控制会阻止TCP发送方发送超过PEP允许的TCP播发窗口的数据。因此,PEP及其断开链路后的对应方可以采用修改的TCP版本,该版本在断开期间保留状态和所有未确认的数据段,然后在链路重新连接时执行本地恢复。链路断开的时间段可能对应用程序和用户隐藏,也可能不对应用程序和用户隐藏,这取决于用户使用TCP连接的应用程序。

3.5 Priority-based Multiplexing
3.5 基于优先级的多路复用

Implementing priority-based multiplexing of data over a slow and expensive link may significantly improve the performance and usability of the link for selected applications or connections.


A user behind a slow link would experience the link more feasible to use in case of simultaneous data transfers, if urgent data transfers (e.g., interactive connections) could have shorter response time (better performance) than less urgent background transfers. If the interactive connections transmit enough data to keep the slow link fully utilized, it might be necessary to fully suspend the background transfers for awhile to ensure timely delivery for the interactive connections.


In flight TCP segments of an end-to-end TCP connection (with low priority) cannot be delayed for a long time. Otherwise, the TCP timer at the sending end would expire, resulting in suboptimal performance. However, this kind of operation can be controlled in conjunction with a split connection TCP PEP by assigning different priorities for different connections (or applications). A split connection PEP implementation allows the PEP in an intermediate node

端到端TCP连接(低优先级)的飞行中TCP段不能延迟很长时间。否则,发送端的TCP计时器将过期,导致性能不佳。但是,这种操作可以通过为不同的连接(或应用程序)分配不同的优先级,与分割连接TCP PEP一起进行控制。拆分连接PEP实现允许PEP位于中间节点中

to delay the data delivery of a lower-priority TCP flow for an unlimited period of time by simply rescheduling the order in which it forwards data of different flows to the destination host behind the slow link. This does not have a negative impact on the delayed TCP flow as normal TCP flow control takes care of suspending the flow between the TCP sender and the PEP, when the PEP is not forwarding data for the flow, and resumes it once the PEP decides to continue forwarding data for the flow. This can further be assisted, if the protocol stacks on both sides of the slow link implement priority based scheduling of connections.


With such a PEP implementation, along with user-controlled priorities, the user can assign higher priority for selected interactive connection(s) and have much shorter response time for the selected connection(s), even if there are simultaneous low priority bulk data transfers which in regular end-to-end operation would otherwise eat the available bandwidth of the slow link almost completely. These low priority bulk data transfers would then proceed nicely during the idle periods of interactive connections, allowing the user to keep the slow and expensive link (e.g., wireless WAN) fully utilized.


Other priority-based mechanisms may be applied on shared wireless links with more than two terminals. With shared wireless mediums becoming a weak link in Internet QoS architectures, many may turn to PEPs to provide extra priority levels across a shared wireless medium [SHEL00]. These PEPs are distributed on all nodes of the shared wireless medium. For example, in an 802.11 WLAN this PEP is implemented in the access point (base station) and each mobile host. One PEP then uses distributed queuing techniques to coordinate traffic classes of all nodes. This is also sometimes called subnet bandwidth management. See [BBKT97] for an example of queuing techniques which can be used to achieve this. This technique can be implemented either above or below the IP layer. Priority treatment can typically be specified either by the user or by marking the (IPv4) ToS or (IPv6) Traffic Class IP header field.

其他基于优先级的机制可应用于具有两个以上终端的共享无线链路上。随着共享无线介质成为Internet QoS体系结构中的薄弱环节,许多人可能会求助于PEP来跨共享无线介质提供额外的优先级[SHEL00]。这些PEP分布在共享无线媒体的所有节点上。例如,在802.11 WLAN中,该PEP在接入点(基站)和每个移动主机中实现。一个PEP然后使用分布式排队技术来协调所有节点的流量类别。这有时也称为子网带宽管理。参见[BBKT97]了解可用于实现此目的的排队技术示例。这种技术可以在IP层之上或之下实现。优先级处理通常可以由用户指定,也可以通过标记(IPv4)ToS或(IPv6)流量类IP头字段来指定。

3.6 Protocol Booster Mechanisms
3.6 协议增强机制

Work in [FMSBMR98] shows a range of other possible PEP mechanisms called protocol boosters. Some of these mechanisms are specific to UDP flows. For example, a PEP may apply asymmetrical methods such as extra UDP error detection. Since the 16 bit UDP checksum is optional, it is typically not computed. However, for links with errors, the checksum could be beneficial. This checksum can be added to outgoing UDP packets by a PEP.


Symmetrical mechanisms have also been developed. A Forward Erasure Correction (FZC) mechanism can be used with real-time and multicast traffic. The encoding PEP adds a parity packet over a block of packets. Upon reception, the parity is removed and missing data is regenerated. A jitter control mechanism can be implemented at the expense of extra latency. A sending PEP can add a timestamp to outgoing packets. The receiving PEP then delays packets in order to reproduce the correct interval.


4. Implications of Using PEPs
4. 使用政治公众人物的意义

The following sections describe some of the implications of using Performance Enhancing Proxies.


4.1 The End-to-end Argument
4.1 端到端的论点

As indicated in [RFC1958], the end-to-end argument [SRC84] 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 potential negative implications associated with using PEPs are related to the possibility of 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.5, not all PEP implementations break the end-to-end semantics of connections. Correctly designed PEPs do not attempt to replace any application level end-to-end function, but only attempt to add performance optimizations to a subpath of the end-to-end path between the application endpoints. Doing this can be consistent with the end-to-end argument. However, a user or network administrator adding a PEP to his network configuration should be aware of the potential end-to-end implications related to the mechanisms being used by the particular PEP implementation.


4.1.1 Security
4.1.1 安全

In most cases, security applied above the transport layer can be used with PEPs, especially transport layer PEPs. However, today, only a limited number of applications include support for the use of transport (or higher) layer security. Network (IP) layer security (IPsec) [RFC2401], on the other hand, can generally be used by any application, transparently to the application.

在大多数情况下,应用于传输层之上的安全性可用于PEP,尤其是传输层PEP。然而,目前只有少数应用程序支持使用传输(或更高)层安全性。另一方面,网络(IP)层安全性(IPsec)[RFC2401]通常可以被任何应用程序透明地使用。 Security Implications 安全影响

The most detrimental negative implication of breaking the end-to-end semantics of a connection is that it disables end-to-end use of IPsec. In general, a user or network administrator must choose between using PEPs and using IPsec. If IPsec is employed end-to-end, PEPs that are implemented on intermediate nodes in the network cannot examine the transport or application headers of IP packets because encryption of IP packets via IPsec's ESP header (in either transport or tunnel mode) renders the TCP header and payload unintelligible to the PEPs. Without being able to examine the transport or application headers, a PEP may not function optimally or at all.


If a PEP implementation is non-transparent to the users and the users trust the PEP in the middle, IPsec can be used separately between each end system and PEP. However, in most cases this is an undesirable or unacceptable alternative as the end systems cannot trust PEPs in general. In addition, this is not as secure as end-to-end security. (For example, the traffic is exposed in the PEP when it is decrypted to be processed.) 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 PEP, 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 PEP could be implemented to prevent this from happening by being smart enough to force the same level of security to each end system but this increases the complexity of the PEP implementation (and still is not as secure as end-to-end security).


With a transparent PEP implementation, it is difficult for the end systems to trust the PEP because they may not be aware of its existence. Even if the user is aware of the PEP, setting up acceptable security associations with the PEP while maintaining the PEP's transparent nature is problematic (if not impossible).


Note that even when a PEP implementation does not break the end-to-end semantics 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 PEP cannot reliably determine which IP packets contain ACKs of interest. In any case, the authors are currently not aware of any PEP implementations, transparent or non-transparent, which provide support for end-to-end IPsec, except in a case where the PEPs are implemented on the end hosts.

请注意,即使PEP实现没有破坏连接的端到端语义,PEP实现也可能无法在存在IPsec的情况下运行。例如,如果PEP不能可靠地确定哪些IP数据包包含感兴趣的ACK,则很难确定ACK间隔。在任何情况下,作者目前都不知道有任何PEP实现(透明或非透明)提供对端到端IPsec的支持,但PEP在终端主机上实现的情况除外。 Security Implication Mitigations 安全影响缓解措施

There are some steps which can be taken to allow the use of IPsec and PEPs to coexist. If an end user can select the use of IPsec for some traffic and not for other traffic, PEP processing can be applied to the traffic sent without IPsec. Of course, the user must then do without security for this traffic or provide security for the traffic via other means (for example, by using transport layer security). However, even when this is possible, significant complexity may need to be added to the configuration of the end system.


Another alternative is to implement IPsec between the two PEPs of a distributed PEP implementation. This at least protects the traffic between the two PEPs. (The issue of trusting the PEPs does not change.) In the case where the PEP implementation is not transparent to the user, (assuming that the user trusts the PEPs,) the user can configure his end system to use the PEPs as the end points of an IPsec tunnel. And, an IPsec tunnel could even potentially be used between the end system and a PEP to protect traffic on this part of the path. But, all of this adds complexity. And, it still does not eliminate the risk of the traffic being exposed in the PEP itself as the traffic is received from one IPsec tunnel, processed and then forwarded (even if forwarded through another IPsec tunnel).

另一种选择是在分布式PEP实现的两个PEP之间实现IPsec。这至少可以保护两个PEP之间的通信量。(信任PEP的问题没有改变。)在PEP实施对用户不透明的情况下(假设用户信任PEP),用户可以将其终端系统配置为使用PEP作为IPsec隧道的端点。而且,在终端系统和PEP之间甚至可能使用IPsec隧道来保护这部分路径上的流量。但是,所有这些都增加了复杂性。而且,当从一个IPsec隧道接收、处理然后转发(即使通过另一个IPsec隧道转发)流量时,它仍然不能消除在PEP本身中暴露流量的风险。 Security Research Related to PEPs 与政治公众人物相关的安全研究

There is research underway investigating the possibility of changing the implementation of IPsec to be more friendly to the use of PEPs. One approach being actively looked at is the use of multi-layer IP security. [Zhang00] describes a method which allows TCP headers to be encrypted as one layer (with the PEPs in the path of the TCP connections included in the security associations used to encrypt the TCP headers) while the TCP payload is encrypted end-to-end as a separate layer. This still involves trusting the PEP, but to a much lesser extent. However, a drawback to this approach is that it adds a significant amount of complexity to the IP security implementation. Given the existing complexity of IPsec, this drawback is a serious impediment to the standardization of the multi-layer IP security idea and it is very unlikely that this approach will be adopted as a standard any time soon. Therefore, relying on this type of approach will likely involve the use of non-standard protocols (and the associated risk of doing so).


4.1.2 Fate Sharing
4.1.2 命运分享

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 survive the failure depends upon how much state is being maintained


on behalf of the connection in the network and whether the state is self-healing. If no connection specific state resides in the network or such state is self-healing as in case of regular end-to-end operation, then a failure in the network will break the connection only 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 PEP), then a failure in the network (e.g., the node containing a PEP 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 PEPs is dependent upon both the PEP implementation and upon the types of applications being used. Sometimes coincidentally but more often by design, PEPs are used in environments where there is no alternate path between the end systems and, therefore, a failure of the intermediate node containing a PEP would result in the termination of the connection in any case. And, even when this is not the case, the risk of losing the connection in the case of regular end-to-end operation may exist as the connection could break for some other reason, for example, a long enough link outage of a last-hop wireless link to the end host. Therefore, users may choose to accept the risk of a PEP crashing in order to take advantage of the performance gains offered by the PEP implementation. The important thing is that accepting the risk should be under the control of the user (i.e., the user should always have the option to choose end-to-end operation) and, if the user chooses to use the PEP, the user should be aware of the implications that a PEP failure has with respect to the applications being used.


4.1.3 End-to-end Reliability
4.1.3 端到端可靠性

Another aspect of the end-to-end argument is that of acknowledging the receipt of data end-to-end in order to achieve reliable end-to-end delivery of data. An application aiming at reliable end-to-end delivery must implement an end-to-end check and recovery at the application level. According to the end-to-end argument, this is the only possibility to correctly implement reliable end-to-end operation. Otherwise the application violates the end-to-end argument. This also means that a correctly designed application can never fully rely on the transport layer (e.g., TCP) or any other communication subsystem to provide reliable end-to-end delivery.


First, a TCP connection may break down for some reason and result in lost data that must be recovered at the application level. Second, the checksum provided by TCP may be considered inadequate, resulting in undetected (by TCP) data corruption [Pax99] and requiring an


application level check for data corruption. Third, a 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, a well designed application must use an application layer acknowledgement to ensure end-to-end delivery of application layer data. Note that this does not diminish the value of a reliable transport protocol (i.e., TCP) as such a protocol allows efficient implementation of several essential functions (e.g., congestion control) for an application.


If a PEP implementation acknowledges application data prematurely (before the PEP receives an application ACK from the other endpoint), end-to-end reliability cannot be guaranteed. Typically, application layer PEPs do not acknowledge data prematurely, i.e., the PEP does not send an application ACK to the sender until it receives an application ACK from the receiver. And, transport layer PEP implementations, including TCP PEPs, generally do not interfere with end-to-end application layer acknowledgments as they let applications operate end-to-end. However, the user and/or network administrator employing the PEP must understand how it operates in order to understand the risks related to end-to-end reliability.

如果PEP实现过早地确认应用程序数据(在PEP从另一个端点接收到应用程序确认之前),则无法保证端到端的可靠性。通常,应用层PEP不会过早地确认数据,即,PEP在从接收方接收到应用ACK之前不会向发送方发送应用ACK。而且,传输层PEP实现(包括TCP PEP)通常不会干扰端到端应用层确认,因为它们允许应用程序端到端运行。但是,使用PEP的用户和/或网络管理员必须了解其运行方式,以便了解与端到端可靠性相关的风险。

Some Internet applications do not necessarily operate end-to-end in their regular operation, thus abandoning any end-to-end reliability guarantee. For example, Internet email delivery often operates via relay Mail Transfer Agents, that is, relay Simple Mail Transfer Protocol (SMTP) servers. An originating MTA (SMTP server) sends the mail message to a relay MTA that receives the mail message, stores it in non-volatile storage (e.g., on disk) and then sends an application level acknowledgement. The relay MTA then takes "full responsibility" for delivering the mail message to the destination SMTP server (maybe via another relay MTA); it tries to forward the message for a relatively long time (typically around 5 days). This scheme does not give a 100% guarantee of email delivery, but reliability is considered "good enough".


An application layer PEP for this kind of an application may acknowledge application data (e.g., mail message) without essentially decreasing reliability, as long as the PEP operates according to the same procedure as the regular proxy (e.g., relay MTA). Again, as indicated above, the user and/or network administrator employing such a PEP needs to understand how it operates in order to understand the reliability risks associated with doing so.


4.1.4 End-to-end Failure Diagnostics
4.1.4 端到端故障诊断

Another aspect of the end-to-end argument is the ability to support end-to-end failure diagnostics when problems are encountered. If a network problem occurs which breaks a connection, the end points of the connection will detect the failure via timeouts. However, the existence of a PEP in between the two end points could delay (sometimes significantly) the detection of the failure by one or both of the end points. (Of course, some PEPs are intentionally designed to hide these types of failures as described in Section 3.4.) The implications of delayed detection of a failed connection depend on the applications being used. Possibilities range from no impact at all (or just minor annoyance to the end user) all the way up to impacting mission critical business functions by delaying switchovers to alternate communications paths.


In addition, tools used to debug connection failures may be affected by the use of a PEP. For example, PING (described in [RFC792] and [RFC2151]) is often used to test for connectivity. But, because PING is based on ICMP instead of TCP (i.e., it is implemented using ICMP Echo and Reply commands at the network layer), it is possible that the configuration of the network might route PING traffic around the PEP. Thus, PING could indicate that an end-to-end path exists between two hosts when it does not actually exist for TCP traffic. Even when the PING traffic does go through the PEP, the diagnostics indications provided by the PING traffic are altered. For example, if the PING traffic goes transparently through the PEP, PING does not provide any indication that the PEP exists and since the PING traffic is not being subjected to the same processing as TCP traffic, it may not necessarily provide an accurate indication of the network delay being experienced by TCP traffic. On the other hand, if the PEP terminates the PING and responds to it on behalf of the end host, then the PING provides information only on the connectivity to the PEP. Traceroute (also described in [RFC2151]) is similarly affected by the presence of the PEP.

此外,用于调试连接故障的工具可能会受到PEP使用的影响。例如,PING(在[RFC792]和[RFC2151]中描述)通常用于测试连接性。但是,由于PING基于ICMP而不是TCP(即,它是在网络层使用ICMP Echo和Reply命令实现的),因此网络配置可能会在PEP周围路由PING流量。因此,PING可能表示两台主机之间存在一条端到端路径,而TCP流量实际上并不存在该路径。即使PING流量通过PEP,PING流量提供的诊断指示也会改变。例如,如果PING通信量透明地通过PEP,那么PING不提供PEP存在的任何指示,并且由于PING通信量没有受到与TCP通信量相同的处理,因此它可能不一定提供TCP通信量所经历的网络延迟的准确指示。另一方面,如果PEP终止PING并代表终端主机响应,则PING仅提供与PEP连接的信息。示踪路由(也在[RFC2151]中描述)同样受到PEP存在的影响。

4.2 Asymmetric Routing
4.2 非对称路由

Deploying a PEP implementation usually requires that traffic to and from the end hosts is routed through the intermediate node(s) where PEPs reside. With some networks, this cannot be accomplished, or it might require that the intermediate node is located several hops away from the target link edge which in turn is impractical in many cases and may result in non-optimal routing.


Note that this restriction does not apply to all PEP implementations. For example, a PEP which is simply doing ACK spacing only needs to see one direction of the traffic flow (the direction in which the ACKs are flowing). ACK spacing can be done without seeing the actual flow of data.


4.3 Mobile Hosts
4.3 移动主机

In environments where a PEP implementation is used to serve mobile hosts, additional problems may be encountered because PEP related state information may need to be transferred to a new PEP node during a handoff.


When a mobile host moves, it is subject to handovers. If the intermediate node and home for the serving PEP changes due to handover, any state information that the PEP maintains and is required for continuous operation must be transferred to the new intermediate node to ensure continued operation of the connection. This requires extra work and overhead and may not be possible to perform fast enough, especially if the host moves frequently over cell boundaries of a wireless network. If the mobile host moves to another IP network, routing to and from the mobile host may need to be changed to traverse a new PEP node.


Today, mobility implications with respect to using PEPs are more significant to W-LAN networks than to W-WAN networks. Currently, a W-WAN base station typically does not provide the mobile host with the connection point to the wireline Internet. (A W-WAN base station may not even have an IP stack.) Instead, the W-WAN network takes care of mobility with the connection point to the wireline Internet remaining unchanged while the mobile host moves. Thus, PEP state handover is not currently required in most W-WAN networks when the host moves. However, this is generally not true in W-LAN networks and, even in the case of W-WAN networks, the user and/or network administrator using a PEP needs to be cognizant of how the W-WAN base stations and the PEP work in case W-WAN PEP state handoff becomes necessary in the future.

今天,与使用PEP有关的移动性影响对于W-LAN网络比W-WAN网络更为重要。目前,W-WAN基站通常不向移动主机提供到有线因特网的连接点。(W-WAN基站甚至可能没有IP堆栈。)相反,W-WAN网络负责移动性,在移动主机移动时,到有线因特网的连接点保持不变。因此,当主机移动时,大多数W-WAN网络中目前不需要PEP状态切换。然而,这在W-LAN网络中通常是不正确的,并且即使在W-WAN网络的情况下,使用PEP的用户和/或网络管理员也需要知道在将来需要W-WAN PEP状态切换的情况下W-WAN基站和PEP如何工作。

4.4 Scalability
4.4 可伸缩性

Because a PEP typically processes packet information above the IP layer, a PEP requires more processing power per packet than a router. Therefore, PEPs will always be (at least) one step behind routers in terms of the total throughput they can support. (Processing above the IP layer is also more difficult to implement in hardware.) In addition, since most PEP implementations require per connection state, PEP memory requirements are generally significantly higher


than with a router. Therefore, a PEP implementation may have a limit on the number of connections which it can support whereas a router has no such limitation.


Increased processing power and memory requirements introduce scalability issues with respect to the use of PEPs. Placement of a PEP on a high speed link or a link which supports a large number of connections may require network topology changes beyond just inserting the PEP into the path of the traffic. For example, if a PEP can only handle half of the traffic on a link, multiple PEPs may need to be used in parallel, adding complexity to the network configuration to divide the traffic between the PEPs.


4.5 Other Implications of Using PEPs
4.5 使用政治公众人物的其他影响

This document describes some significant implications with respect to using Performance Enhancing Proxies. However, the list of implications provided in this document is not necessarily exhaustive. Some examples of other potential implications related to using PEPs include the use of PEPs in multi-homing environments and the use of PEPs with respect to Quality of Service (QoS) transparency. For example, there may be potential interaction with the priority-based multiplexing mechanism described in Section 3.5 and the use of differentiated services [RFC2475]. Therefore, users and network administrators who wish to deploy a PEP should look not only at the implications described in this document but also at the overall impact (positive and negative) that the PEP will have on their applications and network infrastructure, both initially and in the future when new applications are added and/or changes in the network infrastructure are required.


5. PEP Environment Examples
5. PEP环境示例

The following sections describe examples of environments where PEP is currently used to improve performance. The examples are provided to illustrate the use of the various PEP types and PEP mechanisms described earlier in the document and to help illustrate the motivation for their development and use.


5.1 VSAT Environments
5.1 VSAT环境

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. VSATs represent an environment with highly asymmetric links, with an outroute typically


much larger than an inroute. (Multiple inroutes can be used with each outroute but any particular VSAT only has access to a single inroute at a time, making the link asymmetric.)


VSAT networks are generally used to implement private networks (i.e., intranets) for enterprises (e.g., corporations) with geographically dispersed sites. VSAT networks are rarely, if ever, used to implement Internet connectivity except at the edge of the Internet (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 necessary) NAT [RFC2663] devices.


5.1.1 VSAT Network Characteristics
5.1.1 VSAT网络特性

With respect to TCP performance, VSAT networks exhibit the following subset of the satellite characteristics documented in [RFC2488]:


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 bandwidth*delay 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 acknowledgments [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. (The issue of asymmetric link impact on TCP performance is described in more detail in [BPK97].)


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 an overall network availability point of view) and VSAT networks are generally engineered to work during these conditions but not to optimize performance during these conditions.


5.1.2 VSAT Network PEP Implementations
5.1.2 VSAT网络PEP实现

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 not a dominant PEP implementation used with VSAT networks. Each VSAT network vendor tends to implement their own version of PEP functionality, 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. NettGain [FLASH] and Venturi [FOURELLE] are examples of such products. VSAT network PEP implementations generally share the following characteristics:


- They focus on improving TCP performance;

- 他们专注于提高TCP性能;

- They use an asymmetric distributed implementation;

- 他们使用非对称的分布式实现;

- They use a split connection approach with local acknowledgments 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;

- 通过卫星链路使用的协议。一些实现使用TCP的修改版本,而另一些使用运行在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.

- 使用的压缩类型。第三方VSAT网络PEP实施通常侧重于特定于应用程序(如HTTP)的压缩算法,而集成到VSAT网络中的PEP实施通常侧重于特定于链路的压缩。

PEP implementations integrated into a VSAT product are generally transparent to the end systems. Third party PEP implementations used with VSAT networks usually require configuration changes in the remote site end systems to route TCP packets to the remote site proxies but do not require changes to the hub site end systems. In some cases, the PEP implementation is actually integrated transparently into the end system node itself, using a "bump in the stack" approach. In all cases, the use of a PEP is non-transparent to the user, i.e., the user is aware when a PEP implementation is being used to boost performance.


5.1.3 VSAT Network PEP Motivation
5.1.3 VSAT网络PEP激励

VSAT networks, since the early stages of their deployment, have supported the use of local termination of a protocol (e.g., SDLC and X.25) on each side of the satellite link to hide the satellite link from the applications using the protocol. Therefore, when LAN capabilities were added to VSAT networks, VSAT customers expected and, in fact, demanded, the use of similar techniques for improving the performance of IP based traffic, in particular TCP traffic.


As indicated in Section 5.1, VSAT networks are primarily used to implement intranets with Internet connectivity limited to and closely controlled at the hub site of the VSAT network. Therefore, VSAT customers are not as affected (or at least perceive that they are not as affected) by the Internet related implications of using PEPs as are other technologies. Instead, what is more important to VSAT customers is the optimization of the network. And, VSAT customers, in general, prefer that the optimization of the network be done by the network itself rather than by implementing changes (such as enabling the TCP scaled window option) to their own equipment. VSAT customers prefer to optimize their end system configuration for local communications related to their local mission critical functions and let the VSAT network hide the presence of the satellite link as much as possible. VSAT network vendors have also been able to use PEP functionality to provide value added "services" to their customers such as extending the useful of life of older equipment which includes older, "non-modern" TCP stacks.


Of course, as the line between intranets and the Internet continues to fade, the implications of using PEPs start to become more significant for VSAT networks. For example, twelve years ago security was not a major concern because the equipment cost related to being able to intercept VSAT traffic was relatively high. Now, as technology has advanced, the cost is much less prohibitive. Therefore, because the use of PEP functionality in VSAT networks prevents the use of IPsec, customers must rely on the use of higher layer security mechanisms such as TLS or on proprietary security mechanisms implemented in the VSAT networks themselves (since currently many applications are incapable of making (or simply don't make) use of the standardized higher layer security mechanisms). This, in turn, affects the cost of the VSAT network as well as affects the ability of the customers to make use of Internet based capabilities.


5.2 W-WAN Environments
5.2 W-WAN环境

In mobile wireless WAN (W-WAN) environments the wireless link is typically used as the last-hop link to the end user. W-WANs include such networks as GSM [GSM], GPRS [GPRS],[BW97], CDPD [CDPD], IS-95 [CDMA], RichoNet, and PHS. Many of these networks, but not all, have been designed to provide mobile telephone voice service in the first place but include data services as well or they evolve from a mobile telephone network.


5.2.1 W-WAN Network Characteristics
5.2.1 W-WAN网络特性

W-WAN links typically exhibit some combination of the following link characteristics:


- low bandwidth (with some links the available bandwidth might be as low as a few hundred bits/sec)

- 低带宽(对于某些链路,可用带宽可能低至几百位/秒)

- high latency (minimum round-trip delay close to one second is not exceptional)

- 高延迟(接近1秒的最小往返延迟并不例外)

- high BER resulting in frame or packet losses, or long variable delays due to local link-layer error recovery

- 高误码率导致帧或数据包丢失,或由于本地链路层错误恢复导致长时间可变延迟

- some W-WAN links have a lot of internal buffer space which tend to accumulate data, thus resulting in increased round-trip delay due to long (and variable) queuing delays

- 一些W-WAN链路具有大量内部缓冲空间,这些缓冲空间往往会累积数据,因此由于长(和可变)排队延迟,导致往返延迟增加

- on some W-WAN links the users may share common channels for their data packet delivery which, in turn, may cause unexpected delays to the packet delivery of a user due to simultaneous use of the same channel resources by the other users

- 在一些W-WAN链路上,用户可以共享用于其数据分组传送的公共信道,这反过来可能由于其他用户同时使用相同信道资源而导致用户分组传送的意外延迟

- unexpected link disconnections (or intermittent link outages) may occur frequently and the period of disconnection may last a very long time

- 意外链路断开(或间歇性链路中断)可能会频繁发生,断开时间可能会持续很长时间

- (re)setting the link-connection up may take a long time (several tens of seconds or even minutes)

- (重新)设置链路连接可能需要很长时间(几十秒甚至几分钟)

- the 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

- W-WAN网络通常负责终端移动性:当用户与移动主机一起移动时,保留到Internet的连接点

- the use of most W-WAN links is expensive. Many of the service providers apply time-based charging.

- 大多数W-WAN链路的使用成本很高。许多服务提供商采用基于时间的收费。

5.2.2 W-WAN PEP Implementations
5.2.2 W-WAN PEP实现

Performance Enhancing Proxies implemented for W-WAN environments generally focus on improving the interactive response time but at the same time aim at improving throughput, mainly by reducing the transfer volume over the inherently slow link in various ways. To achieve this, typically enhancements are applied at almost all protocol layers.

为W-WAN环境实施的性能增强代理通常侧重于提高交互响应时间,但同时旨在提高吞吐量,主要是通过以各种方式减少固有慢速链路上的传输量。为了实现这一点,通常会在几乎所有协议层上应用增强功能。 Mowgli System 莫格利系统

The Mowgli system [KRA94] is one of the early approaches to address the challenges induced by the problematic characteristics of low bandwidth W-WAN links.


The indirect approach used in Mowgli is not limited to a single layer as in many other split connection approaches, but it involves all protocol layers. The basic architecture is based on split TCP (UDP is also supported) together with full support for application layer proxies with a distributed PEP approach. An application layer proxy pair may be added between a client and server, the agent (local proxy) on a mobile host and the proxy on an intermediate node that provides the mobile host with the connection to the wireline Internet. Such a pair may be either explicit or fully transparent to the applications, but it is, at all times, under end-user control thus allowing the user to select the traffic that traverses through the PEP implementation and choose end-to-end IP for other traffic.


In order to allow running legacy applications unmodified and without recompilation, the socket layer implementation on the mobile host is slightly modified to connect the applications, which are configured to traverse through the PEP, to a local agent while retaining the original TCP/IP socket semantics. Two types of application layer agent-proxy pairs can be configured for mobile host application use.


A generic pair can be used with any application and it simply provides split transport service with some optional generic enhancements like compression. An application-specific pair can be retailed for any application or a group of applications that are able to take leverage on the same kind of enhancements. A good example of enhancements achieved with an application-specific proxy pair is the Mowgli WWW system that improves significantly the user perceived response time of Web browsing mainly by reducing the transfer volume and the number of round trips over the wireless link [LAKLR95], [LHKR96].

通用对可以用于任何应用程序,它只提供带有一些可选通用增强功能(如压缩)的拆分传输服务。特定于应用程序的一对可以针对任何应用程序或一组能够利用同类增强功能的应用程序进行零售。使用特定于应用程序的代理对实现的一个很好的增强示例是Mowgli WWW系统,该系统主要通过减少无线链路上的传输量和往返次数[LAKLR95],[LHKR96],显著提高了用户感知的Web浏览响应时间。

Mowgli provides also an option to replace the TCP/IP core protocols on the last-hop link with a custom protocol that is tuned for low-bandwidth W-WAN links [KRLKA97]. This protocol was designed to provide the same transport service with similar semantics as regular TCP and UDP provide, but use a different protocol implementation that can freely apply any appropriate protocol mechanisms without being constrained by the current TCP/IP packet format or protocol operation. As this protocol is required to operate over a single logical link only, it could partially combine the protocol control information and protocol operation of the link, network, and transport layers. In addition, the protocol can operate on top of various link services, for example on top of different raw link services, on top of PPP, on top of IP, or even on top of a single TCP connection using it as a link service and implementing "TCP multiplexing" over it. In all other cases, except when the protocol is configured to operate on top of raw (wireless) link service, IP may co-exist with the custom protocol allowing simultaneous end-to-end IP delivery for the traffic not traversing through the PEP implementation.


Furthermore, the custom protocol can be run in different operation modes which turn on or off certain protocol functions depending on the underlying link service. For example, if the underlying link service provides reliable data delivery, the checksum and the window-based error recovery can be turned off, thus reducing the protocol overhead; only a very simple recovery mechanism is needed to allow recovery from an unexpected link disconnection. Therefore, the protocol design was able to use extremely efficient header encoding (only 1-3 bytes per packet in a typical case), reduce the number of round trips significantly, and various features that are useful with low-bandwidth W-WAN links were easy to add. Such features include suspending the protocol operation over the periods of link disconnection or link outage together with fast start once the link becomes operational again, priority-based multiplexing of user data over the W-WAN link thus offering link capacity to interactive


applications in a timely manner even in presence of bandwidth-intensive background transfers, and link-level flow control to prevent data from accumulating into the W-WAN link internal buffers.


If desired, regular TCP/IP transport, possibly with corresponding protocol modifications in TCP (and UDP) that would tune it more suitable for W-WAN links, can be employed on the last-hop link.

如果需要,可以在最后一跳链路上使用常规TCP/IP传输,可能在TCP(和UDP)中进行相应的协议修改,以使其更适合W-WAN链路。 Wireless Application Protocol (WAP) 无线应用协议(WAP)

The Mowgli system was designed to support mobile hosts that are attached to the Internet over constrained links, but did not address the specific challenges with low-end mobile devices. Many mobile wireless devices are power, memory, and processing constrained, and the communication links to these devices have lower bandwidth and less stable connections. These limitations led designers to develop the Wireless Application Protocol (WAP) that specifies an application framework and network protocols intended to work across differing narrowband wireless network technologies bringing Internet content and advanced data services to low-end digital cellular phones and other mobile wireless terminals, such as pagers and PDAs.


The WAP model consists of a WAP client (mobile terminal), a WAP proxy, and an origin server. It requires a WAP proxy between the WAP client and the server on the Internet. WAP uses a layered, scalable architecture [WAPARCH], specifying the following five protocol layers to be used between the terminal and the proxy: Application Layer (WAE) [WAPWAE], Session Layer (WSP) [WAPWSP], Transaction Layer (WTP) [WAPWTP], Security Layer (WTLS) [WAPWTLS], and Transport Layer (WDP) [WAPWDP]. Standard Internet protocols are used between the proxy and the origin server. If the origin server includes WAP proxy functionality, it is called a WAP Server.


In a typical scenario, a WAP client sends an encoded WAP request to a WAP proxy. The WAP proxy translates the WAP request into a WWW (HTTP) request, performing the required protocol conversions, and submits this request to a standard web server on the Internet. After the web server responds to the WAP proxy, the response is encoded into a more compact binary format to decrease the size of the data over the air. This encoded response is forwarded to the WAP client [WAPPROXY].


WAP operates over a variety of bearer datagram services. When communicating over these bearer services, the WAP transport layer (WDP) is always used between the WAP client and WAP proxy and it provides port addressed datagram service to the higher WAP layers. If the bearer service supports IP (e.g., GSM-CSD, GSM-GPRS, IS-136, CDPD), UDP is used as the datagram protocol. However, if the bearer


service does not support IP (e.g., GSM-SMS, GSM-USSD, GSM Cell Broadcast, CDMS-SMS, TETRA-SDS), WDP implements the required datagram protocol as an adaptation layer between the bearer network and the protocol stack.


The use of the other layers depends on the port number. WAP has registered a set of well-known ports with IANA. The port number selected by the application for communication between a WAP client and proxy defines the other layers to be used at each end. The security layer, WTLS, provides privacy, data integrity and authentication. Its functionality is similar to TLS 1.0 [RFC2246] extended with datagram support, optimized handshake and dynamic key refreshing. If the origin server includes WAP proxy functionality, it might be used to facilitate the end-to-end security solutions, otherwise it provides security between the mobile terminal and the proxy.

其他层的使用取决于端口号。WAP已经向IANA注册了一组著名的端口。应用程序为WAP客户端和代理之间的通信选择的端口号定义了在每一端使用的其他层。安全层WTLS提供隐私、数据完整性和身份验证。其功能类似于TLS 1.0[RFC2246],通过数据报支持、优化握手和动态密钥刷新进行扩展。如果源服务器包含WAP代理功能,则它可能用于促进端到端安全解决方案,否则它将提供移动终端和代理之间的安全性。

The transaction layer, WTP, is message based without connection establishment and tear down. It supports three types of transaction classes: an unconfirmed request (unidirectional), a reliable (confirmed) request (unidirectional), and a reliable (confirmed) request-reply transaction. Data is carried in the first packet and 3-way handshake is eliminated to reduce latencies. In addition acknowledgments, retransmission, and flow control are provided. It allows more than one outstanding transaction at a time. It handles the bearer dependence of a transfer, e.g., selects timeout values and packet sizes according to the bearer. Unfortunately, WTP uses fixed retransmission timers and does not include congestion control, which is a potential problem area as the use of WAP increases [RFC3002].


The session layer, WSP, supports binary encoded HTTP 1.1 with some extensions such as long living session with suspend/resume facility and state handling, header caching, and push facility. On top of the architecture is the application environment (WAE).

会话层WSP支持二进制编码的HTTP 1.1和一些扩展,例如具有挂起/恢复功能和状态处理、头缓存和推送功能的长期会话。体系结构之上是应用程序环境(WAE)。

5.2.3 W-WAN PEP Motivation
5.2.3 W-WAN政治公众人物激励

As indicated in Section 5.2.1, W-WAN networks typically offer very low bandwidth connections with high latency and relatively frequent periods of link disconnection and they usually are expensive to use. Therefore, the transfer volume and extra round-trips, such as those associated with TCP connection setup and teardown, must be reduced and the slow W-WAN link should be efficiently shielded from excess traffic and global (wired) Internet congestion to make Internet access usable and economical. Furthermore, interactive traffic must be transmitted in a timely manner even if there are other simultaneous bandwidth intensive (background) transfers and during the periods with connectivity the link must be kept fully utilized


due to expensive use. In addition, the (long) periods of link disconnection must not abort active (bulk data) transfers, if an end-user so desires.


As (all) applications cannot be made mobility/W-WAN aware in short time frame or maybe ever, support for mobile W-WAN use should be implemented in a way which allows most applications, at least those running on fixed Internet hosts, to continue their operation unmodified.


5.3 W-LAN Environments
5.3 W-LAN环境

Wireless LANs (W-LAN) are typically organized in a cellular topology where an access point with a W-LAN transceiver controls a single cell. A cell is defined in terms of the coverage area of the base station. The access points are directly connected to the wired network. The access point 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 transceivers 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 access point of the new cell. This is known as a handoff. Many W-LAN systems also support an operation mode enabling ad-hoc networking. In this mode access points are not necessarily needed, but hosts with W-LAN transceiver can communicate directly with the other hosts within the transceiver's transmission range.


5.3.1 W-LAN Network Characteristics
5.3.1 W-LAN网络特性

Current wireless LANs typically provide link bandwidth from 1 Mbps to 11 Mbps. In the future, wide deployment of higher bandwidths up to 54 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 IEEE 802.11, HomeRF, and Hiperlan. Wireless personal area networks (WPAN) such as Bluethooth can use the same PEP techniques.

当前的无线局域网通常提供从1Mbps到11Mbps的链路带宽。在未来,预计将广泛部署高达54 Mbps甚至更高的更高带宽。无线局域网的往返延迟大约为几毫秒或几十毫秒。W-LAN的示例包括IEEE 802.11、HomeRF和Hiperlan。诸如Bluethooth之类的无线个人区域网络(WPAN)可以使用相同的PEP技术。

Wireless LANs are error-prone due to bit errors, collisions and link outages. In addition, consecutive packet losses may also occur during handoffs. Most W-LAN MAC protocols perform low level retransmissions. This feature shields upper layers from most losses. However, unavoidable losses, retransmission latency and link outages still affect upper layers. TCP performance over W-LANs or a network path involving a W-LAN link is likely to suffer from these effects.

由于位错误、冲突和链路中断,无线局域网容易出错。此外,在切换期间也可能发生连续的分组丢失。大多数W-LAN MAC协议执行低级重传。此功能可保护上层免受大部分损失。然而,不可避免的损失、重传延迟和链路中断仍然会影响上层。通过W-LAN或涉及W-LAN链路的网络路径的TCP性能可能会受到这些影响。

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.


5.3.2 W-LAN PEP Implementations: Snoop
5.3.2 W-LAN PEP实现: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 for each TCP connection. The Snoop agent is an asymmetric PEP implementation as it operates differently on TCP data and ACK channels as well as on the uplink (from the mobile host) and downlink (to the mobile host) TCP segments.


For a data transfer to a mobile host, the Snoop agent caches unacknowledged TCP data segments which it forwards to the TCP receiver and monitors the corresponding ACKs. It does two things:


1. Retransmits any lost data segments locally by using local timers and TCP duplicate ACKs to identify packet loss, instead of waiting for the TCP sender to do so end-to-end.

1. 通过使用本地计时器和TCP复制确认来识别数据包丢失,而不是等待TCP发送方端到端地重新传输任何丢失的数据段。

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.

2. 在从移动主机返回发送方的过程中抑制重复的ACK,从而避免后者的快速重传和拥塞避免。

Suppressing the duplicate ACKs is required to avoid unnecessary fast retransmits by the TCP sender as 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 S 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, R receives packets A, C, D, E and B (in that order). Receipt of packets C, D and E trigger duplicate ACKs. When S receives three duplicate ACKs, 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 ACKs. The fast retransmit at S occurs despite the local retransmit on the wireless link, degrading throughput. Snoop deals with this problem by dropping TCP duplicate ACKs appropriately at BS.


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 the TCP sender of the packet losses on the wireless link, one possibility to implement them is using the Selective Acknowledgment (SACK) option of 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 advised 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 later in the path to the receiver. Instead, the sender must wait for a cumulative ACK to arrive.

当Snoop代理使用NAK通知TCP发送方无线链路上的数据包丢失时,实现它们的一种可能性是使用TCP[RFC2018]的选择性确认(SACK)选项。这需要在移动主机上启用SACK处理。当Snoop代理检测到来自移动主机的传输序列中存在漏洞或在特定时间段内未从移动主机接收任何新数据包时,它会发送TCP SACK。这种方法依赖于SACK的建议性质:建议移动发送方重新传输SACK指示的缺失段,但不能假设SACK确认的段成功端到端传递,因为这些段可能稍后在通往接收方的路径中丢失。相反,发送方必须等待累计ACK到达。

When the ELN mechanism is used to inform the mobile sender of the packet losses, Snoop uses one of the 'unreserved' bits in the TCP header for ELN [SNOOPELN]. The Snoop agent keeps track of the holes that correspond to segments lost over the wireless link. When a (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.


The ELN mechanism using one of the six bits reserved for future use in the TCP header is dangerous as it exercises checks that might not be correctly implemented in TCP stacks, and may expose bugs.


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 link-layer recovery for lost data, then this scheme is not beneficial. Also, if the TCP window tends to stay smaller than four segments, for example, due to congestion related losses on the wired network, the probability that the Snoop agent will have an opportunity to locally retransmit a lost packet is small. This is because at least three duplicate ACKs are needed to trigger the local retransmission, but due to small window the Snoop


agent may not be able to forward three new packets after the lost packet and thus induce the required three duplicate ACKs. Conversely, when the TCP window is large enough, Snoop can provide significant performance improvement (compared with standard TCP).


In order to alleviate the problem with small TCP windows, Snoop proposes a solution in which a TCP sender is allowed to transmit a new data segment for each duplicate ACK it receives as long as the number of duplicate ACKs is less than the threshold for TCP fast retransmission (three duplicate ACKs). If the new segment reaches the receiver, it will generate another duplicate ACK which, in turn, allows the sender to transmit yet another data segment. This continues until enough duplicate ACKs have accumulated to trigger TCP fast retransmission. This proposal is the same as the "Limited Transfer" proposal [RFC3042] that has recently been forwarded to the standards track. However, to be able to benefit from this solution, it needs to be deployed on TCP senders and therefore it is not ready for use in a short time frame.


Snoop requires the intermediate node (base station) to examine and operate on the traffic between the mobile host and the other end host on the wired Internet. Hence, 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;

- 使Snoop代理成为客户端和服务器之间的安全关联的一方;

- IPsec tunneling mode, terminated at the Snooping base station.

- IPsec隧道模式,在侦听基站终止。

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, the Snoop agent may duplicate efforts by the link layer as it retransmits the TCP data segments "at the transport layer" across the wireless link. (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.)


5.3.3 W-LAN PEP Motivation
5.3.3 W-LAN政治公众人物激励

Wireless LANs suffer from an error prone wireless channel. Errors can typically be considered bursty and channel conditions may change rapidly from mobility and environmental changes. Packets are dropped from bit errors or during handovers. Periods of link outage can also be experienced. Although the typical MAC performs retransmissions, dropped packets, outages and retransmission latency still can have serious performance implications for IP performance, especially TCP.


PEPs can be used to alleviate problems caused by packet losses, protect TCP from link outages, and to add priority multiplexing. Techniques such as Snoop are integrally implemented in access points, while priority and compression schemes are distributed across the W-LAN.


6. Security Considerations
6. 安全考虑

The use of Performance Enhancing Proxies introduces several issues which impact security. First, (as described in detail in Section 4.1.1,) using PEPs and using IPsec is generally mutually exclusive. Unless the PEP is also both capable and trusted to be the endpoint of an IPsec tunnel (and the use of an IPsec tunnel is deemed good enough security for the applicable threat model), a user or network administrator must choose between improved performance and network layer security. In some cases, transport (or higher) layer security can be used in conjunction with a PEP to mitigate the impact of not having network layer security. But, support by applications for the use of transport (or higher) layer security is far from ubiquitous.


Additionally, the PEP itself needs to be protected from attack. First, even when IPsec tunnels are used with the PEP, the PEP represents a point in the network where traffic is exposed. And, the placement of a PEP in the network makes it an ideal platform from which to launch a denial of service or man in the middle attack. (Also, taking the PEP out of action is a potential denial of service attack itself.) Therefore, the PEP must be protected (e.g., by a firewall) or must protect itself from improper access by an attacker just like any other device which resides in a network.


7. IANA Considerations
7. IANA考虑

This document is an informational overview document and, as such, does not introduce new nor modify existing name or number spaces managed by IANA.


8. Acknowledgements
8. 致谢

This document grew out of the Internet-Draft "TCP Performance Enhancing Proxy Terminology", RFC 2757 "Long Thin Networks", and work done in the IETF TCPSAT working group. The authors are indebted to the active members of the PILC working group. In particular, Joe Touch and Mark Allman gave us invaluable feedback on various aspects of the document and Magdolna Gerendai provided us with essential help on the WAP example.

本文件源于互联网草案“TCP性能增强代理术语”、RFC 2757“长瘦网络”,以及IETF TCPSAT工作组所做的工作。作者感谢PILC工作组的积极成员。特别是,Joe Touch和Mark Allman就文档的各个方面向我们提供了宝贵的反馈,Magdolna Gerendai为我们提供了WAP示例方面的重要帮助。

9. References
9. 工具书类
   [BBKT97]    P. Bhagwat, P. Bhattacharya, A. Krishma, S.K. Tripathi,
               "Using channel state dependent packet scheduling to
               improve TCP throughput over wireless LANs," ACM Wireless
               Networks, March 1997, pp. 91 - 102.  Available at:
   [BBKT97]    P. Bhagwat, P. Bhattacharya, A. Krishma, S.K. Tripathi,
               "Using channel state dependent packet scheduling to
               improve TCP throughput over wireless LANs," ACM Wireless
               Networks, March 1997, pp. 91 - 102.  Available at:

[BPK97] H. Balakrishnan, V.N. Padmanabhan, R.H. Katz, "The Effects of Asymmetry on TCP Performance," Proc. ACM/IEEE Mobicom, Budapest, Hungary, September 1997.

[BPK97]H.Balakrishnan,V.N.Padmanabhan,R.H.Katz,“不对称对TCP性能的影响”,Proc。ACM/IEEE Mobicom,匈牙利布达佩斯,1997年9月。

[BW97] G. Brasche, B. Walke, "Concepts, Services, and Protocols of the New GSM Phase 2+ general Packet Radio Service," IEEE Communications Magazine, Vol. 35, No. 8, August 1997.


[CDMA] Electronic Industry Alliance (EIA)/Telecommunications Industry Association (TIA), IS-95: Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System, 1993.


[CDPD] Wireless Data Forum, CDPD System Specification, Release 1.1, 1995.


[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," Proc. MobiCom'97, Budapest, Hungary, September 1997.

[CTC+97]H.Chang,C.Tait,N.Cohen,M.Shapiro,S.Mastrianni,R.Floyd,B.House,D.Lindquist,“无线环境中的网页浏览:ARTour Web Express中的断开连接和异步操作”,Proc。MobiCom'97,匈牙利布达佩斯,1997年9月。

[FMSBMR98] D.C. Feldmeier, A.J. McAuley, J.M. Smith, D.S. Bakin, W.S. Marcus, T.M. Raleigh, "Protocol Boosters," IEEE Journal on Selected Areas of Communication, Vol. 16, No. 3, April 1998.


[FLASH] Flash Networks Ltd., performance boosting products technology vendor based in Holmdel, New Jersey. Website at

[FLASH]FLASH Networks Ltd.,性能提升产品技术供应商,总部位于新泽西州霍姆德尔。网址:

[FOURELLE] Fourelle Systems, performance boosting products technology vendor based in Santa Clara, California. Website at

[FOURELLE]FOURELLE Systems,性能提升产品技术供应商,总部位于加利福尼亚州圣克拉拉。网址:

[GPRS] ETSI, "General Packet Radio Service (GPRS): Service Description, Stage 2," GSM03.60, v.6.1.1, August 1998.


[GSM] M. Rahnema, "Overview of the GSM system and protocol architecture," IEEE Communications Magazine, Vol. 31, No. 4, pp. 92-100, April 1993.


[HNS] Hughes Network Systems, Inc., VSAT technology vendor based in Germantown, Maryland. Website at


[I-TCP] A. Bakre, B.R. Badrinath, "I-TCP: Indirect TCP for Mobile Hosts," Proc. 15th International Conference on Distributed Computing Systems (ICDCS), May 1995.


[KRA94] M. Kojo, K. Raatikainen, T. Alanko, "Connecting Mobile Workstations to the Internet over a Digital Cellular Telephone Network," Proc. Workshop on Mobile and Wireless Information Systems (MOBIDATA), Rutgers University, NJ, November 1994. Revised version published in Mobile Computing, pp. 253-270, Kluwer, 1996.


[KRLKA97] M. Kojo, K. Raatikainen, M. Liljeberg, J. Kiiskinen, T. Alanko, "An Efficient Transport Service for Slow Wireless Telephone Links," IEEE Journal on Selected Areas of Communication, Vol. 15, No. 7, September 1997.


[LAKLR95] M. Liljeberg, T. Alanko, M. Kojo, H. Laamanen, K. Raatikainen, "Optimizing World-Wide Web for Weakly-Connected Mobile Workstations: An Indirect Approach," Proc. of the 2nd Int. Workshop on Services in Distributed and Networked Environments, Whistler, Canada, pp. 132- 139, June 1995.


[LHKR96] M. Liljeberg, H. Helin, M. Kojo, K. Raatikainen, "Mowgli WWW Software: Improved Usability of WWW in Mobile WAN Environments," Proc. IEEE Global Internet 1996 Conference, London, UK, November 1996.

[LHKR96]M.Liljeberg,H.Helin,M.Kojo,K.Raatikainen,“Mowgli WWW软件:在移动WAN环境中改进WWW的可用性”,Proc。IEEE全球互联网1996年会议,伦敦,英国,1996年11月。

[M-TCP] K. Brown, S. Singh, "M-TCP: TCP for Mobile Cellular Networks," ACM Computer Communications Review Volume 27(5), 1997. Available at


[Pax99] V. Paxson, "End-to-End Internet Packet Dynamics," IEEE/ACM Transactions on Networking, Vol. 7, No. 3, 1999, pp. 277-292.




[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.

[RFC0792]Postel,J.,“互联网控制消息协议”,STD 5,RFC 792,1981年9月。

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC0793]Postel,J.,“传输控制协议”,标准7,RFC 793,1981年9月。

[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communications Layers", STD 3, RFC 1122, October 1989.

[RFC1122]Braden,R.,“互联网主机的要求——通信层”,标准3,RFC 1122,1989年10月。

[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.


[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.

[RFC1323]Jacobson,V.,Braden,R.和D.Borman,“高性能TCP扩展”,RFC 1323,1992年5月。

[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.


[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.

[RFC2018]Mathis,M.,Mahdavi,J.,Floyd,S.和A.Romanow,“TCP选择性确认选项”,RFC 2018,1996年10月。

[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", FYI 30, RFC 2151, June 1997.

[RFC2151]Kessler,G.和S.Shepard,“互联网和TCP/IP工具及实用程序入门”,FYI 30,RFC 2151,1997年6月。

[RFC2246] Dierk, T. and E. Allen, "TLS Protocol Version 1," RFC 2246, January 1999.


[RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPcomp)", RFC 2393, December 1998.

[RFC2393]Shacham,A.,Monsour,R.,Pereira,R.和M.Thomas,“IP有效载荷压缩协议(IPcomp)”,RFC 23931998年12月。

[RFC2401] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[RFC2401]Kent,S.和R.Atkinson,“互联网协议的安全架构”,RFC 2401,1998年11月。

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.

[RFC2475]Blake,S.,Black,D.,Carlson,M.,Davies,E.,Wang,Z.和W.Weiss,“差异化服务架构”,RFC 24751998年12月。

[RFC2488] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.

[RFC2488]Allman,M.,Glover,D.和L.Sanchez,“使用标准机制增强卫星信道上的TCP”,BCP 28,RFC 2488,1999年1月。

[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.

[RFC2507]Degermark,M.,Nordgren,B.和S.Pink,“IP头压缩”,RFC 2507,1999年2月。

[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.

[RFC2508]Casner,S.和V.Jacobson,“压缩低速串行链路的IP/UDP/RTP报头”,RFC 2508,1999年2月。

[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.

[RFC2509]Engan,M.,Casner,S.和C.Bormann,“PPP上的IP报头压缩”,RFC 2509,1999年2月。

[RFC2663] Srisuresh, P. and Y. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.

[RFC2663]Srisuresh,P.和Y.Holdrege,“IP网络地址转换器(NAT)术语和注意事项”,RFC 2663,1999年8月。

[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson, T., Heidemann, J., Kruse, H., Ostermann, S., Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.

[RFC2760]奥尔曼,M.,道金斯,S.,格洛弗,D.,格林纳,J.,亨德森,T.,海德曼,J.,克鲁斯,H.,奥斯特曼,S.,斯科特,K.,塞姆克,J.,Touch,J.和D.Tran,“正在进行的与卫星相关的TCP研究”,RFC 27602000年2月。

[RFC3002] Mitzel, D., "Overview of 2000 IAB Wireless Internetworking Workshop", RFC 3002, December 2000.

[RFC3002]Mitzel,D.,“2000年IAB无线互联车间概述”,RFC 30022000年12月。

[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.

[RFC3042]Allman,M.,Balakrishnan,H.和S.Floyd,“使用有限传输增强TCP的丢失恢复”,RFC 3042,2001年1月。

[SHEL00] Z. Shelby, T. Saarinen, P. Mahonen, D. Melpignano, A. Marshall, L. Munoz, "Wireless IPv6 Networks - WINE," IST Mobile Summit, Ireland, October 2000.


[SNOOP] H. Balakrishnan, S. Seshan, E. Amir, R. Katz, "Improving TCP/IP Performance over Wireless Networks," Proc. 1st ACM Conference on Mobile Communications and Networking (Mobicom), Berkeley, California, November 1995.


[SNOOPELN] H. Balakrishnan, R. Katz, "Explicit Loss Notification and Wireless Web Performance," Proc. IEEE Globecom 1998, Internet Mini-Conference, Sydney, Australia, November 1998.

[SNOOPELN]H.Balakrishnan,R.Katz,“显式丢失通知和无线网络性能”,Proc。IEEE Globecom 1998,因特网小型会议,澳大利亚悉尼,1998年11月。

[SPACENET] Spacenet, VSAT technology vendor based in Mclean, Virginia. Website at


[SRC84] J.H. Saltzer, D.P. Reed, D.D. Clark, "End-To-End Arguments in System Design," ACM TOCS, Vol. 2, No. 4, pp. 277-288, November 1984.

[SRC84]J.H.Saltzer,D.P.Reed,D.D.Clark,“系统设计中的端到端参数”,ACM TOCS,第2卷,第4期,第277-288页,1984年11月。

[WAPARCH] Wireless Application Protocol Architecture Specification, April 1998,


[WAPPROXY] Wireless Application Protocol Push Proxy Gateway Service Specification, August 1999,


[WAPWAE] Wireless Application Protocol Wireless Application Environment Overview, March 2000,


[WAPWDP] Wireless Application Protocol Wireless Datagram Protocol Specification, February 2000,


[WAPWSP] Wireless Application Protocol Wireless Session Protocol Specification, May 2000,


[WAPWTLS] Wireless Application Protocol Wireless Transport Layer Security Specification, February 2000,


[WAPWTP] Wireless Application Protocol Wireless Transaction Protocol Specification, February 2000,


[Zhang00] Y. Zhang, B. Singh, "A Multi-Layer IPsec Protocol," Proc. proceedings of 9th USENIX Security Symposium, Denver, Colorado, August 2000. Available at


10. Authors' Addresses
10. 作者地址

Questions about this document may be directed to:


John Border Hughes Network Systems 11717 Exploration Lane Germantown, Maryland 20876


   Phone: +1-301-548-6819
   Fax:   +1-301-548-1196
   Phone: +1-301-548-6819
   Fax:   +1-301-548-1196

Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland

马尔库科乔赫尔辛基大学计算机科学系P.O盒26(TeulLuuukkutu 23)FIF-000 014赫尔辛基芬兰

   Phone: +358-9-1914-4179
   Fax:   +358-9-1914-4441
   Phone: +358-9-1914-4179
   Fax:   +358-9-1914-4441

Jim Griner NASA Glenn Research Center MS: 54-5 21000 Brookpark Orad Cleveland, Ohio 44135-3191

吉姆·格林纳美国宇航局格伦研究中心MS:54-5 21000俄亥俄州布鲁克公园奥拉德克利夫兰44135-3191

   Phone: +1-216-433-5787
   Fax:   +1-216-433-8705
   Phone: +1-216-433-5787
   Fax:   +1-216-433-8705

Gabriel Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan, FRANCE

加布里埃尔黑山太阳微系统实验室,欧洲29号,chemin du Vieux Chene 38240 Meylan,法国

   Phone: +33 476 18 80 45
   Phone: +33 476 18 80 45

Zach Shelby University of Oulu Center for Wireless Communications PO Box 4500 FIN-90014 Finland


   Phone: +358-40-779-6297
   Phone: +358-40-779-6297

Appendix A - 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.)


ACK filtering


Removing acknowledgments to prevent congestion of a low speed link, usually used with paths which include a highly asymmetric link. Sometimes also called ACK reduction. See Section 3.1.4.


ACK spacing


Delayed forwarding of acknowledgments in order to space them appropriately, for example, to help minimize the burstiness of TCP data. See Section 3.1.1.


application layer PEP


A Performance Enhancing Proxy operating above the transport layer. May be aimed at improving application or transport protocol performance (or both). Described in detail in Section 2.1.2.


asymmetric link


A link which has different rates for the forward channel (used for data segments) 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, usually expressed as a percent of the raw bandwidth of the link.




Has several meanings with respect to PEPs, 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 acknowledged. More precisely, data sent for which the sender has not yet received the acknowledgement.


link layer PEP


A Performance Enhancing Proxy operating below the network layer.


local acknowledgement


The generation of acknowledgments by an entity in the path between two end systems in order to allow the sending system to transmit more data without waiting for end-to-end acknowledgments. Described (in the context of TCP) in Section 3.1.2.


performance enhancing proxy


An entity in the network acting on behalf of an end system or user (with or without the knowledge of the end system or user) in order to enhance protocol performance. Section 2 describes various types of performance enhancing proxies. Section 3 describes the mechanisms performance enhancing proxies use to improve performance.


raw bandwidth


The total capacity of an unloaded link available to carry information.




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 acknowledgments 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 Section 5.3.2 and [SNOOP].


split connection


A connection that has been terminated before reaching the intended destination end system in order to initiate another connection towards the end system. This allows the use of different connection characteristics for different parts of the path of the originally intended connection. See Section 2.4.




A Performance Enhancing Proxy operating at the transport layer with TCP. Aimed at improving TCP performance.


TCP splitting


Using one or more split TCP connections to improve TCP performance.


TCP spoofing


Sometimes used as a synonym for TCP PEP. More accurately, TCP spoofing refers to using transparent (to the TCP stacks in the end systems) mechanisms to improve TCP performance. See Section 2.1.1.

有时用作TCP PEP的同义词。更准确地说,TCP欺骗是指使用透明(对终端系统中的TCP堆栈)机制来提高TCP性能。见第2.1.1节。



In the context of a PEP, transparent refers to not requiring changes to be made to the end systems, transport endpoints and/or applications involved in a connection. See Section 2.5 for a more detailed explanation.


transport layer PEP


A Performance Enhancing Proxy operating at the transport layer. Described in detail in Section 2.1.1.




In the context of PEPs, tunneling refers to the process of wrapping a packet for transmission over a particular link between two PEPs. See Section 3.2.




The Wireless Application Protocol specifies an application framework and network protocols intended to work across differing narrow-band wireless network technologies. See Section


Full Copyright Statement


Copyright (C) The Internet Society (2001). 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 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.






Funding for the RFC Editor function is currently provided by the Internet Society.