RFC3150 日本語訳
3150 End-to-end Performance Implications of Slow Links. S. Dawkins, G.Montenegro, M. Kojo, V. Magret. July 2001. (Format: TXT=39942 bytes) (Also BCP0048) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Dawkins
Request for Comments: 3150 G. Montenegro
BCP: 48 M . Kojo
Category: Best Current Practice V. Magret
July 2001
コメントを求めるワーキンググループS.ダウキンズの要求をネットワークでつないでください: 3150G.モンテネグロBCP: 48M Kojoカテゴリ: 最も良い現在の練習V.Magret2001年7月
End-to-end Performance Implications of Slow Links
終わりから終わりへの遅いリンクのパフォーマンス含意
Status of this Memo
この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.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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/第2ワイヤレス・アクセスがリンクされるどんなネットワーク(それの両方が広く配布される)でも役に立つかもしれません。
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.
このドキュメントには、RFC2689と共用していくつかの推薦があります、「低いbitrateリンクの上に統合サービスを供給し」て、特にヘッダー圧縮のような領域で。 このドキュメントは「ベストエフォート型配送」が適切である伝統的なデータアプリケーションにさらに焦点を合わせます。
Dawkins, et al. Best Current Practice [Page 1] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[1ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
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
1.0序論… 2 2.0 最適化の記述… 3 2.1 ヘッダー圧縮代替手段… 3 2.2 有効搭載量圧縮代替手段… 5 2.3 選んでいるMTUサイズ… 5 TCP混雑との2.4回の相互作用が[RFC2581]を制御します… 6 2.5 TCPは自動チューニングをバッファリングします… 9 2.6 小さい窓の効果… 10 お勧めの最適化の3.0概要… 10 さらなる仕事のための4.0の話題… 12 5.0 セキュリティ問題… 12 6.0 IANA問題… 13 7.0の承認… 13 8.0の参照箇所… 13人の作者のアドレス… 16 完全な著作権宣言文… 17
1.0 Introduction
1.0 序論
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拡張子」[RFC1323]で説明されるように比例するTCPの窓の使用)だけでこのデザイン目標を達成しました。
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.
プレWWWアプリケーション・プロトコルは、データをわずか、に送る対話型アプリケーション(例えば、Telnet)か対話的な応答を必要としなかったバルク転送アプリケーション(例えば、File Transferプロトコル、Network News)のどちらかである傾向がありました。 WWWはイメージ、音、およびビデオを含んでいて、ともに対話的でしばしば「かさばる」通信を私たちに与えました。
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.
また、WWWはインターネットを普及させました、インターネットに非常に「典型的な企業内ネットワーク速度より遅い」リンク速度の上アクセスすることへの重要な関心があるように。 事実上、現在のインターネットユーザの重要なプロポーションは比較的遅い最後のホップリンクの上のインターネットに関連づけられます。 これから、様々なモバイル機器が遅いワイヤレスのリンクの上のインターネットに付けられるために見通されるようにそのようなユーザの数は雨後の竹の子のように出そうです。
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
これらの「かさばる」転送のための最も良い対話的な応答を提供するために、作成者は実際にこれらの「遅い」接続の上に伝えられたビットの数を最小にしたがっているかもしれません。 2があります。
Dawkins, et al. Best Current Practice [Page 2] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[2ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
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.
考えることができる領域--接続に関連しているオーバーヘッドを作るビットを圧縮して、接続の上で輸送されるペイロードを作るビットを圧縮します。
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が低速リンクの上の性能を向上させるためにテクニックとしてウインドウ設定と列を作りメカニズムを受け取ると考えたがっているかもしれません。 これらのテクニックがプロトコル変化を伴っていない間、それらは本書では完全性のために含まれています。
2.0 Description of Optimizations
2.0 最適化の記述
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.
このセクションはホストが彼らのリンクを飽和状態にすることができる状況における使用のために示された最適化について説明します。 次のセクションはこれらの最適化の使用に関して推薦をまとめます。
2.1 Header Compression Alternatives
2.1 ヘッダー圧縮代替手段
Mechanisms for TCP and IP header compression defined in [RFC1144, RFC2507, RFC2508, RFC2509, RFC3095] provide the following benefits:
TCPのためのメカニズムと中で定義されたIPヘッダー圧縮[RFC1144、RFC2507、RFC2508、RFC2509、RFC3095]は以下の利益を提供します:
- 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バイトのa典型的なダイアルアップMTUのために、TCP/IPヘッダーのオーバーヘッドは典型的な40バイトのヘッダーと共に3-5バイトの圧縮されたヘッダーでおよそ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 Header圧縮のためのProposed Standardです。 残念ながら、それは損失性リンクで被害を受け易いです、シングルさえコンプレッサーと減圧装置の間の同期の損失で誤り結果に噛み付いたので。 それはそのような同期の損失を検出するのにTCPタイムアウトを使用しますが、これらの誤りはデータの喪失(完全なTCPの窓までの)、完全なRTO、および不要な遅れた出発の遅れをもたらします。
Dawkins, et al. Best Current Practice [Page 3] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[3ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
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の原稿のエラー条件)のものと同じくらい極端な条件のもとでよく振る舞うのをやめます。 これらのケースのために、'強健なHeader Compression'ワーキンググループは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一連番号スペースが「包装されること」を防いで、明白なTCP往復のタイミングを提供することによってTCP RTT見積りを改良するのにおいて、使用されています。 TCPタイムスタンプの使用は、TCPオプションとしてタイムスタンプを送るので、ヘッダー圧縮を防ぎます。 これは、それぞれのtimestampedヘッダーには前のヘッダーと異なっている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]を実装してください、特にモバイルIPのためにIPv4トンネルとMinimal Encapsulationに関連して、TCPヘッダー圧縮に損失性リンクに関連して、その追加注文パケットをリンクするとき。 PPPのできるデバイスは「pppの上のIPヘッダー圧縮」[RFC2509]を実装するはずです。 強健なHeader Compression[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 Timestamps[RFC1323]の使用はこれらの接続と共に推薦されません。 Robust Header Compression(ROHC)ワーキンググループはこれを治すために仕様を開発していますが、それらのメカニズムは、まだ完全に開発されていて、配布されないで、一般に、正当でないかもしれません。 その上、「遅い」リンクを横断する接続がTCP一連番号ラッピングに対する保護を必要としません。
Dawkins, et al. Best Current Practice [Page 4] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[4ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
2.2 Payload Compression Alternatives
2.2 有効搭載量圧縮代替手段
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有効搭載量Compressionプロトコル(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ペイロードを無作為のbitstreamsに変換するので、それが必要です、一般的に配布しているよりコンパクトに表すことができる余分な「情報」がないのを持っているペイロードに直面しているリンクレイヤ圧縮機構を破って。
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]はContentをコード化していてAcceptをコード化しているヘッダーを含んでいます、テキスト/平野のような一般的な圧縮性の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.
アプリケーションレベル圧縮のテクニックの大規模な使用はIPCompと、特にWWWユーザの必要性を減少させるでしょう。
Recommendation: IPComp may optionally be implemented.
推薦: IPCompは任意に実装されるかもしれません。
2.3 Choosing MTU Sizes
2.3 MTUが大きさで分ける選ぶこと
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タイムアウトより長い間最初に、リンクを占領する、(最大500ミリセカンドであるかもしれないこと以外の通常200ミリセカンド、意志でACKを生成するこのタイムアウトは、あらゆる2番目のセグメントよりむしろあらゆるセグメントTCPのほとんどの実装で起こるので、ACKアルゴリズムを遅らせました。
Dawkins, et al. Best Current Practice [Page 5] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[5ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
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.
2番目に、「比較的大きい」MTUs(ネットワークに伝えられるには人間知覚可能な量の時間がかかる)は、同じリンクを使用することで他の流れの人間知覚可能な遅れを作成します。 [RFC1144]は、100-200ミリセカンドの遅れが人間知覚可能であるとみなします。 296バイトのMTUsをダイアルアップアクセスに選ぶ(ヘッダー圧縮が可能にされている状態で)コンベンションは9.6KB/秒のミリセカンドがリンクする等身大のMTUsおよそ200と共に最大のリンク占有遅れを制限する感染です。
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.
3番目で、より大きいリンクMTUサイズを使用して、したがってより大きいMSSを使用する最後のホップリンクでは、TCP送付者は、より小さいMTUサイズ(そして、より小さいMSS)を使用することでいつよりバイトで速く混雑ウィンドウを増強できるだろうか。 しかしながら、より小さいMTUサイズ、および、より小さいMSSサイズに従って、セグメントで測定されると、混雑ウィンドウは、より大きいMSSサイズでそうするだろうよりはやく増加します。 パケット損失が遭遇するとき、速くサイズがセグメントを3写しに承認、引き金となることを生成するほど、より送ることができそうであるより小さいMSSを使用するコネクションズが/速い回復を再送します。 したがって、より小さい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.
最終的に、いくつかのネットワークが1キロバイトあたり1個のベースで課金するのではなく、1パケットあたり1個のベースでトラフィックに課金します。 これらの場合では、より小さい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.
推薦: そうするのが可能であるなら、人間知覚可能な量の時間ネットワーク・インターフェースを独占しないMTUsは選ばれるべきです、そして、作成者は選ばれるべきです。100-200ミリセカンドかなり以上でネットワーク・インターフェースを占領するMTUsは選びませんでした。
2.4 Interactions with TCP Congestion Control [RFC2581]
TCP混雑との2.4回の相互作用が制御されます。[RFC2581]
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つの一般的な構成がターミナルサーバ(最後のホップルータ)へのダイアルアップアクセスを使用するラップトップコンピュータであるかもしれなく、HTTPサーバがオンの高速LAN“behind"はターミナルサーバです。
Dawkins, et al. Best Current Practice [Page 6] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[6ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
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.
パケット損失は起こっていますが、ルータバッファ領域の後の1RTT回が疲れ果てるまで、それはTCP送付者に検出されません、そして、最初のパケットは下げられます。 この遅い混雑信号は最初のパケットがルータで下げられたときのそれがサイズであったのを倍にするために上がっている増加への混雑ウィンドウを許容します。
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が使用中であり、遅れたACKsを利用できるなら、混雑ウィンドウは1.5の1RTTの要素で増加します。 どちらの場合も、送付者は、最後のホップルータの混雑ポイントを超えてパケットをよく伝え続けています、単一の窓の複数のパケット損失をもたらして。
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アウトバウンドリンクあたりのバッファがある最後のホップルータが使用されているとき、最初のバッファオーバーフローはルータにより多くのバッファがあるならそうするより早く起こります。 次により少ない数のバッファで、周期的なパケット損失は輻輳回避の間、より頻繁に起こります、送付者が利用可能な帯域幅に調べるとき。
Dawkins, et al. Best Current Practice [Page 7] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[7ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
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.
ルータバッファの最も重要な責任は炸裂を吸収することです。 わずか過ぎるしか非常に小さい炸裂さえ吸収しそうにない状態でルータはそれらのバッファプールから非常に容易にはみ出して、ある手段をバッファリングしません(例えば、1[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]でアクティブな待ち行列管理メカニズムがRandom Early Detection(RED)[RED93]のようにすべてのインターネットルータで実装されるべきであることが勧められました、遅いリンクの正面に最後のホップルータを含んでいて。 また、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:
アクティブな待ち行列管理メカニズムは、パケット滴を排除するのではなく、混雑信号としてパケット滴に敏感な流れのための完全な待ち行列問題を解決するために代わりに早期のステージでパケットを下げます。 直接低速リンクに接続されるホストが制限するかもしれない、それらが最後のホップルータにおけるパケット滴の数を下げるか、または排除するために広告を出す窓を受けてください。 しかしながら、そう1つをするのが、広告を出している窓が大きいことに注意するべきであるとき、最後のホップリンク容量の完全利用を許容して、速く引き金となるのを許容できるくらい再送します、パケット損失が遭遇するとき。 この推薦は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アクセス」と同じくらい簡単であるかもしれません--経験豊富なネットワーク・デザイナーで手で調整する必要でない、これは多くの環境を収容するでしょう。)
Dawkins, et al. Best Current Practice [Page 8] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[8ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
- 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で接続されたドッキングステーションがあるダイヤルアップラップトップコンピュータ)の上に他のホストに接するかもしれないホストに関しては、受信バッファのために自動チューニングしているバッファについて、より合理的な推薦であり、以下で議論します。
2.5 TCP Buffer Auto-tuning
2.5 TCPバッファ自動チューニング
[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.
提案されたテクニックは現在の混雑ウィンドウに基づいてネットワーク経路に関する少しも知識なしでpreallocate 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つの窓を含むことができるくらい大きいバッファを送る受信バッファをもたらします、接続に長い再送タイムアウトを使用させないでSACKと速い回復が損失を取り戻すことができるように。
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.
推薦: ホストが遅いリンクを通して時々接されますが、また、著しく異なったリンク速度との他のインタフェースを使用することでホストが接されるなら、それは適切な値に広告を出している窓を調整するために自動チューニングしている受信バッファを使用するかもしれません。
Dawkins, et al. Best Current Practice [Page 9] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[9ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
2.6 Small Window Effects
2.6 小さい窓の効果
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.
推薦: 限られたTransmitはすべてのホストで実行されるべきです。
3.0 Summary of Recommended Optimizations
3.0 お勧めの最適化の概要
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タイムスタンプをオフにしなければなりません。
Dawkins, et al. Best Current Practice [Page 10] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[10ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
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有効搭載量Compression[RFC2393]は実行されるべきです、このメカニズムがプロトコル・スタック(例えば、[RFC2616])の、より高い層での圧縮で、より役に立たないようになるかもしれませんが。
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ミリセカンドより以上のためのネットワーク・インターフェースを独占しないMTUsを選ぶべきです、ネットワーク・インターフェースを共有している他のすべての接続のときに単独結合の影響を制限するために。
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.
活発な待ち行列管理の使用は遅いリンクの後ろで主催するインターネット・アクセスを提供する最後のホップルータでお勧めです。 さらに、遅いリンクあたりのルータバッファの数はただ一つの流れ以上から同時発生のデータ炸裂を吸収できるくらい大きいはずです。 1送付者あたり3つの背中合わせのセグメントの典型的なデータ炸裂に応じて、同時発生のデータを吸収するのは2か3人のTCP送付者からはち切れます、少なくとも6(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.
限られたTransmit[RFC3042]は混雑ウィンドウが小さい速く引き金となるのを助けるときホストが再送するすべての終わりで実行されるべきです。
All of the mechanisms described above are stable standards-track RFCs (at Proposed Standard status, as of this writing).
上で説明されたメカニズムのすべてが安定した標準化過程RFCs(この書くこと現在Proposed Standard状態の)です。
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.
上のメカニズムでは、Header Compression(IPとTCPのための)だけが、終わりから終わりへのIPSECの面前で働くのをやめるかもしれません。 しかしながら、[RFC3095]は超能力ヘッダーを圧縮させます。
Dawkins, et al. Best Current Practice [Page 11] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[11ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
4.0 Topics For Further Work
4.0 さらなる仕事のための話題
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ヘッダ表現をコンパクト性のための2進法表示に取り替えました。 しかしながら、HTTP-NGは前方へ動いていません、そして、HTTP/1.1は、よりコンパクトなHTTPヘッダ表現を含むように高められていません。 代わりに、ワイヤレス・アプリケーション・プロトコル(WAP)フォーラムはXMLベースのWireless Sessionプロトコル[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内容encodingsは提案されました[ミヨー]。
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オプションが今日配備されているヘッダー圧縮技術を無効にすることに注意します、ヘッダーのいくつかの分野が前のセグメントから変わりがないのを示す方法が全くないので、他の分野はそうではありませんが。 Robust Header Compressionワーキンググループはタイムスタンプや選択している承認などの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].
続く価値がある別の努力は'デルタEncoding'のものです。 ここで、何らかの以前にキャッシュされたリソースのわずかに変更されたバージョンを要求するクライアントが全体のリソース[HTTPデルタ]よりむしろ違いの簡潔な解説を受けるでしょう。
5.0 Security Considerations
5.0 セキュリティ問題
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).
本書では含まれていたすべての推薦は、安定した規格道のRFCs(この書くこと現在Proposed Standard状態の)であるか別の方法でどんなプロトコルへの少しの変化も示しません。 ヴァンジェーコブソン圧縮[RFC1144]と[RFC2507、RFC2508、RFC2509]を除いて、他のすべてのメカニズムが終わりから終わりへのIPSecによって保護されたTCP接続に適切です。 これはROHC[RFC3095]を含んでいます、部分的ですが、一番はずれの超能力ヘッダーをある程度圧縮できますが、暗号化がまだどんなペイロードデータuncompressibleもレンダリングしているので(どんなその後のプロトコルヘッダーも含んでいて)。
Dawkins, et al. Best Current Practice [Page 12] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[12ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
6.0 IANA Considerations
6.0 IANA問題
This document is a pointer to other, existing IETF standards. There are no new IANA considerations.
このドキュメントは他の、そして、既存のIETF規格へのポインタです。 どんな新しいIANA問題もありません。
7.0 Acknowledgements
7.0 承認
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ワーキンググループで行われた仕事の利益を得ました)。
8.0 References
8.0の参照箇所
[AlPa99] Mark Allman and Vern Paxson, "On Estimating End-to-End
Network Path Properties", in ACM SIGCOMM 99 Proceedings,
1999.
[AlPa99]はACM SIGCOMM99議事、1999年に「終わりから端へのネットワーク経路が土地であると見積もっている」ときのオールマンとバーン・パクソンをマークします。
[HTTP-DELTA] J. Mogul, et al., "Delta encoding in HTTP", Work in
Progress.
[HTTPデルタ] J.ムガール人、他、「HTTPにおけるデルタコード化」、ProgressのWork。
[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] マイクSpreitzer、ジャンセン、「HTTP'次世代'」、第9国際WWWコンファレンスに2000年5月を請求してください。 また、以下として利用可能です。 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、「ミヨー:」 「ウェブの上のXMLの効率的な表現と交換のためのコード化形式」、第9国際WWWコンファレンス、2000年5月。 また、以下として利用可能です。 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.、「終わりから終わりへのインターネットパケット力学」、以下として利用可能なSIGCOMM97Proceedingsの1997 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] Congestion Avoidance、IEEE/ACM TransactionsのためのNetworking、V.1 N.4、1993年8月、ページのフロイド、S.とジェーコブソン、V.、Random Early Detectionゲートウェイ 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.
1990年2月の[RFC1144]ジェーコブソン対「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144
Dawkins, et al. Best Current Practice [Page 13] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[13ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン(V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol: Version
1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは議定書を作ります」。 バージョン1インチ、RFC2246、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.とRamakrishnanとK.、ShenkerとS.とWroclawskiとJ.とL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」RFC2309(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)」、RFC2393 1998年12月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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.ヤマウズラ、「いつTCPは4つのパケットと共に3つのバッファだけに始動する」RFC2416(1998年9月)。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2507] デーゲルマルクとM.とNordgrenとB.とS.ピンク、「IPヘッダー圧縮」、RFC2507、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.ジェーコブソン。 「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮します」、RFC2508、1999年2月。
[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header
Compression over PPP", RFC 2509, February 1999.
[RFC2509] EnganとM.とCasnerとS.とC.ボルマン、「pppの上のIPヘッダー圧縮」、RFC2509、1999年2月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and
N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[RFC2757] モンテネグロとG.とダウキンズとS.とKojoとM.とMagret、V.とN.Vaidya、「長い薄いネットワーク」、RFC2757、2000年1月。
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing
TCP's Loss Recovery Using Limited Transmit", RFC 3042,
January 2001.
[RFC3042] オールマンとM.とBalakrishnanとH.とS.フロイド、「株式会社を使用することでTCPの損失回復を機能アップして、伝わってください」、RFC3042、2001年1月。
Dawkins, et al. Best Current Practice [Page 14] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[14ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
[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.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4Profiles: 「UDP ESPであって解凍されたRTP」、RFC3095、7月2001日
[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] ACM SIGCOMM98議事1998におけるジェフリーSemke、マシュー・マシスとJamshid Mahdavi、「自動TCPバッファ調律。」 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]アラン・O.フライア、フィリップKarlton、ポール・C.コッハー、SSLは議定書を作ります: 1996年3月のバージョン3.0。 ( 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]ハーリBalakrishnan(Venkata N.Padmanabhan、Srinivasan Seshan)がStemm、ランディ・H.キャッツをマークする、「忙しいインターネットサーバのTCP働き:」 「分析と改良」(IEEE Infocom)は1998を行進させます。 利用可能: http://www.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]DongリンとH.T.キュング、「TCPの速い回復戦略:」 「分析と改良」(IEEE Infocom)は1998を行進させます。 利用可能: http://www.eecs.harvard.edu/networking/papers/ のinfocom- 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).
「WAPの無線のセッションプロトコル仕様」という[WSP]ワイヤレス・アプリケーション・プロトコルForumは http://www1.wapforum.org/tech/documents/WAP-203-WSP- 20000504a.pdfからの利用可能な2000年5月4日を承認しました。 (有益な参照。)
Dawkins, et al. Best Current Practice [Page 15] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[15ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
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 メールしてください: spencer.dawkins@fnc.fujitsu.com
Gabriel Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan, FRANCE
ガブリエルモンテネグロサン・マイクロシステムズ研究所、ヨーロッパ29、chemin du Vieux Chene38240メラン、フランス
Phone: +33 476 18 80 45 EMail: gab@sun.com
以下に電話をしてください。 +33 476 18 80 45はメールされます: gab@sun.com
Markku Kojo Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland
ヘルシンキ私書箱26(Teollisuuskatu23)フィン-00014ヘルシンキフィンランドのマルックKojoコンピュータサイエンス学部大学
Phone: +358-9-1914-4179 Fax: +358-9-1914-4441 EMail: kojo@cs.helsinki.fi
以下に電話をしてください。 +358-9-1914-4179 Fax: +358-9-1914-4441 メールしてください: kojo@cs.helsinki.fi
Vincent Magret Alcatel Internetworking, Inc. 26801 W. Agoura road Calabasas, CA, 91301
カラバサス、ヴィンセントMagretアルカテルInternetworking Inc.26801W.Agoura道路カリフォルニア 91301
Phone: +1 818 878 4485 EMail: vincent.magret@alcatel.com
以下に電話をしてください。 +1 4485年の818 878メール: vincent.magret@alcatel.com
Dawkins, et al. Best Current Practice [Page 16] RFC 3150 PILC - Slow Links July 2001
ダウキンズ、他 最も良い現在の習慣[16ページ]RFC3150PILC--2001年7月にリンクを遅くしてください。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Dawkins, et al. Best Current Practice [Page 17]
ダウキンズ、他 最も良い現在の習慣[17ページ]
一覧
スポンサーリンク
