Network Working Group S. Dawkins
Request for Comments: 3150 G. Montenegro
BCP: 48 M . Kojo
Category: Best Current Practice V. Magret
July 2001
End-to-end Performance Implications of Slow Links
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document makes performance-related recommendations for users of network paths that traverse "very low bit-rate" links.
この文書では、「非常に低ビットレート」リンクを通過ネットワークパスの利用者のためのパフォーマンス関連の勧告を行います。
"Very low bit-rate" implies "slower than we would like". This recommendation may be useful in any network where hosts can saturate available bandwidth, but the design space for this recommendation explicitly includes connections that traverse 56 Kb/second modem links or 4.8 Kb/second wireless access links - both of which are widely deployed.
「非常に低いビットレートは、」「私たちは希望よりも遅い」を意味します。この勧告は、ホストが利用可能な帯域幅を飽和させることができる任意のネットワークに有用であり得るが、この勧告の設計空間は、明示的に56 KB /秒モデムリンクまたは4.8 KB /秒の無線アクセスリンクを横断接続含む - に広く展開されている両方があります。
This document discusses general-purpose mechanisms. Where application-specific mechanisms can outperform the relevant general-purpose mechanism, we point this out and explain why.
この文書では、汎用的なメカニズムについて説明します。アプリケーション固有のメカニズムは、関連する汎用的なメカニズムをアウトパフォームすることができますどこで、我々はこれを指摘し、理由を説明します。
This document has some recommendations in common with RFC 2689, "Providing integrated services over low-bitrate links", especially in areas like header compression. This document focuses more on traditional data applications for which "best-effort delivery" is appropriate.
この文書では、特にヘッダ圧縮などの分野では、「低ビットレートリンク上で統合されたサービスの提供」、RFC 2689と共通のいくつかの勧告を持っています。この文書では、「ベストエフォート型の配信は」適切であるため、従来のデータ・アプリケーションに、より焦点を当てています。
Table of Contents
目次
1.0 Introduction ................................................. 2
2.0 Description of Optimizations ................................. 3
2.1 Header Compression Alternatives ...................... 3
2.2 Payload Compression Alternatives ..................... 5
2.3 Choosing MTU sizes ................................... 5
2.4 Interactions with TCP Congestion Control [RFC2581] ... 6
2.5 TCP Buffer Auto-tuning ............................... 9
2.6 Small Window Effects ................................. 10
3.0 Summary of Recommended Optimizations ......................... 10
4.0 Topics For Further Work ...................................... 12
5.0 Security Considerations ...................................... 12
6.0 IANA Considerations .......................................... 13
7.0 Acknowledgements ............................................. 13
8.0 References ................................................... 13
Authors' Addresses ............................................... 16
Full Copyright Statement ......................................... 17
The Internet protocol stack was designed to operate in a wide range of link speeds, and has met this design goal with only a limited number of enhancements (for example, the use of TCP window scaling as described in "TCP Extensions for High Performance" [RFC1323] for very-high-bandwidth connections).
インターネット・プロトコル・スタックは、[リンク速度の広い範囲で動作するように設計された、および機能拡張（例えば、TCPウィンドウスケーリングの使用は、「ハイパフォーマンスのためのTCP拡張機能」で説明したように限られた数で、この設計目標を満たしています超高帯域幅の接続のためのRFC1323]）。
Pre-World Wide Web application protocols tended to be either interactive applications sending very little data (e.g., Telnet) or bulk transfer applications that did not require interactive response (e.g., File Transfer Protocol, Network News). The World Wide Web has given us traffic that is both interactive and often "bulky", including images, sound, and video.
前のワールド・ワイド・ウェブ・アプリケーション・プロトコルは、インタラクティブな応答を必要としませんでした非常に少ないデータ（例えば、Telnet接続）またはバルク転送アプリケーションを送信する対話型アプリケーションのいずれかの傾向にあった（例えば、ファイル転送プロトコル、ネットワークニュース）。ワールド・ワイド・ウェブは私たちに、画像、音声、ビデオなど、インタラクティブ、しばしば「かさばる」の両方でトラフィックを与えています。
The World Wide Web has also popularized the Internet, so that there is significant interest in accessing the Internet over link speeds that are much "slower" than typical office network speeds. In fact, a significant proportion of the current Internet users is connected to the Internet over a relatively slow last-hop link. In future, the number of such users is likely to increase rapidly as various mobile devices are foreseen to to be attached to the Internet over slow wireless links.
典型的なオフィスのネットワーク速度よりもはるかに「遅く」あるリンク速度を介してインターネットにアクセスする際に大きな関心があるように、ワールド・ワイド・ウェブはまた、インターネットを普及しています。実際には、現在のインターネットユーザーのかなりの割合が比較的遅く、最後のホップリンク上でインターネットに接続されています。将来的には、このようなユーザーの数は、様々なモバイルデバイスが低速無線リンクを介してインターネットに接続されるようにするために予見されているとして、急速に増加する可能性があります。
In order to provide the best interactive response for these "bulky" transfers, implementors may wish to minimize the number of bits actually transmitted over these "slow" connections. There are two areas that can be considered - compressing the bits that make up the overhead associated with the connection, and compressing the bits that make up the payload being transported over the connection.
これらの「嵩高い」転送のための最善の対話式応答を提供するために、実装は、実際にこれら「低速」接続で送信されるビットの数を最小限にすることを望むかもしれません。接続に関連するオーバーヘッドを構成するビットを圧縮し、そして接続を介して搬送されるペイロードを構成するビットを圧縮 - 考えることができる2つの領域があります。
In addition, implementors may wish to consider TCP receive window settings and queuing mechanisms as techniques to improve performance over low-speed links. While these techniques do not involve protocol changes, they are included in this document for completeness.
また、実装者は、TCPが低速リンクでのパフォーマンスを改善するための技術として、ウィンドウの設定およびキューイングメカニズムを受け取る検討すると良いかもしれません。これらの技術は、プロトコルの変更を伴わないが、万全を期すため、この文書に含まれています。
This section describes optimizations which have been suggested for use in situations where hosts can saturate their links. The next section summarizes recommendations about the use of these optimizations.
このセクションでは、ホストがリンクを飽和状態にすることができますような状況で使用するために提案されている最適化を説明しています。次のセクションでは、これらの最適化の使用についての提言をまとめました。
Mechanisms for TCP and IP header compression defined in [RFC1144, RFC2507, RFC2508, RFC2509, RFC3095] provide the following benefits:
[RFC1144、RFC2507、RFC2508、RFC2509、RFC3095]で定義されたTCPおよびIPヘッダー圧縮のためのメカニズムは、次のような利点を提供します。
- Improve interactive response time
- インタラクティブな応答時間を改善
- Decrease header overhead (for a typical dialup MTU of 296 bytes, the overhead of TCP/IP headers can decrease from about 13 percent with typical 40-byte headers to 1-1.5 percent with with 3-5 byte compressed headers, for most packets). This enables use of small packets for delay-sensitive low data-rate traffic and good line efficiency for bulk data even with small segment sizes (for reasons to use a small MTU on slow links, see section 2.3)
- 減少ヘッダオーバヘッド（296バイトの典型的なダイヤルアップMTUのために、TCP / IPヘッダーのオーバーヘッドがほとんどパケットについて、3-5バイトに圧縮ヘッダを有する1から1.5パーセントに典型的な40バイトのヘッダを約13％から減少させることができます）。これは、（低速リンク上の小さなMTUを使用する理由のために、セクション2.3を参照）は、遅延に敏感な低データ・レート・トラフィックと小さなセグメントサイズを有する大量のデータのための良好なライン効率のために小さなパケットの使用を可能にします
- Many slow links today are wireless and tend to be significantly lossy. Header compression reduces packet loss rate over lossy links (simply because shorter transmission times expose packets to fewer events that cause loss).
- 多くの低速リンク今日は無線であり、大幅に非可逆になる傾向があります。ヘッダ圧縮は、（短い送信時間が失わ少ないイベントにパケットを公開するというだけの理由）非可逆リンク上でのパケット損失率を低減します。
[RFC1144] header compression is a Proposed Standard for TCP Header compression that is widely deployed. Unfortunately it is vulnerable on lossy links, because even a single bit error results in loss of synchronization between the compressor and decompressor. It uses TCP timeouts to detect a loss of such synchronization, but these errors result in loss of data (up to a full TCP window), delay of a full RTO, and unnecessary slow-start.
[RFC1144]ヘッダー圧縮が広く展開されているTCPヘッダー圧縮のための提案された標準です。残念ながら、それは、損失の多いリンクに脆弱であるコンプレッサとデコンプレッサとの間の同期の損失であってもシングルビットエラーをもたらすからです。これは、TCPは、このような同期の損失を検出するためのタイムアウト使用していますが、これらのエラーは、完全なRTOの遅延、および不要なスロースタート、（完全なTCPウィンドウまで）データの損失につながります。
A more recent header compression proposal [RFC2507] includes an explicit request for retransmission of an uncompressed packet to allow resynchronization without waiting for a TCP timeout (and executing congestion avoidance procedures). This works much better on links with lossy characteristics.
より最近のヘッダ圧縮提案[RFC2507]はTCPタイムアウトを待って（及び輻輳回避手順を実行する）ことなく、再同期を可能にするために圧縮されていないパケットの再送信のための明示的な要求を含みます。これは非可逆特性を持つリンクをはるかに優れて動作します。
The above scheme ceases to perform well under conditions as extreme as those of many cellular links (error conditions of 1e-3 or 1e-2 and round trip times over 100 ms.). For these cases, the 'Robust Header Compression' working group has developed ROHC [RFC3095]. Extensions of ROHC to support compression of TCP headers are also under development.
上記のスキームは、多くの細胞リンクのもののような極端なような条件の下で十分に機能しなくなる（1E-3または1E-2と100ミリ秒を超える往復時間のエラー状態。）。これらのケースについては、「ロバストヘッダ圧縮」ワーキンググループはROHC [RFC3095]を開発しました。 TCPヘッダの圧縮をサポートするために、ROHCの拡張機能も開発中です。
[RFC1323] defines a "TCP Timestamp" option, used to prevent "wrapping" of the TCP sequence number space on high-speed links, and to improve TCP RTT estimates by providing unambiguous TCP roundtrip timings. Use of TCP timestamps prevents header compression, because the timestamps are sent as TCP options. This means that each timestamped header has TCP options that differ from the previous header, and headers with changed TCP options are always sent uncompressed. In addition, timestamps do not seem to have much of an impact on RTO estimation [AlPa99].
[RFC1323]は高速リンク上のTCPシーケンス番号空間の「ラッピング」を防止するために、及びTCP RTTが明白TCP往復タイミングを提供することによって推定改善するために使用される「TCPタイムスタンプ」オプションを定義します。タイムスタンプは、TCPオプションとして送信されるため、TCPタイムスタンプの使用は、ヘッダ圧縮を防止します。これは、各タイムスタンプヘッダが前ヘッダ異なるTCPオプションを有し、および変更TCPオプションを持つヘッダは常に圧縮されていない送信されることを意味します。また、タイムスタンプは[AlPa99] RTO推定への影響の多くを持っていないようです。
Nevertheless, the ROHC working group is developing schemes to compress TCP headers, including options such as timestamps and selective acknowledgements.
それにも関わらず、ROHCワーキンググループは、このようなタイムスタンプと選択的確認応答などのオプションを含むTCPヘッダを圧縮するためのスキームを開発しています。
Recommendation: Implement [RFC2507], in particular as it relates to IPv4 tunnels and Minimal Encapsulation for Mobile IP, as well as TCP header compression for lossy links and links that reorder packets. PPP capable devices should implement "IP Header Compression over PPP" [RFC2509]. Robust Header Compression [RFC3095] is recommended for extremely slow links with very high error rates (see above), but implementors should judge if its complexity is justified (perhaps by the cost of the radio frequency resources).
推奨：[RFC2507]を実装は、特にそれは、IPv4トンネルとロッシーリンクパケットを並べ替えるリンクのための最小限のモバイルIPのカプセル化、並びにTCPヘッダ圧縮に関連します。 PPP可能なデバイスは、「PPP上のIPヘッダー圧縮」[RFC2509]を実装する必要があります。ロバストヘッダ圧縮[RFC3095]は、非常に高いエラー率（上記参照）と非常に低速リンクのために推奨されますが、その複雑さは（おそらく無線周波数資源のコストで）正当化される場合には実装者が判断する必要があります。
[RFC1144] header compression should only be enabled when operating over reliable "slow" links.
信頼できる「遅い」リンク上で動作しているときに[RFC1144]ヘッダー圧縮は、有効にされるべきです。
Use of TCP Timestamps [RFC1323] is not recommended with these connections, because it complicates header compression. Even though the Robust Header Compression (ROHC) working group is developing specifications to remedy this, those mechanisms are not yet fully developed nor deployed, and may not be generally justifiable. Furthermore, connections traversing "slow" links do not require protection against TCP sequence-number wrapping.
それはヘッダー圧縮を複雑にするため、TCPタイムスタンプ[RFC1323]の使用は、これらの接続にはお勧めしません。ロバストヘッダ圧縮（ROHC）ワーキンググループは、これを解決するための仕様を開発しているにもかかわらず、それらのメカニズムはまだ完全に開発されたにも展開され、一般的に正当ではないかもしれないされていません。さらに、「遅い」のリンクを通過する接続は、TCPシーケンス番号ラップに対する保護を必要としません。
Compression of IP payloads is also desirable on "slow" network links. "IP Payload Compression Protocol (IPComp)" [RFC2393] defines a framework where common compression algorithms can be applied to arbitrary IP segment payloads.
IPペイロードの圧縮は「遅い」ネットワークリンク上も望ましいです。 「IPペイロード圧縮プロトコル（のIPComp）」[RFC2393]は一般的な圧縮アルゴリズムは、任意のIPセグメントペイロードに適用することができるフレームワークを定義します。
IP payload compression is something of a niche optimization. It is necessary because IP-level security converts IP payloads to random bitstreams, defeating commonly-deployed link-layer compression mechanisms which are faced with payloads that have no redundant "information" that can be more compactly represented.
IPペイロード圧縮は、ニッチの最適化のようなものです。 IPレベルのセキュリティをよりコンパクトに表現することができる冗長「情報」を有していないペイロードに直面している一般的展開リンク層圧縮機構を破り、ランダムビットストリームにIPペイロードを変換するためにそれが必要です。
However, many IP payloads are already compressed (images, audio, video, "zipped" files being transferred), or are already encrypted above the IP layer (e.g., SSL [SSL]/TLS [RFC2246]). These payloads will not "compress" further, limiting the benefit of this optimization.
しかし、多くのIPペイロードが既に圧縮されている（画像、オーディオ、ビデオは、 "zip形式" ファイルが転送される）、又は既にIP層の上に暗号化されている（例えば、SSL [SSL] / TLS [RFC2246]）。これらのペイロードは、この最適化の恩恵を制限する、さらに「圧縮」ではないでしょう。
For uncompressed HTTP payload types, HTTP/1.1 [RFC2616] also includes Content-Encoding and Accept-Encoding headers, supporting a variety of compression algorithms for common compressible MIME types like text/plain. This leaves only the HTTP headers themselves uncompressed.
圧縮されていないHTTPペイロードタイプは、HTTP / 1.1 [RFC2616]も、プレーンテキスト/のような一般的な圧縮MIMEタイプの圧縮アルゴリズムの様々な支援、コンテンツの符号化及び受け入れエンコードをヘッダを含みます。これは、HTTPヘッダ自身を非圧縮のまま。
In general, application-level compression can often outperform IPComp, because of the opportunity to use compression dictionaries based on knowledge of the specific data being compressed.
一般に、アプリケーション・レベルの圧縮はしばしば圧縮される特定のデータについての知識に基づいて、圧縮辞書を使用する機会と、のIPCompを上回ることができます。
Extensive use of application-level compression techniques will reduce the need for IPComp, especially for WWW users.
アプリケーションレベルの圧縮技術の広範な使用は、特にWWWユーザーのために、IPCompのための必要性を軽減します。
Recommendation: IPComp may optionally be implemented.
推奨：のIPCompは、必要に応じて実施されてもよいです。
There are several points to keep in mind when choosing an MTU for low-speed links.
低速リンクのMTUを選択する際に留意すべき点がいくつかあります。
First, if a full-length MTU occupies a link for longer than the delayed ACK timeout (typically 200 milliseconds, but may be up to 500 milliseconds), this timeout will cause an ACK to be generated for every segment, rather than every second segment, as occurs with most implementations of the TCP delayed ACK algorithm.
全長MTUは、（典型的には200ミリ秒が、500ミリ秒までであってもよい）遅延ACKタイムアウト時間よりも長いためのリンクを占有する場合、まず、このタイムアウトは、各セグメントに対して生成されるACKはなく、すべての第二のセグメントを引き起こすであろうTCP遅延ACKアルゴリズムのほとんどの実装で発生します。
Second, "relatively large" MTUs, which take human-perceptible amounts of time to be transmitted into the network, create human-perceptible delays in other flows using the same link. [RFC1144] considers 100-200 millisecond delays as human-perceptible. The convention of choosing 296-byte MTUs (with header compression enabled) for dialup access is a compromise that limits the maximum link occupancy delay with full-length MTUs close to 200 milliseconds on 9.6 Kb/second links.
第二に、当時の人間が知覚量を取り、「比較的大きな」のMTUは、ネットワークに送信されるように、同じリンクを使用して他のフローでは、人間が知覚可能な遅延を作成します。 [RFC1144]は、人間が知覚できるように100〜200ミリ秒の遅延を考慮する。ダイヤルアップアクセスのための（有効ヘッダ圧縮で）296バイトのMTUを選択する規則は9.6 KB /秒リンク上の200ミリ秒に全長のMTUの近くで最大リンク占有遅延を制限妥協です。
Third, on last-hop links using a larger link MTU size, and therefore larger MSS, would allow a TCP sender to increase its congestion window faster in bytes than when using a smaller MTU size (and a smaller MSS). However, with a smaller MTU size, and a smaller MSS size, the congestion window, when measured in segments, increases more quickly than it would with a larger MSS size. Connections using smaller MSS sizes are more likely to be able to send enough segments to generate three duplicate acknowledgements, triggering fast retransmit/fast recovery when packet losses are encountered. Hence, a smaller MTU size is useful for slow links with lossy characteristics.
大きなリンクMTUサイズを使用して、最後のホップリンクに、第三に、したがって、より大きなMSSは、TCPの送信側が速くバイト単位の小さなMTUサイズ（と小さいMSS）を使用した場合に比べて混雑ウィンドウを増加できるようになります。しかしながら、セグメントで測定小さいMTUサイズ、およびより小さいMSSサイズ、混雑ウィンドウと、より迅速に、より大きなMSSサイズの場合と比べて増加します。小さいMSSサイズを使用した接続は、パケットロスが発生した際に高速再送/高速回復をトリガ、3つの重複確認応答を生成するのに十分なセグメントを送信することができる可能性が高くなります。したがって、より小さなMTUサイズは、損失特性を有する低速リンクのために有用です。
Fourth, using a smaller MTU size also decreases the queuing delay of a TCP flow (and thereby RTT) compared to use of larger MTU size with the same number of packets in a queue. This means that a TCP flow using a smaller segment size and traversing a slow link is able to inflate the congestion window (in number of segments) to a larger value while experiencing the same queuing delay.
第四に、より小さなMTUサイズを使用すると、キュー内のパケットの同じ番号の大きいMTUサイズの使用と比較してTCPフロー（およびそれによってRTT）のキューイング遅延を減少させます。これは、低速リンクをより小さなセグメントサイズを使用して横断するTCPフローが同一のキューイング遅延を経験しながら、より大きな値に（セグメントの数）輻輳ウィンドウを膨張させることが可能であることを意味します。
Finally, some networks charge for traffic on a per-packet basis, not on a per-kilobyte basis. In these cases, connections using a larger MTU may be charged less than connections transferring the same number of bytes using a smaller MTU.
最後に、いくつかのネットワークは、パケット単位ではなく、あたりのキロバイト単位でトラフィックのために充電してください。これらのケースでは、より大きなMTUを使用して接続が小さいMTUを使用して同じバイト数を転送する接続未満で充電することができます。
Recommendation: If it is possible to do so, MTUs should be chosen that do not monopolize network interfaces for human-perceptible amounts of time, and implementors should not chose MTUs that will occupy a network interface for significantly more than 100-200 milliseconds.
推奨事項：それはそうすることが可能である場合は、MTUのは時間の人間が知覚量のためのネットワークインターフェースを独占しないように選択すべきである、と実装がはるかに100〜200ミリ秒以下のネットワークインターフェースを占有しますのMTUを選びましてはなりません。
In many cases, TCP connections that traverse slow links have the slow link as an "access" link, with higher-speed links in use for most of the connection path. One common configuration might be a laptop computer using dialup access to a terminal server (a last-hop router), with an HTTP server on a high-speed LAN "behind" the terminal server.
多くの場合、低速リンクを通過するTCP接続は、接続パスのほとんどのために使用されている高速リンクで「アクセス」リンクなどの低速リンクを、持っています。一つの一般的な構成は、ターミナルサーバ「の後ろに」高速LAN上のHTTPサーバで、ターミナルサーバーへのダイヤルアップアクセス（ラストホップルータ）を使用して、ラップトップコンピュータであるかもしれません。
In this case, the HTTP server may be able to place packets on its directly-attached high-speed LAN at a higher rate than the last-hop router can forward them on the low-speed link. When the last-hop router falls behind, it will be unable to buffer the traffic intended for the low-speed link, and will become a point of congestion and begin to drop the excess packets. In particular, several packets may be dropped in a single transmission window when initial slow start overshoots the last-hop router buffer.
この場合、HTTPサーバは、低速リンク上でそれらを転送することができ、最後のホップルータよりも高いレートでその直接接続している高速LAN上のパケットを配置することができるかもしれません。ラストホップルータが遅れた場合は、低速リンクを対象としたトラフィックをバッファリングすることができなくなり、輻輳のポイントとなり、余分なパケットを廃棄し始めます。初期スロースタートは、最後のホップルータのバッファをオーバーシュートするとき、特に、いくつかのパケットが単一送信ウィンドウにドロップすることができます。
Although packet loss is occurring, it isn't detected at the TCP sender until one RTT time after the router buffer space is exhausted and the first packet is dropped. This late congestion signal allows the congestion window to increase up to double the size it was at the time the first packet was dropped at the router.
パケットロスが発生しているが、それはルータのバッファスペースが使い果たされると、最初のパケットが破棄された後、1 RTTの時間まで、TCP送信側で検出されていません。この後半の輻輳信号は、輻輳ウィンドウは、それが最初のパケットは、ルータでドロップされた時にあったサイズを2倍まで増やすことができます。
If the link MTU is large enough to take more than the delayed ACK timeout interval to transmit a packet, an ACK is sent for every segment and the congestion window is doubled in a single RTT. If a smaller link MTU is in use and delayed ACKs can be utilized, the congestion window increases by a factor of 1.5 in one RTT. In both cases the sender continues transmitting packets well beyond the congestion point of the last-hop router, resulting in multiple packet losses in a single window.
リンクMTUがパケットを送信するために遅延ACKタイムアウト間隔よりも多くを取ることが十分に大きい場合、ACKは、すべてのセグメントのために送られ、輻輳ウィンドウは、単一のRTTで倍増しています。小さいリンクMTUが使用され、遅延ACKは、1 RTT 1.5倍輻輳ウィンドウ増加を利用することができる場合。両方の場合において、送信側は、単一のウィンドウ内の複数のパケット損失をもたらす、よく最後のホップルータの輻輳点を超えてパケットを送信し続けます。
The self-clocking nature of TCP's slow start and congestion avoidance algorithms prevent this buffer overrun from continuing. In addition, these algorithms allow senders to "probe" for available bandwidth - cycling through an increasing rate of transmission until loss occurs, followed by a dramatic (50-percent) drop in transmission rate. This happens when a host directly connected to a low-speed link offers an advertised window that is unrealistically large for the low-speed link. During the congestion avoidance phase the peer host continues to probe for available bandwidth, trying to fill the advertised window, until packet loss occurs.
TCPのスロースタートと輻輳回避アルゴリズムのセルフクロッキングの性質は、継続からオーバーランこのバッファを防ぎます。損失が発生するまでの伝送速度の増加を循環、伝送速度の劇的な（50％）低下が続く - 加えて、これらのアルゴリズムは、送信者が利用可能な帯域幅のために、「プローブ」することを可能にします。直接低速リンクに接続されたホストが、低速リンクのための非現実的に大きい広告ウィンドウを提供しています場合に発生します。パケットロスが発生するまで輻輳回避フェーズの間、ピアのホストは、広告ウィンドウを埋めようと、利用可能な帯域幅をプローブし続けています。
The same problems may also exist when a sending host is directly connected to a slow link as most slow links have some local buffer in the link interface. This link interface buffer is subject to overflow exactly in the same way as the last-hop router buffer.
最も低速リンクは、リンクインタフェースにおけるいくつかのローカルバッファを持っているとして、送信側のホストが直接低速リンクに接続されている場合、同じ問題も存在してもよいです。このリンクインターフェイスバッファは、最後のホップルータのバッファと同じように正確にオーバーフローされることがあります。
When a last-hop router with a small number of buffers per outbound link is used, the first buffer overflow occurs earlier than it would if the router had a larger number of buffers. Subsequently with a smaller number of buffers the periodic packet losses occur more frequently during congestion avoidance, when the sender probes for available bandwidth.
アウトバウンドリンクあたりのバッファの数が少ないとの最後のホップルータを使用する場合は、第1のバッファオーバーフローが、それは、ルータがバッファを多く持っていたならばより早く起こります。その後、バッファ数の少ない周期パケット損失は時に送信側プローブ利用可能な帯域幅のため、輻輳回避中に、より頻繁に発生します。
The most important responsibility of router buffers is to absorb bursts. Too few buffers (for example, only three buffers per outbound link as described in [RFC2416]) means that routers will overflow their buffer pools very easily and are unlikely to absorb even a very small burst. When a larger number of router buffers are allocated per outbound link, the buffer space does not overflow as quickly but the buffers are still likely to become full due to TCP's default behavior. A larger number of router buffers leads to longer queuing delays and a longer RTT.
ルータのバッファの最も重要な責任は、バーストを吸収することです。少なすぎるバッファは、（例えば、[RFC2416]に記載されているようにアウトバウンドリンクあたりわずか3つのバッファ）がルータが非常に簡単にバッファプールをオーバーフローさせても非常に小さいバーストを吸収する可能性は低いであろうことを意味します。ルータのバッファの数が多いほど、アウトバウンドリンクごとに割り当てられている場合には、バッファ空間が早くオーバーフローしませんが、バッファはまだによるTCPのデフォルトの動作にいっぱいになりそうです。ルータのバッファの数が多いほど、長い遅延と長いRTTをキューイングにつながります。
If router queues become full before congestion is signaled or remain full for long periods of time, this is likely to result in "lock-out", where a single connection or a few connections occupy the router queue space, preventing other connections from using the link [RFC2309], especially when a tail drop queue management discipline is being used.
ルータのキューが輻輳が通知される前に一杯になったり、長時間のフル残っている場合、これは単一の接続または少数の接続が使用してから他の接続を防止し、ルータのキュースペースを占有する「ロックアウト」をもたらす可能性がありますテールドロップキュー管理規律が使用されている、特にリンク[RFC2309]、。
Therefore, it is essential to have a large enough number of buffers in routers to be able to absorb data bursts, but keep the queues normally small. In order to achieve this it has been recommended in [RFC2309] that an active queue management mechanism, like Random Early Detection (RED) [RED93], should be implemented in all Internet routers, including the last-hop routers in front of a slow link. It should also be noted that RED requires a sufficiently large number of router buffers to work properly. In addition, the appropriate parameters of RED on a last-hop router connected to a slow link will likely deviate from the defaults recommended.
したがって、データバーストを吸収できるようにするには、ルータのバッファの十分な大きさの数を持っていますが、通常は小さなキューを維持するために不可欠です。これを達成するためには、ランダム早期検出（RED）のようなアクティブキュー管理機構[RED93]は、遅いの前で最後のホップルータを含め、すべてのインターネットルータに実装されるべきであること、[RFC2309]で推奨されていますリンク。また、REDが適切に動作するルータのバッファの十分な数を必要とすることに留意すべきです。また、低速リンクに接続され、最後のホップルータ上のREDの適切なパラメータは、おそらく推奨デフォルトからずれてしまいます。
Active queue management mechanism do not eliminate packet drops but, instead, drop packets at earlier stage to solve the full-queue problem for flows that are responsive to packet drops as congestion signal. Hosts that are directly connected to low-speed links may limit the receive windows they advertise in order to lower or eliminate the number of packet drops in a last-hop router. When doing so one should, however, take care that the advertised window is large enough to allow full utilization of the last-hop link capacity and to allow triggering fast retransmit, when a packet loss is encountered. This recommendation takes two forms:
アクティブキュー管理機構がパケットのドロップを排除したが、その代わり、混雑信号としてドロップしたパケットに応答する流れのためのフルキューの問題を解決するために早い段階でパケットをドロップしません。直接低速リンクに接続されているホストは、彼らが、パケットの数は最後のホップルータに低下下げるか、排除するために宣伝受信ウィンドウを制限する可能性があります。その際一つは、しかし、パケットロスが発生したときに、広告ウィンドウが最終ホップリンク容量の完全な利用を可能にし、高速再送をトリガできるように十分な大きさであることに注意する必要があります。この推奨事項は、次の2つの形式をとります。
- Modern operating systems use relatively large default TCP receive buffers compared to what is required to fully utilize the link capacity of low-speed links. Users should be able to choose the default receive window size in use - typically a system-wide parameter. (This "choice" may be as simple as "dial-up access/LAN access" on a dialog box - this would accommodate many environments without requiring hand-tuning by experienced network engineers.)
- 現代のオペレーティングシステムは、比較的大型のデフォルトのTCPが完全に低速リンクのリンク容量を利用するために必要とされるものに比べて受信バッファを使用します。通常、システム全体のパラメータを - ユーザーが使用中の受信ウィンドウサイズをデフォルトを選択することができるはずです。 （これは、「選択」ダイアログボックスの「ダイヤルアップアクセス/ LANアクセス」のような単純なものも - これは、経験豊富なネットワークエンジニアによって手チューニングを必要とせずに、多くの環境に対応します。）
- Application developers should not attempt to manually manage network bandwidth using socket buffer sizes. Only in very rare circumstances will an application actually know both the bandwidth and delay of a path and be able to choose a suitably low (or high) value for the socket buffer size to obtain good network performance.
- アプリケーション開発者は手動でソケットバッファサイズを使用してネットワーク帯域幅を管理するために試みるべきではありません。ごくまれに、アプリケーションは、実際には、パスの帯域幅と遅延の両方を知っていると良いネットワーク性能を得るために、ソケットバッファサイズのために適切に低い（または高い）値を選択することができるであろう。
This recommendation is not a general solution for any network path that might involve a slow link. Instead, this recommendation is applicable in environments where the host "knows" it is always connected to other hosts via "slow links". For hosts that may connect to other host over a variety of links (e.g., dial-up laptop computers with LAN-connected docking stations), buffer auto-tuning for the receive buffer is a more reasonable recommendation, and is discussed below.
この勧告は、低速リンクを伴う可能性のあるネットワーク経路のための一般的なソリューションではありません。代わりに、この勧告は、ホストが、それが常に「低速リンク」を経由して他のホストに接続されている「知っている」環境に適用可能です。受信バッファの自動チューニングをバッファ（例えば、ダイヤルアップLAN接続されたドッキングステーションを有するラップトップコンピュータ）をリンクの多様を介して他のホストに接続できるホストのためのより合理的な勧告であり、そして以下に説明されます。
[SMM98] recognizes a tension between the desire to allocate "large" TCP buffers, so that network paths are fully utilized, and a desire to limit the amount of memory dedicated to TCP buffers, in order to efficiently support large numbers of connections to hosts over network paths that may vary by six orders of magnitude.
【SMM98】効率的にホストへの接続の多数をサポートするために、ネットワークパスを完全に利用されるように、「大」TCPバッファを割り当てる欲望、およびTCPバッファ専用のメモリの量を制限したいという要望との間の緊張を認識する6桁によって変化し得るネットワーク経路上。
The technique proposed is to dynamically allocate TCP buffers, based on the current congestion window, rather than attempting to preallocate TCP buffers without any knowledge of the network path.
提案された技術ではなく、ネットワークパスの知識なしTCPバッファを事前に割り当てしようとするよりも、現在の輻輳ウィンドウに基づいて、動的にTCPバッファを割り当てることです。
This proposal results in receive buffers that are appropriate for the window sizes in use, and send buffers large enough to contain two windows of segments, so that SACK and fast recovery can recover losses without forcing the connection to use lengthy retransmission timeouts.
この提案は、の結果は、使用中のウィンドウサイズに適した受信バッファ、およびSACKと速い回復は長い再送タイムアウトを使用する接続を強制することなく、損失を回復することができるように、セグメントの2つのウィンドウが含まれているのに十分な大きさのバッファを送信します。
While most of the motivation for this proposal is given from a server's perspective, hosts that connect using multiple interfaces with markedly-different link speeds may also find this kind of technique useful. This is true in particular with slow links, which are likely to dominate the end-to-end RTT. If the host is connected only via a single slow link interface at a time, it is fairly easy to (dynamically) adjust the receive window (and thus the advertised window) to a value appropriate for the slow last-hop link with known bandwidth and delay characteristics.
この提案の動機の大部分は、サーバの観点から与えられるが、著しく、異なるリンク速度で複数のインタフェースを使用して接続するホストはまた、有用な技術のこの種を見つけることができます。これは、エンドツーエンドのRTTを支配する可能性がある低速リンク、と特に真実です。ホストが一度に単一の低速リンクインターフェースを介して接続されている場合、それはにかなり容易である（動的に）受信ウィンドウを調整する（したがって広告ウィンドウ）は、既知の帯域幅を持つ遅い最終ホップリンクのために適切な値へと遅延特性。
Recommendation: If a host is sometimes connected via a slow link but the host is also connected using other interfaces with markedly-different link speeds, it may use receive buffer auto-tuning to adjust the advertised window to an appropriate value.
推奨：ホストが時々低速リンクを介して接続されているが、ホストも著しく、異なるリンク速度で他のインターフェースを用いて接続されている場合、それは適切な値に広告ウィンドウを調整するために、バッファの自動チューニングを受信使用してもよいです。
If a TCP connection stabilizes with a congestion window of only a few segments (as could be expected on a "slow" link), the sender isn't sending enough segments to generate three duplicate acknowledgements, triggering fast retransmit and fast recovery. This means that a retransmission timeout is required to repair the loss - dropping the TCP connection to a congestion window with only one segment.
TCP接続が（「遅い」のリンクを期待できるとして）わずか数セグメントの輻輳ウィンドウで安定している場合、送信者は、3つの重複確認応答を生成するのに十分なセグメントを送信する高速再送と高速リカバリをトリガされていません。唯一のセグメントで輻輳ウィンドウへのTCP接続をドロップする - これは、再送タイムアウトが損失を修復するために必要であることを意味します。
[TCPB98] and [TCPF98] observe that (in studies of network trace datasets) it is relatively common for TCP retransmission timeouts to occur even when some duplicate acknowledgements are being sent. The challenge is to use these duplicate acknowledgements to trigger fast retransmit/fast recovery without injecting traffic into the network unnecessarily - and especially not injecting traffic in ways that will result in instability.
[TCPB98]と[TCPF98] TCP再送タイムアウトが一部重複確認応答が送信されている場合でも発生するため（ネットワークトレースデータセットの研究で）それは比較的一般的であることを確認します。特に不安定になります方法でトラフィックを注入していない - 課題は、不必要にネットワークにトラフィックを注入することなく、高速再送/高速回復をトリガするためにこれらの重複確認応答を使用することです。
The "Limited Transmit" algorithm [RFC3042] suggests sending a new segment when the first and second duplicate acknowledgements are received, so that the receiver is more likely to be able to continue to generate duplicate acknowledgements until the TCP retransmit threshold is reached, triggering fast retransmit and fast recovery. When the congestion window is small, this is very useful in assisting fast retransmit and fast recovery to recover from a packet loss without using a retransmission timeout. We note that a maximum of two additional new segments will be sent before the receiver sends either a new acknowledgement advancing the window or two additional duplicate acknowledgements, triggering fast retransmit/fast recovery, and that these new segments will be acknowledgement-clocked, not back-to-back.
「リミテッド送信」アルゴリズム[RFC3042]は、高速トリガは、第1および第2の重複確認応答を受信したとき受信機はTCP再送信閾値に到達するまで、重複確認応答を生成し続けることができやすくなるように、新たなセグメントを送信示唆します再送と高速回復。輻輳ウィンドウが小さい場合には、これは再送タイムアウトを使用せずに、パケットの損失から回復するために高速再送と高速回復を補助するのに非常に便利です。私たちは、受信機が高速再送/高速回復をトリガ、ウィンドウまたは二つの追加の重複確認応答を進めるのいずれかの新しい確認を送信する前に2つの追加の新しいセグメントの最大が送信されること、およびこれらの新しいセグメントは、確認応答クロックされていない戻ってくることに注意してください-to-バック。
Recommendation: Limited Transmit should be implemented in all hosts.
勧告：リミテッド送信は、すべてのホストで実施されるべきです。
This section summarizes our recommendations regarding the previous standards-track mechanisms, for end nodes that are connected via a slow link.
このセクションでは、低速リンクを介して接続されているエンドノードのために、従来の規格トラックメカニズムに関する当社提言をまとめました。
Header compression should be implemented. [RFC1144] header compression can be enabled over robust network links. [RFC2507] should be used over network connections that are expected to experience loss due to corruption as well as loss due to congestion. For extremely lossy and slow links, implementors should evaluate ROHC [RFC3095] as a potential solution. [RFC1323] TCP timestamps must be turned off because (1) their protection against TCP sequence number wrapping is unjustified for slow links, and (2) they complicate TCP header compression.
ヘッダ圧縮を実装する必要があります。 [RFC1144]ヘッダー圧縮は、堅牢なネットワークリンクを介して有効にすることができます。 [RFC2507]は混雑に起因破損並びに損失に損失が発生することが予想されるネットワーク接続で使用されるべきです。非常に非可逆と低速リンクについては、実装者は、潜在的な解決策として、ROHC [RFC3095]を評価する必要があります。 （1）TCPシーケンス番号ラッピングに対するその保護は低速リンクのために不当であり、そして（2）それらがTCPヘッダー圧縮を複雑にするので、[RFC1323]は、TCPタイムスタンプをオフにしなければなりません。
IP Payload Compression [RFC2393] should be implemented, although compression at higher layers of the protocol stack (for example [RFC 2616]) may make this mechanism less useful.
プロトコルスタックの上位層に圧縮（例えば、[RFC 2616]）このメカニズムはあまり有用なものかもしれないIPペイロード圧縮[RFC2393]は、実装されるべきです。
For HTTP/1.1 environments, [RFC2616] payload compression should be implemented and should be used for payloads that are not already compressed.
HTTP / 1.1環境では、[RFC2616]ペイロード圧縮が実施されるべきであり、既に圧縮されていないペイロードに使用されるべきです。
Implementors should choose MTUs that don't monopolize network interfaces for more than 100-200 milliseconds, in order to limit the impact of a single connection on all other connections sharing the network interface.
実装は、ネットワークインターフェースを共有する他のすべての接続上の単一の接続の影響を制限するために、より100-200ミリ秒ネットワークインターフェースを独占していないのMTUを選択しなければなりません。
Use of active queue management is recommended on last-hop routers that provide Internet access to host behind a slow link. In addition, number of router buffers per slow link should be large enough to absorb concurrent data bursts from more than a single flow. To absorb concurrent data bursts from two or three TCP senders with a typical data burst of three back-to-back segments per sender, at least six (6) or nine (9) buffers are needed. Effective use of active queue management is likely to require even larger number of buffers.
アクティブキュー管理の使用は低速リンクの後ろにホストへのインターネットアクセスを提供し、最後のホップルータに推奨されます。また、低速リンクあたりのルータのバッファの数は、単一のフローよりも多くの同時データバーストを吸収するのに十分な大きさでなければなりません。 、送信者ごとに3つのバックツーバックセグメントの典型的なデータバーストを有する2つのまたは3つのTCPセンダからの少なくとも6個または9の同時データバーストを吸収する（9）バッファが必要とされています。アクティブキュー管理の有効活用は、バッファのさらに大きな数を必要とする可能性が高いです。
Implementors should consider the possibility that a host will be directly connected to a low-speed link when choosing default TCP receive window sizes.
実装者は、デフォルトのTCPウィンドウサイズを受け取り選択する際、ホストが直接低速リンクに接続される可能性を検討すべきです。
Application developers should not attempt to manually manage network bandwidth using socket buffer sizes as only in very rare circumstances an application will be able to choose a suitable value for the socket buffer size to obtain good network performance.
アプリケーション開発者は、手動でアプリケーションが優れたネットワークパフォーマンスを得るために、ソケットバッファサイズに適した値を選択することができます非常にまれな状況でのみとソケットバッファサイズを使用してネットワーク帯域幅を管理するために試みるべきではありません。
Limited Transmit [RFC3042] should be implemented in all end hosts as it assists in triggering fast retransmit when congestion window is small.
それは混雑ウィンドウが小さい場合に高速再送信をトリガするのを助けるように限られた送信[RFC3042]は全てのエンドホストに実装されるべきです。
All of the mechanisms described above are stable standards-track RFCs (at Proposed Standard status, as of this writing).
上述した機構の全ては、安定した基準トラックのRFC（提案された標準状態で、これを書いているような）です。
In addition, implementors may wish to consider TCP buffer auto-tuning, especially when the host system is likely to be used with a wide variety of access link speeds. This is not a standards-track TCP mechanism but, as it is an operating system implementation issue, it does not need to be standardized.
また、実装者は、ホストシステムがアクセスリンク速度の多種多様で使用される可能性がある場合は特に、TCPバッファの自動チューニングを検討することを望むかもしれません。これは、標準トラックTCPメカニズムはありませんが、それは、オペレーティングシステムの実装の問題であるとして、それが標準化される必要はありません。
Of the above mechanisms, only Header Compression (for IP and TCP) may cease to work in the presence of end-to-end IPSEC. However, [RFC3095] does allow compressing the ESP header.
上記のメカニズム、（IPおよびTCPのための）唯一のヘッダー圧縮は、エンド・ツー・エンドのIPSECの存在下で働くのをやめることがあります。しかしながら、[RFC3095]はESPヘッダを圧縮することを可能ありません。
In addition to the standards-track mechanisms discussed above, there are still opportunities to improve performance over low-speed links.
上記の標準トラックメカニズムに加えて、低速リンクでのパフォーマンスを改善する機会はまだあります。
"Sending fewer bits" is an obvious response to slow link speeds. The now-defunct HTTP-NG proposal [HTTP-NG] replaced the text-based HTTP header representation with a binary representation for compactness. However, HTTP-NG is not moving forward and HTTP/1.1 is not being enhanced to include a more compact HTTP header representation. Instead, the Wireless Application Protocol (WAP) Forum has opted for the XML-based Wireless Session Protocol [WSP], which includes a compact header encoding mechanism.
「より少ないビットを送信する」リンク速度を遅くする明白な応答です。今はなきHTTP-NG提案[HTTP-NGは】小型のバイナリ表現とテキストベースのHTTPヘッダ表現を置き換えます。しかし、HTTP-NGは前進せず、HTTP / 1.1は、よりコンパクトなHTTPヘッダ表現を含むように拡張されていません。代わりに、ワイヤレスアプリケーションプロトコル（WAP）フォーラムは、コンパクトヘッダ符号化機構を含むXMLベースの無線セッションプロトコル[WSP]を選択しました。
It would be nice to agree on a more compact header representation that will be used by all WWW communities, not only the wireless WAN community. Indeed, general XML content encodings have been proposed [Millau], although they are not yet widely adopted.
それだけでなく、すべてのWWWコミュニティによって使用されるよりコンパクトなヘッダー表現に同意するワイヤレスWANコミュニティいいだろう。彼らはまだ広く採用されていないが、確かに、一般的なXMLコンテンツのエンコーディングは、[ミヨー]が提案されています。
We note that TCP options which change from segment to segment effectively disable header compression schemes deployed today, because there's no way to indicate that some fields in the header are unchanged from the previous segment, while other fields are not. The Robust Header Compression working group is developing such schemes for TCP options such as timestamps and selective acknowledgements. Hopefully, documents subsequent to [RFC3095] will define such specifications.
他のフィールドではない一方で、ヘッダーの一部のフィールドは、前のセグメントから変化していないことを示す方法はありませんので、我々は、セグメントにセグメントから変更TCPオプションの効果を無効にヘッダー圧縮スキームが今日配備されることに注意してください。ロバストヘッダ圧縮ワーキンググループは、このようなタイムスタンプと選択的確認応答などのTCPオプションのようなスキームを開発しています。うまくいけば、[RFC3095]に後続する文書は、そのような仕様を定義します。
Another effort worth following is that of 'Delta Encoding'. Here, clients that request a slightly modified version of some previously cached resource would receive a succinct description of the differences, rather than the entire resource [HTTP-DELTA].
以下の価値があるもう一つの取り組みは、「デルタエンコーディング」のことです。ここでは、いくつかの以前にキャッシュされたリソースを少し変更したバージョンを要求するクライアントは、違いの簡潔な説明、全体ではなく、リソース[HTTP-DELTA]を受け取ることになります。
All recommendations included in this document are stable standards-track RFCs (at Proposed Standard status, as of this writing) or otherwise do not suggest any changes to any protocol. With the exception of Van Jacobson compression [RFC1144] and [RFC2507, RFC2508, RFC2509], all other mechanisms are applicable to TCP connections protected by end-to-end IPSec. This includes ROHC [RFC3095], albeit partially, because even though it can compress the outermost ESP header to some extent, encryption still renders any payload data uncompressible (including any subsequent protocol headers).
推奨事項は、この文書に含まれるすべてのは、安定した標準化過程のRFC（案標準状態では、これを書いているように）しているか、そうでない場合は任意のプロトコルへの変更を示唆していません。ヴァンヤコブソン圧縮[RFC1144]及び[RFC2507、RFC2508、RFC2509]を除いて、全ての他のメカニズムは、エンドツーエンドのIPSecで保護されたTCP接続に適用可能です。部分的にいえ、それはある程度最外ESPヘッダを圧縮することができるにもかかわらず、暗号化がまだ（後続のプロトコルヘッダを含む）非圧縮任意のペイロードデータをレンダリングするので、これは、ROHC [RFC3095]を含みます。
This document is a pointer to other, existing IETF standards. There are no new IANA considerations.
この文書は、他の既存のIETF標準へのポインタです。新しいIANAの考慮事項はありません。
This recommendation has grown out of "Long Thin Networks" [RFC2757], which in turn benefited from work done in the IETF TCPSAT working group.
この勧告は、順番にIETF TCPSATワーキンググループで行われた作業の恩恵を受けた「ロングシンネットワーク」[RFC2757]、外に成長してきました。
[AlPa99] Mark Allman and Vern Paxson, "On Estimating End-to-End Network Path Properties", in ACM SIGCOMM 99 Proceedings, 1999.
[AlPa99]マークオールマンとバーン・パクソン、ACM SIGCOMMで、99回の議事録、1999「推定エンドツーエンドのネットワークパスのプロパティに」。
[HTTP-DELTA] J. Mogul, et al., "Delta encoding in HTTP", Work in Progress.
[HTTP-DELTA] J.モーグル、ら、 "HTTPにおけるデルタ符号化は" 進行中の作業します。
[HTTP-NG] Mike Spreitzer, Bill Janssen, "HTTP 'Next Generation'", 9th International WWW Conference, May, 2000. Also available as: http://www.www9.org/w9cdrom/60/60.html
[HTTP-NG]マイク・スプレイッツァー、ビル・ヤンセン、「HTTP 『次世代』」、第9回国際WWW会議、月、2000年も利用できるように：http://www.www9.org/w9cdrom/60/60.html
[Millau] Marc Girardot, Neel Sundaresan, "Millau: an encoding format for efficient representation and exchange of XML over the Web", 9th International WWW Conference, May, 2000. Also available as: http://www.www9.org/w9cdrom/154/154.html
[ミヨー]マルク・ジラルド、ネールSundaresan、「ミヨー：効率的な表現やWeb上でXMLを交換するための符号化形式」、第9回国際WWW会議、月、としても利用できる2000：http://www.www9.org/ w9cdrom / 154 / 154.html
[PAX97] Paxson, V., "End-to-End Internet Packet Dynamics", 1997, in SIGCOMM 97 Proceedings, available as: http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-97.html
[PAX97]パクソン、V.、 "エンドツーエンドのインターネットパケットダイナミクス" 利用できるよう、1997年、SIGCOMM 97回の議事録では、：http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr -TOC-97.html
[RED93] Floyd, S., and Jacobson, V., Random Early Detection gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, pp. 397-413. Also available from http://ftp.ee.lbl.gov/floyd/red.html.
[RED93]フロイド、S.、およびヤコブソン、V.、輻輳回避のためのランダム早期検出・ゲートウェイ、ネットワーク、V.1 N.4、1993年8月、頁上のIEEE / ACM取引。397から413まで。またhttp://ftp.ee.lbl.gov/floyd/red.htmlから入手できます。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol: Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコル：バージョン1.0"、RFC 2246、1999年1月。
[RFC2309] Braden, R., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]ブレーデン、R.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.とL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, December 1998.
[RFC2393] Shacham、A.、Monsour、R.、ペレイラ、R.とM.トーマス、 "IPペイロード圧縮プロトコル（IPCompの）"、RFC 2393、1998年12月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[RFC2416]シェパード、T.とC.パートリッジ、RFC 2416、1998年9月「TCPは3つしかバッファに4つのパケットで起動」。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B.とS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[RFC2508] Casner, S. and V. Jacobson. "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S.及びV.ヤコブソン。 、RFC 2508、1999年2月 "低速シリアルリンクのための圧縮IP / UDP / RTPヘッダ"。
[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[RFC2509] Engan、M.、Casner、S.とC.ボルマン、 "PPP上のIPヘッダー圧縮"、RFC 2509、1999年2月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[RFC2757]モンテネグロ、G.、ドーキンス、S.、古城、M.、Magret、V.、およびN. Vaidya、 "細長いネットワーク"、RFC 2757、2000年1月。
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]オールマン、M.、バラクリシュナン、H.とS.フロイド、 "株式会社トランスミットを使用したTCPの損失回復の強化"、RFC 3042、2001年1月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four Profiles: RTP, UDP ESP and uncompressed", RFC 3095, July 2001.
[RFC3095]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.とH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP ESPと2001年7月、RFC 3095、」圧縮されていません。
[SMM98] Jeffrey Semke, Matthew Mathis, and Jamshid Mahdavi, "Automatic TCP Buffer Tuning", in ACM SIGCOMM 98 Proceedings 1998. Available from http://www.acm.org/sigcomm/sigcomm98/tp/abs_26.html.
[SMM98]ジェフリーSemke、マシュー・マティス、およびジャムシードMahdavi、 "自動TCPバッファ調整"、ACM SIGCOMMで98の議事http://www.acm.org/sigcomm/sigcomm98/tp/abs_26.htmlから利用可能な1998年。
[SSL] Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol: Version 3.0, March 1996. (Expired Internet-Draft, available from http://home.netscape.com/eng/ssl3/ssl-toc.html)
[SSL]アラン・O.フライアー、フィリップKarlton、ポール・C.コッヘル、SSLプロトコル：バージョン3.0、1996年3月（期限切れのインターネットドラフト、http://home.netscape.com/eng/ssl3/ssl-から入手可能toc.html）
[TCPB98] Hari Balakrishnan, Venkata N. Padmanabhan, Srinivasan Seshan, Mark Stemm, Randy H. Katz, "TCP Behavior of a Busy Internet Server: Analysis and Improvements", IEEE Infocom, March 1998. Available from: http://www.cs.berkeley.edu/~hari/papers/infocom98.ps.gz
[TCPB98]ハリ・バラクリシュナン、ヴェンカタN. Padmanabhan、スリニバサン・セシャン、マーク・Stemm、ランディH.カッツ、「忙しいインターネットサーバのTCPの挙動：分析と改善」、IEEEインフォコム、から利用可能な1998年3月：のhttp：// WWW .cs.berkeley.edu /〜ハリ/論文/ infocom98.ps.gz
[TCPF98] Dong Lin and H.T. Kung, "TCP Fast Recovery Strategies: Analysis and Improvements", IEEE Infocom, March 1998. Available from: http://www.eecs.harvard.edu/networking/papers/ infocom-tcp-final-198.pdf
【TCPF98]ドンリン及びH.T.クン、「TCP高速リカバリ戦略：分析と改善」、IEEEインフォコム、から利用可能な1998年3月：http://www.eecs.harvard.edu/networking/papers/インフォコム-TCP-最終-198.pdf
[WSP] Wireless Application Protocol Forum, "WAP Wireless Session Protocol Specification", approved 4 May, 2000, available from http://www1.wapforum.org/tech/documents/WAP-203-WSP-20000504-a.pdf. (informative reference).
[WSP]ワイヤレスアプリケーションプロトコルフォーラム、「WAP無線セッションプロトコル仕様」、http://www1.wapforum.org/tech/documents/WAP-203-WSP-20000504-a.pdfから入手できる2000年5月4日に、承認されました。 （参考参照）。
Authors' Addresses
著者のアドレス
Questions about this document may be directed to:
このドキュメントに関するご質問は、対象とすることができます。
Spencer Dawkins Fujitsu Network Communications 2801 Telecom Parkway Richardson, Texas 75082
スペンサー・ドーキンス富士通ネットワークコミュニケーションズ2801テレコムパークウェイリチャードソン、テキサス州75082
Phone: +1-972-479-3782 EMail: spencer.dawkins@fnc.fujitsu.com
電話：+ 1-972-479-3782 Eメール：spencer.dawkins@fnc.fujitsu.com
Gabriel Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan, FRANCE
ガブリエルモンテネグロSun Microsystemsの研究所、欧州29、CHEMINドゥヴューシュヌ38240メラン、フランス
Phone: +33 476 18 80 45 EMail: gab@sun.com
電話：+33 476 18 80 45 Eメール：gab@sun.com
Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
コンピュータサイエンス、ヘルシンキ大学、私書箱のマルック古城部門ボックス26（Teollisuuskatu 23）FIN-00014ヘルシンキ、フィンランド
Phone: +358-9-1914-4179 Fax: +358-9-1914-4441 EMail: kojo@cs.helsinki.fi
電話：+ 358-9-1914-4179ファックス：+ 358-9-1914-4441 Eメール：kojo@cs.helsinki.fi
Vincent Magret Alcatel Internetworking, Inc. 26801 W. Agoura road Calabasas, CA, 91301
ヴィンセントMagretアルカテル・インターネット、Inc.の26801のW.アゴーラ道路カラバサス、CA、91301
Phone: +1 818 878 4485 EMail: vincent.magret@alcatel.com
電話：+1 818 878 4485 Eメール：vincent.magret@alcatel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。