RFC3135 日本語訳
3135 Performance Enhancing Proxies Intended to Mitigate Link-RelatedDegradations. J. Border, M. Kojo, J. Griner, G. Montenegro, Z.Shelby. June 2001. (Format: TXT=114825 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations
Status of this Memo
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.
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 Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Abstract
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.
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
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
Border, et al. Informational [Page 1] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 1] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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 4.1.1.1 Security Implications . . . . . . . . . . . . . . . . . . 15 4.1.1.2 Security Implication Mitigations . . . . . . . . . . . . . 16 4.1.1.3 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 5.2.2.1 Mowgli System . . . . . . . . . . . . . . . . . . . . . . 26 5.2.2.2 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 4.1.1.1 Security Implications . . . . . . . . . . . . . . . . . . 15 4.1.1.2 Security Implication Mitigations . . . . . . . . . . . . . 16 4.1.1.3 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 5.2.2.1 Mowgli System . . . . . . . . . . . . . . . . . . . . . . 26 5.2.2.2 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
Border, et al. Informational [Page 2] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 2] RFC 3135 PILC - Performance Enhancing Proxies June 2001
1. Introduction
1. Introduction
The Transmission Control Protocol [RFC0793] (TCP) is used as the transport layer protocol by many Internet and intranet applications. However, in certain environments, TCP and other higher layer protocol performance is limited by the link characteristics of the environment.
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].
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.
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 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
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
Border, et al. Informational [Page 3] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 3] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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].
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.
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).
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. Types of Performance Enhancing Proxies
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.
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.
The following sections describe some of the key characteristics which differentiate different types of PEPs.
2.1 Layering
2.1 Layering
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.
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.
Border, et al. Informational [Page 4] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 4] RFC 3135 PILC - Performance Enhancing Proxies June 2001
2.1.1 Transport Layer PEPs
2.1.1 Transport Layer 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.
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.
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.
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.
2.1.2 Application Layer PEPs
2.1.2 Application Layer 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 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.
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
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
Border, et al. Informational [Page 5] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 5] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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].
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 Distribution
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 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.
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 Implementation Symmetry
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.)
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.)
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
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
Border, et al. Informational [Page 6] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 6] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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).
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 Split Connections
A split connection TCP implementation terminates the TCP connection received from an end system and establishes a corresponding TCP connection to the other end system. In a distributed 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.
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.
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.
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.
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
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
Border, et al. Informational [Page 7] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 7] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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.
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.
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 Transparency
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.
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.
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.
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.
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.
Border, et al. Informational [Page 8] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 8] RFC 3135 PILC - Performance Enhancing Proxies June 2001
3. PEP Mechanisms
3. PEP Mechanisms
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.
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 ACK Handling
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.
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.
3.1.1 TCP ACK Spacing
3.1.1 TCP ACK Spacing
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].
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 Local TCP Acknowledgements
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.)
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.
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.
3.1.3 Local TCP Retransmissions
3.1.3 Local TCP Retransmissions
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
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
Border, et al. Informational [Page 9] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 9] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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.
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.
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.)
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 ACK Filtering and Reconstruction
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].
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].
3.2 Tunneling
3.2 Tunneling
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.
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 Compression
Many PEP implementations include support for one or more forms of compression. In some PEP implementations, compression may even be the only mechanism used for performance improvement. Compression reduces the number of bytes which need to be sent across a link. This is useful in general and can be very important for bandwidth
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
Border, et al. Informational [Page 10] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 10] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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.
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].
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.
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].
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].
3.4 Handling Periods of Link Disconnection with TCP
3.4 Handling Periods of Link Disconnection with 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
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
Border, et al. Informational [Page 11] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 11] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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.
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.
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.
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.
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.
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.
3.5 Priority-based Multiplexing
3.5 Priority-based Multiplexing
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.
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.
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
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
Border, et al. Informational [Page 12] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 12] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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.
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.
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.
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.
3.6 Protocol Booster Mechanisms
3.6 Protocol Booster Mechanisms
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.
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.
Border, et al. Informational [Page 13] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 13] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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.
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. Implications of Using PEPs
The following sections describe some of the implications of using Performance Enhancing Proxies.
The following sections describe some of the implications of using Performance Enhancing Proxies.
4.1 The End-to-end Argument
4.1 The End-to-end Argument
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 [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.
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 Security
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.
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.
Border, et al. Informational [Page 14] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 14] RFC 3135 PILC - Performance Enhancing Proxies June 2001
4.1.1.1 Security Implications
4.1.1.1 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.
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).
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).
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.
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.
Border, et al. Informational [Page 15] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 15] RFC 3135 PILC - Performance Enhancing Proxies June 2001
4.1.1.2 Security Implication Mitigations
4.1.1.2 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.
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).
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).
4.1.1.3 Security Research Related to PEPs
4.1.1.3 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).
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 Fate Sharing
Another important aspect of the end-to-end argument is fate sharing. If a failure occurs in the network, the ability of the connection to survive the failure depends upon how much state is being maintained
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
Border, et al. Informational [Page 16] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 16] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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.
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.
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 End-to-end Reliability
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.
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
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
Border, et al. Informational [Page 17] RFC 3135 PILC - Performance Enhancing Proxies June 2001
Border, et al. Informational [Page 17] RFC 3135 PILC - Performance Enhancing Proxies June 2001
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.
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.
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.
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".
いくつかのインターネットアプリケーションが必ず彼らの正常な操業で終わらせる端を操作して、その結果、終わりから終わりへの信頼性のどんな保証も捨てるというわけではありません。 例えば、インターネットメール配送はリレーメールTransferエージェント(すなわち、リレーシンプルメールトランスファプロトコル(SMTP)サーバ)を通してしばしば作動します。 起因するMTA(SMTPサーバー)は、メール・メッセージを受け取るリレーMTAにメール・メッセージを送って、非揮発性記憶装置(例えば、ディスクの上の)でそれを保存して、次に、アプリケーションレベル承認を送ります。 次に、リレーMTAは目的地SMTPサーバにメール・メッセージを提供することへの「完全な責任」を取ります(多分別のリレーMTAを通して)。 それは比較的長い時間(通常およそ5日間)へのメッセージを転送しようとします。 この体系はメール配送の100%の保証を与えませんが、信頼性は「十分良い」と考えられます。
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.
アプリケーションのこの種類PEP応用層は本質的には減少している信頼性なしでアプリケーションデータ(例えば、メール・メッセージ)を承認するかもしれません、レギュラーのプロキシ(例えば、リレーMTA)と同じ手順によると、PEPが作動する限り。 一方、上で示されるように、そのようなPEPを使うユーザ、そして/または、ネットワーク管理者は、それがそうすると関連している信頼性の危険を理解するためにどのように作動するかを理解する必要があります。
Border, et al. Informational [Page 18] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[18ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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.
終わりから終わりへの議論のもう一つの側面は問題が行きあたられるとき終わりから終わりへの故障が病気の特徴であるとサポートする能力です。 接続を調教するネットワーク問題が起こると、接続のエンドポイントはタイムアウトを通して失敗を検出するでしょう。 しかしながら、2つのエンドポイントの間のPEPの存在はエンドポイントの1か両方で失敗の検出を遅らせるかもしれません(かなり時々)。 (もちろん、いくつかのPEPsがセクション3.4で説明されるようにこれらのタイプの失敗を隠すように故意に設計されています。) 失敗した接続の遅れた検出の含意は使用されるアプリケーションによります。 ポシビリティーズは影響からいっぱいにコミュニケーション経路を交替するために転換を遅らせることによってミッションクリティカルなビジネス機能に影響を与えるまで全く(または、まさしくエンドユーザへの小さい方のいらだち)変化しません。
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がTCPの代わりにICMPに基づいているので(すなわち、それはネットワーク層におけるICMP Echoを使用して、Replyコマンドであると実装されます)、ネットワークの構成がPINGトラフィックをPEPの周りに発送するのは、可能です。 したがって、PINGは、TCPトラフィックのために実際に存在しないとき、終わりから端への経路が2人のホストの間に存在するのを示すことができました。 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.
通常、PEP実装を配布するのは、ホストと終わりのホストからのトラフィックがPEPsが住んでいる中間的ノードを通して発送されるのを必要とします。 いくつかのネットワークと共に、これを達成できませんか、またはそれは、中間的ノードが見つけられて、目標から遠くのいくつかのホップが多くの場合、順番に非実用的な縁をリンクして、非最適ルーティングをもたらすかもしれないということであることを必要とするかもしれません。
Border, et al. Informational [Page 19] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[19ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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.
この制限がすべてのPEP実装に適用されないことに注意してください。 例えば、単にACKにスペースをしているPEPは、交通の流れ(ACKsが流れている方向)の一方向を見る必要があるだけです。 データの実際の流れを見ないで、ACKスペースができます。
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.
PEP実装がモバイルホストに役立つのに使用される環境で、PEPが情報が移管の間、新しいPEPノードに移される必要があるかもしれない状態を関係づけたので、追加問題に行きあたるかもしれません。
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.
モバイルホストが移行するとき、それは身柄の引き渡しを受けることがあります。 給仕PEPのための中間的ノードとホームが引き渡しのため変化するなら、接続の継続運転を確実にするために、継続的作業に、PEPが維持して、必要であるというどんな州の情報も新しい中間的ノードに移さなければなりません。 これは、時間外労働とオーバーヘッドを必要として、十分速く働くのにおいて可能でないかもしれません、特にホストがワイヤレス・ネットワークのセル限界を頻繁に譲るなら。 モバイルホストが別のIPネットワークに移行するなら、モバイルホストとモバイルホストからのルーティングは、新しいPEPノードを横断するために変えられる必要があるかもしれません。
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.
今日、PEPsを使用することに関する移動性含意はW-WANネットワークよりW-LANネットワークに重要です。 現在、W-WAN基地局はワイヤーラインインターネットへの接続拠点をモバイルホストに通常提供しません。 (W-WAN基地局には、IPスタックがしさえしないかもしれません。) 代わりに、モバイルホストが移行している間、ワイヤーラインインターネットへの接続拠点は変わりがなく、W-WANネットワークが移動性の世話をします。 ホストが現在移行するとき、したがって、PEP州の引き渡しはほとんどのW-WANネットワークで必要ではありません。 しかしながら、一般に、これは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
PEPがIP層を超えてパケット情報を通常処理するので、PEPはルータより1パケットあたりの処理能力を必要とします。 したがって、PEPsはそれらがサポートすることができる総スループットに関するルータの後ろでいつも(少なくとも)の1ステップになるでしょう。 (また、IP層を超えた処理はハードウェアで実装するのも、より難しいです。) 一般に、さらに、PEP実装が接続状態単位で必要とする大部分以来、PEPメモリ要件はかなり高いです。
Border, et al. Informational [Page 20] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[20ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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.
ルータより。 したがって、PEP実装はそれがサポートすることができるポートの数に限界を持っているかもしれませんが、ルータには、どんなそのような制限もありません。
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.
増強された処理能力とメモリ要件はPEPsの使用に関してスケーラビリティ問題を紹介します。 ただトラフィックの経路にPEPを挿入することを超えて高速リンクか多くの接続をサポートするリンクにおけるPEPのプレースメントはネットワーク形態変化を必要とするかもしれません。 例えば、PEPがリンクの上に半分のトラフィックを扱うことができるだけであるなら、複数のPEPsが、平行で使用される必要があるかもしれません、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.
このドキュメントはパフォーマンスEnhancing Proxiesを使用することに関していくつかの重要な含意について説明します。 しかしながら、本書では提供された含意のリストは必ず徹底的であるというわけではありません。 PEPsを使用すると関連する他の潜在的含意に関するいくつかの例がService(QoS)透明のQualityに関してマルチホーミング環境におけるPEPsの使用とPEPsの使用を含んでいます。 例えば、セクション3.5で説明される優先権ベースのマルチプレクシングメカニズムとの潜在的相互作用と差別化されたサービス[RFC2475]の使用があるかもしれません。 したがって、PEPを配布したがっているユーザとネットワーク管理者は本書では説明された含意を見るだけではなく、PEPがそれらのアプリケーションとネットワークインフラに持っている総合的な影響力(積極的で否定的な)も見るべきです、初めは、そして、新しいアプリケーションが加えられて、ネットワークインフラにおける変化が必要である未来の両方。
5. PEP Environment Examples
5. 気力環境の例
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.
以下のセクションはPEPが現在性能を向上させるのに使用される環境に関する例について説明します。 より早くドキュメントで説明された様々なPEPタイプとPEPメカニズムの使用を例証して、彼らの開発と使用に関する動機を例証するのを助けるために例を提供します。
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
今日、VSATネットワークは静止衛星で実装されます。 VSATデータ網は、スタートポロジーを使用することで通常実装されます。 大きいハブ地上局はネットワークのリモートサイトで使用されるVSATsのスターのセンターに位置しています。 「外-ルート」を通してハブからリモートサイトにデータを送ります。 1つ以上の「不-ルート」を通してリモートサイトからハブにデータを送ります。 VSATsは非常に非対称のリンク、「外-ルート」で環境を通常表します。
Border, et al. Informational [Page 21] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[21ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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も一度に単一の「不-ルート」に近づく手段を持っているだけです、リンクを非対称にして。)
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.
一般に、企業(例えば、会社)のために地理的に分散しているサイトで私設のネットワークが(すなわち、イントラネット)であると実装するのにおいてVSATネットワークは使用されています。 かつてなら、インターネット(すなわち、最後のホップとしての)の縁以外に、インターネットが接続性であると実装するのにおいてVSATネットワークはめったに使用されていません。 通常、VSATネットワークのためのインターネットとの接続は、VSATネットワークハブサイトで適切なファイアウォールと(必要であるときに)NAT[RFC2663]デバイスを使用することで実装されます。
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]:
TCP性能に関して、VSATネットワークは[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.
静止衛星ネットワークの送付者から受信機までの伝播遅延は240〜280ミリセカンドに及ぶことができます、衛星足跡には送受信サイトがあるところによって。 これはまさしく伝播遅延のため少なくとも480ミリセカンドと同じくらい周遊旅行時間になります。 メソッドが数秒の注文ときに時々総遅れを増強できる共有されたチャンネルアクセスによる待ち行列遅れと遅れ。
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.
VSATネットワークはいくつかの1秒あたりのキロビットから複数の1秒あたりのメガビットまで変化する容量をサポートすることができます。 比較的長い周遊旅行時間に結合されると、TCPは、衛星中継を完全に利用するために「飛行」で多くのパケットを保つ必要があります。
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.
上で示されるように、通常、VSATネットワークの「外-ルート」は「不-ルート」よりかなり大きいです。 ネットワークの中で複数の「不-ルート」を使用できますが、与えられたVSATは一度に1つの「不-ルート」しかアクセスできません。 したがって、VSATのための入って来るのであっ(「外-ルート」)て外向的な(「不-ルート」)容量はしばしば非常に非対称です。 「外-ルート」容量が近年増加したのに従って、400対1以上の比率はますます一般的になっています。 1460バイトと遅れた承認[RFC1122]のTCPの最大のセグメントサイズが使用中の状態で、ACKsのためのIPパケットバイトへのデータのためのIPパケットバイトの比率は75対1にすぎません。
Border, et al. Informational [Page 22] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[22ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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].)
したがって、ACKsを運ぶための「不-ルート」容量は重要な影響をTCP性能に与えることができます。 (TCP性能の非対称のリンク影響の問題はさらに詳細に[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.
[RFC2488]に記載された他の衛星の特性に関して、VSATネットワークは間欠接続性か可変周遊旅行時間が通常欠点ではありません。 また、一般に、VSATネットワークはかなりの量のエラー修正コード化を含んでいます。 これで、ビット誤り率はからりと晴れた空状態の間、非常に低くなります、典型的な地球のネットワークのビット誤り率にアプローチして。 そのような状態はまれです、そして、(総合的なネットワーク有用性観点から見られると)天気擾乱のときに、ビット誤り率はかなり増加するかもしれませんが、一般に、VSATネットワークは、これらの状態の間、性能を最適化するのではなく、これらの状態の間、働くために設計されます。
5.1.2 VSAT Network PEP Implementations
5.1.2 VSATネットワーク気力実装
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.
パフォーマンスEnhancing Proxiesは、VSATのために一般に、ネットワークがスループット(FTPやHTTPウェブページretrievalsなどのアプリケーションのための)を改良するところの焦点であると実装しました。 また、より少ない度合いと、PEP実装は、小さいトランザクションのための対話的な応答時間を改良するために取り組みます。
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:
VSATネットワークと共に使用される優位なPEP実装がありません。 それぞれのVSATネットワークベンダは、それら自身のPEPの機能性のバージョンを実装する傾向があります、それらのVSAT製品の他の特徴について統合しています。 [HNS]と[SPACENET]は統合PEP能力でVSAT製品について説明します。 また、VSATネットワークと共に使用されるように設計された第三者PEP実装があります。 これらの製品はハブとリモートサイトをVSATネットワークへの外部のノードで動きます。 NettGain[FLASH]とVenturi[FOURELLE]はそのような製品に関する例です。 一般に、VSATネットワークPEP実装は以下の特性を共有します:
- 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:
VSATネットワークPEP実装の間の主要な識別因子は以下の通りです。
- The maximum throughput they attempt to support (mainly a function of the amount of buffer space they use);
- 彼らがサポートするのを試みる最大のスループット(主に彼らが使用するバッファ領域の量の関数)。
Border, et al. Informational [Page 23] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[23ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
- 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;
- 衛星中継の上で使用されるプロトコル。 他のものがUDPの上で固有のプロトコル実行を使用している間、いくつかの実装がTCPの変更されたバージョンを使用します。
- 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実装が特定の圧縮のリンクに焦点を合わせている間、第三者VSATネットワークPEP実装はアプリケーション(例えば、HTTP)の特定の圧縮アルゴリズムに焦点を合わせます。
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.
いくつかの場合、PEP実装は実際に透過的に終わりのシステムノード自体に統合しています、「スタックでの隆起」アプローチを使用して。一般に、VSAT製品と統合されたPEP実装はエンドシステムに透明です。VSATネットワークと共に使用される第三者PEP実装は、TCPパケットをリモートサイトプロキシに発送するためにリモートサイトエンドシステムで通常構成変更を必要としますが、ハブサイトエンドシステムに釣り銭がいません。 PEP実装が性能を上げるのに使用されているとき、すなわち、ユーザはケース、ユーザにとって、PEPの使用が非透過であることを全部で、意識しています。
5.1.3 VSAT Network PEP Motivation
5.1.3 VSATネットワーク気力動機
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.
彼らの展開の初期段階以来ネットワークが衛星の各側面におけるプロトコル(例えば、SDLCとX.25)の地方の終了の使用をサポートしているVSATは、プロトコルを使用することでアプリケーションから衛星中継を隠すためにリンクします。 LAN能力がしたがって、VSATネットワークに追加されたときVSAT顧客、予想されて、事実上、同様のテクニックのIPの性能を向上させる使用がトラフィック(特定のTCPが取引するコネ)を基礎づけたのを要求します。
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.
セクション5.1にみられるように、VSATネットワークは、VSATネットワークのハブサイトでインターネットの接続性が制限されているイントラネットを実装して、しっかりと制御するのに主として使用されます。 したがって、VSAT顧客はPEPsを使用する他の技術であるのとインターネットのそばで同じくらい影響を受ける(彼らが影響を受けないと少なくとも知覚する)関連する含意ではありません。 代わりに、VSAT顧客には、より重要なことはネットワークの最適化です。 そして、一般に、VSAT顧客は、それら自身の設備に変化を実装することによって(可能であるように、TCPは窓のオプションをスケーリングしました)というよりむしろネットワーク自体がネットワークの最適化を完了しているのを好みます。 VSAT顧客は、地元のミッションクリティカルな機能に関連するローカルのコミュニケーションのために彼らのエンドシステム構成を最適化して、VSATネットワークに衛星中継の存在をできるだけ隠させるのを好みます。 また、VSATネットワークベンダは、より古くて、「非現代」のTCPスタックを含んでいるより古い設備の寿命の役に立つのを広げなどなどの彼らの顧客への付加価値が付いた「サービス」を提供するのにPEPの機能性を使用できました。
Border, et al. Informational [Page 24] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[24ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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.
もちろん、イントラネットとインターネットの間の系列がずっと色あせるのに従って、PEPsを使用する含意はVSATネットワークには、より重要になり始めます。 例えば、VSATトラフィックを妨害できると関連する設備費用が比較的高かったので、12年前に、セキュリティは主要な関心事ではありませんでした。 現在、技術が進んだのに従って、費用はあまりそれほどひどく高くはありません。 したがって、VSATネットワークにおけるPEPの機能性の使用がIPsecの使用を防ぐので顧客がTLSなど、または、独占セキュリティー対策におけるより高い層のセキュリティー対策のVSATネットワーク自体で実装された使用に依存しなければならない、(現在多くのアプリケーションが作成で不可能である、(絶対にしないでください、造) 標準化されたより高い層のセキュリティー対策の使用、) これは、順番にVSATネットワークの費用に影響して、顧客がインターネットの使用をベースの能力にする能力に影響します。
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.
モバイルワイヤレスのWAN(W-WAN)環境で、ワイヤレスのリンクはエンドユーザへの最後のホップリンクとして通常使用されます。 W-WANがGSM[GSM]、GPRS[GPRS]のようなネットワーク[BW97]、CDPD[CDPD]を含んでいる、-95である、[CDMA]、RichoNet、およびPHS。 すべてではなく、これらのネットワークの多くが第一に、移動電話声のサービスを提供しますが、また、データサービスを含むように設計されているか、またはそれらは移動電話ネットワークから発展します。
5.2.1 W-WAN Network Characteristics
5.2.1 W-WANネットワークの特性
W-WAN links typically exhibit some combination of the following link characteristics:
W-WANリンクは以下のリンクの特性の何らかの組み合わせを通常示します:
- low bandwidth (with some links the available bandwidth might be as low as a few hundred bits/sec)
- 低い帯域幅(いくつかのリンクで、利用可能な帯域幅は数100ビット/秒と同じくらい低いかもしれません)
- 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
- 船体の骨組を組み立て終えて結果になる高いBER、パケット損失、または地方のリンクレイヤエラー回復への支払い満期の長い可変遅れ
- 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リンクの上では、ユーザは他のユーザによる同じチャンネルリソースの同時の使用のため順番にユーザのパケット配信に不測の遅延を引き起こすかもしれない彼らのデータパケット配信のための一般的なチャンネルを共有するかもしれません。
Border, et al. Informational [Page 25] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[25ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
- 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)
- リンク結合をセットアップする(re)は長くかかるかもしれません。(何十秒の、または、も同等の数分)
- 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ネットワークは通常端末の移動性の世話をします: ユーザがモバイルホストと共に移行している間、インターネットへの接続拠点は保有されます。
- 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気力実装
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環境のために実装されたパフォーマンスEnhancing Proxiesは対話的な応答時間を改良しますが、同じ時間目的においてスループットを改良するのに集中します、主に本来遅いリンクの上に転送ボリュームをいろいろ減少させることによって。 これを達成するために、通常、増進はほとんどすべてのプロトコル層に適用されます。
5.2.2.1 Mowgli System
5.2.2.1 Mowgliシステム
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.
Mowgliシステム[KRA94]は低い帯域幅W-WANリンクの問題の多い特性によって引き起こされた挑戦を扱う早めのアプローチの1つです。
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.
Mowgliで使用される間接的なアプローチは他の多くの分裂接続アプローチのように単一層に制限されませんが、それはすべてのプロトコル層にかかわります。 基本的なアーキテクチャは分配されたPEPアプローチによる応用層プロキシの全面的な支援と共に分裂TCP(また、UDPはサポートされる)に基づいています。 応用層プロキシ組はクライアントとサーバ(モバイルホストの上のエージェント(地元のプロキシ)とワイヤーラインインターネットとの接続をモバイルホストに提供する中間的ノードの上のプロキシ)の間で加えられるかもしれません。 そのような組は、明白であるか、またはアプリケーションに完全に透明であるかもしれませんが、それがいつもその結果ユーザがそれがPEP実装を通して横断するトラフィックを選択して、他のトラフィックのための終わらせる終わりのIPを選ぶエンドユーザコントロールの下にあります。
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.
変更されていなくレガシーアプリケーションを実行するのを許容して、「再-編集」なしで変更して、モバイルホストの上のソケットレイヤー実装は、オリジナルのTCP/IPソケット意味論を保有している間、地元のエージェントにアプリケーションに接するようにわずかに変更されます。(アプリケーションはPEPを通した横断に構成されます)。 モバイルホストアプリケーション使用のために2つのタイプの応用層エージェント兼プロキシ組を構成できます。
Border, et al. Informational [Page 26] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[26ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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].
どんなアプリケーションと共にもジェネリック組を使用できます、そして、それは圧縮のように単にいくつかの任意のジェネリック増進を分裂輸送サービスに提供します。 どんなアプリケーションのためにもアプリケーション特有の組を小売できますか、または取ることができるアプリケーションのグループは同じ種類の増進ときに力を入れます。 アプリケーション特有のプロキシ組と共に達成された増進の好例はワイヤレスのリンク[LAKLR95][LHKR96]の上に主に転送ボリュームを減少させるのによるウェブブラウジングの応答時間と周遊旅行の数であると知覚されたユーザをかなり改良するMowgli WWWシステムです。
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.
また、Mowgliは、低い帯域幅W-WANリンク[KRLKA97]に調整されるカスタムプロトコルとの最後のホップリンクの上にTCP/IPコアプロトコルを置き換えるためにオプションを提供します。 このプロトコルは、通常のTCPとUDPが提供するとき同様の意味論を同じ輸送サービスに提供しますが、自由に現在のTCP/IPパケット・フォーマットかプロトコル操作で抑制されないでどんな適切なプロトコルメカニズムも適用できる異なったプロトコル実装を使用するように設計されました。 このプロトコルが単一の論理的なリンクだけの上に操作するのに必要であるときに、それはリンク、ネットワーク、およびトランスポート層のプロトコル制御情報とプロトコル操作を部分的に結合するかもしれません。 さらに、プロトコルはそれの上で例えば、様々なリンクサービスの上、または、異なった生のリンクサービスの上、または、PPPの上、または、IPの上、または、リンクサービスとしてそれを使用している単独のTCP接続と「TCPマルチプレクシング」を実装する上でさえ作動できます。 プロトコルが生(ワイヤレスの)のリンクサービスの上で作動するために構成される時以外の他のすべての場合では、IPはPEP実装を通して横断ではなく、トラフィックのための同時の終わりから終わりへのIP配送を許すカスタムプロトコルに共存するかもしれません。
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
その上、カスタムプロトコルは基本的なリンクサービスに依存するあるプロトコル機能をつけたり消したりする異なったオペレーションモードに立候補することであるかもしれません。 例えば、基本的なリンクサービスが確実な資料配送を提供するなら、チェックサムと窓のベースのエラー回復をオフにすることができます、その結果、プロトコルオーバーヘッドを下げます。 非常に簡単な回収機構だけが、予期していなかったリンクの切断からの回復を許すのに必要です。 したがって、プロトコルデザインは、周遊旅行の数をかなり減少させて、非常に効率的なヘッダーコード化(典型的な場合におけるパケットあたり1-3バイトだけ)を使用できました、そして、低バンド幅W-WANリンクによって役に立つ様々な特徴は加えやすかったです。 そのような特徴は、リンクの切断の期間、プロトコル操作を中断させるのを含んでいるか、またはリンクが再びいったん操作上になると、速い始めと共に供給停止をリンクします、その結果リンク容量をインタラクティブに提供するW-WANリンクの上の利用者データの優先権ベースのマルチプレクシング
Border, et al. Informational [Page 27] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[27ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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.
直ちにデータがW-WANリンクに内部のバッファを蓄積するのを防ぐ帯域幅の徹底的なバックグラウンド転送、およびリンク・レベルフロー制御の存在におけるさえアプリケーション。
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.
望まれているなら、ことによるとW-WANリンクにより適当にそれを調整するTCP(そして、UDP)での対応するプロトコル変更で、最後のホップリンクの上に定期的なTCP/IP輸送を使うことができます。
5.2.2.2 Wireless Application Protocol (WAP)
5.2.2.2 ワイヤレス・アプリケーション・プロトコル(ワップ)
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.
Mowgliシステムは、強制的なリンクの上のインターネットに付けられているモバイルホストをサポートするように設計されましたが、ローエンドモバイル機器で特定の挑戦を扱いませんでした。 多くのモバイルワイヤレス機器が、パワーと、メモリと、抑制された処理です、そして、これらのデバイスへの通信リンクには、下側の帯域幅とそれほど安定していない接続があります。 これらの制限が、デザイナーがアプリケーションフレームワークを指定するワイヤレス・アプリケーション・プロトコル(WAP)を開発するように導いて、ネットワーク・プロトコルは、インターネット内容をもたらしながら狭帯域の異なったワイヤレスネットワーク技術の向こう側に働くつもりであり、ローエンドデジタル携帯電話と他のモバイルワイヤレスの端末に対するデータサービスを進めました、ポケットベルやPDAのように。
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.
WAPモデルはWAPクライアント(移動体端末)、WAPプロキシ、および発生源サーバから成ります。それはインターネットでWAPクライアントとサーバの間のWAPプロキシを必要とします。 WAPは層にされて、スケーラブルなアーキテクチャ[WAPARCH]を使用します、端末とプロキシの間で使用されるために以下の5個のプロトコル層を指定して: 応用層(WAE)[WAPWAE]、セッション層(WSP)[WAPWSP]、トランザクション層(WTP)[WAPWTP]、セキュリティは(WTLS)[WAPWTLS]、およびトランスポート層(WDP)[WAPWDP]を層にします。 標準のインターネットプロトコルはプロキシと発生源サーバの間で使用されます。発生源サーバがWAPプロキシの機能性を含んでいるなら、それは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クライアントはコード化されたWAP要求をWAPプロキシに送ります。 WAPプロキシは、必要なプロトコル変換を実行して、WWW(HTTP)要求にWAP要求を翻訳して、インターネットで標準のウェブサーバーにこの要求を提出します。 ウェブサーバーがWAPプロキシに反応した後に、応答は、空気の上でデータのサイズを減少させるために、よりコンパクトなバイナリフォーマットにコード化されます。 WAPクライアント[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
WAPはさまざまな運搬人データグラムサービスの上で作動します。 これらの運搬人サービスの上で交信するとき、WAP(WDP)トランスポート層はWAPクライアントとWAPプロキシの間でいつも使用されます、そして、それは、より高いWAP層へのデータグラムサービスであると扱われたポートを提供します。 運搬人サービスがIPをサポートする、(例えば、GSM-CSD、GSM-GPRS、-136である、CDPD)、UDPはデータグラムプロトコルとして使用されます。 しかしながら、運搬人です。
Border, et al. Informational [Page 28] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[28ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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.
サービスは、IPが(例えば、GSM-SMS、GSM-USSD、GSM Cell Broadcast、CDMS-SMS、TETRA-SDS)であるとサポートしないで、WDPは基幹ネットワークとプロトコル・スタックの間の適合層として必要なデータグラムプロトコルを実装します。
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は1セットのウェルノウンポートをIANAに登録しました。 WAPクライアントとプロキシとのコミュニケーションのアプリケーションで選択されたポートナンバーは、各端のときに使用されるために他の層を定義します。 セキュリティ層(WTLS)はプライバシー、データ保全、および認証を提供します。 機能性はデータグラムサポート、最適化された握手、およびダイナミックな主要なリフレッシュで広げられたTLS1.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].
トランザクション層(WTP)は設立と裂け目が倒す接続なしで基づくメッセージです。 それはトランザクションのクラスの3つのタイプをサポートします: 未確認の要求(単方向)、信頼できる(確認される)要求(単方向)、および信頼できる(確認される)要求回答トランザクション。 データは最初のパケットで運ばれます、そして、3ウェイ握手は、潜在を減少させるために排除されます。 さらに、承認、「再-トランスミッション」、およびフロー制御を提供します。 それは一度に1つ以上の傑出しているトランザクションを許容します。 それは例えば転送の運搬人の依存を扱います。運搬人によると、タイムアウト値とパケットサイズを選択します。 残念ながら、WTPは固定再送信タイマーを使用して、輻輳制御[RFC3002]を含んでいません。(WAPの使用が増加するのに従って、それは、潜在的な問題領域です)。
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、バイナリーが長い生活セッションなどのいくつかの延期があるHTTP1.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
セクション5.2.1にみられるように、W-WANネットワークは高い潜在と比較的頻繁な期間のリンクの切断との非常に低い帯域幅関係を通常提供します、そして、通常、それらは、使用するために高価です。 したがって、TCP接続設定と分解に関連づけられたものなどのように、転送ボリュームと付加的な周遊旅行を抑えなければなりません、そして、遅いW-WANリンクは、インターネット・アクセスを使用可能で経済的にするように余分なトラフィックとグローバルな(配線される)インターネット混雑から効率的に保護されるべきです。 その上、他の同時の帯域幅徹底的な(バックグラウンド)転送があっても、直ちに対話的な通信を伝えなければなりません、そして、接続性がある期間、完全に利用されているようにリンクを保たなければなりません。
Border, et al. Informational [Page 29] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[29ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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.
短い時間枠か多分決して(すべて)のアプリケーションをW-WAN移動性/意識するようにすることができないように、モバイルW-WAN使用のサポートはほとんどのアプリケーションを許容する方法で実装されるべきです、少なくともものが変更されなく彼らの操作を続けるために固定インターネット・ホストの上で作業して。
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.
無線LAN(W-LAN)はW-LANトランシーバーがあるアクセスポイントが単細胞を制御するセルトポロジーで通常組織化されます。 セルは基地局の適用範囲の地域で定義されます。 アクセスポイントは直接有線ネットワークにつなげられます。 それぞれのセルの中のアクセスポイントはホストとセルを位置するホストからパケットを進めるのに責任があります。 しばしば、W-LANトランシーバーをもっているホストモバイルです。 そのようなモバイルホストが1つのセルから別のセルまで移行するとき、有線ネットワークとモバイルホストの間にパケットを送ることへの責任を新しいセルのアクセスポイントに移さなければなりません。 これは移管として知られています。 また、多くのW-LANシステムがオペレーションモードの可能な臨時のネットワークをサポートします。 このモードで、アクセスポイントが必ず必要であるというわけではありませんが、W-LANトランシーバーをもっているホストはトランシーバーのトランスミッション範囲の中の他のホストと共に直接伝達できます。
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.
現在の無線LANは1Mbpsから11Mbpsまでのリンク帯域幅を通常供給します。 54Mbpsまでの、より高い帯域幅の将来的で、広い展開かさらに高く、予想できます。 数ミリセカンドか何十ミリセカンドもの注文には無線LANがある往復の遅れがあります。 W-LANに関する例はIEEE802.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.
無線LANは、誤りビットのために傾向がある誤りと、衝突とリンク供給停止です。 また、さらに、連続したパケット損失はhandoffsの間、起こるかもしれません。 ほとんどのW-LAN MACプロトコルが低レベル「再-トランスミッション」を実行します。 この特徴はほとんどの損失から上側の層を保護します。 しかしながら、避けられない損失、「再-トランスミッション」潜在、およびリンク供給停止はまだ上側の層に影響しています。 W-LANリンクにかかわるW-LANかネットワーク経路の上のTCP性能はこれらの効果に苦しみそうです。
Border, et al. Informational [Page 30] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[30ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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.
TCPがネットワークの混雑になるように誤ってこれらのパケット損失を解釈するとき、TCP送付者は、連敗から回復するために混雑ウィンドウを減少させて、しばしばタイムアウトに強制されます。 結果は終わりから終わりへのしばしば容認できないほど不十分な性能です。
5.3.2 W-LAN PEP Implementations: Snoop
5.3.2 W-LAN気力実装: スヌープ
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.
バークレーのスヌーププロトコル[スヌープ]はTCP意識しているモジュール(スヌープエージェント)が最後のホップルータとしてモバイルホストに機能するW-LAN基地局で配布されるTCP特有のアプローチです。 スヌープはTCP終わりから終わりへの意味論を保有するのを目的とします。 スヌープエージェントは、基地局を通り抜けるあらゆるパケットをどちらの方向にもモニターして、それぞれのTCP接続のために軟性国家を維持します。 TCPデータとACKチャンネルとアップリンク(モバイルホストからの)とダウンリンク(モバイルホストへの)TCPセグメントを異なって作動させるとき、スヌープエージェントは非対称のPEP実装です。
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:
モバイルホストへのデータ転送のために、スヌープエージェントは、それがTCP受信機に送る不承認のTCPデータ・セグメントをキャッシュして、対応するACKsをモニターします。 それは2つのことをします:
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写しACKsを使用することによって、局所的にどんなロストデータセグメントも再送します。
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. 後者でモバイルホストから送付者への途中に、その結果、速く避けるのが再送する写しACKsと輻輳回避を抑圧します。
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.
スヌープエージェントが局所的にパケットを再送するのに従って、不要な状態でACKsが避けていなければならない写しを抑圧するのはTCP送付者に速く再送されます。 スヌープエージェントと基地局BSを通して受信機Rにパケットを送るTCP送付者Sを雇うシステムを考えてください。 SがワイヤレスのリンクでBSによってワイヤレスの受信機R.Assumeに送られて、パケットBの最初のトランスミッションが誤りのため失われているということであるE(そのオーダーにおける)をパケットA、B C、Dに送ると仮定してください。 この場合、RはパケットA、C、D、E、およびB(そのオーダーにおける)を受けます。 パケットCの領収書、D、およびEは写しACKsの引き金となります。 Sが受信されるとき、3はACKsをコピーして、それは断食が再送する引き金(「再-トランスミッション」、および混雑ウィンドウの減少におけるどの結果)であるか。 また、3写しACKsを受けるとき、スヌープエージェントは局所的にBを再送します。 速さはSで再送されます。地方にもかかわらず、ワイヤレスのリンクの上に再送して、スループットを下げながら、起こります。 TCPを下げるのによるこの問題とのスヌープ取引はBSに適切にACKsをコピーします。
Border, et al. Informational [Page 31] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[31ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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.
モバイルホストからのデータ転送のために、スヌープエージェントは、ワイヤレスのリンクの上にそれが進めるデータ・セグメントをモニターすることによって、パケット損失を検出します。 次に、それが局所的に、Negative Acknowledgements(NAK)を使うか、またはパケット損失が、混雑に関連されないで、その結果、送付者が通常の混雑の引き金とならないで再送するのを許容していたことをモバイル送付者に知らせるExplicit Loss Notifications(ELN)は手順を制御します。 これを実装するために、モバイルホストの変化が必要です。
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.
スヌープエージェントがワイヤレスのリンクの上にパケット損失についてTCP送付者に知らせるのにNAKsを使用すると、それらを実装する1つの可能性がTCP[RFC2018]のSelective Acknowledgment(SACK)オプションを使用しています。 これは、モバイルホストでSACK処理を可能にするのを必要とします。 スヌープエージェントはTCP SACKを送ります、モバイルホストからトランスミッション系列の穴を検出するか、またはある期間モバイルホストから新しいパケットをまだ受けていないとき。 このアプローチはSACKsの顧問自然を当てにします: モバイル送付者が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.
ELNメカニズムがパケット損失についてモバイル送付者に知らせるのに使用されるとき、スヌープはELN[SNOOPELN]にTCPヘッダーで'無遠慮な'ビットの1つを使用します。 スヌープエージェントはワイヤレスのリンクの上に失われたセグメントに対応する穴の動向をおさえます。 系列スペースの穴に対応する(写し)ACKがTCP受信機から到着するとき、スヌープエージェントは、ACKのELNビットに損失が混雑に関係なく、次に、TCP送付者にACKを送るのを示すように設定します。 送付者がELN(モバイルホストにおける構成可能な変数、例えば、2)と共に(写し)ACKsのある数を受けるとき、どんな輻輳制御測定も実行しないで、それはなくなったセグメントを再送します。
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.
TCPスタックで正しく実装されないかもしれなくて、バグを暴露するかもしれないチェックを運動させるとき、TCPヘッダーにおける今後の使用のために予約された6ビットの1つを使用するELNメカニズムは危険です。
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
断食がワイヤレスの誤りのため再送されるaの可能性が非取るにたらない場合にだけ、スヌープなどの体系が必要です。 ワイヤレスのリンクがロストデータにリンクレイヤ回復を使用するなら、この体系は特に、有益ではありません。 また、TCPの窓が、例えば混雑による4つのセグメントが損失を有線ネットワークに関係づけたより小さいままである傾向があるなら、スヌープエージェントには局所的に無くなっているパケットを再送する機会があるという確率もわずかです。 これは少なくとも3写しACKsが地方の「再-トランスミッション」の引き金となるのに必要ですが、小さいウィンドウスヌープのためあります。
Border, et al. Informational [Page 32] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[32ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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).
エージェントは、3つの新しいパケットを無くなっているパケットの後に送って、その結果、3必要な写しACKsを引き起こすことができないかもしれません。 TCPの窓が十分大きいときに、逆に、スヌープは顕著な性能改良(標準の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.
小さいTCPの窓に関する問題を軽減するために、スヌープはTCP送付者がそれぞれの写しACKのために新しいデータ・セグメントを伝えるのが許容されて、TCPの速い「再-トランスミッション」には、写しACKsの数が敷居より少ない(3はACKsをコピーします)限り、受信するということであるソリューションを提案します。 新しいセグメントが受信機に達すると、それは、別の写しが送付者にさらに別のデータ・セグメントを順番に伝えさせるACKであると生成するでしょう。 十分な写しACKsがTCPの速い「再-トランスミッション」の引き金となるように蓄積するまで、これは続きます。 この提案は最近規格に送られた「株式会社転送」提案[RFC3042]が追跡するのと同じです。 しかしながら、このソリューションの利益を得ることができるように、TCP送付者の上で配布されるのが必要です、そして、したがって、短い時間枠での使用の、準備ができていません。
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:
スヌープはワイヤードなインターネットでモバイルホストと他の終わりのホストの間のトラフィックで調べて、操作する中間的ノード(基地局)を必要とします。 したがって、IPトラフィックが暗号化されているなら、スヌープは働いていません。 可能なソリューションは以下にかかわります。
- making the Snoop agent a party to the security association between the client and the server;
- スヌープエージェントをクライアントとサーバとのセキュリティ仲間へのパーティーにします。
- IPsec tunneling mode, terminated at the Snooping base station.
- Snooping基地局で終えられた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.)
また、スヌープは、データと対応するACKsの両方が同じ基地局を横断するのを必要とします。 その上、「トランスポート層」でワイヤレスのリンクの反対側にTCPデータ・セグメントを再送するのに従って、スヌープエージェントはリンクレイヤのそばに取り組みをコピーするかもしれません。 (スヌープはデザイナーによってTCP意識しているリンクレイヤと説明されます。 これは正しい解決法です: リンクとネットワーク層は厳しいレイヤリングが示すより互いをはるかに意識している場合があります。)
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.
無線LANは誤りの傾向があるワイヤレスのチャンネルが欠点です。 burstyであると誤りを通常考えることができます、そして、チャンネル状態は移動性と環境の変化から急速に変化するかもしれません。 パケットは噛み付いている誤りか身柄の引き渡しの間、下げられます。 また、リンク供給停止の一区切りを経験できます。 典型的なMACは「再-トランスミッション」を実行しますが、下げられたパケット、供給停止、および「再-トランスミッション」潜在はまだIP性能(特にTCP)のための重大な性能意味を持つことができます。
Border, et al. Informational [Page 33] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[33ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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.
そして、PEPs缶がパケット損失で引き起こされた問題を軽減するのに使用されて、リンク供給停止からTCPを保護してください、優先権マルチプレクシングを加えるために。 スヌープなどのテクニックはアクセスポイントで不可欠に実装されます、優先権と圧縮技術は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.
パフォーマンスEnhancing Proxiesの使用はセキュリティに影響を与えるいくつかの問題を紹介します。 一般に、まず最初に、(セクション4.1.1で詳細に説明されるように)のPEPsを使用して、IPsecを使用するのは互いに排他的です。 PEPがまた、ともにできて、IPsecトンネルの終点であることは信じられない場合(IPsecトンネルの使用は適切な脅威モデルのために十分良いセキュリティであると考えられます)、ユーザかネットワーク管理者が向上した性能とネットワーク層セキュリティを選ばなければなりません。 いくつかの場合、ネットワーク層セキュリティを持たない影響を緩和するのにPEPに関連して輸送(より高い)層のセキュリティを使用できます。 しかし、アプリケーションによる輸送(より高い)層のセキュリティの使用のサポートは全く遍在していません。
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.
さらに、PEP自身は、攻撃から保護される必要があります。 IPsecトンネルがPEPと共に使用さえされるとき、まず最初に、PEPはトラフィックが暴露されるネットワークでポイントを表します。 そして、ネットワークにおける、PEPのプレースメントはそれをサービスの否定に着手する理想的なプラットホームにするか、中央攻撃でやれやれ。 (また、動作からPEPを取り出すのは、潜在的サービス不能攻撃自体です。) したがって、PEPは保護しなければならないか(例えば、ファイアウォールのそばで)、またはまさしくネットワークで住んでいるいかなる他のデバイスのような攻撃者による不適当なアクセスからも我が身をかばわなければなりません。
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.
このドキュメントは、そういうものとして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パフォーマンス」から成長して、RFC2757は「長い間、ネットワークを薄くし」て、IETF TCPSATワーキンググループでしていた状態で働いています。 作者はPILCワーキンググループの活動的なメンバーの世話になっています。 特に、ジョーTouchとマーク・オールマンはドキュメントの種々相の非常に貴重なフィードバックを私たちに与えました、そして、Magdolna GerendaiはWAPの例で不可欠の助けを私たちに提供しました。
Border, et al. Informational [Page 34] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[34ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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: http://www.acm.org/pubs /articles/journals/wireless/1997-3-1/p91-bhagwat/p91- bhagwat.pdf
[BBKT97] P.Bhagwat、P.バッタチャリヤ、A.Krishma、S.K.Tripathi、「チャンネルを使用して、依存するパケットスケジューリングを述べて、無線LANの上でTCPスループットを改良してください」、ACM Wireless Networks、1997年3月、ページ 91 - 102. 利用可能: http://www.acm.org/pubs /articles/journals/wireless/1997-3-1/p91-bhagwat/p91bhagwat.pdf
[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対N.Padmanabhan、R.H.キャッツ、「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.
IEEE Communications Magazine、Vol.35、1997年8月No.日8[BW97]G.Brascheと、B.Walkeと、「New GSM Phase2+一般的なPacket Radio Serviceの概念、Services、およびプロトコル」
[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.
[CDMA]エレクトロニクス産業Alliance(EIA)/電気通信産業連盟(TIA)、-95である、: デュアル・モード広帯域のモバイル駅基地局互換性規格はスペクトルセルラ方式、1993を広げました。
[CDPD] Wireless Data Forum, CDPD System Specification, Release 1.1, 1995.
[CDPD] ワイヤレスのデータフォーラム(CDPDシステム仕様)は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.チャン、C.テート、N.コーエン、M.シャピロ、S.Mastrianni、R.フロイド、B.Housel、D.リンドキスト、「ワイヤレスの環境で以下をブラウズするウェブ」 「ARTourウェブ急行における切断されるのと非同期動作」、Proc。 ブダペスト(ハンガリー)1997年9月のMobiCom97年。
[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.
[FMSBMR98]直流Feldmeier、A.J.マコーリー、J.M.スミス、D.S.Bakin(南西マーカス、T.M.ローリー)は「ブースターについて議定書の中で述べます」、コミュニケーションの選択された領域に関するIEEEジャーナル、Vol.16、No.3、1998年4月。
[FLASH] Flash Networks Ltd., performance boosting products technology vendor based in Holmdel, New Jersey. Website at http://www.flashnetworks.com.
[FLASH]はNetworks Ltd.、Holmdel、ニュージャージーに拠点を置く製品技術ベンダを上げる性能をひらめかせます。 http://www.flashnetworks.com のウェブサイト。
[FOURELLE] Fourelle Systems, performance boosting products technology vendor based in Santa Clara, California. Website at http://www.fourelle.com.
[FOURELLE]Fourelle Systems、サンタクララ(カリフォルニア)に拠点を置く製品技術ベンダを上げる性能。 http://www.fourelle.com のウェブサイト。
[GPRS] ETSI, "General Packet Radio Service (GPRS): Service Description, Stage 2," GSM03.60, v.6.1.1, August 1998.
[GPRS]ETSI、「一般パケットラジオは(GPRS)を修理します」。 「1998年8月に記述、Stage2インチ、GSM03.60、v.6.1.1を調整してください。
Border, et al. Informational [Page 35] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[35ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
[GSM] M. Rahnema, "Overview of the GSM system and protocol architecture," IEEE Communications Magazine, Vol. 31, No. 4, pp. 92-100, April 1993.
[GSM]M.Rahnema、「GSMシステムとプロトコルアーキテクチャの概要」、IEEE Communications Magazine、Vol.31、No.4、ページ 92-100と、1993年4月。
[HNS] Hughes Network Systems, Inc., VSAT technology vendor based in Germantown, Maryland. Website at http://www.hns.com.
[HNS]ヒューズNetwork Systems Inc.、ジャーマンタウン(メリーランド)に拠点を置くVSAT技術ベンダ。 http://www.hns.com のウェブサイト。
[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.
[I-TCP]A.Bakre、B.R.バドリーナート、「I-TCP:」 「モバイルホストのための間接的なTCP」、Proc。 1995年5月の分散コンピューティングシステム(ICDCS)に関する第15国際会議。
[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.
[KRA94] M.Kojo、K.Raatikainen、T.Alanko、「デジタル携帯電話ネットワークの上でモバイルワークステーションをインターネットに接続する」Proc。 1994年11月のモバイルの、そして、ワイヤレスの情報システム(MOBIDATA)、ラトガース大学、ニュージャージーに関するワークショップ。 モバイルComputing、ページで発行された改訂版 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.
[KRLKA97]M.Kojo、K.Raatikainen、M.Liljeberg、J.Kiiskinen、T.Alanko、「遅い無線電話のための効率的な輸送サービスはリンクします」、コミュニケーションの選択された領域に関するIEEEジャーナル、Vol.15、No.7、1997年9月。
[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.
[LAKLR95]M.Liljeberg、T.Alanko、M.Kojo、H.Laamanen、K.Raatikainen、「弱々しく接続されたモバイルワークステーションのためにWWWを最適化します:」 「間接的なアプローチ」、Proc、第2Intについて。 DistributedとNetworked Environments、ウィスラー、カナダ、ページのServicesに関するワークショップ 132- 139と、1995年6月。
[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.ヘリーン、M.Kojo、K.Raatikainen、「Mowgli WWWソフトウェア:」 「変わりやすい青白い環境における、WWWの改良されたユーザビリティ」、Proc。 1996年のIEEEのグローバルなインターネットコンファレンス、ロンドン、イギリス、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 ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz.
K.ブラウン、[M-TCP]S.シン、「M-TCP:」 「モバイルセルラー・ネットワークのためのTCP」、ACMコンピュータコミュニケーションレビューボリューム27(5)、1997。 ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz では、利用可能です。
[Pax99] V. Paxson, "End-to-End Internet Packet Dynamics," IEEE/ACM Transactions on Networking, Vol. 7, No. 3, 1999, pp. 277-292.
[Pax99]V.パクソン、「終わりから終わりへのインターネットパケット力学」、Networking、Vol.7、No.3、1999、ページのIEEE/ACM Transactions 277-292.
[PILCWEB] http://pilc.grc.nasa.gov.
[PILCWEB] http://pilc.grc.nasa.gov 。
Border, et al. Informational [Page 36] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[36ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communications Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
1990年2月の[RFC1144]ジェーコブソン対「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン(V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018] マシスとM.とMahdaviとJ.とフロイドとS.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、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] ケスラーとG.とS.シェパード、「インターネット、TCP/IPツール、およびユーティリティに関する入門書」、FYI30、RFC2151、1997年6月。
[RFC2246] Dierk, T. and E. Allen, "TLS Protocol Version 1," RFC 2246, January 1999.
[RFC2246] DierkとT.とE.アレン、「TLSプロトコルバージョン1」、RFC2246、1999年1月。
[RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPcomp)", RFC 2393, December 1998.
[RFC2393]ShachamとA.とMonsourとR.とペレイラとR.とM.トーマス、「IP有効搭載量圧縮プロトコル(IPcomp)」、RFC2393 1998年12月。
[RFC2401] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
1998年11月の[RFC2401]ケント、S.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」RFC2401。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、1998年12月。
[RFC2488] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[RFC2488]のオールマン、M.、手袋製造業者、D.、およびL.サンチェス、「衛星の上の高めるTCPは標準のメカニズムを使用することで精神を集中します」、BCP28、RFC2488、1999年1月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] デーゲルマルクとM.とNordgrenとB.とS.ピンク、「IPヘッダー圧縮」、RFC2507、1999年2月。
Border, et al. Informational [Page 37] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[37ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508]Casner、S.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[RFC2509] EnganとM.とCasnerとS.とC.ボルマン、「pppの上のIPヘッダー圧縮」、RFC2509、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)用語と問題をネットワークでつなぐ」RFC2663、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.、Griner、J.、ヘンダーソン、T.、Heidemann、J.、クルーゼ、H.、オステルマン、S.、スコット、K.、Semke、J.、接触、J.、およびD.チャン、「進行中のTCP研究は衛星に関連しました」、RFC2760、2000年2月。
[RFC3002] Mitzel, D., "Overview of 2000 IAB Wireless Internetworking Workshop", RFC 3002, December 2000.
[RFC3002] Mitzel、D.、「2000のIABのワイヤレスのインターネットワーキングワークショップの概要」、RFC3002、2000年12月。
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042] オールマンとM.とBalakrishnanとH.とS.フロイド、「株式会社を使用することでTCPの損失回復を機能アップして、伝わってください」、RFC3042、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.
[SHEL00] Z.シエルビイ、T.サーリネン、P.Mahonen、D.Melpignano、A.マーシャル、L.ムニョス、「ワイヤレスのIPv6ネットワーク--ワインでもてなしてください」、ISTモバイルであるというサミット、アイルランド(2000年10月)。
[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.
[スヌープ]H.Balakrishnan、S.Seshan、E.アミール、R.キャッツ、「ワイヤレス・ネットワークの上のTCP/IP性能を向上させます」、Proc。 移動通信と1995年11月に(Mobicom)、バークレー(カリフォルニア)をネットワークでつなぐときの最初のACMコンファレンス。
[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.キャッツと、「明白な損失通知とワイヤレスウェブパフォーマンス」、Proc。 ミニコンファレンスのインターネットシドニー(オーストラリア)1998年11月のIEEE Globecom1998。
[SPACENET] Spacenet, VSAT technology vendor based in Mclean, Virginia. Website at http://www.spacenet.com.
[SPACENET]Spacenet、マックリーン(ヴァージニア)に拠点を置くVSAT技術ベンダ。 http://www.spacenet.com のウェブサイト。
[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.リード、D.D.クラーク、「システム設計における終わりから終わりへの議論」、ACM TOCS、Vol.2、No.4、ページ 277-288と、1984年11月。
[WAPARCH] Wireless Application Protocol Architecture Specification, April 1998, http://www.wapforum.org.
[WAPARCH]ワイヤレス・アプリケーション・プロトコルアーキテクチャ仕様、1998年4月、 http://www.wapforum.org 。
Border, et al. Informational [Page 38] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[38ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
[WAPPROXY] Wireless Application Protocol Push Proxy Gateway Service Specification, August 1999, http://www.wapforum.org.
[WAPPROXY]ワイヤレス・アプリケーション・プロトコルプッシュプロキシゲートウェイサービス仕様、1999年8月、 http://www.wapforum.org 。
[WAPWAE] Wireless Application Protocol Wireless Application Environment Overview, March 2000, http://www.wapforum.org.
[WAPWAE]ワイヤレス・アプリケーション・プロトコルワイヤレスアプリケーション環境概要、2000年3月、 http://www.wapforum.org 。
[WAPWDP] Wireless Application Protocol Wireless Datagram Protocol Specification, February 2000, http://www.wapforum.org.
[WAPWDP]ワイヤレス・アプリケーション・プロトコルワイヤレスデータグラムプロトコル仕様、2000年2月、 http://www.wapforum.org 。
[WAPWSP] Wireless Application Protocol Wireless Session Protocol Specification, May 2000, http://www.wapforum.org.
[WAPWSP]ワイヤレス・アプリケーション・プロトコルワイヤレスセッションプロトコル仕様、2000年5月、 http://www.wapforum.org 。
[WAPWTLS] Wireless Application Protocol Wireless Transport Layer Security Specification, February 2000, http://www.wapforum.org.
[WAPWTLS]ワイヤレス・アプリケーション・プロトコルワイヤレストランスポート層セキュリティ仕様、2000年2月、 http://www.wapforum.org 。
[WAPWTP] Wireless Application Protocol Wireless Transaction Protocol Specification, February 2000, http://www.wapforum.org.
[WAPWTP]ワイヤレス・アプリケーション・プロトコルワイヤレストランザクションプロトコル仕様、2000年2月、 http://www.wapforum.org 。
[Zhang00] Y. Zhang, B. Singh, "A Multi-Layer IPsec Protocol," Proc. proceedings of 9th USENIX Security Symposium, Denver, Colorado, August 2000. Available at http://www.wins.hrl.com/people/ygz/papers/usenix00.html.
[Zhang00] Y.チャン、B.シン、「マルチ層のIPsecプロトコル」Proc USENIX Security Symposium、デンバー(コロラド)2000年8月9日の議事。 http://www.wins.hrl.com/people/ygz/papers/usenix00.html では、利用可能です。
10. Authors' Addresses
10. 作者のアドレス
Questions about this document may be directed to:
このドキュメントに関する質問による以下のことよう指示されるかもしれません。
John Border Hughes Network Systems 11717 Exploration Lane Germantown, Maryland 20876
Laneジャーマンタウン、ジョン境界ヒューズネットワーク・システム11717Explorationメリーランド 20876
Phone: +1-301-548-6819 Fax: +1-301-548-1196 EMail: border@hns.com
以下に電話をしてください。 +1-301-548-6819 Fax: +1-301-548-1196 メールしてください: border@hns.com
Border, et al. Informational [Page 39] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[39ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
ヘルシンキ私書箱26(Teollisuuskatu23)フィン-00014ヘルシンキフィンランドのマルックKojoコンピュータサイエンス学部大学
Phone: +358-9-1914-4179 Fax: +358-9-1914-4441 EMail: kojo@cs.helsinki.fi
以下に電話をしてください。 +358-9-1914-4179 Fax: +358-9-1914-4441 メールしてください: kojo@cs.helsinki.fi
Jim Griner NASA Glenn Research Center MS: 54-5 21000 Brookpark Orad Cleveland, Ohio 44135-3191
ジムGriner NASAグレンリサーチセンタMS: 54-5 21000 Brookpark Oradクリーブランド、オハイオ44135-3191
Phone: +1-216-433-5787 Fax: +1-216-433-8705 EMail: jgriner@grc.nasa.gov
以下に電話をしてください。 +1-216-433-5787 Fax: +1-216-433-8705 メールしてください: jgriner@grc.nasa.gov
Gabriel Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan, FRANCE
ガブリエルモンテネグロサン・マイクロシステムズ研究所、ヨーロッパ29、chemin du Vieux Chene38240メラン、フランス
Phone: +33 476 18 80 45 EMail: gab@sun.com
以下に電話をしてください。 +33 476 18 80 45はメールされます: gab@sun.com
Zach Shelby University of Oulu Center for Wireless Communications PO Box 4500 FIN-90014 Finland
無線通信私書箱4500フィン-90014フィンランドへのオウルのセンターのザックシエルビイ大学
Phone: +358-40-779-6297 EMail: zach.shelby@ee.oulu.fi
以下に電話をしてください。 +358-40-779-6297 メールしてください: zach.shelby@ee.oulu.fi
Border, et al. Informational [Page 40] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[40ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
Appendix A - PEP Terminology Summary
付録A--気力用語概要
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.)
この付録はパフォーマンスEnhancing Proxiesの議論の間に頻繁に使用される用語の概要を提供します。 (いくつかの場合、これらの用語には、それらの非PEPの関連する用法からの異なった意味があります。)
ACK filtering
ACKフィルタリング
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減少と呼ばれます。 セクション3.1.4を見てください。
ACK spacing
ACKスペース
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.
適切にそれらを区切って、TCPデータのburstinessを最小にするのを例えば助ける承認の遅れた推進。 セクション3.1.1を見てください。
application layer PEP
応用層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.
トランスポート層を超えて作動するパフォーマンスEnhancing Proxy。 アプリケーションかトランスポート・プロトコル性能(ともに)を向上させるのは目的とされるかもしれません。 セクション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).
順方向通信路(データ・セグメントのために、使用される)と戻っている(または、リターン)チャンネル(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.
実際の情報量は通常、リンクの生の帯域幅のパーセントとして言い表された与えられた時代にリンクを引き渡しました。
gateway
ゲートウェイ
Has several meanings with respect to PEPs, depending on context:
文脈によって、PEPsに関していくつかの意味を持っています:
- An access point to a particular link;
- 特定のリンクへのアクセスポイント。
Border, et al. Informational [Page 41] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[41ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
- 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
リンクレイヤPEP
A Performance Enhancing Proxy operating below the network layer.
ネットワーク層の下で作動するパフォーマンスEnhancing Proxy。
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.
2の間の経路の実体による承認の世代は、送付システムが終わりから終わりへの承認を待たないで、より多くのデータを送るのを許容するためにシステムを終わらせます。 セクション3.1.2で説明されています(TCPの文脈の)。
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.
プロトコル性能を高めるためにエンドシステムかユーザ(エンドシステムかユーザに関する知識のあるなしにかかわらず)を代表して行動するネットワークにおける実体。 セクション2はプロキシを高める様々なタイプに関する実績について説明します。 セクション3は性能を向上させるためにプロキシ使用を機能アップするメカニズム性能について説明します。
raw bandwidth
生の帯域幅
The total capacity of an unloaded link available to carry information.
情報を運ぶために利用可能な降ろされたリンクの総容積。
Snoop
スヌープ
A TCP-aware link layer developed for wireless packet radio and cellular networks. It works by caching segments at a wireless base station. If the base station sees duplicate 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].
TCP意識しているリンクレイヤはワイヤレスのパケットラジオとセルラー・ネットワークのために発生しました。 それは、ワイヤレスの基地局でセグメントをキャッシュすることによって、働いています。 基地局がそれがキャッシュしたセグメントのための写し承認を見るなら、それはワイヤレスの受信機が新しいデータを承認し始めるまで送付者に送って戻される写し承認ストリームを抑圧している間、なくなったセグメントを再送します。 セクションで詳細に5.3.2と[スヌープ]に説明されます。
Border, et al. Informational [Page 42] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[42ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
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.
エンドシステムに向かって別の接続を開始するために意図している目的地エンドシステムに達する前に終えられた接続。 これは異なった接続の特性の元々意図した接続の経路の異なった地域の使用を許します。 セクション2.4を見てください。
TCP PEP
TCP気力
A Performance Enhancing Proxy operating at the transport layer with TCP. Aimed at improving TCP performance.
TCPと共にトランスポート層で作動するパフォーマンスEnhancing Proxy。 TCP性能を向上させるのは目的とされます。
TCP splitting
TCPの分かれること
Using one or more split TCP connections to improve TCP performance.
より多くの使用1は、TCP性能を向上させるためにTCP接続を分けました。
TCP spoofing
TCPスプーフィング
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を見てください。
transparent
透明
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.
PEPの文脈で透明である、エンドシステム(終点、そして/または、アプリケーションが接続にかかわった輸送)に作られているために釣り銭がいないのを示します。 より詳細な説明に関してセクション2.5を見てください。
transport layer PEP
トランスポート層PEP
A Performance Enhancing Proxy operating at the transport layer. Described in detail in Section 2.1.1.
トランスポート層で作動するパフォーマンスEnhancing Proxy。 セクション2.1.1で詳細に説明されます。
tunneling
トンネリング
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.
PEPsの文脈では、トンネリングは2PEPsの間の特定のリンクの上のトランスミッションのために荷を包装するプロセスについて言及します。 セクション3.2を見てください。
Border, et al. Informational [Page 43] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[43ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
WAP
ワップ
The Wireless Application Protocol specifies an application framework and network protocols intended to work across differing narrow-band wireless network technologies. See Section 5.2.2.2.
ワイヤレス・アプリケーション・プロトコルは狭周波数帯の異なったワイヤレスネットワーク技術の向こう側に働くことを意図するアプリケーションフレームワークとネットワーク・プロトコルを指定します。 .2にセクション5.2.2を見てください。
Border, et al. Informational [Page 44] RFC 3135 PILC - Performance Enhancing Proxies June 2001
境界、他 情報[44ページ]のRFC3135PILC--2001年6月にプロキシを高めるパフォーマンス
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Border, et al. Informational [Page 45]
境界、他 情報[45ページ]
一覧
スポンサーリンク