[要約] 要約：RFC 3150は、遅いリンクのエンドツーエンドのパフォーマンスへの影響についての情報を提供しています。 目的：このRFCの目的は、遅いリンクがネットワークパフォーマンスに与える影響を理解し、適切な対策を講じるためのガイドラインを提供することです。
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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/2番目のモデムリンクまたは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.
World Wide Wide Webアプリケーションプロトコルは、データ（Telnetなど）を送信するインタラクティブなアプリケーションまたはインタラクティブな応答を必要としないバルク転送アプリケーション（ファイル転送プロトコル、ネットワークニュースなど）のいずれかである傾向がありました。World Wide Webは、画像、サウンド、ビデオなど、インタラクティブでしばしば「かさばる」トラフィックを与えてくれました。
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.
World Wide Webもインターネットを普及させているため、典型的なオフィスネットワークの速度よりも「遅い」リンク速度を介してインターネットにアクセスすることに大きな関心があります。実際、現在のインターネットユーザーのかなりの割合が、比較的遅いラストホップリンクを介してインターネットに接続されています。将来的には、さまざまなモバイルデバイスが遅いワイヤレスリンクを介してインターネットに添付されると予測されるため、このようなユーザーの数は急速に増加する可能性があります。
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ヘッダーのオーバーヘッドは、ほとんどのパケットの場合、典型的な40バイトヘッダーで約13％から1〜1.5％に減少します。。これにより、小さなセグメントサイズが少ない場合でも、遅延に敏感な低データレートトラフィックとバルクデータの優れたライン効率に小さなパケットを使用できます（遅いリンクで小さな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ヘッダー圧縮の提案された標準です。残念ながら、1つのビットエラーでもコンプレッサーと減圧装置間の同期が失われるため、Lossy Linksで脆弱です。TCPのタイムアウトを使用してそのような同期の損失を検出しますが、これらのエラーはデータの損失（完全なTCPウィンドウまで）、完全なRTOの遅延、および不必要なスロースタートをもたらします。
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.
上記のスキームは、多くの細胞リンクの範囲と同じくらい極端な条件下でうまく機能しなくなります（100ミリ秒以上の1E-3または1E-2のエラー条件と往復時間）。これらの場合、「堅牢なヘッダー圧縮」ワーキンググループが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 RTT推定値を改善します。TCPタイムスタンプを使用すると、タイムスタンプがTCPオプションとして送信されるため、ヘッダー圧縮が防止されます。つまり、各タイムスタンプヘッダーには、以前のヘッダーとは異なるTCPオプションがあり、変更されたTCPオプションを備えたヘッダーは常に圧縮されていないと送信されます。さらに、タイムスタンプはRTO推定に大きな影響を与えていないようです[Alpa99]。
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ペイロードは既に圧縮されています（画像、オーディオ、ビデオ、「ジップ」ファイルが転送されています）、またはすでに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が遅延ACKタイムアウト（通常200ミリ秒）よりも長い間リンクを占有している場合、このタイムアウトは、各セグメントではなく、すべてのセグメントで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.
第4に、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接続には、「アクセス」リンクとして遅いリンクがあり、ほとんどの接続パスでより高速リンクが使用されています。一般的な構成の1つは、端子サーバー（最終ホップルーター）へのダイヤルアップアクセスを使用したラップトップコンピューターであり、ターミナルサーバーの背後に「高速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.
Link MTUが遅延したACKタイムアウト間隔を超えてパケットを送信するのに十分な大きさである場合、すべてのセグメントに対してACKが送信され、単一のRTTで輻輳ウィンドウが2倍になります。小さいリンク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.
アウトバウンドリンクごとに少数のバッファーを備えたラストホップルーターを使用すると、ルーターにバッファーが多い場合よりも早くバッファオーバーフローが発生します。その後、バッファーの数が少ないと、周期的なパケット損失は、送信者が利用可能な帯域幅をプローブするときに、渋滞回避中により頻繁に発生します。
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.
したがって、データバーストを吸収できるようにルーターに十分な数のバッファーを持つことが不可欠ですが、キューは通常小さくなります。これを達成するために、[RFC2309]では、ランダムアーリー検出（RED）[RED93]などのアクティブキュー管理メカニズムが、スローの前のラストホップルーターを含むすべてのインターネットルーターに実装する必要があることが推奨されています。リンク。また、赤が適切に機能するために十分に多数のルーターバッファーが必要であることに注意する必要があります。さらに、遅いリンクに接続されたラストホップルーター上の赤の適切なパラメーターは、推奨されるデフォルトから逸脱する可能性があります。
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.
この提案の結果、使用中のウィンドウサイズに適したバッファーを受信し、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つの重複した謝辞を生成するのに十分なセグメントを送信していないため、高速な再送信と迅速な回復をトリガーします。これは、損失を修復するために再送信タイムアウトが必要であることを意味します - 1つのセグメントのみで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つの追加の重複謝辞のいずれかを送信する前に、最大2つの追加の新しいセグメントが送信され、高速再送信/高速回復をトリガーし、これらの新しいセグメントは承認詰まっています。 - バックへ。
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]を評価する必要があります。[RFC1323] TCPタイムスタンプは、（1）TCPシーケンス数ラッピングに対する保護が遅いリンクに対して不当であり、（2）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.
IPペイロード圧縮[RFC2393]を実装する必要がありますが、プロトコルスタックの高層での圧縮（たとえば[RFC 2616]）により、このメカニズムがそれほど有用ではない場合があります。
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.
ワイヤレスWANコミュニティだけでなく、すべてのWWWコミュニティで使用される、よりコンパクトなヘッダー表現に同意することは素晴らしいことです。実際、一般的なXMLコンテンツのエンコーディングが提案されています[Millau]が、まだ広く採用されていません。
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オプションに注意してください。堅牢なヘッダー圧縮ワーキンググループは、タイムスタンプや選択的謝辞などの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].
従う価値のあるもう1つの努力は、「デルタエンコーディング」の努力です。ここでは、以前にキャッシュされたいくつかのリソースのわずかに変更されたバージョンを要求するクライアントは、リソース全体ではなく、違いの簡潔な説明を受け取ります[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（この記述のように提案された標準ステータス）であるか、その他のプロトコルの変更を提案しません。Van Jacobson圧縮[RFC1144]および[RFC2507、RFC2508、RFC2509]を除き、他のすべてのメカニズムは、エンドツーエンドのIPSECによって保護されているTCP接続に適用できます。これには、部分的にはROHC [RFC3095]が含まれますが、最も外側のESPヘッダーをある程度圧縮できるにもかかわらず、暗号化によりペイロードデータが圧縮されないようになります（後続のプロトコルヘッダーを含む）。
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.
この推奨事項は、「長い薄いネットワーク」[RFC2757]から成長し、IETF TCPSATワーキンググループで行われた作業の恩恵を受けました。
[AlPa99] Mark Allman and Vern Paxson, "On Estimating End-to-End Network Path Properties", in ACM SIGCOMM 99 Proceedings, 1999.
[Alpa99] Mark Allman and Vern Paxson、「エンドツーエンドのネットワークパスプロパティの推定について」、ACM Sigcomm 99 Proceedings、1999。
[HTTP-DELTA] J. Mogul, et al., "Delta encoding in HTTP", Work in Progress.
[http-delta] J. Mogul、et al。、「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 'next Generation'」、第9回国際WWW会議、2000年5月。http：//www.www.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
[ミラウ]マーク・ジラルド、ニール・スンダレサン、「ミラウ：ウェブ上のXMLの効率的な表現と交換のためのエンコーディング形式」、2000年5月9日。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] Paxson、V。、「エンドツーエンドのインターネットパケットダイナミクス」、1997年、Sigcomm 97 Proceedings、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] Floyd、S。、およびJacobson、V.、渋滞回避のためのランダムな早期検出ゲートウェイ、IEEE/ACMトランザクション、v.1 N.4、1993年8月、pp。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] 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月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol: Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「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] 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、「インターネットでのキュー管理と混雑回避に関する推奨事項」、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.、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月。
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[RFC2416] Shepard、T。およびC. Partridge、「TCPが4つのパケットから3つのバッファーに始まるとき」、RFC 2416、1998年9月。
[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月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、 "Hypertext Transfer Protocol-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] Montenegro、G.、Dawkins、S.、Kojo、M.、Magret、V。、およびN. Vaidya、「Long Thin Networks」、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] Allman、M.、Balakrishnan、H。およびS. Floyd、「限定送信を使用した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] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T。、およびH. Zheng、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP ESPおよび非圧縮」、RFC 3095、2001年7月。
[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] Jeffrey Semke、Matthew Mathis、およびJamshid Mahdavi、「自動TCPバッファーチューニング」、ACM Sigcomm 98 Proceedings 1998. http://www.acm.org/sigcomm/sigcomm98/tp/abs_26.html。
[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] Alan O. Freier、Philip Karlton、Paul C. Kocher、The SSL Protocol：バージョン3.0、1996年3月。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] Hari Balakrishnan、Venkata N. Padmanabhan、Srinivasan Seshan、Mark Stemm、Randy H. Katz、「忙しいインターネットサーバーのTCP動作：分析と改善」、IEEE Infocom、1998年3月.cs.berkeley.edu/〜hari/papers/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.Kung、「TCP高速回復戦略：分析と改善」、IEEE Infocom、1998年3月。http：//www.eecs.harvard.edu/networking/papers/ infocom-tcp-final-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ワイヤレスセッションプロトコル仕様」、2000年5月4日承認、http：//www1.wapforum.org/tech/documents/wap-203-wsp-20000504-a.pdfから入手可能。（有益なリファレンス）。
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
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
Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
ヘルシンキ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
Vincent Magret Alcatel Internetworking, Inc. 26801 W. Agoura road Calabasas, CA, 91301
Vincent Magret Alcatel InternetWorking、Inc。26801 W. Agoura Road Calabasas、CA、91301
Phone: +1 818 878 4485
EMail: vincent.magret@alcatel.com
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エディター機能の資金は現在、インターネット協会によって提供されています。