Network Working Group J. Border
Request for Comments: 3135 Hughes Network Systems
Category: Informational M. Kojo
University of Helsinki
J. Griner
NASA Glenn Research Center
G. Montenegro
Sun Microsystems, Inc.
Z. Shelby
University of Oulu
June 2001
Performance Enhancing Proxies Intended to Mitigate Link-Related
Degradations
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書では、多くの場合、例えば、衛星、ワイヤレスWAN、および無線LAN環境における特定のリンク環境の特性に起因する劣化したTCP性能を改善するために使用パフォーマンス強化プロキシ（のPEP）の調査です。性能向上プロキシの異なるタイプのパフォーマンスを向上させるために使用されるメカニズムと同様に説明されています。重点はTCPで動作プロキシに置かれます。また、その開発と利用のための動機は、特にインターネットの文脈では、それらを使用しての結果の一部と一緒に説明されています。
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
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
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.
伝送制御プロトコル[RFC0793]（TCP）は、多くのインターネットおよびイントラネットアプリケーションでトランスポート層プロトコルとして使用されます。しかし、特定の環境では、TCPおよび他の上位層プロトコル性能は環境のリンク特性によって制限されます。
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].
この文書では、パフォーマンス強化プロキシ（PEP）の性能migitigation技術の調査です。 PEPは、ネイティブパフォーマンスがパス上のリンクまたはサブネットワークの特性に起因受けるネットワーク経路上のインターネット・プロトコルの性能を改善するために使用されます。この文書は情報提供され、それらを使用してのPEPを使用していないかについての勧告を行うことはありません。明確な基準は、低帯域幅でリンクし、エラー率の高いリンク上でTCPのパフォーマンスの緩和のための勧告を追跡し、というように、開発されているか、リンク特性WG（PILC）[PILCWEB]のパフォーマンスへの影響により、開発中です。
Link design choices may have a significant influence on the performance and efficiency of the Internet. However, not all link characteristics, for example, high latency, can be compensated for by choices in the link layer design. And, the cost of compensating for some link characteristics may be prohibitive for some technologies. The techniques surveyed here are applied to existing link technologies. When new link technologies are designed, they should be designed so that these techniques are not required, if at all possible.
リンク・デザインの選択肢は、インターネットのパフォーマンスと効率性に重大な影響を与える可能性があります。しかし、すべてのリンクの特性、例えば、高いレイテンシは、リンク層の設計で選択することによって補償することができます。そして、いくつかのリンクの特性を補償する費用は、いくつかの技術のために法外かもしれません。ここでの調査技術は、既存のリンク技術に適用されます。新しいリンク・テクノロジーを設計する際にこれらの技術が必要とされないように、すべての可能な場合、それらは、設計すべきです。
This document does not advocate the use of PEPs in any general case. On the contrary, we believe that the end-to-end principle in designing Internet protocols should be retained as the prevailing approach and PEPs should be used only in specific environments and circumstances where end-to-end mechanisms providing similar performance enhancements are not available. In any environment where one might consider employing a PEP for improved performance, an end user (or, in some cases, the responsible network administrator) should be aware of the PEP and the choice of employing PEP functionality should be under the control of the end user, especially if employing the PEP would interfere with end-to-end usage of IP layer security mechanisms or otherwise have undesirable implications in some circumstances. This would allow the user to choose end-to-end IP at all times but, of course, without the performance enhancements that employing the PEP may yield.
このドキュメントは、一般的なケースでのPEPの使用を提唱していません。それどころか、私たちは、インターネットプロトコルを設計する上でのエンド・ツー・エンド原理が支配的なアプローチとして保持しなければならないとのPEPのみ同様のパフォーマンスの向上を提供するエンド・ツー・エンドのメカニズムが利用できない特定の環境や状況で使用されるべきであると信じています。 1は、性能向上のためにPEPを採用する検討するかもしれないどのような環境では、エンドユーザー（または、いくつかのケースでは、担当するネットワーク管理者）はPEPを認識すべきであり、PEPの機能を利用するの選択は終わりの制御下でなければなりませんユーザ、PEPを使用するIP層のセキュリティメカニズムのエンド・ツー・エンドの利用を妨害し、またはそうでなければ、いくつかの状況において望ましくない影響を有するであろう場合は特に。これは、PEPを採用すると生じることがパフォーマンスの向上せず、当然のことながら、ユーザーはすべての回で、エンドツーエンドのIPを選択できるようにだろうが。
This survey does not make recommendations, for or against, with respect to using PEPs. Standards track recommendations have been or are being developed within the IETF for individual link characteristics, e.g., links with high error rates, links with low bandwidth, links with asymmetric bandwidth, etc., by the Performance Implications of Link Characteristics WG (PILC) [PILCWEB].
この調査はのPEPを使っに関して、またはに対し、勧告を行うものではありません。規格は、[リンク特性WG（PILC）のパフォーマンスへの影響により、勧告がされているか、個々のリンク特性、例えばのためにIETFの中で開発されている追跡、高いエラー率とリンクし、低帯域幅のリンクなど、非対称の帯域幅とリンクPILCWEB]。
The remainder of this document is organized as follows. Section 2 provides an overview of different kinds of PEP implementations.
このドキュメントの残りは以下の通り構成されています。セクション2は、PEP実装の異なる種類の概要を提供します。
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).
セクション3は、のPEPは、パフォーマンスを向上させるために使用することができるメカニズムのいくつかを論じています。第4章では、特にグローバルなインターネットのコンテキストで、のPEPを使っに関しての影響のいくつかを説明します。衛星微小開口端子（VSAT）環境、モバイル無線WAN（W-WAN）環境や無線LAN（W-LAN）環境：最後に、第5節ではのPEPが使用されるいくつかの例示的な環境について説明します。 PEP用語の概要は、付録（付録A）に含まれています。
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.
性能向上プロキシの多くの種類があります。 PEPに異なる種類のプロトコルのパフォーマンスに影響を与えるさまざまなリンク特性を克服するために、異なる環境で使用されています。性能向上が必ずしもスループットの範囲に限定されるものではありません。その他のパフォーマンス関連の側面には、リンクのユーザビリティのように、また、対処することができます。例えば、[M-TCPは、無線ネットワークにおける断線の期間中生存TCPコネクションを維持する問題に対処します。
The following sections describe some of the key characteristics which differentiate different types of PEPs.
次のセクションでは、のPEPの種類を区別主要な特性のいくつかを説明します。
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.
原理的には、PEP実装は、任意のプロトコル層で機能することができるが、典型的には、1つのまたは2つの層で機能します。この文書では、このようなのPEPが最も一般的に問題の特性を有するリンク上性能を向上させるために使用されるトランスポート層で、またはアプリケーション層で機能PEP実装に焦点を当てます。 PEP実装は、ネットワーク層の下に動作することができる、とすることができ、典型的には何ら変更を必要としない、ネットワークと上位層に透過的に実装されていることは、リンク層であるが、この文書は、リンクレイヤ機構などのPEPに少しだけ注意を払っリンク・レイヤ上のプロトコル操作。また、いくつかのPEP実装はプロトコル情報を利用し、おそらくはつ以上の層でのプロトコル操作を変更することにより、いくつかのプロトコル層を横切って動作することに留意すべきです。このようなPEPのために正確に動作する層（複数可）で定義することは困難です。
Transport layer PEPs operate at the transport level. They may be aware of the type of application being carried by the transport layer but, at most, only use this information to influence their behavior with respect to the transport protocol; they do not modify the application protocol in any way, but let the application protocol operate end-to-end. Most transport layer PEP implementations interact with TCP. Such an implementation is called a TCP Performance Enhancing Proxy (TCP PEP). For example, in an environment where ACKs may bunch together causing undesirable data segment bursts, a TCP PEP may be used to simply modify the ACK spacing in order to improve performance. On the other hand, in an environment with a large bandwidth*delay product, a TCP PEP may be used to alter the behavior of the TCP connection by generating local acknowledgments to TCP data segments in order to improve the connection's throughput.
トランスポート層のPEPは、トランスポート・レベルで動作します。彼らは、トランスポート層によって運ばれているアプリケーションの種類を認識することはなく、せいぜい、唯一のトランスポートプロトコルに対する彼らの行動に影響を与えるために、この情報を使用してもよいです。彼らはどのような方法でアプリケーションプロトコルを変更しますが、アプリケーションプロトコルは、エンドツーエンドで動作させてください。ほとんどのトランスポート層PEPの実装は、TCPと対話します。このような実装は、TCP性能向上プロキシ（TCP PEP）と呼ばれています。例えば、ACKが束一緒に望ましくないデータセグメントバーストを引き起こすことができる環境では、TCP PEPは、単にパフォーマンスを向上させるためにACK間隔を変更するために使用されてもよいです。一方、大きい帯域幅*遅延製品と環境において、TCP PEPは、接続のスループットを向上させるためにTCPデータセグメントにローカル確認応答を生成することによって、TCP接続の動作を変更するために使用することができます。
The term TCP spoofing is sometimes used synonymously for TCP PEP functionality. However, the term TCP spoofing more accurately describes the characteristic of intercepting a TCP connection in the middle and terminating the connection as if the interceptor is the intended destination. While this is a characteristic of many TCP PEP implementations, it is not a characteristic of all TCP PEP implementations.
用語のTCPスプーフィングは時々TCP PEP機能に同義的に使用されます。しかしながら、用語TCPスプーフィングをより正確に中央にTCP接続をインターセプトし、インターセプタが意図された宛先であるかのように接続を終了する特性を記述する。これは、多くのTCP PEP実装の特徴であるが、それはすべてのTCP PEP実装の特性ではありません。
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.
アプリケーション層のPEPは、トランスポート層の上で動作します。今日では、アプリケーション層のプロキシの種類は、インターネットで広く使用されています。このようなプロキシは、Webキャッシュとリレーメール転送エージェント（MTA）を含めると、彼らは通常、一般的に、あらゆる環境に適用可能である方法で、パフォーマンスやサービスの可用性と信頼性を改善しようとするが、それらは必ずしも一定に固有のいずれかの最適化が含まれていません。リンク特性。
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.
アプリケーション層のPEPが、一方、リンクの特定のタイプに使用されている特定のアプリケーションに対するアプリケーションプロトコルならびにトランスポート層の性能を改善するために実施することができます。アプリケーション層PEPは、同じアプリケーションに対応する正規のプロキシと同じ機能を有していてもよい（例えば、MTAまたはWebキャッシングプロキシをリレー）が、アプリケーションプロトコルの動作のリンク固有の最適化と拡張します。
Some application protocols employ extraneous round trips, overly verbose headers and/or inefficient header encoding which may have a significant impact on performance, in particular, with long delay and slow links. This unnecessary overhead can be reduced, in general or for a particular type of link, by using an application layer PEP in an intermediate node. Some examples of application layer PEPs which have been shown to improve performance on slow wireless WAN links are described in [LHKR96] and [CTC+97].
いくつかのアプリケーションプロトコルは、長い遅延と低速リンクと、特に、パフォーマンスに大きな影響を有していてもよい外来往復、過度に冗長ヘッダおよび/または非効率的なヘッダの符号化を用います。この不必要なオーバーヘッドは、中間ノードにアプリケーション層PEPを用いて、一般に、リンクの特定のタイプのために、減少させることができます。いくつかの遅い無線WANリンク上の性能を改善することが示されているアプリケーション層のPEPの実施例に記載されている[LHKR96]及び[CTC + 97]。
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.
PEP実装はすなわち、それは単一PEPコンポーネント単一のノード内に実装され、または分散を含む、統合されてもよい、すなわち、それは、典型的には、複数のノードに実装二つ以上のPEP成分を含みます。統合されたPEP実装は、性能向上が適用される単一の点を表します。例えば、単一PEPコンポーネントは、有線および無線リンクが交わる点でのインピーダンス整合を提供するために実装されるかもしれません。
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.
分散PEP実装は、一般的に性能向上が望まれる特定のリンクを囲むために使用されます。例えば、衛星接続のためのPEPの実装では、衛星リンクの両端に位置する2つのPEPとの間に分配されてもよいです。
A PEP implementation may be symmetric or asymmetric. Symmetric PEPs use identical behavior in both directions, i.e., the actions taken by the PEP occur independent from which interface a packet is received. Asymmetric PEPs operate differently in each direction. The direction can be defined in terms of the link (e.g., from a central site to a remote site) or in terms of protocol traffic (e.g., the direction of TCP data flow, often called the TCP data channel, or the direction of TCP ACK flow, often called the TCP ACK channel). An asymmetric PEP implementation is generally used at a point where the characteristics of the links on each side of the PEP differ or with asymmetric protocol traffic. For example, an asymmetric PEP might be placed at the intersection of wired and wireless networks or an asymmetric application layer PEP might be used for the request-reply type of HTTP traffic. A PEP implementation may also be both symmetric and asymmetric at the same time with regard to different mechanisms it employs. (PEP mechanisms are described in Section 3.)
PEP実装は、対称または非対称であってもよいです。対称のPEPが両方向に同じ挙動を使用し、すなわち、PEPによって取られるアクションは、パケットが受信されるインターフェイス、そこから独立して起こります。非対称のPEPは、各方向に異なる動作します。方向は（例えば、TCPデータフローの方向、多くの場合、TCPデータチャネルと呼ばれる、またはTCPの方向（中央サイトからリモートサイトに、例えば）またはプロトコルトラフィックの面で、リンクの観点から定義することができますACKの流れは、多くの場合）TCP ACKチャネルと呼ばれます。非対称PEP実装は、一般的にPEPの各側のリンクの特性が異なる時点で又は非対称プロトコルトラフィックに使用されます。例えば、非対称PEPは、有線および無線ネットワークの交点に配置されるかもしれない、または非対称なアプリケーション層PEPは、HTTPトラフィックの要求 - 応答型のために使用されるかもしれません。 PEP実装は、それが使用する異なるメカニズムに関して同時に対称および非対称の両方であってもよいです。 （PEP機構は、セクション3に記載されています）
Whether a PEP implementation is symmetric or asymmetric is independent of whether the PEP implementation is integrated or distributed. In other words, a distributed PEP implementation might operate symmetrically at each end of a link (i.e., the two PEPs function identically). On the other hand, a distributed PEP implementation might operate asymmetrically, with a different PEP implementation at each end of the link. Again, this usually is used with asymmetric links. For example, for a link with an asymmetric amount of bandwidth available in each direction, the PEP on the end of the link forwarding traffic in the direction with a large amount of bandwidth might focus on locally acknowledging TCP traffic in order to use the available bandwidth. At the same time, the PEP on the end of the link forwarding traffic in the direction with very little bandwidth might focus on reducing the amount of TCP acknowledgement traffic being forwarded across the link (to keep the link from congesting).
PEP実装が対称または非対称であるかどうかは、PEP実装が統合または分散されているかどうかとは無関係です。換言すれば、分散PEP実装は（すなわち2つのPEPは同じ機能）リンクの両端に対称的に動作するかもしれません。一方、分散PEP実装は、リンクの各端に異なるPEP実装で、非対称に動作するかもしれません。繰り返しますが、これは通常、非対称リンクで使用されます。例えば、各方向に使用可能な帯域幅の非対称量とのリンクのために、大量の帯域幅と方向にトラフィックを転送するリンクの端部にPEPは、局所的に利用可能な帯域幅を使用するためにTCPトラフィックを認める集中かもしれません。同時に、非常に少ない帯域幅と方向にトラフィックを転送し、リンクの端にあるPEPは（輻輳からのリンクを維持するために）リンクを介して転送されているTCP確認応答トラフィックの量を減らすことに焦点を当てることがあります。
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.
分割接続TCPの実装では、エンドシステムから受信したTCP接続を終了し、他のエンド・システムに対応するTCPコネクションを確立します。分散PEPの実装では、これは、典型的には、リンクのために最適化された2つのPEPとの間の第3の接続の使用を可能にするために行われます。これは、リンク用に最適化されたTCPコネクションであるかもしれないまたはそれは例えば、独自のプロトコルがUDPの上で実行されている、別のプロトコルであるかもしれません。また、分散型の実装は、各TCP接続のためのプロキシ間の別の接続を使用する可能性があるか、のPEPとの間の単一の接続を介して複数のTCP接続からのデータを多重化するかもしれません。
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.
統合されたPEPの接続TCPの実装を分割、PEPは再び一端システムからの接続を終了し、他のエンドシステムへの別個の接続を発信します。 [I-TCP]単一PEPは、接続の実装を分割する例を説明します。
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.
多くの統合されたPEPには、二つのエンドシステム間のTCP機能の不一致を解決するために、分割された接続の実装を使用しています。例えば、TCPウィンドウスケーリングオプション[RFC1323]は「飛行中」であることができるTCPデータの最大量を拡張するために使用することができる（すなわち、送信および肯定応答待ち）。これは、高帯域幅*遅れ製品を持っているリンクを充填するために有用です。 1つのエンドシステムがスケーリングTCPウィンドウを使用することが可能となるが、他ではない場合は、対応していないエンド・システムは、高帯域幅*遅延リンクのその側にPEPとの接続をセットアップすることができます。スプリット接続PEPは、他のエンドシステムへのリンク上でウィンドウスケーリングとのTCP接続をセットアップします。
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.
TCPコネクション分割の実装は、効果的に特定のリンクのための最適なTCPパフォーマンスの向上を活用することができますが、必ずしもグローバルなインターネット上で安全に使用することができません。
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
スプリット接続のPEPを使用すると、必然的にエンドツーエンドの接続のためのIPの同時使用を排除するものではないことに注意してください。スプリット接続がアプリケーションごとに、または接続ごとに管理し、エンドユーザーの制御下にある場合は、ユーザーが特定のかどうかを決めることができます
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接続またはアプリケーションが分割接続PEPを使用するか、それがエンド・ツー・エンドで動作するかどうか。 PEPは、最後のホップリンク上で使用されている場合、エンドユーザーコントロールは、実装が比較的容易です。
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.
実際には、TCPベースのアプリケーションのためのアプリケーション層プロキシは、特定のアプリケーションに関連するサービスとしてのPEPを用いて、エンドシステムとの接続TCPの実装を分割しています。したがって、分割接続TCP実装で使用可能なすべてのトランスポート（TCP）層の強化は、アプリケーション層の強化と関連してアプリケーション層のPEPと共に用いることができます。
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.
PEPのもう一つの重要な特徴は、透明性の程度です。 PEPは、エンドシステム、トランスポート・エンドポイント、またはアプリケーションへの変更を必要としない、（接続で）関与するエンドシステム、トランスポートエンドポイント、および/またはアプリケーションに完全に透過的に動作することができます。
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.
一方、PEP実装が使用されるために両端に修正を必要とするかもしれません。間において、PEP実装が関与する端部のいずれか一方のみの変更を必要とするかもしれません。 PEP実装のこれらの種類のいずれかが、少なくとも修正を必要層に、非透明です。
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.
4つのレベルにおけるPEP実装の透明度、エンドシステム（ネットワーク層透明PEP）に対する透明性、トランスポート・エンドポイント（トランスポート層の透明PEP）に対する透明性、透明度を考えると便利な場合がありアプリケーション（アプリケーション層の透明PEP）に対するユーザーに対して透明性を有します。例えば、衛星インターネット接続サービスに加入しているユーザーは、衛星端末は、TCP / IPスタックとユーザーのPC内のアプリケーションがそれを実装PEPを認識していないにもかかわらず、性能向上サービスを提供していることを認識してあります。
Note that the issue of transparency is not the same as the issue of maintaining end-to-end semantics. For example, a PEP implementation which simply uses a TCP ACK spacing mechanism maintains the end-to-end semantics of the TCP connection while a split connection TCP PEP implementation may not. Yet, both can be implemented transparently to the transport endpoints at both ends. The implications of not maintaining the end-to-end semantics, in particular the end-to-end semantics of TCP connections, are discussed in Section 4.
透明性の問題は、エンドツーエンドのセマンティクスを維持することの問題と同じではないことに注意してください。例えば、単にTCP ACK間隔メカニズムを使用PEP実装は分割接続のTCP PEP実装はないかもしれないが、TCP接続のエンドツーエンドのセマンティクスを維持します。しかし、両方のは、両端のトランスポートエンドポイントに透過的に実装することができます。エンドツーエンドのセマンティクスを維持しない場合の影響は、TCP接続のエンドツーエンドのセマンティクス、特に、第4章に記載されています。
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.
PEP実装の明白な重要な特徴は、パフォーマンスを向上させるために使用するメカニズム（複数可）です。 PEP機構のいくつかの例は、以下のサブセクションに記載されています。 PEPの実装では、これらのメカニズムを複数実装する場合があります。
Many TCP PEP implementations are based on TCP ACK manipulation. The handling of TCP acknowledgments can differ significantly between different TCP PEP implementations. The following subsections describe various TCP ACK handling mechanisms. Many implementations combine some of these mechanisms and possibly employ some additional mechanisms as well.
多くのTCP PEP実装は、TCP ACK操作に基づいています。 TCP確認応答の取り扱いが異なるTCP PEP実装の間で大きく異なることができます。次のサブセクションでは、さまざまなTCPのACK処理メカニズムを説明します。多くの実装では、これらのメカニズムのいくつかを組み合わせて、可能性だけでなく、いくつかの追加的なメカニズムを採用しています。
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].
ACKが一緒に束に傾向がある環境では、ACK間隔は、リンクを通過するTCP確認応答の流れを滑らかにするために使用されています。これは、TCPの送信者が背中合わせするTCP確認応答[BPK97]到着により送信したTCPデータセグメントのバーストを排除することにより、パフォーマンスが向上します。
In some PEP implementations, TCP data segments received by the PEP are locally acknowledged by the PEP. This is very useful over network paths with a large bandwidth*delay product as it speeds up TCP slow start and allows the sending TCP to quickly open up its congestion window. Local (negative) acknowledgments are often also employed to trigger local (and faster) error recovery on links with significant error rates. (See Section 3.1.3.)
いくつかのPEP実装では、PEPによって受信されたTCPデータセグメントは、ローカルPEPによって認められています。それはTCPスロースタートをスピードアップし、送信側TCPはすぐにその輻輳ウィンドウを開くことができますので、これは大きな帯域幅*遅れ製品とネットワークパスにわたって非常に便利です。ローカル（負の）確認応答は、多くの場合も、重大なエラー率とのリンク上のローカル（および速い）エラー回復をトリガするために使用されています。 （3.1.3項を参照してください。）
Local acknowledgments are automatically employed with split connection TCP implementations. When local acknowledgments are used, the burden falls upon the TCP PEP to recover any data which is dropped after the PEP acknowledges it.
ローカル確認応答は、自動的にTCPコネクション分割実装で使用されています。ローカル確認応答を使用する場合には、負担がPEPはそれを認めた後、ドロップされたすべてのデータを回復するためにTCP PEPに当たります。
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 when to locally retransmit lost data. TCP PEPs sending local acknowledgments to the sending end system are required to employ local retransmissions towards the receiving end system.
TCP PEP局所的に再送信することができるデータ・セグメントは、このように失われたデータから、より速い回復を目指し、TCP PEPと受信側システムとの間の経路上に失われました。 TCP PEPにこれを達成するために、局所的に失われたデータを再送信する時を決定するために、適切なタイムアウトと共に、TCPデータセグメントを受信したエンド・システムから到着する確認応答を使用してもよいです。送信側システムにローカル確認応答を送信するTCPのPEPは、受信側システムに向けて地元の再送を採用する必要があります。
Some PEP implementations perform local retransmissions even though they do not use local acknowledgments to alter TCP connection performance. Basic Snoop [SNOOP] is a well know example of such a PEP implementation. Snoop caches TCP data segments it receives and forwards and then monitors the end-to-end acknowledgments coming from the receiving TCP end system for duplicate acknowledgments (DUPACKs). When DUPACKs are received, Snoop locally retransmits the lost TCP data segments from its cache, suppressing the DUPACKs flowing to the sending TCP end system until acknowledgments for new data are received. The Snoop system also implements an option to employ local negative acknowledgments to trigger local TCP retransmissions. This can be achieved, for example, by applying TCP selective acknowledgments locally on the error-prone link. (See Section 5.3 for details.)
彼らはTCP接続のパフォーマンスを変更するローカル確認応答を使用していないにもかかわらず、いくつかのPEP実装は、地元の再送を行います。基本スヌープ[スヌープ]は、このようなPEP実装のよく知っている例です。スヌープは、それが受信して転送した後、重複確認応答（DUPACKs）のための受信TCPエンドシステムからのエンドツーエンドの肯定応答を監視するTCPデータセグメントをキャッシュします。 DUPACKsが受信されると、スヌープは、ローカルに新しいデータのための確認応答が受信されるまで送信TCPエンドシステムに流れるDUPACKsを抑制し、そのキャッシュから失われたTCPデータセグメントを再送します。スヌープ・システムは、ローカルTCP再送信をトリガするために地元の否定応答を利用するためのオプションを実装しています。これは、例えば、エラーが発生しやすいリンク上でローカルにTCP選択的確認応答を適用することにより、達成することができます。 （詳細については、5.3節を参照してください。）
On paths with highly asymmetric bandwidth the TCP ACKs flowing in the low-speed direction may get congested if the asymmetry ratio is high enough. The ACK filtering and reconstruction mechanism addresses this by filtering the ACKs on one side of the link and reconstructing the deleted ACKs on the other side of the link. The mechanism and the issue of dealing with TCP ACK congestion with highly asymmetric links are discussed in detail in [RFC2760] and in [BPK97].
非対称比が十分に高い場合、高度に非対称な帯域幅を有する経路上低速方向に流れるTCPのACKは輻輳得ることができます。 ACKフィルタリング及び再構成機構は、リンクの一方の側にACKをフィルタリングし、リンクのもう一方の側で削除されたACKを再構成することによって、これを解決します。メカニズムおよび[RFC2760]にし、[BPK97]で詳細に説明されている非常に非対称リンクでTCP ACKの混雑を扱うの問題。
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.
パフォーマンス強化プロキシは、特定のリンクを介してメッセージを運ぶために、または特定のパスを横断するメッセージを強制的にメッセージをカプセル化してもよいです。カプセル化トンネルの他端にPEPは、受信エンドシステムへの最終的な配信の前にトンネルラッパーを除去します。トンネルは、分散のPEPとの間の接続をするための手段として配布分割接続TCPの実装によって使用されるかもしれません。トンネルは、分散PEP実装のエンドポイントを通過する非対称ルーティングを使用してTCP接続を強制的にサポートするために使用されるかもしれません。
Many PEP implementations include support for one or more forms of compression. In some PEP implementations, compression may even be the only mechanism used for performance improvement. Compression reduces the number of bytes which need to be sent across a link. This is useful in general and can be very important for bandwidth limited links. Benefits of using compression include improved link efficiency and higher effective link utilization, reduced latency and improved interactive response time, decreased overhead and reduced packet loss rate over lossy links.
多くのPEP実装は、圧縮の一の以上のフォームをサポートしています。いくつかのPEP実装では、圧縮は、さらに性能向上のために使用される唯一の機構であってもよいです。圧縮は、リンクを介して送信する必要のあるバイトの数を減らします。これは、一般的に有用であり、帯域幅が制限されたリンクのために非常に重要になることがあります。圧縮を使用することの利点は、改善されたリンク効率及びより高い有効なリンク利用率、減少待ち時間及び改善された対話式応答時間を含む、オーバーヘッドが減少し、損失の多いリンク上でのパケット損失率を低下させました。
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].
適切な場合には、リンク層の圧縮が使用されています。 TCPおよびIPヘッダー圧縮はまた、しばしばPEP実装で使用されています。 [RFC1144]はTCPヘッダを圧縮するために広く展開方法を記載しています。他のヘッダ圧縮アルゴリズムは[RFC2507]、[RFC2508]及び[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.
ペイロード圧縮も望ましいとインターネットのセキュリティ上の今日の増加重点を置いて重要性が増しています。ネットワーク（IP）層（以上）のセキュリティメカニズムは、冗長除去または隠蔽することによりランダムビットストリーム敗北該当するリンク層圧縮機構にIPペイロードを変換する「情報」。したがって、ペイロードの圧縮は、セキュリティメカニズムが適用される前に適用する必要があります。 [RFC2393]は一般的な圧縮アルゴリズムは、任意のIPセグメントペイロードに適用することができるフレームワークを定義します。ただし、[RFC2393]圧縮は常に適用されていません。 IPペイロード（例えば、画像、音声、ビデオ、および転送されている「zip形式」のファイル）には多くの種類が既に圧縮されています。そのようなTLS [RFC2246]などのセキュリティメカニズムは、ネットワーク（IP）層の上に適用されるときと、データが既に暗号化された（そしておそらく、圧縮）され、再びペイロード内の任意の冗長性を除去または隠蔽。得られた追加のトランスポートまたはネットワーク層の圧縮は小さいヘッダーのみを、圧縮、およびおそらく既にそれら自身の別個の圧縮アルゴリズムによって覆われます。
With application layer PEPs one can employ application-specific compression. Typically an application-specific (or content-specific) compression mechanism is much more efficient than any generic compression mechanism. For example, a distributed Web PEP implementation may implement more efficient binary encoding of HTTP headers, or a PEP can employ lossy compression that reduces the image quality of online-images on Web pages according to end user instructions, thus reducing the number of bytes transferred over a slow link and consequently the response time perceived by the user [LHKR96].
アプリケーション層のPEPと1は、アプリケーション固有の圧縮を採用することができます。典型的には、アプリケーション固有の（またはコンテンツ固有）の圧縮機構は、はるかに効率的な任意の汎用圧縮機構よりなります。例えば、分散Web PEP実装は、HTTPヘッダーをより効率的にバイナリ符号化を実施することができる、またはPEPは、このように転送されたバイトの数を減らすことは、エンドユーザの指示に従って、Webページ上のオンライン画像の画質を低下させる非可逆圧縮を使用することができますユーザ[LHKR96]によって知覚される低速リンクし、その結果、応答時間をかけ。
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 disconnected link. The TCP PEP retains the last ACK, so that it can shut down the TCP sender's window by sending the last ACK with a window set to zero. Thus, the TCP sender will go into persist mode.
リンク切れやリンク機能停止の期間は、いくつかの無線リンクで非常に一般的です。これらの期間中は、TCPの送信者が予想される確認応答を受信しません。再送信タイマーが満了すると、これは関連する欠点の全てをその輻輳ウィンドウを閉じるには、TCPの原因となります。 TCP PEPは、切断されたリンクの背後にあるTCP受信機に向けてTCPの送信者からのトラフィックを監視することができます。それがゼロに設定ウィンドウで、最後のACKを送信することにより、TCPの送信者のウィンドウをシャットダウンすることができるようにTCP PEPは、最後のACKを保持します。このように、TCPの送信者は、モードを持続になります。
To make this work in both directions with an integrated TCP PEP implementation, the TCP receiver behind the disconnected link must be aware of the current state of the connection and, in the event of a disconnection, it must be capable of freezing all timers. [M-TCP] implements such operation. Another possibility is that the disconnected link is surrounded by a distributed PEP pair.
統合されたTCP PEP実装と両方向にこの作業を行うには、切断リンクの背後にあるTCP受信機は接続の現在の状態を認識する必要がありますと、断線が発生した場合に、それはすべてのタイマーを凍結することが可能でなければなりません。 [M-TCPは、このような動作を実現します。別の可能性は、切断されたリンクを分散PEPのペアで囲まれていることです。
In split connection TCP implementations, a period of link disconnection can easily be hidden from the end host on the other side of the PEP thus precluding the TCP connection from breaking even if the period of link disconnection lasts a very long time; if the TCP PEP cannot forward data due to link disconnection, it stops receiving data. Normal TCP flow control then prevents the TCP sender from sending more than the TCP advertised window allowed by the PEP. Consequently, the PEP and its counterpart behind the disconnected link can employ a modified TCP version which retains the state and all unacknowledged data segments across the period of disconnection and then performs local recovery as the link is reconnected. The period of link disconnection may or may not be hidden from the application and user, depending upon what application the user is using the TCP connection for.
分割接続TCP実装では、リンク切断の期間は容易従ってリンク切断の期間が非常に長い時間続く場合であっても破壊からのTCP接続を排除PEPの反対側のエンドホストから隠すことができます。 TCP PEPは、順方向データは、断線をリンクすることができない場合、それはデータの受信を停止します。通常のTCPフロー制御は、TCPは、PEPで許可されているウィンドウを宣伝よりも多くを送信してから、TCPの送信者を防ぐことができます。従って、PEPと切断リンクの後ろのその対応は、断線の期間を横切って状態およびすべての未確認のデータセグメントを保持した後、リンクが再接続されるローカル回復を実行する変更されたTCPバージョンを使用することができます。リンク切断の期間は、ユーザがためにTCP接続を使用しているものの用途に応じたアプリケーションおよびユーザーから隠されていてもいなくてもよいです。
Implementing priority-based multiplexing of data over a slow and expensive link may significantly improve the performance and usability of the link for selected applications or connections.
遅くて高価なリンクを介したデータの優先度ベースの多重化を実現することは非常に選択したアプリケーションや接続のためのリンクのパフォーマンスと使いやすさを向上させることができます。
A user behind a slow link would experience the link more feasible to use in case of simultaneous data transfers, if urgent data transfers (e.g., interactive connections) could have shorter response time (better performance) than less urgent background transfers. If the interactive connections transmit enough data to keep the slow link fully utilized, it might be necessary to fully suspend the background transfers for awhile to ensure timely delivery for the interactive connections.
緊急のデータ転送（例えば、対話型の接続は）緊急性の低いバックグラウンド転送より短い応答時間（より良いパフォーマンスを）持っていることができれば低速リンクの背後にあるユーザーは、同時データ転送の場合に使用することがより実現可能なリンクを経験するでしょう。インタラクティブ接続が完全に利用低速リンクを維持するために十分なデータを送信した場合、完全にインタラクティブな接続のためのタイムリーな配送を確保するためにしばらくの間バックグラウンド転送を中断する必要がある場合があります。
In flight TCP segments of an end-to-end TCP connection (with low priority) cannot be delayed for a long time. Otherwise, the TCP timer at the sending end would expire, resulting in suboptimal performance. However, this kind of operation can be controlled in conjunction with a split connection TCP PEP by assigning different priorities for different connections (or applications). A split connection PEP implementation allows the PEP in an intermediate node 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.
（低優先度）のエンドツーエンドのTCP接続の飛行TCPセグメントに長時間遅延させることができません。それ以外の場合は、送信側のTCPタイマーが次善のパフォーマンスが得られ、有効期限が切れます。しかしながら、このような操作は、異なる接続（またはアプリケーション）のための異なる優先順位を割り当てることによってTCPコネクション分割PEPに関連して制御することができます。分割接続PEP実装は、中間ノードにおけるPEPは、単に遅い後ろ宛先ホストに、それが異なるフローのデータを転送する順序を再スケジュールすることにより、時間無制限の期間のためのより低い優先度のTCPフローのデータ配信を遅延することを可能にしますリンク。通常のTCPフロー制御は、PEPは、フローのためにデータを転送していないときに、TCPの送信者とPEPとの間の流れを中断するの世話をし、PEPはに決定したら、それを再開するので、これは遅れたTCPフローにマイナスの影響を与えることはありません。フローの転送データを続けます。低速リンクの両側のプロトコルスタックは、接続の優先度に基づくスケジューリングを実装する場合、これはさらに、補助することができます。
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.
このようなPEP実装で、ユーザ制御の優先順位とともに、ユーザは、選択されたインタラクティブな接続（単数または複数）のためのより高い優先順位を割り当てることができると同時に低優先バルクデータ転送があっても、選択された接続（S）のための非常に短い応答時間を有します定期的なエンド・ツー・エンドの操作でそれはそれ以外の場合はほぼ完全に低速リンクの利用可能な帯域幅を食べてしまいます。これらの低優先度のバルクデータ転送は、ユーザが遅く、高価なリンク（例えば、無線WAN）完全に利用を維持することを可能にする、インタラクティブな接続のアイドル期間中にうまく進行します。
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.
他の優先度ベースのメカニズムは、二つ以上の端末と共有する無線リンクに適用することができます。共有無線媒体は、インターネットのQoSアーキテクチャの弱点になってきてと、多くの人が共有無線媒体[SHEL00]全体の余分なプライオリティレベルを提供するのPEPになるかもしれません。これらのPEPは、共有無線媒体のすべてのノードに分散されます。例えば、802.11 WLANこのPEPは、アクセスポイント（基地局）と各モバイルホストに実装されています。一つのPEPは、すべてのノードのトラフィッククラスを調整し、分散キューイング技術を使用しています。これはまた時々サブネット帯域幅管理と呼ばれています。これを達成するために使用することができる技術をキューイングの例について[BBKT97]参照。この技術は、IP層の上または下のいずれかで実施することができます。優先度処理は、典型的には、ユーザによって、または（IPv4）ののToSまたは（IPv6）のトラフィッククラスIPヘッダフィールドをマーキングすることによってのいずれかで指定することができます。
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.
【FMSBMR98]における作業は、プロトコルブースターと呼ばれる他の可能なPEPメカニズムの範囲を示しています。これらのメカニズムのいくつかは、UDPフローに固有のものです。例えば、PEPは、そのような余分なUDPエラー検出などの非対称な方法を適用することができます。 16ビットのUDPチェックサムはオプションであるので、典型的には計算されません。ただし、エラーのあるリンクのために、チェックサムは有益である可能性があります。このチェックサムは、PEPにより、発信UDPパケットに追加することができます。
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.
対称仕組みも開発されています。前方消失訂正（FZC）メカニズムは、リアルタイムおよびマルチキャストトラフィックに使用することができます。エンコードのPEPは、パケットのブロックの上にパリティパケットを追加します。受信すると、パリティが除去され、失われたデータが再生されます。ジッタ制御機構は、余分なレイテンシを犠牲にして実装することができます。送信PEPは、発信パケットにタイムスタンプを追加することができます。受信PEPは、正しい間隔を再現するために、パケットを遅らせます。
The following sections describe some of the implications of using Performance Enhancing Proxies.
次のセクションでは、パフォーマンス強化プロキシを使用した場合の影響のいくつかを説明します。
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.
[RFC1958]に示されるように、エンド・ツー・エンドの引数は、[SRC84]インターネットのアーキテクチャの原則の一つです。基本的な引数は、第一の原則として、特定の必要なエンドツーエンドの機能が正しくのみエンドシステム自身で行うことができる、ということです。 PEPを使用することに伴う潜在的な負の影響のほとんどは、接続のエンドツーエンドのセマンティクスを破壊する可能性に関連しています。これは、PEPには、一般的な使用は推奨されていない主な理由の一つです。
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.
2.5節で示したように、すべてではないPEP実装は、接続のエンドツーエンドのセマンティクスを破ります。正しく設計のPEPは、任意のアプリケーション・レベルのエンド・ツー・エンドの機能を交換しようとしますが、唯一のアプリケーションのエンドポイント間のエンドツーエンドのパスのサブパスにパフォーマンスの最適化を追加しようとしません。これを実行するエンド・ツー・エンドの引数と一致することができます。しかし、彼のネットワーク構成にPEPを追加ユーザまたはネットワーク管理者は、特定のPEP実装によって使用されるメカニズムに関連する潜在的なエンド・ツー・エンドの意味を認識しなければなりません。
In most cases, security applied above the transport layer can be used with PEPs, especially transport layer PEPs. However, today, only a limited number of applications include support for the use of transport (or higher) layer security. Network (IP) layer security (IPsec) [RFC2401], on the other hand, can generally be used by any application, transparently to the application.
ほとんどの場合、トランスポート層の上に適用されるセキュリティは、特に、層のPEPを輸送、のPEPと共に使用することができます。しかし、今日では、アプリケーションの限られた数は、トランスポート（またはそれ以上）層のセキュリティを使用するためのサポートが含まれています。ネットワーク（IP）層セキュリティ（IPsec）[RFC2401]は、一方で、一般的に透過的アプリケーションに、任意のアプリケーションで使用することができます。
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.
接続のエンドツーエンドのセマンティクスを壊すの最も有害な負の意味は、それがIPSecのエンドツーエンドの使用を無効にしていることです。一般的には、ユーザまたはネットワーク管理者がのPEPを使用し、IPsecを使用するかを選択しなければなりません。 IPsecは、エンドツーエンドを使用する場合（トランスポートまたはトンネルモードのいずれかで）のIPsecのESPヘッダを介して、IPパケットの暗号化は、TCPをレンダリングするため、ネットワーク内の中間ノードに実装されているのPEPは、IPパケットのトランスポート又はアプリケーションヘッダを調べることができませんヘッダおよびペイロードのPEPに判読できません。輸送やアプリケーションのヘッダーを調べることができず、PEPは最適か、まったく機能しない場合があります。
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).
PEP実装がユーザーに対して非透過的であり、ユーザが途中でPEPを信頼する場合、IPsecは各エンドシステムとPEPとの間に別々に使用することができます。しかし、ほとんどの場合、これは、エンドシステムは、一般的にのPEPを信頼することはできませんとして、望ましくない、または容認できない代替手段です。また、これはエンドツーエンドのセキュリティほど安全ではありません。 （処理される復号化された場合、例えば、トラフィックがPEPに露出している。）そして、それは、潜在的にエンドシステムによるセキュリティレベルの仮定を誤解につながる可能性があります。両端システムはPEPとのセキュリティのさまざまなレベルを交渉する場合、セキュリティのより強いレベルをネゴシエートエンドシステムは、セキュリティの低いレベルは、接続の一部のために提供されていることを認識しないかもしれません。 PEPは、各エンドシステムにセキュリティの同じレベルを強制的に十分にスマートであることによってこれを防止するために実施することができるが、これはPEPの実装の複雑さを増大させ（まだエンドツーエンドのセキュリティほど安全ではありません）。
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).
エンドシステムは、PEPを信頼するために、彼らはその存在を認識していない可能性があるため、透明PEP実装では、それが困難です。ユーザーはPEPを認識している場合でも、PEPの透明性を維持しながら、PEPでも許容されるセキュリティアソシエーションを設定することは問題（不可能ではない）です。
Note that even when a PEP implementation does not break the end-to-end semantics of a connection, the PEP implementation may not be able to function in the presence of IPsec. For example, it is difficult to do ACK spacing if the PEP cannot reliably determine which IP packets contain ACKs of interest. In any case, the authors are currently not aware of any PEP implementations, transparent or non-transparent, which provide support for end-to-end IPsec, except in a case where the PEPs are implemented on the end hosts.
PEP実装は、接続のエンドツーエンドのセマンティクスを破壊しない場合でも、PEP実装はIPsecの存在下で機能することができないかもしれないことに注意してください。 PEPは、確実にIPパケットが関心のACKを含めるかを決定することができない場合例えば、ACK間隔を行うことは困難です。いずれの場合においても、著者らは、現在のPEPがエンドホストに実装されている場合を除き、エンドツーエンドのIPsecをサポートする透明又は不透明任意PEP実装、に気づいていません。
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.
IPsecとのPEPの使用が共存できるようにするために撮影することができますいくつかのステップがあります。エンドユーザーが他のトラフィックのためのいくつかのトラフィックやないのIPsecの使用を選択することができた場合は、PEP処理は、IPsecなしで送信されるトラフィックに適用することができます。もちろん、ユーザーは、このトラフィックのセキュリティなしで行うか、他の手段を介して（例えば、トランスポート層セキュリティを使用して）トラフィックのセキュリティを提供する必要があります。しかし、これは可能であっても、有意な複雑さは、エンドシステムの構成に追加する必要があるかもしれません。
Another alternative is to implement IPsec between the two PEPs of a distributed PEP implementation. This at least protects the traffic between the two PEPs. (The issue of trusting the PEPs does not change.) In the case where the PEP implementation is not transparent to the user, (assuming that the user trusts the PEPs,) the user can configure his end system to use the PEPs as the end points of an IPsec tunnel. And, an IPsec tunnel could even potentially be used between the end system and a PEP to protect traffic on this part of the path. But, all of this adds complexity. And, it still does not eliminate the risk of the traffic being exposed in the PEP itself as the traffic is received from one IPsec tunnel, processed and then forwarded (even if forwarded through another IPsec tunnel).
別の方法としては、分散PEP実装の2つのPEP間のIPsecを実装することです。これは、少なくとも2つのPEP間のトラフィックを保護します。 （のPEPを信頼の問題は変化しない。）PEP実装はユーザに透明でない場合には、（ユーザーがのPEPを信頼することを仮定して）ユーザがエンドとしてのPEPを使用するために彼のエンドシステムを構成することができIPsecトンネルの点。そして、IPsecトンネルがあっても、潜在的経路のこの部分上のトラフィックを保護するために、エンドシステムとPEPとの間で使用することができます。しかし、このすべてが複雑になります。そして、それはまだトラフィックを（別のIPsecトンネルを介して転送された場合であっても）と、1つのIPsecトンネルから受け取った処理された後に転送されるPEP自体に曝されるトラフィックのリスクを排除しません。
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).
進行中のPEPを使用することにより優しいことのIPsecの実装を変更する可能性を調査する研究があります。積極的に検索される一つのアプローチは、マルチレイヤIPセキュリティを使用することです。 [Zhang00]（TCPヘッダを暗号化するために使用されるセキュリティアソシエーションに含まれるTCP接続の経路内のPEPと共に）TCPペイロードは、エンドツーエンドの暗号化されつつ、TCPヘッダが一つの層として暗号化されることを可能にする方法が記載されています別個の層として。これはまだPEPを信頼が、はるかに低い程度に含まれます。しかし、このアプローチの欠点は、IPセキュリティ実装の複雑さを大幅に追加していることです。 IPsecの既存の複雑さを考えると、この欠点は、マルチレイヤIPセキュリティアイデアの標準化に深刻な障害となっている、このアプローチは、いつでもすぐに標準として採用されることはほとんどありません。したがって、このタイプのアプローチに頼ることは可能性の高い非標準プロトコルの使用（そうすることのリスクを）含むことになります。
Another important aspect of the end-to-end argument is fate sharing. If a failure occurs in the network, the ability of the connection to survive the failure depends upon how much state is being maintained on behalf of the connection in the network and whether the state is self-healing. If no connection specific state resides in the network or such state is self-healing as in case of regular end-to-end operation, then a failure in the network will break the connection only if there is no alternate path through the network between the end systems. And, if there is no path, both end systems can detect this. However, if the connection depends upon some state being stored in the network (e.g., in a PEP), then a failure in the network (e.g., the node containing a PEP crashes) causes this state to be lost, forcing the connection to terminate even if an alternate path through the network exists.
エンド・ツー・エンドの引数のもう一つの重要な側面は、運命の共有です。ネットワークに障害が発生した場合は、失敗を生き残るためには、接続の能力は、ネットワークでの接続に代わって維持されているどのくらいの状態に依存し、状態かどうかを自己修復です。いかなる接続特定の状態がネットワーク内に存在しない、またはそのような状態は、通常のエンド・ツー・エンド動作の場合のように自己治癒である場合との間のネットワークを通る代替経路が存在しない場合にのみ、ネットワークに障害が接続を切断しますエンドシステム。パスがない場合は、両方のエンドシステムは、これを検出することができます。接続は、いくつかの状態に依存する場合は、ネットワーク（例えば、PEPで）に格納され、その後、ネットワーク内の障害が（例えば、PEPがクラッシュを含むノード）は、この状態を終了するために接続を強制的に失われネットワークを介して、代替パスが存在する場合でも。
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.
PEPに対するエンドツーエンドの引数のこの局面の重要性は、PEPの実装の両方に依存し、アプリケーションのタイプに使用されています。エンドシステムとの間に代替パスが存在しない場合、時々、偶然が、より頻繁に設計することにより、のPEPは、環境で使用され、従って、PEPを含む中間ノードの障害がどのような場合に接続の終了をもたらすであろう。そして、これがそうでない場合でも、定期的なエンド・ツー・エンドの操作の場合の接続を失うリスクは、例えば何らかの理由で破損することがあり、接続、最後の十分な長リンク停止として存在してもよいですエンドホストへの無線リンクを-hop。そのため、ユーザーは、PEP実装が提供するパフォーマンス向上の利点を活用するために、クラッシュPEPのリスクを受け入れることを選択することもできます。重要なことは、リスクを受け入れることは、ユーザの制御下でなければなりません（つまり、ユーザーは常に、エンドツーエンドの操作を選択するオプションを持っている必要があります）と、ユーザーはPEPを使用することを選択した場合、ユーザーはあるべきであるということですPEP障害がアプリケーションに対して有する影響の認識は、使用されています。
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.
エンドツーエンドの引数の別の態様は、データの信頼性のあるエンドツーエンドの送達を達成するために、データのエンドツーエンドの受信を確認するものです。信頼性の高いエンドツーエンドの配信を目指しアプリケーションは、アプリケーションレベルでのエンド・ツー・エンドのチェックと回復を実装する必要があります。エンド・ツー・エンドの引数によると、これは正確に信頼性の高いエンドツーエンドの動作を実現するための唯一の可能性です。そうしないとアプリケーションは、エンドツーエンドの引数に違反します。また、これは正しく設計されたアプリケーションは、完全に信頼性の高いエンドツーエンドの配信を提供するために、トランスポート層（例えば、TCP）、または任意の他の通信サブシステムに頼ることはできないということを意味します。
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
まず、TCP接続が何らかの理由で破壊し、アプリケーションレベルで回収しなければならないデータが失われることがあります。第二に、TCPによって提供されるチェックサムは（TCPによって）検出されないデータ破損[Pax99]をもたらし、必要不十分と考えることができます
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.
データ破損のためのアプリケーションレベルのチェック。第三に、TCP受信確認は、データのみが、他のエンドシステム上のTCP実装に配信されたことを示しています。これは、データを他のエンドシステム上のアプリケーション層に配信されたことを保証するものではありません。したがって、うまく設計されたアプリケーションは、アプリケーション層データのエンド・ツー・エンド配信を保証するために、アプリケーション・レイヤ応答を使用しなければなりません。そのようなプロトコルは、アプリケーションのためのいくつかの重要な機能（例えば、輻輳制御）の効率的な実装を可能にするように、これは信頼性の高いトランスポートプロトコル（すなわち、TCP）の値を減少させないことに留意されたいです。
If a PEP implementation acknowledges application data prematurely (before the PEP receives an application ACK from the other endpoint), end-to-end reliability cannot be guaranteed. Typically, application layer PEPs do not acknowledge data prematurely, i.e., the PEP does not send an application ACK to the sender until it receives an application ACK from the receiver. And, transport layer PEP implementations, including TCP PEPs, generally do not interfere with end-to-end application layer acknowledgments as they let applications operate end-to-end. However, the user and/or network administrator employing the PEP must understand how it operates in order to understand the risks related to end-to-end reliability.
PEP実装が（PEPは、他のエンドポイントからアプリケーションのACKを受信する前に）途中でアプリケーションデータを承認した場合、エンドツーエンドの信頼性を保証することはできません。典型的には、アプリケーション層のPEPは、早期データを承認していないが、受信機からアプリケーションのACKを受信するまで、すなわち、PEPは、送信者へのアプリケーションのACKを送信しません。彼らは、アプリケーションがエンドツーエンドで動作させようと、TCPののPEPを含むトランスポート層PEP実装は、一般的にエンドツーエンドのアプリケーション層の確認応答を妨げることはありません。しかし、PEPを採用し、ユーザおよび/またはネットワーク管理者は、エンドツーエンドするために信頼性に関連するリスクを理解するためにどのように動作するかを理解する必要があります。
Some Internet applications do not necessarily operate end-to-end in their regular operation, thus abandoning any end-to-end reliability guarantee. For example, Internet email delivery often operates via relay Mail Transfer Agents, that is, relay Simple Mail Transfer Protocol (SMTP) servers. An originating MTA (SMTP server) sends the mail message to a relay MTA that receives the mail message, stores it in non-volatile storage (e.g., on disk) and then sends an application level acknowledgement. The relay MTA then takes "full responsibility" for delivering the mail message to the destination SMTP server (maybe via another relay MTA); it tries to forward the message for a relatively long time (typically around 5 days). This scheme does not give a 100% guarantee of email delivery, but reliability is considered "good enough".
一部のインターネットアプリケーションでは、必ずしもこのように任意のエンド・ツー・エンドの信頼性の保証を放棄し、彼らの通常の操作では、エンドツーエンドを操作しないでください。たとえば、インターネット電子メールの配信は、多くの場合、それは、簡易メール転送プロトコル（SMTP）サーバを中継され、リレーメール転送エージェントを経由して動作します。発信MTA（SMTPサーバ）、電子メールメッセージを受信した中継MTAにメールメッセージを送信する（ディスク上の例えば、）は、不揮発性記憶装置に格納し、その後、アプリケーションレベルの肯定応答を送信します。リレーMTAは、（多分他の中継MTAを経由して）先のSMTPサーバーにメールを配信するための「全責任」を取ります。それは、比較的長い時間（典型的には約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は限りPEPは、通常のプロキシ（例えば、MTAリレー）と同様の方法に従って動作するように、本質的に信頼性を低下させることなく（例えば、メール）アプリケーションデータを確認してもよいです。上述したように、再び、そのようなPEPを用いたユーザおよび/またはネットワーク管理者は、それがそうすることに関連付けられた信頼性上のリスクを理解するためにどのように動作するかを理解する必要があります。
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の存在は、一つまたはエンドポイントの両方で（時には顕著に）故障の検出が遅れる可能性があります。 （もちろん、いくつかのPEPは、意図的に第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は、ICMPの代わりにTCP（すなわち、それはICMPエコーを使用して実装され、ネットワーク層でコマンドを返信される）に基づいているので、しかし、それはPEP周りネットワークかもしれないルートPINGトラフィックの構成が可能です。したがって、PINGは、それが実際にTCPトラフィックのために存在しない場合、エンドツーエンドのパスは、2つのホスト間に存在することを示している可能性があります。 PINGトラフィックがPEPを通過しない場合でも、PINGトラフィックが提供する診断表示が変更されています。例えば、PINGトラフィックがPEPを介して透過的に移行した場合、PINGは、PEPが存在する兆候を提供していないとPINGトラフィックがTCPトラフィックと同じ処理が施されていないため、必ずしも正確な表示を提供しないかもしれませんネットワーク遅延は、TCPトラフィックが経験されています。 PEPは、PINGを終了し、エンドホストに代わって、それに応答するかどうか一方、その後、PINGはPEPへの接続に関する情報を提供します。トレースルートは、（また、[RFC2151]に記載されている）と同様PEPの存在によって影響されます。
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の実装を展開する通常およびエンドホストからのトラフィックがのPEPが存在する中間ノード（複数可）を介してルーティングされることを必要とします。一部のネットワークでは、これは達成することができない、またはそれが中間ノードは、いくつかのホップ離れ今度は多くの場合非実用的であり、非最適なルーティングをもたらす可能性がターゲットリンク端から配置されることを必要とするかもしれません。
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はトラフィックフロー（ACKが流れている方向）の一方の方向を見る必要があります。 ACK間隔は、実際のデータの流れを見ることなく行うことができます。
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.
今日、のPEPを使っに関してモビリティへの影響は、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状態ハンドオフは、将来的に必要になります。
Because a PEP typically processes packet information above the IP layer, a PEP requires more processing power per packet than a router. Therefore, PEPs will always be (at least) one step behind routers in terms of the total throughput they can support. (Processing above the IP layer is also more difficult to implement in hardware.) In addition, since most PEP implementations require per connection state, PEP memory requirements are generally significantly higher than with a router. Therefore, a PEP implementation may have a limit on the number of connections which it can support whereas a router has no such limitation.
PEPは、典型的には、IP層の上のパケット情報を処理するため、PEPは、ルータよりもパケットあたりの処理能力を必要とします。したがって、のPEPは、常に、それらがサポートすることができる総スループットの点で（少なくとも）ルータの背後にある一歩であろう。 （IP層以上の処理は、ハードウェアで実現することもより困難である。）また、最もPEP実装が接続状態ごとに必要とするため、PEPのメモリ要件は、一般に、ルータよりも有意に高いです。したがって、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.
増加した処理能力とメモリ要件は、のPEPの使用に関してスケーラビリティの問題を導入します。多数の接続をサポートしている高速リンク上のPEPの配置やリンクは、単にトラフィックのパスにPEPを挿入越えたネットワークトポロジの変更が必要な場合があります。 PEPのみリンク上のトラフィックの半分を処理できる場合、例えば、複数のPEPのPEPの間のトラフィックを分割するネットワーク構成に複雑さを追加して、並行して使用する必要があるかもしれません。
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.
この文書では、性能向上のプロキシを使用に関していくつかの重要な意味を説明しています。しかし、このドキュメントに記載されている意味合いのリストは必ずしも完全なものではありません。 PEPの使用に関連する他の潜在的な影響のいくつかの例には、マルチホーミング環境でのPEPの使用とサービス品質（QoS）の透明度に関してのPEPの使用を含みます。例えば、セクション3.5に記載の優先度ベースの多重化機構と差別化サービス[RFC2475]を用いて、潜在的な相互作用があるかもしれません。したがって、PEPを展開したいユーザーやネットワーク管理者は、PEPは、両方の初めとでは、そのアプリケーションとネットワークインフラストラクチャ上で持っていることを、この文書で説明する意味合いでも（正と負）全体的な影響ではないだけになります新しいアプリケーションが追加され、および/またはネットワークインフラストラクチャの変更が必要とされている未来。
The following sections describe examples of environments where PEP is currently used to improve performance. The examples are provided to illustrate the use of the various PEP types and PEP mechanisms described earlier in the document and to help illustrate the motivation for their development and use.
以下のセクションでは、PEPが現在のパフォーマンスを改善するために使用される環境の例を記載しています。実施例は、先に文書で説明された様々なPEPタイプおよびPEP機構の使用を例示し、その開発と使用のためのモチベーションを例示するために提供されます。
Today, VSAT networks are implemented with geosynchronous satellites. VSAT data networks are typically implemented using a star topology. A large hub earth station is located at the center of the star with VSATs used at the remote sites of the network. Data is sent from the hub to the remote sites via an outroute. Data is sent from the remote sites to the hub via one or more inroutes. VSATs represent an environment with highly asymmetric links, with an outroute typically much larger than an inroute. (Multiple inroutes can be used with each outroute but any particular VSAT only has access to a single inroute at a time, making the link asymmetric.)
今日では、VSATネットワークは静止衛星を用いて実装されています。 VSATデータネットワークは、一般的にスター型トポロジを使用して実装されています。大ハブ地球局は、ネットワークのリモートサイトで使用のVSATと星の中心に位置しています。データはハブからoutroute経由でリモートサイトに送信されます。データは、一つ以上のinroutesを経由してリモートサイトからハブに送信されます。 VSATはinrouteより一般的にはるかに大きいoutrouteで、非常に非対称リンクを含む環境を表しています。 （複数inroutes各outrouteで使用することができるが、任意の特定のVSATのみリンクが非対称作り、一度に単一inrouteへのアクセスを有します。）
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ネットワークのためのインターネットへの接続は、通常、適切なファイアウォールおよび（必要な）NAT [RFC2663]のデバイスを使用して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ネットワークは、第2のアップ当たり数キロビットから毎秒数メガビットまでの容量をサポートすることができます。比較的長い往復時間と組み合わせると、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ネットワークのoutrouteは通常inrouteより著しく大きいです。複数inroutesがネットワーク内で使用することができるにもかかわらず、所定のVSATは、一度に1つのinrouteにアクセスすることができます。したがって、VSATの着信（outroute）および発信（inroute）能力は、しばしば非常に非対称です。 outroute容量が近年増加しているように、1から400以上の比率は、ますます一般的になってきています。 1460バイトと遅延確認応答のTCP最大セグメントサイズ[RFC1122]使用中で、ACKのためのIPパケットのバイトにデータのIPパケットのバイトの割合が75 1（40から3000）のみです。
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].)
このように、ACKを運ぶためのinroute容量は、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ネットワークは、一般的に、これらの状態の間に動作するように設計されているが、これらの状態の間のパフォーマンスを最適化しないような条件はまれです。
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.
プロキシのパフォーマンスの向上は、一般的に（例えばFTPやHTTP Webページの回収のようなアプリケーションのための）スループットの向上に注力VSATネットワークのために実装されています。より少ない程度に、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ネットワークベンダーは、彼らのVSAT製品の他の機能と統合され、PEP機能の独自のバージョンを実装する傾向があります。 [HNS]と[スペースネット（Spacenet）]統合PEP機能を備えたVSAT製品について説明します。 VSATネットワークで使用するように設計されたサードパーティのPEPの実装もあります。これらの製品は、ハブとリモートサイトのVSATネットワークの外部ノードで実行されます。 NettGain [FLASH]とベンチュリ[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).
- 彼らは（inroute帯域幅を節約に重点を置いて）必要な帯域幅の量を減らすために圧縮のいくつかのフォームをサポートしています。
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);
- 彼らは（彼らが使用するバッファ領域の量の主機能）をサポートしようとする最大スループット。
- 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実装が一般アプリケーションに焦点を当てる（例えば、HTTP）VSATネットワークに統合PEP実装は、一般的にリンク特定の圧縮に焦点を当てながら、特定の圧縮アルゴリズム。
PEP implementations integrated into a VSAT product are generally transparent to the end systems. Third party PEP implementations used with VSAT networks usually require configuration changes in the remote site end systems to route TCP packets to the remote site proxies but do not require changes to the hub site end systems. In some cases, the PEP implementation is actually integrated transparently into the end system node itself, using a "bump in the stack" approach. In all cases, the use of a PEP is non-transparent to the user, i.e., the user is aware when a PEP implementation is being used to boost performance.
VSAT製品に組み込まPEP実装は、一般的にエンドシステムに透明です。 VSATネットワークで使用するサードパーティのPEPの実装は通常、リモートサイトのプロキシへのルートのTCPパケットにリモートサイトのエンドシステムでの設定を変更する必要がなく、ハブサイトのエンドシステムへの変更を必要としません。いくつかのケースでは、PEP実装は実際には「バンプスタック内」アプローチを使用して、エンド・システム・ノード自体に透過的に統合されています。全ての場合において、PEPの使用は、PEP実装はパフォーマンスを向上するために使用されている場合、すなわち、ユーザが認識している、ユーザに対して非透過的です。
VSAT networks, since the early stages of their deployment, have supported the use of local termination of a protocol (e.g., SDLC and X.25) on each side of the satellite link to hide the satellite link from the applications using the protocol. Therefore, when LAN capabilities were added to VSAT networks, VSAT customers expected and, in fact, demanded, the use of similar techniques for improving the performance of IP based traffic, in particular TCP traffic.
VSATネットワークは、それらの配備の初期段階から、プロトコルを使用して、アプリケーションからの衛星リンクを非表示にする衛星リンクの各側のプロトコル（例えば、SDLCおよびX.25）のローカル終了の使用を支持しています。したがってLAN機能がVSATネットワークに追加されたとき、VSATの顧客は期待して、実際には、特定のTCPトラフィックに、IPベースのトラフィックのパフォーマンスを向上させるために、同様の技術を使用することを要求しました。
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されたお客様は、影響を受けない（又は少なくともそれらが影響されないことを認識する）他の技術であるとしてのPEPを用いたインターネット関連の影響により。代わりに、VSATのお客様に、より重要なことは、ネットワークの最適化があります。そして、VSATのお客様は、一般的には、ネットワークの最適化は、ネットワーク自体ではなく、自分の機器に（例えばTCPスケールウィンドウオプションを有効にするなど）の変更を実装することによって行われることを好みます。 VSATのお客様は、地元のミッションクリティカルな機能に関連するローカル通信のための彼らの最後のシステム構成を最適化し、VSATネットワークは、できるだけ多くの衛星リンクの存在を隠すようにすることを好みます。 VSATネットワークベンダーも、このような古い、「非近代的な」TCPスタックを含み、古い機器の寿命の有用な拡張として、顧客に付加価値「サービス」を提供するために、PEP機能を使用することができました。
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.
イントラネットとインターネットの間のラインがフェードインし続けているもちろん、のPEPを使用する意味は、VSATネットワークのためのより重要になり始めます。 VSATのトラフィックを傍受することができることに関連する設備コストが比較的高かったので、例えば、12年前にセキュリティが大きな問題ではありませんでした。技術が進歩したとして今、コストはそれほど法外です。 VSATネットワークにおけるPEP機能の使用はIPsecの使用を防ぐため、現在、多くのアプリケーションがすることができないので、そのため、顧客がTLSなどやVSATネットワークそのものに実装独自のセキュリティメカニズム（上の上位層のセキュリティメカニズムの使用に依存しなければなりません）標準化され、より高い層のセキュリティメカニズムの使用を作る（または単にしないでください）。これは、順番に、VSATネットワークのコストに影響を与えるだけでなく、インターネットベースの機能を利用する顧客の能力に影響を与えます。
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]、IS-95 CDMA]、RichoNet、及びPHSなどのネットワークを含みます。これらのネットワークの多くは、すべてではありませんが、最初の場所での携帯電話の音声サービスを提供するが、同様にデータ・サービスを含むように設計または彼らは、携帯電話網から進化してきました。
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)
- 低帯域幅（いくつかのリンクで利用可能な帯域幅が数百ビット/秒程度の低かもしれません）
- 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
- ローカルリンク層エラー回復のためにフレームやパケット損失、またはlong変数遅延が得られる高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は、ユーザーが順番に、他のユーザーによる同一チャネル・リソースの同時使用によるユーザーのパケット配信に予期せぬ遅延を引き起こす可能性があり、そのデータパケットの配信のための共通のチャネルを共有することがリンクの上に
- unexpected link disconnections (or intermittent link outages) may occur frequently and the period of disconnection may last a very long time
- 予期しないリンクの切断（または断続的なリンクの停止）が頻繁に発生する可能性がありますと断線の期間が非常に長い時間が続くことがあり
- (re)setting the link-connection up may take a long time (several tens of seconds or even minutes)
- （秒あるいは数十分）長い時間がかかることがあり、リンク接続のセットアップを設定（再）
- the W-WAN network typically takes care of terminal mobility: the connection point to the Internet is retained while the user moves with the mobile host
- W-WANネットワークは、通常、端末のモビリティの世話をする：インターネットへの接続ポイントが保持され、ユーザーがモバイルホストと移動しながら、
- the use of most W-WAN links is expensive. Many of the service providers apply time-based charging.
- ほとんどの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環境での実装プロキシのパフォーマンスの向上は、一般的に、主に、さまざまな方法で本質的に低速リンク経由で転送量を減らすことによって、スループットを向上させることで、インタラクティブな応答時間を改善する上ではなく、同じ時間を目的に焦点を当てます。これを達成するために、通常の拡張機能は、ほぼすべてのプロトコル層で適用されます。
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.
モーグリシステムは、[KRA94]低帯域幅W-WANリンクの問題の特性によって誘発される課題に対処するため、早期のアプローチの一つです。
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.
モーグリに使用される間接的なアプローチは、多くの他の分割接続手法のように単一層に限定されるものではなく、それは、すべてのプロトコル層を含みます。基本的なアーキテクチャは、分散PEPアプローチとアプリケーション層プロキシを完全にサポートと共に（UDPもサポートされている）分割TCPに基づいています。アプリケーション層プロキシ対は、クライアントとサーバ、モバイルホストのエージェント（ローカルプロキシ）と有線インターネットへの接続を有するモバイルホストを提供する中間ノードのプロキシとの間に追加してもよいです。このようなペアは、アプリケーションに対して明示的または完全に透明のいずれであってもよいが、それはこのように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を横断するように構成されているアプリケーションを、接続するように修正されます。アプリケーション層エージェントプロキシ対の二種類がモバイルホストアプリケーションの使用のために構成することができます。
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]上のラウンドトリップの数を減少させることによって、大幅にWebブラウジングのユーザ知覚される応答時間を改善するモーグリWWWシステム、です[ LHKR96]。
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.
モーグリは、低帯域幅の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 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.
さらに、カスタムプロトコルは、基礎となるリンクサービスに応じて、特定のプロトコル機能をオンまたはオフオン異なる動作モードで実行することができます。基礎となるリンクサービスが信頼できるデータ配信を提供する場合、例えば、チェックサム、ウィンドウベースのエラー回復は、したがって、プロトコルオーバーヘッドを低減、オフにすることができます。唯一の非常に単純な回復メカニズムは、予期しないリンクの切断からの回復を可能にするために必要とされます。したがって、プロトコルの設計は著しくラウンドトリップの数を減少させる、非常に効率的なヘッダ符号化（典型的な場合にパケット当たりわずか1~3バイト）を使用することができた、低帯域幅のW-WANリンクで有用である様々な特徴でした追加するのは簡単。そのような機能は、リンクが再び動作可能になるとこのようにタイムリーに双方向アプリケーションへのリンク容量を提供し、ファストスタートと一緒にリンク切断若しくはリンク停止の期間にわたってW-WANリンクを介してユーザデータの優先度に基づく多重化プロトコルの動作を停止含みます偶数帯域幅集約型のバックグラウンド転送の存在、および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トランスポート、。
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.
モーグリシステムは、制約のリンクを介してインターネットに接続されているモバイルホストをサポートするように設計されましたが、ローエンドの携帯デバイスとの具体的な課題に対応していませんでした。多くの移動無線装置は、電源、メモリ、および処理制約され、そしてこれらのデバイスへの通信リンクは、低い帯域幅および安定性の低い接続を有します。これらの制限は、ローエンドのデジタル携帯電話や他の携帯無線端末にインターネットコンテンツをもたらす狭帯域無線ネットワーク技術と高度なデータサービスを異なる渡って動作するように意図したアプリケーション・フレームワークとネットワークプロトコルを指定するワイヤレスアプリケーションプロトコル（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プロキシが必要です。アプリケーション層（WAE）WAPWAE]、セッション層（WSP）WAPWSP]、トランザクション層（WTP）：WAP端末とプロキシとの間で使用される次の5つのプロトコル層を指定して、[WAPARCH層状、スケーラブルなアーキテクチャを使用します[WAPWTP]、セキュリティ層（WTLS）[WAPWTLS]、およびトランスポート層（WDP）[WAPWDP]。標準的なインターネット・プロトコルは、プロキシとオリジンサーバの間で使用されています。オリジンサーバは、WAPプロキシ機能が含まれている場合、それは、WAPサーバーと呼ばれています。
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要求を変換し、インターネット上での標準的なWebサーバーにこの要求を送信します。ウェブサーバは、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 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.
WAPは、ベアラデータグラムの様々なサービスで動作します。これらのベアラサービスを介して通信するとき、WAP輸送層（WDP）は常にWAPクライアントとWAPプロキシとの間で使用され、ポートが高いWAP層にデータグラムサービスを提供対処しました。ベアラサービスは、IP（例えば、GSM、CSD、GSM、GPRS、IS-136、CDPD）をサポートしている場合、UDPは、データグラムプロトコルとして使用されます。ベアラサービスは、IP（例えば、GSM-SMS、GSM-USSD、GSMセルブロードキャスト、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は、IANAでよく知られているポートのセットを登録しています。 WAPクライアントとプロキシの間の通信のためにアプリケーションによって選択されたポート番号は、各端部に使用される他の層を定義します。セキュリティ層、WTLSは、プライバシー、データ整合性と認証を提供します。その機能は、データグラムのサポート、最適化されたハンドシェイクおよび動的キー爽やかで拡張TLS 1.0 [RFC2246]と同様です。オリジンサーバは、WAPプロキシ機能が含まれている場合、それはエンド・ツー・エンドのセキュリティソリューションを容易にするために使用されるかもしれない、そうでない場合は、携帯端末とプロキシ間のセキュリティを提供します。
The transaction layer, WTP, is message based without connection establishment and tear down. It supports three types of transaction classes: an unconfirmed request (unidirectional), a reliable (confirmed) request (unidirectional), and a reliable (confirmed) request-reply transaction. Data is carried in the first packet and 3-way handshake is eliminated to reduce latencies. In addition acknowledgments, retransmission, and flow control are provided. It allows more than one outstanding transaction at a time. It handles the bearer dependence of a transfer, e.g., selects timeout values and packet sizes according to the bearer. Unfortunately, WTP uses fixed retransmission timers and does not include congestion control, which is a potential problem area as the use of WAP increases [RFC3002].
トランザクション層、WTPは、メッセージ接続確立なしに基づいて解体されます。未確認要求（単一指向性）、信頼性（確認）要求（単一指向性）、および信頼性の高い（確認）要求 - 応答トランザクション：それはトランザクションクラスの3種類をサポートしています。データは、最初のパケットで運ばれ、3ウェイハンドシェイクは、待ち時間を減少させるために除去されます。また肯定応答、再送信、およびフロー制御に設けられています。これは、一度に複数の優秀な取引が可能になります。これは、転送のベアラ依存性を処理、例えば、ベアラに係るタイムアウト値及びパケットサイズを選択します。残念ながら、WTPは、固定された再送タイマーを使用して、WAPが増加[RFC3002]の使用などの潜在的な問題領域である輻輳制御を含みません。
The session layer, WSP, supports binary encoded HTTP 1.1 with some extensions such as long living session with suspend/resume facility and state handling, header caching, and push facility. On top of the architecture is the application environment (WAE).
/再開機能と状態の取り扱い、ヘッダ・キャッシング、およびプッシュ機能が一時停止してセッション層、WSPは、このような長い生活のセッションなど、いくつかの拡張子を持つバイナリエンコードされたHTTP 1.1をサポートしています。アーキテクチャの上にアプリケーション環境（WAE）です。
As indicated in Section 5.2.1, W-WAN networks typically offer very low bandwidth connections with high latency and relatively frequent periods of link disconnection and they usually are expensive to use. Therefore, the transfer volume and extra round-trips, such as those associated with TCP connection setup and teardown, must be reduced and the slow W-WAN link should be efficiently shielded from excess traffic and global (wired) Internet congestion to make Internet access usable and economical. Furthermore, interactive traffic must be transmitted in a timely manner even if there are other simultaneous bandwidth intensive (background) transfers and during the periods with connectivity the link must be kept fully utilized due to expensive use. In addition, the (long) periods of link disconnection must not abort active (bulk data) transfers, if an end-user so desires.
5.2.1項に示すように、W-WANネットワークは、通常、高遅延及びリンク切断の比較的頻繁期間と非常に低い帯域幅接続を提供し、彼らは通常使用するのに費用がかかります。従って、転送量と、そのようなTCP接続のセットアップおよびティアダウンと関連するものなどの余分なラウンドトリップが、低減されなければならないと遅いW-WANリンクが効率的にインターネットアクセスを行うために、過剰なトラフィックとグローバル（有線）インターネット混雑から遮蔽されなければなりません使用可能で経済的。さらに、対話型のトラフィックは、他の同時帯域幅集約型（バックグラウンド）転送がある場合でもタイムリーに送信しなければならないとの接続性を持つ期間中のリンクが原因、高価な使用に十分に活用しておく必要があります。また、リンク切断の（長い）期間は、アクティブ（バルクデータ）転送を中断してはならない場合、エンドユーザ望むので。
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用のサポートは、固定インターネットホスト上で実行少なくともものに、ほとんどのアプリケーションを可能にするように実装する必要がありますその操作はそのまま継続します。
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トランシーバとアクセスポイントが1つのセルを制御するセルラトポロジーに編成されています。セルは、基地局のカバーエリアの点で定義されます。アクセスポイントが直接有線ネットワークに接続されています。各セル内のアクセスポイントは、セル内に位置するホストへとからパケットを転送する責任があります。多くの場合、W-LANトランシーバとホストはモバイルです。別のセルへの1つのセルからの場合、移動ホストが移動し、有線ネットワークと移動ホストとの間でパケットを転送するための責任は、新しいセルのアクセスポイントに転送しなければなりません。これは、ハンドオフとして知られています。多くのW-LANシステムはまた、アドホックネットワーキングを可能にする動作モードをサポートしています。このモードでは、アクセスポイントは、必ずしも必要ではないが、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は通常、1 Mbpsのから11 Mbpsにリンク帯域幅を提供します。将来的には、54 Mbpsまたはさらに高いまでの高帯域幅の広い展開が期待できます。無線LANとの往復遅延時間をミリ秒単位の数ミリ秒または数万のオーダーです。 W-LANの例としては、IEEE 802.11、ホームRF、およびハイパーランが含まれます。例えば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は原因ビットエラー、衝突やリンクの停止にエラーが発生しやすいです。また、連続したパケット損失はまた、ハンドオフ時に発生する可能性があります。ほとんどのW-LAN MACプロトコルは、低レベルの再送を行います。この機能は、ほとんどの損失から上位層を遮蔽します。しかし、避けられない損失は、再送信の待ち時間とリンク停止は、まだ上位層に影響を与えます。 W-LAN上のTCPパフォーマンスやW-LANのリンクを含むネットワークパスがこれらの影響に苦しむ可能性があります。
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の送信者は、その輻輳ウィンドウを減少させ、多くの場合、連敗から回復するためにタイムアウトするように強制されます。その結果、多くの場合、許容できないほど貧しいエンド・ツー・エンドのパフォーマンスです。
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セグメント（モバイルホストに）非対称PEPのそれは（モバイルホストからの）TCPデータとACKチャネル上ならびにアップリンク上で異なる動作として実装し、ダウンリンクです。
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受信機に転送し、対応するACKを監視未確認TCPデータセグメントをキャッシュします。これは、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重複ACKを、パケットロスを識別するために、代わりのTCP送信者がそうするエンド・ツー・エンドのを待つことにより、失われたデータセグメントを再送します。
2. Suppresses the duplicate ACKs on their way from the mobile host back to the sender, thus avoiding fast retransmit and congestion avoidance at the latter.
2.は、このように、後者では高速再送と輻輳回避を避け、送信者にモバイルホストから彼らの方法で重複ACKを抑制します。
Suppressing the duplicate ACKs is required to avoid unnecessary fast retransmits by the TCP sender as the Snoop agent retransmits a packet locally. Consider a system that employs the Snoop agent and a TCP sender S that sends packets to receiver R via a base station BS. Assume that S sends packets A, B, C, D, E (in that order) which are forwarded by BS to the wireless receiver R. Assume the first transmission of packet B is lost due to errors on the wireless link. In this case, R receives packets A, C, D, E and B (in that order). Receipt of packets C, D and E trigger duplicate ACKs. When S receives three duplicate ACKs, it triggers fast retransmit (which results in a retransmission, as well as reduction of the congestion window). The Snoop agent also retransmits B locally, when it receives three duplicate ACKs. The fast retransmit at S occurs despite the local retransmit on the wireless link, degrading throughput. Snoop deals with this problem by dropping TCP duplicate ACKs appropriately at BS.
重複ACKを抑制することはスヌープエージェントはローカルにパケットを再送するようTCPの送信者によって不必要な高速な再送を避けるために必要です。スヌープエージェントと基地局BSを介してRを受信機にパケットを送信するTCP送信者Sを使用するシステムを考えます。 Sは、パケットAを送信すると仮定し、無線受信機RにBSによって転送される（この順序で）B、C、D、Eは、により無線リンク上のエラーのために失われるパケットBの第1の送信を仮定する。この場合、Rは、（この順番で）パケットA、C、D、E及びBを受信します。パケットC、D及びEの受信は重複ACKをトリガします。 S三個の重複ACKを受信すると、これは、高速（再送をもたらすだけでなく、輻輳ウィンドウの減少）再送をトリガします。それは3つの重複ACKを受信したときにスヌープエージェントはまた、ローカルにBを再送します。 Sでの高速再送は、スループットを低下させる、無線リンク上のローカル再送信にもかかわらず発生します。スヌープはBSで適切にTCP重複ACKをドロップすることによって、この問題を扱っています。
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.
モバイルホストからのデータ転送のために、スヌープエージェントは、転送データセグメントを監視することによって、無線リンク上のパケット損失を検出します。次に、このように送信者が通常輻輳制御手順をトリガすることなく再送信することができ、パケット損失が輻輳に関連していなかったことをモバイル送信者に通知するために局所的に否定応答（NAK）または明示的な損失通知（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の送信者に通知するためにNAKを使用する場合、それらを実装するための一つの可能性は、TCPの選択確認応答（SACK）オプションを使用している[RFC2018]。これはモバイルホストでSACK処理を有効にする必要があります。それは、モバイルホストからの送信シーケンスに穴を検出した場合や、スヌープエージェントは、TCPのSACKを送り、それが一定の期間のために、モバイルホストから任意の新しいパケットを受信していないとき。モバイル送信者はSACKで示さ欠落したセグメントを再送することをお勧めしますが、これらのセグメントは、後に失われる可能性がありますように、SACKと認めたセグメントの成功したエンドツーエンドの配信を想定していない必要があります。このアプローチは、袋の顧問性質に依存しています受信機へのパスインチ代わりに、送信者が到着する累積ACKを待たなければなりません。
When the ELN mechanism is used to inform the mobile sender of the packet losses, Snoop uses one of the 'unreserved' bits in the TCP header for ELN [SNOOPELN]. The Snoop agent keeps track of the holes that correspond to segments lost over the wireless link. When a (duplicate) ACK corresponding to a hole in the sequence space arrives from the TCP receiver, the Snoop agent sets the ELN bit on the ACK to indicate that the loss is unrelated to congestion and then forwards the ACK to the TCP sender. When the sender receives a certain number of (duplicate) ACKs with ELN (a configurable variable at the mobile host, e.g., two), it retransmit the missing segment without performing any congestion control measures.
ELN機構は、パケット損失のモバイル送信者に通知するために使用される場合、スヌープはELNのTCPヘッダ内の「予約されていない」ビット[SNOOPELN]の1つを使用します。スヌープエージェントは、無線リンクを介して失われたセグメントに対応する孔を追跡します。配列空間の穴に対応する（重複）ACKは、TCP受信機から到着すると、スヌープエージェントは損失が輻輳とは無関係であることを示すためにACKにELNビットを設定し、TCP送信側にACKを転送します。送信者はELN（モバイルホストの設定変数、例えば、2）とのACK（重複）の特定の数を受信すると、これは、任意の輻輳制御対策を行うことなく、失われたセグメントを再送します。
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ビットのいずれかを使用して、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 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).
そのようなスヌープなどの方式は、無線エラーによる高速再送信の可能性は無視できない場合にのみ必要とされています。無線リンクが失われたデータのためのリンク層の回復を使用している場合は特に、このスキームは有益ではありません。 TCPウィンドウが原因有線ネットワークの輻輳関連の損失に、例えば、4つのセグメントよりも小さい滞在する傾向がある場合も、スヌープエージェントはローカルにする機会があります確率は、失われたパケットが小さい再送します。少なくとも3つの重複ACKがローカル再送をトリガするために必要とされているので、これはですが、小さな窓に起因するスヌープエージェントは、失われたパケットの後つの新しいパケットを転送するため、必要な3つの重複ACKを誘導することができないかもしれません。 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ウィンドウの問題を軽減するために、スヌープは、それがある限り、重複ACKの数は、高速TCPのための閾値未満であるとして受け取るACKを複製TCP送信者がそれぞれの新しいデータセグメントを送信することが許可されている解決策を提案しています再送信（3つの重複ACK）。新しいセグメントが受信機に到達した場合、それは、順番に、送信者は、さらに別のデータセグメントを送信することができ、別の重複ACKを生成します。十分な重複ACKが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.
- スヌーピング基地局で終了した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.)
スヌープは、データとそれに対応するACKの両方が同じ基地局を横切ることを必要とします。それは無線リンクを介して、「トランスポート層で」TCPデータセグメントを再送信するようさらに、スヌープエージェントは、リンク層の努力を複製することができます。 （スヌープはTCP - 認識リンク層としてのデザイナーによって記載されている。これは、適切なアプローチである：リンクとネットワーク層は、厳密な階層化を示唆しているよりも互いのはるかに知ることができます）
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は、エラーが発生しやすい無線チャネルに苦しみます。エラーは通常、バースト性と考えることができ、チャネル条件は、移動性と環境変化から急速に変化することがあります。パケットは、ビットエラーまたはハンドオーバーの際に削除されます。リンク停止の期間も体験することができます。典型的なMACの再送信を行いますが、IPのパフォーマンスに深刻なパフォーマンスへの影響、特にTCPを持つことができ、まだパケット、停止および再送信の待ち時間を落としました。
PEPs can be used to alleviate problems caused by packet losses, protect TCP from link outages, and to add priority multiplexing. Techniques such as Snoop are integrally implemented in access points, while priority and compression schemes are distributed across the W-LAN.
PEPには、パケット損失によって引き起こされる問題を軽減するリンクの停止からTCPを保護し、優先度の多重化を追加するために使用することができます。優先圧縮方式がW-LANに分散されているが、このようなスヌープのような技術が一体、アクセスポイントに実装されています。
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.
性能向上プロキシを使用すると、インパクトのセキュリティいくつかの問題を紹介します。まず、（4.1.1項で詳細に記載されるように、）のPEPを用いて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は（ファイアウォールによって、例えば）保護されなければならないか、単に存在する他のデバイスと同様に、攻撃者によって不正アクセスから自身を保護しなければなりませんネットワークインチ
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が管理し、既存の名前または番号にスペースを変更しない、情報の概要を文書であると。
This document grew out of the Internet-Draft "TCP Performance Enhancing Proxy Terminology", RFC 2757 "Long Thin Networks", and work done in the IETF TCPSAT working group. The authors are indebted to the active members of the PILC working group. In particular, Joe Touch and Mark Allman gave us invaluable feedback on various aspects of the document and Magdolna Gerendai provided us with essential help on the WAP example.
この文書はインターネットドラフト「TCPプロキシ用語のパフォーマンスの向上」、RFC 2757「長く細いネットワーク」、およびIETF TCPSATワーキンググループで行われた作業から生まれました。著者は、PILCワーキンググループのアクティブメンバーにお世話になっています。特に、ジョーTouchとマーク・オールマンは、ドキュメントのさまざまな側面に私たちに貴重なフィードバックを与え、Magdolna GerendaiはWAP例の基本的なヘルプを提供してくれました。
[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、ACMワイヤレスネットワーク、1997年3月には91頁、「無線LAN上のTCPスループットを向上させるために、チャネル状態に依存するパケットスケジューリングの使用」 - で利用可能な102：http://www.acm.org/pubs /記事/雑誌/無線/ 1997年3月1日/ P91-bhagwat / p91- bhagwat.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.バラクリシュナン、V.N. Padmanabhan、R.H.カッツ、 "TCPパフォーマンス上の非対称性の影響、" PROC。 ACM / IEEEモビコム、ブダペスト、ハンガリー、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.
[BW97] G. Brasche、B. Walke、 "概念、新しいGSMフェーズ2+汎用パケット無線サービスのサービス、およびプロトコル、" IEEEコミュニケーションズマガジン、巻。 35、第8号、1997年8月。
[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]電子工業会（EIA）/電気通信工業会（TIA）は、IS-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.リンドクイスト、「無線環境でのWebブラウジング：で切断され、非同期動作ARTourのWeb Express、」PROC。 MobiCom'97、ブダペスト、ハンガリー、1997年9月。
[FMSBMR98] D.C. Feldmeier, A.J. McAuley, J.M. Smith, D.S. Bakin, W.S. Marcus, T.M. Raleigh, "Protocol Boosters," IEEE Journal on Selected Areas of Communication, Vol. 16, No. 3, April 1998.
[FMSBMR98] D.C. Feldmeier、A.J. McAuley氏、J.M.スミス、D。S.馬琴、W.S.マーカス、T.M.ローリー、「プロトコルブースター、」IEEEジャーナルコミュニケーション、巻の選択された領域に。 16、第3号、1998年4月。
[FLASH] Flash Networks Ltd., performance boosting products technology vendor based in Holmdel, New Jersey. Website at http://www.flashnetworks.com.
[FLASH]フラッシュネットワークス株式会社、ホルムデル、ニュージャージー州ベースの製品の技術ベンダーを高めるパフォーマンス。 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システム、サンタクララ、カリフォルニア州に拠点を置く製品の技術ベンダーを高めるパフォーマンス。 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）：サービス説明、ステージ2、" GSM03.60、v.6.1.1、1998年8月。
[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コミュニケーションズマガジン、巻。 31、第4号、頁92-100、1993年4月。
[HNS] Hughes Network Systems, Inc., VSAT technology vendor based in Germantown, Maryland. Website at http://www.hns.com.
[HNS]ヒューズ・ネットワーク・システムズ社、ジャーマンタウン、メリーランド州に拠点を置く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。分散コンピューティングシステムでの第15回国際会議（ICDCS）、1995年5月。
[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.古城、K. Raatikainen、T. Alanko、「デジタルセルラー電話ネットワークを介したインターネットへのモバイルワークステーションの接続、」PROC。モバイルおよびワイヤレス情報システム（MOBIDATA）、ラトガース大学、ニュージャージー州、11月モバイル・コンピューティングに発表された1994年改訂版、頁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.古城、K. Raatikainen、M. Liljeberg、J. Kiiskinen、T. Alanko、 "スロー無線電話リンクのための効率的な輸送サービス、" IEEEジャーナルコミュニケーション、巻の選択された領域に。 15、第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.古城、H. Laamanen、K. Raatikainen、 "弱接続されたモバイルワークステーションのための最適化ワールドワイドウェブ：間接アプローチ、" PROC。第二のIntの。分散型でのサービスやネットワーク環境、ウィスラー、カナダ、頁に関するワークショップ。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. Helin氏、M.古城、K. Raatikainen、：PROC "モーグリWWWソフトウェアモバイルWAN環境では、WWWの使いやすさの向上"。 IEEEグローバルインターネット1996年大会、ロンドン、イギリス、1996年11月。
[M-TCP] K. Brown, S. Singh, "M-TCP: TCP for Mobile Cellular Networks," ACM Computer Communications Review Volume 27(5), 1997. Available at ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz.
[M-TCP] K.ブラウン、S.シン、 "M-TCP：モバイルセルラーネットワークのためのTCP、" ACMコンピュータコミュニケーションレビュー27巻（5）、ftp://ftp.ece.orst.eduの利用可能な1997年/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.パクソン、「エンドツーエンドインターネットパケットダイナミクス、」ネットワーク上のIEEE / ACM取引、巻。図7に示すように、第3号、1999、頁277から292。
[PILCWEB] http://pilc.grc.nasa.gov.
【PILCWEB] http://pilc.grc.nasa.gov。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communications Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - コミュニケーションレイヤー"、STD 3、RFC 1122、1989年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、 "インターネットの建築原則"、RFC 1958、1996年6月。
[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の選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", FYI 30, RFC 2151, June 1997.
"インターネット上のプライマーおよびTCP / IPのツールとユーティリティ" [RFC2151]ケスラー、G.とS.シェパード、FYI 30、RFC 2151、1997年6月。
[RFC2246] Dierk, T. and E. Allen, "TLS Protocol Version 1," RFC 2246, January 1999.
[RFC2246] Dierk、T.およびE.アレン、 "TLSプロトコルバージョン1、" RFC 2246、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）"、RFC 2393、1998年12月。
[RFC2401] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.、およびR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、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.サンチェス、BCP 28、RFC 2488、1999年1月、 "標準的なメカニズムを使用して強化TCP上の衛星テレビ"。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B.とS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S.とV. Jacobson氏、 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"、RFC 2508、1999年2月。
[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[RFC2509] Engan、M.、Casner、S.とC.ボルマン、 "PPP上のIPヘッダー圧縮"、RFC 2509、1999年2月。
[RFC2663] Srisuresh, P. and Y. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.およびY.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson, T., Heidemann, J., Kruse, H., Ostermann, S., Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
[RFC2760]オールマン、M.、ドーキンス、S.、グローバー、D.、Griner、J.、ヘンダーソン、T.、Heidemann、J.、クルーズ、H.、Ostermann、S.、スコット、K.、Semke、 J.、タッチ、J.とD.トラン、 "継続的なTCPの研究衛星に関連する"、RFC 2760、2000年2月。
[RFC3002] Mitzel, D., "Overview of 2000 IAB Wireless Internetworking Workshop", RFC 3002, December 2000.
[RFC3002] Mitzel、D.、 "2000 IABワイヤレスインターネットワーキングワークショップの概要"、RFC 3002、2000年12月。
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]オールマン、M.、バラクリシュナン、H.とS.フロイド、 "株式会社トランスミットを使用したTCPの損失回復の強化"、RFC 3042、2001年1月。
[SHEL00] Z. Shelby, T. Saarinen, P. Mahonen, D. Melpignano, A. Marshall, L. Munoz, "Wireless IPv6 Networks - WINE," IST Mobile Summit, Ireland, October 2000.
[SHEL00] Z.シェルビー、T.サーリネン、P. Mahonen、D.メルピニャーノ、マーシャル、L.ムニョス、 "ワイヤレスネットワークのIPv6 - WINE、" 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.
[SNOOP] H.バラクリシュナン、S. Seshan、E.アミール、R.カッツ、PROC "無線ネットワーク上でTCP / IPのパフォーマンスを改善"。第一ACMモバイル通信とネットワークに関する国際会議（モビコム）、バークレー、カリフォルニア州、1995年11月。
[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.バラクリシュナン、R.カッツ、 "明示的な喪失通知とワイヤレスWebパフォーマンス、" PROC。 1998年、インターネットミニ会議、シドニー、オーストラリア、1998年11月GLOBECOM IEEE。
[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、巻。 2、第4号、頁277-288、1984年11月。
[WAPARCH] Wireless Application Protocol Architecture Specification, April 1998, http://www.wapforum.org.
[WAPARCH]ワイヤレスアプリケーションプロトコルアーキテクチャ仕様、1998年4月、http://www.wapforum.org。
[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。 http://www.wins.hrl.com/people/ygz/papers/usenix00.htmlの利用可能な第9回USENIXセキュリティシンポジウム、デンバー、コロラド州、2000年8月の議事録。
Questions about this document may be directed to:
このドキュメントに関するご質問は、対象とすることができます。
John Border Hughes Network Systems 11717 Exploration Lane Germantown, Maryland 20876
ジョン・ボーダー・ヒューズネットワークシステムズ11717探査レーンジャーマンタウン、メリーランド州20876
Phone: +1-301-548-6819 Fax: +1-301-548-1196 EMail: border@hns.com
電話：+ 1-301-548-6819ファックス：+ 1-301-548-1196 Eメール：border@hns.com
Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
コンピュータサイエンス、ヘルシンキ大学、私書箱のマルック古城部門ボックス26（Teollisuuskatu 23）FIN-00014ヘルシンキ、フィンランド
Phone: +358-9-1914-4179 Fax: +358-9-1914-4441 EMail: kojo@cs.helsinki.fi
電話：+ 358-9-1914-4179ファックス：+ 358-9-1914-4441 Eメール：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ブルックパークロードクリーブランド、オハイオ州44135-3191
Phone: +1-216-433-5787 Fax: +1-216-433-8705 EMail: jgriner@grc.nasa.gov
電話：+ 1-216-433-5787ファックス：+ 1-216-433-8705 Eメール：jgriner@grc.nasa.gov
Gabriel Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan, FRANCE
ガブリエルモンテネグロSun Microsystemsの研究所、欧州29、CHEMINドゥヴューシュヌ38240メラン、フランス
Phone: +33 476 18 80 45 EMail: gab@sun.com
電話：+33 476 18 80 45 Eメール：gab@sun.com
Zach Shelby University of Oulu Center for Wireless Communications PO Box 4500 FIN-90014 Finland
無線通信のためのオウルセンターのザックシェルビー大学私書箱4500 FIN-90014フィンランド
Phone: +358-40-779-6297 EMail: zach.shelby@ee.oulu.fi
電話：+ 358-40-779-6297 Eメール：zach.shelby@ee.oulu.fi
Appendix A - PEP Terminology Summary
付録A - PEP用語の概要
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.)
この付録では、頻繁にパフォーマンス強化プロキシの議論の際に使用される用語の概要を示します。 （いくつかの場合において、これらの用語は、それらの非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データのバースト性を最小限に抑えるために、例えば、適切な空間に順番に確認応答の転送を遅らせました。 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.
パフォーマンス強化プロキシは、トランスポート層以上で動作します。アプリケーションまたはトランスポートプロトコルのパフォーマンス（あるいはその両方）を改善することを目的とすることができます。 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).
（データセグメントのために使用される）、順方向チャネル及びバック（またはリターン）（ACKのために使用される）チャネルのために異なるレートを有しているリンク。
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:
コンテキストに応じて、PEPはに関していくつかの意味があります：
- An access point to a particular link;
- 特定のリンクへのアクセスポイント。
- A device capable of initiating and terminating connections on
- 上の接続を開始し、終了することができる装置
behalf of a user or end system (e.g., a firewall or proxy).
ユーザまたはエンドシステム（例えば、ファイアウォールまたはプロキシ）の代わり。
Not necessarily, but could be, a router.
必ずしもそうではありません、しかし、ルータである可能性があります。
in flight (data)
飛行中の（データ）
Data sent but not yet acknowledged. More precisely, data sent for which the sender has not yet received the acknowledgement.
データが送信されたが、まだ確認されません。より正確には、送信されたデータは、送信者がまだ確認応答を受信していないいます。
link layer PEP
リンク層PEP
A Performance Enhancing Proxy operating below the network layer.
ネットワーク層以下で動作する性能向上プロキシ。
local acknowledgement
ローカル確認応答
The generation of acknowledgments by an entity in the path between two end systems in order to allow the sending system to transmit more data without waiting for end-to-end acknowledgments. Described (in the context of TCP) in Section 3.1.2.
送信システムは、エンドツーエンドの肯定応答を待つことなく、より多くのデータを送信することを可能にするために、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項で詳しく説明し、[スヌープ]。
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のPEP
A Performance Enhancing Proxy operating at the transport layer with TCP. Aimed at improving TCP performance.
TCPをトランスポート層で動作する性能向上プロキシ。 TCPのパフォーマンスの改善を目的としました。
TCP splitting
TCP分割
Using one or more split TCP connections to improve TCP performance.
TCPのパフォーマンスを改善するために、1つのまたは複数の分割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.
トランスポート層で動作する性能向上プロキシ。 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.
PEPの文脈では、トンネリングは、二つのPEP間の特定のリンクを介して送信するためのパケットをラップするプロセスを指します。 3.2節を参照してください。
WAP
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.
ワイヤレス・アプリケーション・プロトコルは、狭帯域無線ネットワーク技術の違いを越えて動作することを意図したアプリケーションフレームワークとネットワークプロトコルを指定します。 5.2.2.2項を参照してください。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。