[要約] RFC 3135は、リンク関連の劣化を軽減するための性能向上プロキシに関するものであり、その目的はネットワークのパフォーマンスを向上させることです。
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.
Copyright（c）The Internet Society（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）パフォーマンス緩和手法の調査です。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は、同様のパフォーマンス向上を提供するエンドツーエンドのメカニズムが利用できない特定の環境と状況でのみ使用する必要があるため、PEPは使用する必要があります。。パフォーマンスの改善のためにPEPを使用することを検討する任意の環境では、エンドユーザー（または場合によっては責任あるネットワーク管理者）がPEPを認識し、PEP機能を採用する選択は終了の制御下にある必要があります。ユーザーは、特にPEPを採用すると、IPレイヤーセキュリティメカニズムのエンドツーエンドの使用が妨害されるか、状況によっては望ましくない意味があります。これにより、ユーザーは常にエンドツーエンドのIPを選択できますが、もちろん、PEPを使用することが生成される可能性のあるパフォーマンスの向上はありません。
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の使用に関して、または反対の推奨事項はありません。個々のリンク特性、たとえば高いエラーレートとのリンク、低帯域幅のリンク、非対称帯域幅のリンクなど、個々のリンク特性について、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を使用することに関する意味のいくつかについて説明します。最後に、セクション5では、PEPが使用されるいくつかの例について説明します。衛星非常に小さな開口端子（VSAT）環境、モバイルワイヤレスWAN（W-WAN）環境、ワイヤレスLAN（W-LAN）環境について説明します。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コンポーネント、または分散したもので構成されます。つまり、通常、複数のノードで実装される2つ以上の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の方向の観点から定義できます。しばしばTCP ACKチャネルと呼ばれる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は、大量の帯域幅を使用してトラフィックを転送します。。同時に、リンクの最後の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は、2つのエンドシステム間のTCP機能の不一致に対処するために、スプリット接続実装を使用しています。たとえば、TCPウィンドウスケーリングオプション[RFC1323]を使用して、「飛行中」（つまり、承認を待って待っている）になる可能性のあるTCPデータの最大量を拡張できます。これは、帯域幅の高い*遅延製品を持つリンクを入力するのに役立ちます。一方のエンドシステムがスケーリングされたTCPウィンドウを使用できるが、もう一方のシステムがそうでない場合、能力がないエンドシステムは、高帯域幅*遅延リンクの側面にあるPEPとの接続を設定できます。次に、Split Connection 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.
Split Connection 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 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.
分割接続の使用は、必ずしもエンドツーエンドの接続にIPの同時使用を除外しないことに注意してください。アプリケーションまたは接続ごとに分割接続が管理され、エンドユーザーの制御下にある場合、ユーザーは特定の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ベースのアプリケーションのアプリケーション層プロキシは、特定のアプリケーションに関連するサービスとしてPEPSを使用して、ENDシステムを備えた分割接続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のもう1つの重要な特徴は、透明度の程度です。PEPSは、エンドシステム、接続中に）エンドシステム、輸送エンドポイント、および/またはアプリケーションに完全に透過的に動作し、最終システム、輸送エンドポイント、またはアプリケーションを変更する必要はありません。
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の実装では、関係する端の1つのみを変更する必要がある場合があります。これらの種類の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接続のエンドツーエンドセマンティクスが維持されますが、分割接続TCP PEP実装はそうでない場合があります。しかし、両方とも両端の輸送エンドポイントに透過的に実装できます。エンドツーエンドのセマンティクス、特に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 PEPS送信エンドシステムへのローカル謝辞の送信は、受信エンドシステムに向けてローカルの再送信を使用するために必要です。
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.)
一部のPEP実装は、TCP接続のパフォーマンスを変更するためにローカル承認を使用していない場合でも、ローカルの再送信を実行します。Basic Snoop [Snoop]は、このようなPEP実装のよく知っている例です。Snoop Caches TCPデータセグメント受信および転送のセグメントは、レシーブのTCPエンドシステムからのエンドツーエンドの謝辞（Dupacks）の受信TCPエンドシステムからの監視を監視します。Dupacksを受信すると、SnoopはLost TCPデータセグメントをキャッシュから地元で再送信し、新しいデータの確認が受信されるまで送信TCPエンドシステムに流れるデュパックを抑制します。Snoopシステムは、ローカル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を再構築することにより、これに対処します。非常に非対称リンクを使用したTCP ACKの混雑を扱うメカニズムと問題については、[RFC2760]および[BPK97]で詳しく説明しています。
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は、受信エンドシステムへの最終配信の前にトンネルラッパーを除去します。分散されたPEPS間の接続を運ぶ手段として、分散型スプリット接続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実装には、1つ以上の形式の圧縮のサポートが含まれています。一部の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ペイロード（例：画像、オーディオ、ビデオ、「Zipped」ファイルが転送されている）はすでに圧縮されています。また、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].
アプリケーションレイヤーPEPSを使用すると、アプリケーション固有の圧縮を使用できます。通常、アプリケーション固有の（またはコンテンツ固有の）圧縮メカニズムは、一般的な圧縮メカニズムよりもはるかに効率的です。たとえば、分散された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送信者から来るトラフィックを監視する場合があります。TCP PEPは最後のACKを保持しているため、ウィンドウをゼロに設定して最後のACKを送信することにより、TCP送信者のウィンドウをシャットダウンできます。したがって、TCP送信者は永続モードになります。
To make this work in both directions with an integrated TCP PEP implementation, the TCP receiver behind the disconnected link must be aware of the current state of the connection and, in the event of a disconnection, it must be capable of freezing all timers. [M-TCP] implements such operation. Another possibility is that the disconnected link is surrounded by a distributed PEP pair.
統合されたTCP PEP実装でこの作業を両方向にするには、切断されたリンクの背後にあるTCPレシーバーは、接続の現在の状態を認識し、切断された場合、すべてのタイマーを凍結することができなければなりません。[M-TCP]はそのような操作を実装します。別の可能性は、切断されたリンクが分散したPEPペアに囲まれていることです。
In split connection TCP implementations, a period of link disconnection can easily be hidden from the end host on the other side of the PEP thus precluding the TCP connection from breaking even if the period of link disconnection lasts a very long time; if the TCP PEP cannot forward data due to link disconnection, it stops receiving data. Normal TCP flow control then prevents the TCP sender from sending more than the TCP advertised window allowed by the PEP. Consequently, the PEP and its counterpart behind the disconnected link can employ a modified TCP version which retains the state and all unacknowledged data segments across the period of disconnection and then performs local recovery as the link is reconnected. The period of link disconnection may or may not be hidden from the application and user, depending upon what application the user is using the TCP connection for.
Split Connection TCP実装では、PEPの反対側のエンドホストからリンク切断の期間を簡単に隠すことができます。そのため、リンクの切断期間が非常に長く続く場合でも、TCP接続が破壊されないようになります。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がフローのデータを転送していない場合、PEPが決定するとそれを再開する場合、通常のTCPフロー制御がTCP送信者とPEPの間のフローを一時停止するため、遅延のTCPフローにマイナスの影響を与えません。フローのデータの転送を続けます。Slow Linkの両側にあるプロトコルが接続の優先順位ベースのスケジューリングを実装する場合、これはさらに支援できます。
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実装により、ユーザーが制御する優先順位とともに、ユーザーは選択したインタラクティブ接続に対してより高い優先度を割り当て、選択した接続の応答時間がはるかに短くなります。それ以外の場合、通常のエンドツーエンド操作では、スローリンクの利用可能な帯域幅をほぼ完全に食べます。これらの低優先度のバルクデータ転送は、インタラクティブな接続のアイドル期間中にうまく進み、ユーザーはゆっくりと高価なリンク（ワイヤレス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.
他の優先順位ベースのメカニズムは、2つ以上の端子を持つ共有ワイヤレスリンクに適用できます。共有ワイヤレスメディアがインターネットQoSアーキテクチャの弱いリンクになっているため、多くの人がPEPSに目を向けると、共有ワイヤレス媒体[SHEL00]で追加の優先度レベルを提供する場合があります。これらのPEPは、共有ワイヤレスメディアのすべてのノードに分布しています。たとえば、802.11 WLANでは、このPEPはアクセスポイント（ベースステーション）と各モバイルホストに実装されています。その後、1つの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]は、インターネットの建築原理の1つです。 基本的な議論は、第一原則として、特定の必要なエンドツーエンド関数は、最終システム自体によってのみ正しく実行できるということです。 PEPの使用に関連する潜在的な負の意味のほとんどは、接続のエンドツーエンドのセマンティクスを破壊する可能性に関連しています。 これは、一般的な使用にPEPが推奨されない主な理由の1つです。
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のエンドツーエンドの使用を無効にすることです。一般に、ユーザーまたはネットワーク管理者は、PEPSの使用とIPSECの使用を選択する必要があります。IPSECがエンドツーエンドで採用されている場合、ネットワーク内の中間ノードに実装されているPEPSは、IPSECのESPヘッダーを介したIPパケットの暗号化（輸送またはトンネルモードのいずれか）を介したIPパケットの暗号化がTCPをレンダリングするため、IPパケットのトランスポートまたはアプリケーションヘッダーを調べることができません。ペップに理解できないヘッダーとペイロード。トランスポートまたはアプリケーションのヘッダーを調べることができなくても、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で露出します。）そして、最終システムによって潜在的に誤解を招くセキュリティレベルの仮定につながる可能性があります。2つのエンドシステムが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実装を認識していません。これは、終了ホストにPEPが実装されている場合を除き、エンドツーエンドのIPSECをサポートしています。
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とPEPSを共存できるようにするために、いくつかの手順があります。エンドユーザーが他のトラフィックではなく、一部のトラフィックにIPSECの使用を選択できる場合、IPSECなしで送信されるトラフィックにPEP処理を適用できます。もちろん、ユーザーはこのトラフィックに対してセキュリティなしで行うか、他の手段を介してトラフィックのセキュリティを提供する必要があります（たとえば、輸送層のセキュリティを使用して）。ただし、これが可能な場合でも、エンドシステムの構成に大きな複雑さを追加する必要がある場合があります。
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).
もう1つの選択肢は、分散されたPEP実装の2つのPEPの間にIPSECを実装することです。これにより、少なくとも2つのペップ間のトラフィックが保護されます。（PEPSを信頼するという問題は変わりません。）PEP実装がユーザーに対して透明ではない場合（ユーザーがPEPを信頼すると仮定すると）、ユーザーは最終システムを設定してPEPをエンドとして使用できます。IPSECトンネルのポイント。また、パスのこの部分のトラフィックを保護するために、エンドシステムとPEPの間でIPSECトンネルを使用することさえできます。しかし、これらはすべて複雑さを追加します。そして、1つのIPSECトンネルからトラフィックが受信され、処理されてから転送されたため（別の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).
IPSECの実装をPEPの使用により親しみやすくする可能性を調査する研究が進行中です。積極的に検討されているアプローチの1つは、多層IPセキュリティの使用です。[Zhang00]は、TCPヘッダーを1つのレイヤーとして暗号化できるようにする方法を説明しています（TCPヘッダーの暗号化に使用されるセキュリティアソシエーションに含まれるTCP接続のパスにPEPが含まれています）。別のレイヤーとして。これには依然として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.
エンドツーエンドの議論のもう1つの重要な側面は、運命共有です。ネットワークで障害が発生した場合、障害に耐える接続の能力は、ネットワーク内の接続に代わって維持されている状態の量と、状態が自己治癒しているかどうかに依存します。ネットワークに特定の状態が存在しない場合、またはそのような状態が通常のエンドツーエンド操作の場合のように自己修復である場合、ネットワークの障害は、ネットワークを通る代替パスがない場合にのみ接続を破壊します。エンドシステム。また、パスがない場合、両方のエンドシステムがこれを検出できます。ただし、接続がネットワークに保存されている状態（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を含む中間ノードの障害は、いずれにしても接続の終了になります。そして、そうでない場合でも、通常のエンドツーエンドの操作の場合に接続を失うリスクが存在する可能性があります。-dhop end Hostへのワイヤレスリンク。したがって、ユーザーは、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.
エンドツーエンドの引数のもう1つの側面は、データの信頼できるエンドツーエンドの配信を達成するために、データのエンドツーエンドの受信を認めることです。信頼できるエンドツーエンドの配信を目指しているアプリケーションは、アプリケーションレベルでエンドツーエンドのチェックと回復を実装する必要があります。エンドツーエンドの議論によれば、これは信頼できるエンドツーエンド操作を正しく実装する唯一の可能性です。それ以外の場合、アプリケーションはエンドツーエンドの引数に違反します。これはまた、正しく設計されたアプリケーションが、信頼できるエンドツーエンド配信を提供するために、輸送層（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 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による）データ腐敗[PAX99]を引き起こし、データ腐敗のアプリケーションレベルチェックを要求します。第三に、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はデータを早期に認めません。つまり、PEPは、受信機からアプリケーションACKを受信するまで、アプリケーション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は、宛先SMTPサーバーにメールメッセージを配信するために「全責任」を取ります（おそらく別のリレーMTA経由）。比較的長い間メッセージを転送しようとします（通常は5日ほど）。このスキームは、電子メール配信の100％の保証を提供しませんが、信頼性は「十分に良い」と見なされます。
An application layer PEP for this kind of an application may acknowledge application data (e.g., mail message) without essentially decreasing reliability, as long as the PEP operates according to the same procedure as the regular proxy (e.g., relay MTA). Again, as indicated above, the user and/or network administrator employing such a PEP needs to understand how it operates in order to understand the reliability risks associated with doing so.
この種のアプリケーションのアプリケーションレイヤーPEPは、通常のプロキシ（リレーMTAなど）と同じ手順に従ってPEPが動作する限り、信頼性を本質的に低下させることなく、アプリケーションデータ（たとえば、メールメッセージなど）を確認できます。繰り返しますが、上記のように、そのようなPEPを採用しているユーザーおよび/またはネットワーク管理者は、そうすることに関連する信頼性のリスクを理解するために、それがどのように動作するかを理解する必要があります。
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.
エンドツーエンドの議論のもう1つの側面は、問題が発生したときにエンドツーエンドの故障診断をサポートする能力です。接続を破るネットワークの問題が発生した場合、接続のエンドポイントはタイムアウトを介して障害を検出します。ただし、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はTCPの代わりにICMPに基づいているため（つまり、ネットワークレイヤーでICMPエコーとReplyコマンドを使用して実装されています）、ネットワークの構成がPEPの周りにトラフィックをPingでルーティングする可能性があります。したがって、Pingは、TCPトラフィックに実際に存在しない場合、2つのホストの間にエンドツーエンドのパスが存在することを示している可能性があります。pingトラフィックがPEPを通過する場合でも、pingトラフィックによって提供される診断指示が変更されます。たとえば、pingトラフィックがPEPを介して透過的に進む場合、pingはPEPが存在することを示すものではなく、pingトラフィックはTCPトラフィックと同じ処理にさらされていないため、必ずしも正確な兆候を提供するとは限りません。TCPトラフィックが経験するネットワーク遅延。一方、PEPがPINGを終了し、エンドホストに代わって応答する場合、PINGはPEPへの接続に関する情報のみを提供します。Traceroute（[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は、トラフィックフローの1つの方向（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ベースステーションは通常、モバイルホストにWirelineインターネットへの接続ポイントを提供しません。（W-WANベースステーションはIPスタックさえ持っていない場合があります。）代わりに、W-WANネットワークは、モバイルホストが移動している間は変更されていないWirelineインターネットへの接続ポイントでモビリティを処理します。したがって、ホストが移動するとき、ほとんどのW-WANネットワークでは現在、PEP状態のハンドオーバーは必要ありません。ただし、これは一般に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にはルーターよりもパケットごとの処理能力が必要です。したがって、ペップは、サポートできる合計スループットの観点から、常に（少なくとも）ルーターに1つのステップになります。（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データネットワークは、通常、STARトポロジを使用して実装されます。大きなハブアースステーションは、ネットワークのリモートサイトでVSATが使用されている星の中央にあります。データは、ハブからアウトレウトを介してリモートサイトに送信されます。データは、1つ以上のインラウトを介してリモートサイトからハブに送信されます。VSATは、非常に非対称リンクを持つ環境を表し、通常、アウトラウトはインラートよりもはるかに大きいです。（それぞれのアウトトゥーで複数のインラウトを使用できますが、特定のVSATは一度に単一のインルートにのみアクセスできるため、リンクを非対称にします。）
VSAT networks are generally used to implement private networks (i.e., intranets) for enterprises (e.g., corporations) with geographically dispersed sites. VSAT networks are rarely, if ever, used to implement Internet connectivity except at the edge of the Internet (i.e., as the last hop). Connection to the Internet for the VSAT network is usually implemented at the VSAT network hub site using appropriate firewall and (when necessary) NAT [RFC2663] devices.
VSATネットワークは、一般に、地理的に分散したサイトを持つ企業（例：企業）向けのプライベートネットワーク（つまり、イントラネット）を実装するために使用されます。VSATネットワークは、インターネットの端（つまり、最後のホップとして）を除き、インターネット接続の実装に使用することはめったにありません。VSATネットワークのインターネットへの接続は、通常、適切なファイアウォールと（必要に応じて）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ネットワークは、毎秒数キロビットから1秒あたりの複数のメガビットまでの範囲の容量をサポートできます。比較的長い往復時間と組み合わせると、TCPは衛星リンクを完全に活用するために、「飛行中」の多数のパケットを保持する必要があります。
Asymmetric capacity
非対称容量
As indicated above, the outroute of a VSAT network is usually significantly larger than an inroute. Even though multiple inroutes can be used within a network, a given VSAT can only access one inroute at a time. Therefore, the incoming (outroute) and outgoing (inroute) capacity for a VSAT is often very asymmetric. As outroute capacity has increased in recent years, ratios of 400 to 1 or greater are becoming more and more common. With a TCP maximum segment size of 1460 bytes and delayed acknowledgments [RFC1122] in use, the ratio of IP packet bytes for data to IP packet bytes for ACKs is only (3000 to 40) 75 to 1.
上記のように、VSATネットワークのアウトラウトは通常、インラートよりも大幅に大きいです。ネットワーク内で複数のインラウトを使用できますが、特定のVSATは一度に1つのインルートのみにアクセスできます。したがって、VSATの受信（アウトラウト）および発信（インラート）容量は、しばしば非常に非対称です。近年、アウトルート容量が増加しているため、400対1以上の比率はますます一般的になりつつあります。TCPの最大セグメントサイズは1460バイトで、ACKのIPパケットバイトに対するデータのIPパケットバイトの比率は、（3000〜40）75から1です。
Thus, inroute capacity for carrying ACKs can have a significant impact on TCP performance. (The issue of asymmetric link impact on TCP performance is described in more detail in [BPK97].)
したがって、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.
VSATネットワーク向けに実装されたパフォーマンス向上プロキシは、一般にスループットの改善に焦点を当てています（FTPやHTTP Webページの検索などのアプリケーションの場合）。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]とventuri [folelle]は、そのような製品の例です。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;
- 衛星リンクで使用されるプロトコル。いくつかの実装は、TCPの変更されたバージョンを使用しますが、他のものはUDPの上で実行されている独自のプロトコルを使用します。
- The type of compression used. Third party VSAT network PEP implementations generally focus on application (e.g., HTTP) specific compression algorithms while PEP implementations integrated into the VSAT network generally focus on link specific compression.
- 使用される圧縮のタイプ。サードパーティのVSATネットワークPEP実装は、一般にアプリケーション（例：HTTP）特定の圧縮アルゴリズムに焦点を当て、VSATネットワークに統合されたPEP実装は一般にリンク固有の圧縮に焦点を当てています。
PEP implementations integrated into a VSAT product are generally transparent to the end systems. Third party PEP implementations used with VSAT networks usually require configuration changes in the remote site end systems to route TCP packets to the remote site proxies but do not require changes to the hub site end systems. In some cases, the PEP implementation is actually integrated transparently into the end system node itself, using a "bump in the stack" approach. In all cases, the use of a PEP is non-transparent to the user, i.e., the user is aware when a PEP implementation is being used to boost performance.
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の顧客は予想され、実際には、IPベースのトラフィック、特にTCPトラフィックのパフォーマンスを改善するための同様の手法の使用を要求しました。
As indicated in Section 5.1, VSAT networks are primarily used to implement intranets with Internet connectivity limited to and closely controlled at the hub site of the VSAT network. Therefore, VSAT customers are not as affected (or at least perceive that they are not as affected) by the Internet related implications of using PEPs as are other technologies. Instead, what is more important to VSAT customers is the optimization of the network. And, VSAT customers, in general, prefer that the optimization of the network be done by the network itself rather than by implementing changes (such as enabling the TCP scaled window option) to their own equipment. VSAT customers prefer to optimize their end system configuration for local communications related to their local mission critical functions and let the VSAT network hide the presence of the satellite link as much as possible. VSAT network vendors have also been able to use PEP functionality to provide value added "services" to their customers such as extending the useful of life of older equipment which includes older, "non-modern" TCP stacks.
セクション5.1で示されているように、VSATネットワークは主に、VSATネットワークのハブサイトに限定され、密接に制御されているインターネット接続を備えたイントラネットを実装するために使用されます。したがって、VSATの顧客は、他のテクノロジーと同じようにPEPを使用することのインターネット関連の意味合いによって影響を受けていない（または少なくとも影響を受けていないことを認識していない）。代わりに、VSATの顧客にとってより重要なのは、ネットワークの最適化です。また、VSATの顧客は、一般に、ネットワークの最適化は、変更（TCPスケーリングされたウィンドウオプションを有効にするなど）を独自の機器に実装するのではなく、ネットワーク自体によって行われることを好みます。VSATの顧客は、ローカルミッションクリティカル機能に関連するローカル通信用のエンドシステム構成を最適化し、VSATネットワークが衛星リンクの存在を可能な限り隠すことを好みます。VSATネットワークベンダーは、PEP機能を使用して、古い、非近代的なTCPスタックを含む古い機器の有用な寿命を拡大するなど、顧客に付加価値のある「サービス」を提供することもできました。
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ネットワークにとってより重要になり始めます。たとえば、12年前のセキュリティは、VSATトラフィックを傍受できることに関連する機器のコストが比較的高かったため、大きな懸念事項ではありませんでした。現在、テクノロジーが進歩しているため、コストはそれほど禁止されていません。したがって、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
- 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)
- （re）リンク接続の設定には長い時間がかかる場合があります（数秒または数分）
- the W-WAN network typically takes care of terminal mobility: the connection point to the Internet is retained while the user moves with the mobile host
- W-WANネットワークは通常、ターミナルのモビリティを処理します。ユーザーがモバイルホストで移動する間、インターネットへの接続ポイントが保持されます
- the use of most W-WAN links is expensive. Many of the service providers apply time-based charging.
- ほとんどのW-WANリンクの使用は高価です。サービスプロバイダーの多くは、時間ベースの充電を適用します。
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.
Mowgliシステム[KRA94]は、低帯域幅W-WANリンクの問題のある特性によって引き起こされる課題に対処するための初期のアプローチの1つです。
The indirect approach used in Mowgli is not limited to a single layer as in many other split connection approaches, but it involves all protocol layers. The basic architecture is based on split TCP (UDP is also supported) together with full support for application layer proxies with a distributed PEP approach. An application layer proxy pair may be added between a client and server, the agent (local proxy) on a mobile host and the proxy on an intermediate node that provides the mobile host with the connection to the wireline Internet. Such a pair may be either explicit or fully transparent to the applications, but it is, at all times, under end-user control thus allowing the user to select the traffic that traverses through the PEP implementation and choose end-to-end IP for other traffic.
Mowgliで使用される間接的なアプローチは、他の多くのスプリット接続アプローチのように単一層に限定されませんが、すべてのプロトコル層が含まれます。基本的なアーキテクチャは、分散したPEPアプローチを備えたアプリケーションレイヤープロキシの完全なサポートとともに、分割TCP（UDPもサポートされています）に基づいています。クライアントとサーバーの間にアプリケーションレイヤープロキシペア、モバイルホストのエージェント（ローカルプロキシ）、およびモバイルホストにWirelineインターネットへの接続を提供する中間ノードのプロキシ間に追加できます。このようなペアは、アプリケーションに対して明示的または完全に透過的である可能性がありますが、常にエンドユーザー制御下であるため、ユーザーはPEP実装を介して通過するトラフィックを選択し、エンドツーエンドIPを選択できます。その他のトラフィック。
In order to allow running legacy applications unmodified and without recompilation, the socket layer implementation on the mobile host is slightly modified to connect the applications, which are configured to traverse through the PEP, to a local agent while retaining the original TCP/IP socket semantics. Two types of application layer agent-proxy pairs can be configured for mobile host application use.
レガシーアプリケーションを変更して再コンパイルなしで実行できるようにするために、モバイルホストのソケットレイヤーの実装は、元のTCP/IPソケットセマンティクスを保持しながら、PEPを介してトラバースするように構成されたアプリケーションをローカルエージェントに接続するようにわずかに変更されています。。2種類のアプリケーション層エージェント - プロキシペアをモバイルホストアプリケーションで使用するために構成できます。
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].
一般的なペアは任意のアプリケーションで使用でき、圧縮などのオプションの一般的な拡張機能を備えたスプリットトランスポートサービスを提供するだけです。アプリケーション固有のペアは、同じ種類の拡張機能をレバレッジすることができるアプリケーションまたはアプリケーションのグループに対して販売できます。アプリケーション固有のプロキシペアで達成される機能強化の良い例は、主に転送量とワイヤレスリンクを介した往復数を減らすことにより、Webブラウジングのユーザーの知覚される応答時間を大幅に改善するMowGli WWWシステムです[Laklrr95]、[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.
Mowgliは、最終ホップリンクのTCP/IPコアプロトコルを、低帯域幅W-WANリンク[krlka97]に合わせて調整されたカスタムプロトコルに置き換えるオプションも提供します。このプロトコルは、通常のTCPやUDPが提供するのと同様のセマンティクスを備えた同じ輸送サービスを提供するように設計されていますが、現在のTCP/IPパケット形式またはプロトコル操作によって制約されることなく、適切なプロトコルメカニズムを自由に適用できる別のプロトコル実装を使用します。このプロトコルは、単一の論理リンクのみを操作するために必要であるため、リンク、ネットワーク、および輸送層のプロトコル制御情報とプロトコル操作を部分的に組み合わせることができます。さらに、プロトコルは、さまざまなリンクサービスの上、たとえば異なるRAWリンクサービスの上、PPPの上、IPの上、またはリンクサービスとしてそれを使用して単一のTCP接続の上に動作することができます。その上に「TCP多重化」を実装します。他のすべてのケースでは、プロトコルがRAW（ワイヤレス）リンクサービスの上で動作するように構成されている場合を除き、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.
必要に応じて、通常のTCP/IPトランスポートは、おそらくW-WANリンクにより適したTCP（およびUDP）で対応するプロトコル変更により、最終ホップリンクで使用できます。
The Mowgli system was designed to support mobile hosts that are attached to the Internet over constrained links, but did not address the specific challenges with low-end mobile devices. Many mobile wireless devices are power, memory, and processing constrained, and the communication links to these devices have lower bandwidth and less stable connections. These limitations led designers to develop the Wireless Application Protocol (WAP) that specifies an application framework and network protocols intended to work across differing narrowband wireless network technologies bringing Internet content and advanced data services to low-end digital cellular phones and other mobile wireless terminals, such as pagers and PDAs.
MowGliシステムは、制約されたリンクを介してインターネットに接続されているモバイルホストをサポートするように設計されていますが、ローエンドモバイルデバイスでの特定の課題に対処しませんでした。多くのモバイルワイヤレスデバイスは電源、メモリ、および処理が制約されており、これらのデバイスへの通信リンクは帯域幅が低く、安定した接続が低くなります。これらの制限により、設計者は、インターネットコンテンツと高度なデータサービスをローエンドのデジタルセルラー電話やその他のモバイルワイヤレスターミナルにもたらす異なる狭帯域ワイヤレスネットワークテクノロジーで動作することを目的としたアプリケーションフレームワークとネットワークプロトコルを指定するワイヤレスアプリケーションプロトコル（WAP）を開発するようになりました。ポケットベルやPDAなど。
The WAP model consists of a WAP client (mobile terminal), a WAP proxy, and an origin server. It requires a WAP proxy between the WAP client and the server on the Internet. WAP uses a layered, scalable architecture [WAPARCH], specifying the following five protocol layers to be used between the terminal and the proxy: Application Layer (WAE) [WAPWAE], Session Layer (WSP) [WAPWSP], Transaction Layer (WTP) [WAPWTP], Security Layer (WTLS) [WAPWTLS], and Transport Layer (WDP) [WAPWDP]. Standard Internet protocols are used between the proxy and the origin server. If the origin server includes WAP proxy functionality, it is called a WAP Server.
WAPモデルは、WAPクライアント（モバイル端末）、WAPプロキシ、およびOrigin Serverで構成されています。インターネット上のWAPクライアントとサーバー間のWAPプロキシが必要です。WAPは、層状のスケーラブルなアーキテクチャ[Waparch]を使用し、端子とプロキシの間で使用する次の5つのプロトコル層を指定します。[wapwtp]、セキュリティレイヤー（wtls）[wapwtls]、および輸送層（wapwdp）。標準的なインターネットプロトコルは、プロキシとOrigin Serverの間で使用されます。Origin Serverに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プロキシは、WAP要求をwww（http）リクエストに変換し、必要なプロトコル変換を実行し、この要求をインターネット上の標準Webサーバーに送信します。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は、さまざまなBearer Datagramサービスで動作します。これらのBearerサービスで通信する場合、WAPトランスポートレイヤー（WDP）は常にWAPクライアントとWAPプロキシ間で使用され、ポートアドレス指定されたデータグラムサービスをより高いWAPレイヤーに提供します。Bearer ServiceがIP（GSM-CSD、GSM-GPRS、IS-136、CDPDなど）をサポートする場合、UDPはデータグラムプロトコルとして使用されます。ただし、BearerサービスがIPをサポートしていない場合（GSM-SMS、GSM-OSSD、GSMセルブロードキャスト、CDMS-SMS、TETRA-SDSなど）、WDPは、BearerネットワークとBearerネットワーク間の適応層として必要なデータグラムプロトコルを実装します。プロトコルスタック。
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]に似ています。Origin Serverに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トランシーバーを備えたアクセスポイントが単一のセルを制御する細胞トポロジーに組織されています。セルは、基地局のカバレッジエリアに関して定義されています。アクセスポイントは、有線ネットワークに直接接続されています。各セルのアクセスポイントは、セル内にあるホストとの間のパケットを転送する責任があります。多くの場合、W-LANトランシーバーを持つホストはモバイルです。このようなモバイルホストがあるセルから別のセルに移動する場合、有線ネットワークとモバイルホストの間のパケットを転送する責任は、新しいセルのアクセスポイントに転送する必要があります。これはハンドオフとして知られています。多くの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から11 Mbpsのリンク帯域幅を提供します。将来的には、最大54 Mbps以上のより高い帯域幅の幅広い展開が予想されます。ワイヤレスLANを使用した往復遅延は、数ミリ秒または数十ミリ秒のオーダーにあります。W-LANの例には、IEEE 802.11、Homerf、およびHiperlanが含まれます。Bluethoothなどのワイヤレスパーソナルエリアネットワーク（WPAN）は、同じPEP技術を使用できます。
Wireless LANs are error-prone due to bit errors, collisions and link outages. In addition, consecutive packet losses may also occur during handoffs. Most W-LAN MAC protocols perform low level retransmissions. This feature shields upper layers from most losses. However, unavoidable losses, retransmission latency and link outages still affect upper layers. TCP performance over W-LANs or a network path involving a W-LAN link is likely to suffer from these effects.
ワイヤレスLANは、ビットエラー、衝突、リンクの停止により、エラーが発生しやすくなります。さらに、ハンドオフ中に連続したパケット損失も発生する場合があります。ほとんどのW-LAN MACプロトコルは、低レベルの再送信を実行します。この機能は、ほとんどの損失から上層を保護します。ただし、避けられない損失、再送信の遅延、およびリンクの停止は依然として上層に影響します。W-LANSまたはW-LANリンクを含むネットワークパス上のTCPパフォーマンスは、これらの効果に苦しむ可能性があります。
As TCP wrongly interprets these packet losses to be network congestion, the TCP sender reduces its congestion window and is often forced to timeout in order to recover from the consecutive losses. The result is often unacceptably poor end-to-end performance.
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.
BerkeleyのSnoopプロトコル[Snoop]は、モバイルホストのラストホップルーターとして機能するW-LANベースステーションにTCPに認識されたモジュールであるTCPに適用されるモジュールが展開されるアプローチです。Snoopは、TCPエンドツーエンドのセマンティクスを保持することを目指しています。Snoopエージェントは、いずれかの方向にベースステーションを通過するすべてのパケットを監視し、各TCP接続のソフト状態を維持します。Snoopエージェントは、TCPデータとACKチャネル、およびアップリンク（モバイルホストから）およびダウンリンク（モバイルホストへの）TCPセグメントで異なる動作をするため、非対称PEP実装です。
For a data transfer to a mobile host, the Snoop agent caches unacknowledged TCP data segments which it forwards to the TCP receiver and monitors the corresponding ACKs. It does two things:
モバイルホストへのデータ転送の場合、Snoopエージェントは、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送信者がエンドツーエンドを行うのを待つ代わりに、ローカルタイマーとTCPの複製ACKを使用してパケット損失を特定することにより、失われたデータセグメントをローカルに再送信します。
2. Suppresses the duplicate ACKs on their way from the mobile host back to the sender, thus avoiding fast retransmit and congestion avoidance at the latter.
2. モバイルホストから送信者に戻る途中で重複したAcksを抑制し、後者での迅速な再送信と混雑回避を回避します。
Suppressing the duplicate ACKs is required to avoid unnecessary fast retransmits by the TCP sender as the Snoop agent retransmits a packet locally. Consider a system that employs the Snoop agent and a TCP sender S that sends packets to receiver R via a base station BS. Assume that S sends packets A, B, C, D, E (in that order) which are forwarded by BS to the wireless receiver R. Assume the first transmission of packet B is lost due to errors on the wireless link. In this case, R receives packets A, C, D, E and B (in that order). Receipt of packets C, D and E trigger duplicate ACKs. When S receives three duplicate ACKs, it triggers fast retransmit (which results in a retransmission, as well as reduction of the congestion window). The Snoop agent also retransmits B locally, when it receives three duplicate ACKs. The fast retransmit at S occurs despite the local retransmit on the wireless link, degrading throughput. Snoop deals with this problem by dropping TCP duplicate ACKs appropriately at BS.
Snoopエージェントがパケットをローカルに再送信するため、TCP送信者による不必要な高速再送信を避けるために、重複するAcksを抑制する必要があります。Snoopエージェントを使用するシステムと、ベースステーションBSを介してReceiver Rにパケットを送信するTCP送信者を使用してください。SがBSによってワイヤレスレシーバーRに転送されるパケットa、b、c、d、e（その順序で）を送信すると仮定します。この場合、rはパケットa、c、d、e、およびbを受信します（その順序で）。パケットの受領c、d、およびeトリガーの重複アック。Sが3つの重複したAcksを受け取ると、高速再送信をトリガーします（これにより、再送信が行われ、混雑ウィンドウが削減されます）。Snoopエージェントは、3つの重複したAcksを受け取ると、Bをローカルに再送信します。Sでの高速再送信は、ワイヤレスリンクのローカル再送信にもかかわらず発生し、スループットを分解します。Snoopは、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.
モバイルホストからのデータ転送の場合、Snoopエージェントは、フォワードのデータセグメントを監視することにより、ワイヤレスリンクのパケット損失を検出します。次に、ローカルまたは明示的な損失通知（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.
SnoopエージェントがNAKを使用して、ワイヤレスリンクのパケット損失をTCP送信者に通知する場合、それらを実装する可能性の1つは、TCP [RFC2018]の選択的確認（SACK）オプションを使用することです。これには、モバイルホストでのサック処理を有効にする必要があります。Snoopエージェントは、モバイルホストから送信シーケンスの穴を検出した場合、または特定の期間モバイルホストから新しいパケットを受け取っていない場合、TCPサックを送信します。このアプローチは、サックのアドバイザリーの性質に依存しています：モバイル送信者は、袋で示されている欠落しているセグメントを再送信することをお勧めしますが、これらのセグメントが後で失われる可能性があるため、サックで認められたセグメントのエンドツーエンドの配信が成功したと仮定してはなりません受信機へのパスで。代わりに、送信者は累積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メカニズムを使用してモバイル送信者にパケット損失を通知する場合、SnoopはELN [Snoopeln]のTCPヘッダーに「予約されていない」ビットの1つを使用します。Snoopエージェントは、ワイヤレスリンクで失われたセグメントに対応する穴を追跡します。シーケンススペースの穴に対応する（複製）ACKがTCPレシーバーから到着すると、SnoopエージェントはACKにELNビットを設定して、損失が輻輳とは無関係であることを示し、ACKをTCP送信者に転送します。送信者が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ヘッダーで将来使用するために予約されている6ビットのいずれかを使用したELNメカニズムは、TCPスタックで正しく実装されていない可能性のあるチェックを行使し、バグを暴露する可能性があるため、危険です。
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).
Snoopなどのスキームは、ワイヤレスエラーによる迅速な再送信の可能性が無視できない場合にのみ必要です。特に、ワイヤレスリンクが失われたデータにリンク層回復を使用している場合、このスキームは有益ではありません。また、TCPウィンドウが4つのセグメントよりも小さく留まる傾向がある場合、たとえば、有線ネットワークの輻輳関連損失のために、スヌープエージェントが紛失パケットをローカルに再送信する機会が少ない可能性が小さい場合があります。これは、ローカルの再送信をトリガーするために少なくとも3つの複製ACKが必要であるためですが、小さなウィンドウのため、Snoopエージェントは失われたパケットの後に3つの新しいパケットを転送できないため、必要な3つの重複アクセスを誘導する可能性があります。逆に、TCPウィンドウが十分に大きい場合、Snoopは大幅なパフォーマンス改善を提供できます（標準のTCPと比較して）。
In order to alleviate the problem with small TCP windows, Snoop proposes a solution in which a TCP sender is allowed to transmit a new data segment for each duplicate ACK it receives as long as the number of duplicate ACKs is less than the threshold for TCP fast retransmission (three duplicate ACKs). If the new segment reaches the receiver, it will generate another duplicate ACK which, in turn, allows the sender to transmit yet another data segment. This continues until enough duplicate ACKs have accumulated to trigger TCP fast retransmission. This proposal is the same as the "Limited Transfer" proposal [RFC3042] that has recently been forwarded to the standards track. However, to be able to benefit from this solution, it needs to be deployed on TCP senders and therefore it is not ready for use in a short time frame.
Snoopは、小さなTCPウィンドウで問題を軽減するために、TCP Senderが重複する各ACKの新しいデータセグメントを、重複するACKの数がTCP高速のしきい値よりも少ない限り、新しいデータセグメントを送信できるソリューションを提案します。再送信（3つの重複ACK）。新しいセグメントが受信機に届くと、別の重複ACKが生成され、これにより、送信者がさらに別のデータセグメントを送信できます。これは、TCPの高速再送信をトリガーするために十分な重複ACKが蓄積されるまで続きます。この提案は、最近標準トラックに転送された「限定転送」提案[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:
Snoopは、モバイルホストと有線インターネット上のもう一方の端ホストとの間のトラフィックを調べて操作するために、中間ノード（ベースステーション）が必要です。したがって、IPトラフィックが暗号化されている場合、Snoopは機能しません。可能なソリューションには次のことが含まれます。
- 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.)
Snoopでは、データと対応するACKの両方が同じベースステーションを横断することも必要です。さらに、Snoopエージェントは、ワイヤレスリンクを越えて「輸送層」でTCPデータセグメントを再送信する際に、リンクレイヤーによる努力を複製する場合があります。（Snoopは、デザイナーによって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をリンク停止から保護し、優先度の多重化を追加するために使用できます。Snoopなどの手法はアクセスポイントに統合的に実装されていますが、優先度と圧縮スキームは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で詳細に説明されているように）PEPSを使用し、IPSECを使用することは、一般的に相互に排他的です。PEPがIPSECトンネルのエンドポイントであると信頼されている場合（およびIPSECトンネルの使用が該当する脅威モデルに十分なセキュリティと見なされない場合）、ユーザーまたはネットワーク管理者は、パフォーマンスとネットワークレイヤーの改善を選択する必要があります。安全。場合によっては、ネットワーク層のセキュリティを持たないことの影響を軽減するために、PEPと組み合わせて輸送（またはそれ以上の）層セキュリティを使用できます。しかし、輸送（またはそれ以上の）層のセキュリティを使用するためのアプリケーションによるサポートは、遍在するものとはほど遠いものです。
Additionally, the PEP itself needs to be protected from attack. First, even when IPsec tunnels are used with the PEP, the PEP represents a point in the network where traffic is exposed. And, the placement of a PEP in the network makes it an ideal platform from which to launch a denial of service or man in the middle attack. (Also, taking the PEP out of action is a potential denial of service attack itself.) Therefore, the PEP must be protected (e.g., by a firewall) or must protect itself from improper access by an attacker just like any other device which resides in a network.
さらに、PEP自体は攻撃から保護する必要があります。まず、IPSECトンネルをPEPで使用する場合でも、PEPはトラフィックが露出するネットワーク内のポイントを表します。そして、ネットワークにPEPを配置すると、中央の攻撃でサービスの拒否または人間を立ち上げるための理想的なプラットフォームになります。（また、PEPを行動から除外することは、サービス攻撃自体の潜在的な拒否です。）したがって、PEPを保護する必要があります（例えば、ファイアウォールによって）、または他のデバイスと同じように攻撃者による不適切なアクセスから身を守らなければなりません。ネットワーク内。
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ワーキンググループのアクティブなメンバーに感謝しています。特に、ジョー・タッチとマーク・オールマンは、ドキュメントのさまざまな側面について非常に貴重なフィードバックを与えてくれました。マグドルナ・ゲレンダイは、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。Bhattacharya、A。Krishma、S.K。Tripathi、「ワイヤレスLANS上のTCPスループットを改善するためのチャネル状態依存パケットスケジューリングを使用」、ACMワイヤレスネットワーク、1997年3月、91-102。Wireless/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. Balakrishnan、V.N。Padmanabhan、R.H。Katz、「TCPパフォーマンスに対する非対称性の影響」、Proc。ACM/IEEE Mobicom、ブダペスト、ハンガリー、1997年9月。
[BW97] G. Brasche, B. Walke, "Concepts, Services, and Protocols of the New GSM Phase 2+ general Packet Radio Service," IEEE Communications Magazine, Vol. 35, No. 8, August 1997.
[BW97] G. Brashe、B。Walke、「新しいGSMフェーズ2一般パケットラジオサービスの概念、サービス、およびプロトコル」、IEEE Communications Magazine、Vol。35、No。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] Electronic Industry Alliance（EIA）/Telecommunications Industry Association（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. Chang、C。Tait、N。Cohen、M。Shapiro、S。Mastrianni、R。Floyd、B。Housel、D。Lindquist、「ワイヤレス環境での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。マコーリー、J.M。スミス、D.S。ベイキン、W.S。マーカス、T.M。Raleigh、「プロトコルブースター」、Communicationの選択領域に関するIEEEジャーナル、Vol。16、No。3、1998年4月。
[FLASH] Flash Networks Ltd., performance boosting products technology vendor based in Holmdel, New Jersey. Website at http://www.flashnetworks.com.
[Flash] Flash Networks Ltd.、ニュージャージー州ホルムデルに拠点を置くPerformance Products製品テクノロジーベンダー。http://www.flashnetworks.comのウェブサイト。
[FOURELLE] Fourelle Systems, performance boosting products technology vendor based in Santa Clara, California. Website at http://www.fourelle.com.
[FORELLE]ファールシステム、カリフォルニア州サンタクララに拠点を置くPerformance Products製品テクノロジーベンダー。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 Communications Magazine、Vol。31、No。4、pp。92-100、1993年4月。
[HNS] Hughes Network Systems, Inc., VSAT technology vendor based in Germantown, Maryland. Website at http://www.hns.com.
[HNS] Hughes Network Systems、Inc.、メリーランド州ジャーマンタウンに拠点を置くVSATテクノロジーベンダー。http://www.hns.comのウェブサイト。
[I-TCP] A. Bakre, B.R. Badrinath, "I-TCP: Indirect TCP for Mobile Hosts," Proc. 15th International Conference on Distributed Computing Systems (ICDCS), May 1995.
[I-TCP] A.バクレ、B.R。Badrinath、「I-TCP：モバイルホスト用の間接TCP」、Proc。1995年5月、分散コンピューティングシステム（ICDC）に関する第15回国際会議。
[KRA94] M. Kojo, K. Raatikainen, T. Alanko, "Connecting Mobile Workstations to the Internet over a Digital Cellular Telephone Network," Proc. Workshop on Mobile and Wireless Information Systems (MOBIDATA), Rutgers University, NJ, November 1994. Revised version published in Mobile Computing, pp. 253-270, Kluwer, 1996.
[KRA94] M. Kojo、K。Raatikainen、T。Alanko、「デジタルセルラー電話ネットワークを介してモバイルワークステーションをインターネットに接続する」、Proc。1994年11月、ニュージャージー州ラトガース大学のモバイルおよびワイヤレス情報システム（Mobidata）に関するワークショップ。モバイルコンピューティング、pp。253-270、Kluwer、1996年に公開された改訂版。
[KRLKA97] M. Kojo, K. Raatikainen, M. Liljeberg, J. Kiiskinen, T. Alanko, "An Efficient Transport Service for Slow Wireless Telephone Links," IEEE Journal on Selected Areas of Communication, Vol. 15, No. 7, September 1997.
[Krlka97] M. Kojo、K。Raatikainen、M。Liljeberg、J。Kiiskinen、T。Alanko、「スローワイヤレス電話リンクのための効率的な輸送サービス」15、No。7、1997年9月。
[LAKLR95] M. Liljeberg, T. Alanko, M. Kojo, H. Laamanen, K. Raatikainen, "Optimizing World-Wide Web for Weakly-Connected Mobile Workstations: An Indirect Approach," Proc. of the 2nd Int. Workshop on Services in Distributed and Networked Environments, Whistler, Canada, pp. 132- 139, June 1995.
[Laklr95] M. Liljeberg、T。Alanko、M。Kojo、H。Laamanen、K。Raatikainen、「弱く接続されたモバイルワークステーション用の世界的なWebの最適化：間接的アプローチ」、Proc。2番目のint。分散環境およびネットワーク環境でのサービスに関するワークショップ、カナダ、ウィスラー、pp。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。Kojo、K。Raatikainen、「Mowgli WWWソフトウェア：モバイルWAN環境におけるWWWの使いやすさ」、Proc。IEEE Global Internet 1996 Conference、ロンドン、英国、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. Brown、S。Singh、「M-TCP：Mobile Cellular NetworksのTCP」、ACMコンピューター通信レビューVolume 27（5）、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. Paxson、「エンドツーエンドのインターネットパケットダイナミクス」、IEEE/ACM Transactions on Networking、Vol。7、No。3、1999、pp。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] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communications Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信層」、STD 3、RFC 1122、1989年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144] Jacobson、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] Jacobson、V.、Braden、R。およびD. Borman、「TCP拡張機能のための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] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Aumponredcement Options」、RFC 2018、1996年10月。
[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", FYI 30, RFC 2151, June 1997.
[RFC2151] Kessler、G。およびS. Shepard、「インターネットおよびTCP/IPツールとユーティリティのプライマー」、FYI 30、RFC 2151、1997年6月。
[RFC2246] Dierk, T. and E. Allen, "TLS Protocol Version 1," RFC 2246, January 1999.
[RFC2246] Dierk、T。およびE. Allen、「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.、Pereira、R。、およびM. Thomas、「IPペイロード圧縮プロトコル（IPComp）」、RFC 2393、1998年12月。
[RFC2401] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。、およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 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] Allman、M.、Glover、D。、およびL. Sanchez、「標準メカニズムを使用した衛星チャネル上のTCPの強化」、BCP 28、RFC 2488、1999年1月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B。およびS. Pink、「IPヘッダー圧縮」、RFC 2507、1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S。およびV. Jacobson、「低速シリアルリンクのIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[RFC2509] Engan、M.、Casner、S。およびC. Bormann、「PPP上のIPヘッダー圧縮」、RFC 2509、1999年2月。
[RFC2663] Srisuresh, P. and Y. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびY. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson, T., Heidemann, J., Kruse, H., Ostermann, S., Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
[RFC2760] Allman、M.、Dawkins、S.、Glover、D.、Griner、J.、Henderson、T.、Heidemann、J.、Kruse、H.、Ostermann、S.、Scott、K.、Semke、J.、Touch、J。およびD. Tran、「衛星に関連する進行中の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] Allman、M.、Balakrishnan、H。およびS. Floyd、「限定送信を使用したTCPの損失回復の強化」、RFC 3042、2001年1月。
[SHEL00] Z. Shelby, T. Saarinen, P. Mahonen, D. Melpignano, A. Marshall, L. Munoz, "Wireless IPv6 Networks - WINE," IST Mobile Summit, Ireland, October 2000.
[Shel00] Z. Shelby、T。Saarinen、P。Mahonen、D。Melpignano、A。Marshall、L。Munoz、「ワイヤレスIPv6ネットワーク - ワイン」、ISTモバイルサミット、アイルランド、2000年10月。
[SNOOP] H. Balakrishnan, S. Seshan, E. Amir, R. Katz, "Improving TCP/IP Performance over Wireless Networks," Proc. 1st ACM Conference on Mobile Communications and Networking (Mobicom), Berkeley, California, November 1995.
[Snoop] H. Balakrishnan、S。Seshan、E。Amir、R。Katz、「ワイヤレスネットワーク上のTCP/IPパフォーマンスの改善」、Proc。1995年11月、カリフォルニア州バークレーのモバイルコミュニケーションとネットワーキング（MOBICOM）に関する第1回ACM会議。
[SNOOPELN] H. Balakrishnan, R. Katz, "Explicit Loss Notification and Wireless Web Performance," Proc. IEEE Globecom 1998, Internet Mini-Conference, Sydney, Australia, November 1998.
[Snoopeln] H. Balakrishnan、R。Katz、「明示的な損失通知とワイヤレスWebパフォーマンス」、Proc。IEEE Globecom 1998、インターネットミニカンファレンス、シドニー、オーストラリア、1998年11月。
[SPACENET] Spacenet, VSAT technology vendor based in Mclean, Virginia. Website at http://www.spacenet.com.
[SpaceNet] SpaceNet、バージニア州マクリーンに拠点を置くVSATテクノロジーベンダー。http://www.spacenet.comのウェブサイト。
[SRC84] J.H. Saltzer, D.P. Reed, D.D. Clark, "End-To-End Arguments in System Design," ACM TOCS, Vol. 2, No. 4, pp. 277-288, November 1984.
[SRC84] J.H.Saltzer、D.P。リード、D.D。クラーク、「システム設計におけるエンドツーエンドの議論」、ACM TOCS、Vol。2、No。4、pp。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. Zhang、B。Singh、「マルチレイヤーIPSECプロトコル」、Proc。2000年8月、コロラド州デンバーの第9回USENIXセキュリティシンポジウムの議事録。http：//www.wins.hrl.com/people/ygz/papers/usenix00.htmlで入手可能。
Questions about this document may be directed to:
このドキュメントに関する質問は、次のように向けられます。
John Border Hughes Network Systems 11717 Exploration Lane Germantown, Maryland 20876
John Border Hughes Network Systems 11717 Exploration Lane Germantown、Maryland 20876
Phone: +1-301-548-6819 Fax: +1-301-548-1196 EMail: border@hns.com Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
電話：1-301-548-6819ファックス：1-301-548-1196メール：border@hns.comマルククコジョ科ヘルシンキP.O.Box 26（Teollisuuskatu 23）Fin-00014 Helsinki Finland
Phone: +358-9-1914-4179
Fax: +358-9-1914-4441
EMail: kojo@cs.helsinki.fi
Jim Griner NASA Glenn Research Center MS: 54-5 21000 Brookpark Orad Cleveland, Ohio 44135-3191
ジムグリーナーナサグレンリサーチセンターMS：54-5 21000ブルックパークオラドクリーブランド、オハイオ44135-3191
Phone: +1-216-433-5787
Fax: +1-216-433-8705
EMail: jgriner@grc.nasa.gov
Gabriel Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan, FRANCE
ガブリエルモンテネグロサンマイクロシステムラボラトリーズ、ヨーロッパ29、ケミンデュヴィューチェーン38240メイラン、フランス
Phone: +33 476 18 80 45
EMail: gab@sun.com
Zach Shelby University of Oulu Center for Wireless Communications PO Box 4500 FIN-90014 Finland
ザックシェルビー大学オウル大学ワイヤレス通信PO Box 4500 FIN-90014フィンランド
Phone: +358-40-779-6297
EMail: 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
リンクレイヤーペップ
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および[Snoop]で詳細に説明されています。
split connection
接続を分割します
A connection that has been terminated before reaching the intended destination end system in order to initiate another connection towards the end system. This allows the use of different connection characteristics for different parts of the path of the originally intended connection. See Section 2.4.
エンドシステムに向かって別の接続を開始するために、目的の宛先エンドシステムに到達する前に終了した接続。これにより、元々意図された接続のパスのさまざまな部分に異なる接続特性を使用できます。セクション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.
1つ以上の分割TCP接続を使用して、TCPパフォーマンスを向上させます。
TCP spoofing
TCPスプーフィング
Sometimes used as a synonym for TCP PEP. More accurately, TCP spoofing refers to using transparent (to the TCP stacks in the end systems) mechanisms to improve TCP performance. See Section 2.1.1.
TCP PEPの同義語として時々使用されます。より正確には、TCPスプーフィングとは、TCPパフォーマンスを改善するために、透過的（エンドシステムのTCPスタックに）メカニズムを使用することを指します。セクション2.1.1を参照してください。
transparent
透明分かり切った
In the context of a PEP, transparent refers to not requiring changes to be made to the end systems, transport endpoints and/or applications involved in a connection. See Section 2.5 for a more detailed explanation.
PEPのコンテキストでは、透明性とは、接続に関与するエンドシステム、輸送エンドポイント、および/またはアプリケーションに変更を加える必要がないことを指します。詳細な説明については、セクション2.5を参照してください。
transport layer PEP
輸送層のペップ
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.
PEPSのコンテキストでは、トンネリングとは、2つのPEPの間の特定のリンクを介して送信するためのパケットをラッピングするプロセスを指します。セクション3.2を参照してください。
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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。