RFC3742 日本語訳

Network Working Group                                           S. Floyd
Request for Comments: 3742                                          ICSI
Category: Experimental                                        March 2004

コメントを求めるワーキンググループS.フロイド要求をネットワークでつないでください: 3742年のICSIカテゴリ: 実験的な2004年3月

        Limited Slow-Start for TCP with Large Congestion Windows

大きい混雑WindowsがあるTCPのための限られた遅れた出発

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Copyright(C)インターネット協会(2004)。 All rights reserved。

Abstract

要約

   This document describes an optional modification for TCP's slow-start
   for use with TCP connections with large congestion windows.  For TCP
   connections that are able to use congestion windows of thousands (or
   tens of thousands) of MSS-sized segments (for MSS the sender's
   MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in
   increasing the congestion window by thousands of segments in a single
   round-trip time.  Such an increase can easily result in thousands of
   packets being dropped in one round-trip time.  This is often
   counter-productive for the TCP flow itself, and is also hard on the
   rest of the traffic sharing the congested link.  This note describes
   Limited Slow-Start as an optional mechanism for limiting the number
   of segments by which the congestion window is increased for one
   window of data during slow-start, in order to improve performance for
   TCP connections with large congestion windows.

このドキュメントは大きい混雑ウィンドウとのTCP接続と共に使用のためのTCPの遅れた出発に任意改修について説明します。 MSSサイズのセグメントの数千(または、何万)の混雑ウィンドウを使用できるTCP接続、(MSS、送付者のMAXIMUM SEGMENT SIZE)、現在の遅れた出発手順はただ一つの往復の時間で何千ものセグメントで混雑ウィンドウを増加させるのに結果として生じることができます。 そのような増加は往復の1回の間、容易にちょっと立ち寄る何千ものパケットをもたらすことができます。 これも、カウンタTCP流動自体にしばしば生産的であり、また、混雑しているリンクを共有する交通の残りのときに困難です。 この注意は混雑ウィンドウは遅れた出発の間にデータの1つの窓に増加させられるセグメントの数を制限するために株式会社Slow-始めを任意のメカニズムとして記述します、大きい混雑ウィンドウとのTCP接続のために性能を向上させるために。

1.  Introduction

1. 序論

   This note describes an optional modification for TCP's slow-start for
   use with TCP connections with large congestion windows.  For TCP
   connections that are able to use congestion windows of thousands (or
   tens of thousands) of MSS-sized segments (for MSS the sender's
   MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in
   increasing the congestion window by thousands of segments in a single
   round-trip time.  Such an increase can easily result in thousands of
   packets being dropped in one round-trip time.  This is often
   counter-productive for the TCP flow itself, and is also hard on the
   rest of the traffic sharing the congested link.  This note describes
   Limited Slow-Start, limiting the number of segments by which the

この注意は大きい混雑ウィンドウとのTCP接続と共に使用のためのTCPの遅れた出発に任意改修について説明します。 MSSサイズのセグメントの数千(または、何万)の混雑ウィンドウを使用できるTCP接続、(MSS、送付者のMAXIMUM SEGMENT SIZE)、現在の遅れた出発手順はただ一つの往復の時間で何千ものセグメントで混雑ウィンドウを増加させるのに結果として生じることができます。 そのような増加は往復の1回の間、容易にちょっと立ち寄る何千ものパケットをもたらすことができます。 これも、カウンタTCP流動自体にしばしば生産的であり、また、混雑しているリンクを共有する交通の残りのときに困難です。 セグメントの数を制限して、この注意が株式会社Slow-始めについて説明する、どれ

Floyd                         Experimental                      [Page 1]

RFC 3742     TCP's Slow-Start with Large Congestion Windows   March 2004

フロイド実験的な[1ページ]RFC3742TCPの大きい混雑Windows行進に伴う遅い始めの2004

   congestion window is increased for one window of data during slow-
   start, in order to improve performance for TCP connections with large
   congestion windows.

混雑ウィンドウは遅い始めの間、データの1つの窓に増加します、大きい混雑ウィンドウとのTCP接続のために性能を向上させるために。

   When slow-start results in a large increase in the congestion window
   in one round-trip time, a large number of packets might be dropped in
   the network (even with carefully-tuned active queue management
   mechanisms in the routers).  This drop of a large number of packets
   in the network can result in unnecessary retransmit timeouts for the
   TCP connection.  The TCP connection could end up in the congestion
   avoidance phase with a very small congestion window, and could take a
   large number of round-trip times to recover its old congestion
   window.  This poor performance is illustrated in [F02].

遅れた出発が往復の1回で混雑ウィンドウの大きい増加をもたらすとき、多くのパケットがネットワーク(ルータにおける慎重に調整されたアクティブな待ち行列管理メカニズムがあっても)で落とされるかもしれません。 不要のネットワーク缶の結果における、多くのパケットのこの滴はTCP接続のためにタイムアウトを再送します。 TCP接続は、非常に小さい混雑ウィンドウとの輻輳回避フェーズで終わることができて、古い混雑ウィンドウを回収するために多くの往復の倍取ることができました。 この不十分な性能は[F02]で例証されます。

2.  The Proposal for Limited Slow-Start

2. 株式会社の遅れた出発のための提案

   Limited Slow-Start introduces a parameter, "max_ssthresh", and
   modifies the slow-start mechanism for values of the congestion window
   where "cwnd" is greater than "max_ssthresh".  That is, during Slow-
   Start, when

株式会社Slow-始めは、"cwnd"が「最大_ssthresh」よりすばらしい混雑ウィンドウの値のためにパラメタを紹介して、「_ssthreshに最大限にし」て、遅れた出発メカニズムを変更します。 Slow始めの間、それはいつです。

      cwnd <= max_ssthresh,

cwnd<は最大_ssthreshと等しいです。

   cwnd is increased by one MSS (MAXIMUM SEGMENT SIZE) for every
   arriving ACK (acknowledgement) during slow-start, as is always the
   case.  During Limited Slow-Start, when

各到着ACK(承認)あたり1MSS(MAXIMUM SEGMENT SIZE)が遅れた出発の間、cwndを増加させます、いつものことだが。 株式会社Slow-始め、いつの間

      max_ssthresh < cwnd <= ssthresh,

最大_ssthresh<cwnd<はssthreshと等しいです。

   the invariant is maintained so that the congestion window is
   increased during slow-start by at most max_ssthresh/2 MSS per round-
   trip time.  This is done as follows:

不変式が維持されるので、高々丸い旅行時間あたりの最大_ssthresh/2MSSは遅れた出発の間、混雑ウィンドウを増加させます。 これは以下の通り完了しています:

      For each arriving ACK in slow-start:
        If (cwnd <= max_ssthresh)
           cwnd += MSS;
        else
           K = int(cwnd/(0.5 max_ssthresh));
           cwnd += int(MSS/K);

遅れた出発におけるそれぞれ到着しているACKのために: (cwnd<は最大_ssthreshと等しいです)cwnd+=MSSであるなら。 ほかに、Kはint(cwnd/(0.5最大_ssthresh))と等しいです。 cwnd+=int(MSS/K)。

   Thus, during Limited Slow-Start the window is increased by 1/K MSS
   for each arriving ACK, for K = int(cwnd/(0.5 max_ssthresh)), instead
   of by 1 MSS as in standard slow-start [RFC2581].

したがって、株式会社Slow-始めの間、1/K MSSがそれぞれ到着しているACKのために窓を増加させます、Kが1MSSの代わりに標準の遅れた出発[RFC2581]のようにint(cwnd/(0.5最大_ssthresh))と等しいので。

Floyd                         Experimental                      [Page 2]

RFC 3742     TCP's Slow-Start with Large Congestion Windows   March 2004

フロイド実験的な[2ページ]RFC3742TCPの大きい混雑Windows行進に伴う遅い始めの2004

   When

いつ

     ssthresh < cwnd,

ssthresh<cwnd

   slow-start is exited, and the sender is in the Congestion Avoidance
   phase.

遅れた出発は出られます、そして、送付者がCongestion Avoidanceフェーズにいます。

   Our recommendation would be for max_ssthresh to be set to 100 MSS.
   (This is illustrated in the NS [NS] simulator, for snapshots after
   May 1, 2002, in the tests "./test-all-tcpHighspeed tcp1A" and
   "./test-all-tcpHighspeed tcpHighspeed1" in the subdirectory
   "tcl/lib".  Setting max_ssthresh to Infinity causes the TCP
   connection in NS not to use Limited Slow-Start.)

私たちの推薦は最大_ssthreshが100MSSに用意ができるだろうことです。 「(これはNS[NS]シミュレータで例証されます、後の2002年5月1日のスナップのためにテストで、NSでのTCP接続は」 . /試しにオールtcpHighspeed tcp1Aサブディレクトリの」 」 . /試しにオールtcpHighspeed tcpHighspeed1"「tcl/リブ」 最大_ssthreshをInfinityに設定するのに株式会社Slow-始めを使用しません。)

   With Limited Slow-Start, when the congestion window is greater than
   max_ssthresh, the window is increased by at most 1/2 MSS for each
   arriving ACK; when the congestion window is greater than 1.5
   max_ssthresh, the window is increased by at most 1/3 MSS for each
   arriving ACK, and so on.

混雑ウィンドウが最大_ssthreshよりすばらしく株式会社Slow-始めによると、高々1/2MSSがそれぞれ到着しているACKのために窓を増加させます。 混雑ウィンドウが1.5以上最大_ssthreshであるときに、高々1/3MSSがそれぞれ到着しているACKなどのために窓を増加させます。

   With Limited Slow-Start it takes:

株式会社Slow-始めで、取ります:

      log(max_ssthresh)

ログ(最大_ssthresh)

   round-trip times to reach a congestion window of max_ssthresh, and it
   takes:

混雑ウィンドウに達する往復の回は_ssthreshに最大限にします、そして、取ります:

      log(max_ssthresh) + (cwnd - max_ssthresh)/(max_ssthresh/2)

+ (最大_ssthresh)(cwnd--最大_ssthresh)/を登録してください。(最大_ssthresh/2)

   round-trip times to reach a congestion window of cwnd, for a
   congestion window greater than max_ssthresh.

最大_ssthreshより大きい混雑ウィンドウへのcwndの混雑ウィンドウに達する往復の回。

   Thus, with Limited Slow-Start with max_ssthresh set to 100 MSS, it
   would take 836 round-trip times to reach a congestion window of
   83,000 packets, compared to 16 round-trip times without Limited
   Slow-Start (assuming no packet drops).  With Limited Slow-Start, the
   largest transient queue during slow-start would be 100 packets;
   without Limited Slow-Start, the transient queue during Slow-Start
   would reach more than 32,000 packets.

したがって、100MSSに用意ができている最大_ssthreshとの株式会社Slow-始めで、8万3000のパケットの混雑ウィンドウに達するには往復の836倍かかるでしょう、株式会社Slow-始めなしで往復の16回と比べて(パケット滴を全く仮定しないで)。 株式会社Slow-始めで、遅れた出発の間の最も大きい一時的な待ち行列は100のパケットでしょう。 株式会社Slow-始めがなければ、Slow-始めの間の一時的な待ち行列は3万2000以上のパケットに達するでしょう。

   By limiting the maximum increase in the congestion window in a
   round-trip time, Limited Slow-Start can reduce the number of drops
   during slow-start, and improve the performance of TCP connections
   with large congestion windows.

往復の時間で混雑ウィンドウの最大の増加を制限することによって、株式会社Slow-始めは、遅れた出発の間、低下の数を減少させて、大きい混雑ウィンドウでTCP接続の性能を向上させることができます。

Floyd                         Experimental                      [Page 3]

RFC 3742     TCP's Slow-Start with Large Congestion Windows   March 2004

フロイド実験的な[3ページ]RFC3742TCPの大きい混雑Windows行進に伴う遅い始めの2004

3.  Experimental Results

3. 実験結果

   Tom Dunigan has added Limited Slow-Start to the Linux 2.4.16 Web100
   kernel, and performed experiments comparing TCP with and without
   Limited Slow-Start [D02].  Results so far show improved performance
   for TCPs using Limited Slow-Start.  There are also several
   experiments comparing different values for max_ssthresh.

トムDuniganはリナックスへの株式会社Slow-スタート2.4.16Web100カーネルを加えて、株式会社Slow-始め[D02]のあるなしにかかわらずTCPを比較する実験を行いました。 結果は、今までのところ、株式会社Slow-始めを使用することでTCPsのための向上した性能を示しています。 また、最大_ssthreshのために異価を比較するいくつかの実験があります。

4.  Related Proposals

4. 関連提案

   There has been considerable research on mechanisms for the TCP sender
   to learn about the limitations of the available bandwidth, and to
   exit slow-start before receiving a congestion indication from the
   network [VEGAS,H96].  Other proposals set TCP's slow-start parameter
   ssthresh based on information from previous TCP connections to the
   same destination [WS95,G00].  This document proposes a simple
   limitation on slow-start that can be effective in some cases even in
   the absence of such mechanisms.  The max_ssthresh parameter does not
   replace ssthresh, but is an additional parameter.  Thus, Limited
   Slow-Start could be used in addition to mechanisms for setting
   ssthresh.

TCP送付者が利用可能な帯域幅の制限に関して学んで、ネットワーク[ヴェガス、H96]から混雑指示を受ける前に遅れた出発を出るために、メカニズムのかなりの研究がありました。 他の提案は前のTCP接続から同じ目的地[WS95、G00]に情報に基づくTCPの遅れた出発パラメタssthreshを設定します。 このドキュメントはいくつかの場合そのようなメカニズムがないときでさえ有効である場合がある遅れた出発のときに簡単な制限を提案します。最大_ssthreshパラメタは、ssthreshを取り替えませんが、追加パラメタです。 したがって、ssthreshを設定するためのメカニズムに加えて株式会社Slow-始めを使用できました。

   Rate-based pacing has also been proposed to improve the performance
   of TCP during slow-start [VH97,AD98,KCRP99,ASA00].  We believe that
   rate-based pacing could be of significant benefit, and could be used
   in addition to the Limited Slow-Start in this proposal.

また、レートベースのペースは、遅れた出発[VH97、AD98、KCRP99、ASA00]の間、TCPの性能を向上させるために提案されました。 私たちはレートベースのペースは重要な利益があるかもしれなくて、この提案における株式会社Slow-始めに加えて使用できたと信じています。

   Appropriate Byte Counting [RFC3465] proposes that TCP increase its
   congestion window as a function of the number of bytes acknowledged,
   rather than as a function of the number of ACKs received.
   Appropriate Byte Counting is largely orthogonal to this proposal for
   Limited Slow-Start.

適切なByte Counting[RFC3465]は、バイト数の関数が承認したようにTCPが混雑ウィンドウを増加させるよう提案します、むしろ受け取られたACKsの数の関数より。 適切なByte Countingは株式会社Slow-始めのためのこの提案と主に直交しています。

   Limited Slow-Start is also orthogonal to other proposals to change
   mechanisms for exiting slow-start.  For example, FACK TCP includes an
   overdamping mechanism to decrease the congestion window somewhat more
   aggressively when a loss occurs during slow-start [MM96].  It is also
   true that larger values for the MSS would reduce the size of the
   congestion window in units of MSS needed to fill a given pipe, and
   therefore would reduce the size of the transient queue in units of
   MSS.

また、株式会社Slow-始めも遅れた出発を出るためにメカニズムを変えるという他の提案と直交しています。 損失が遅れた出発[MM96]の間発生するとき、例えば、FACK TCPは、混雑ウィンドウをいくらか積極的に減少させるために超過減衰メカニズムを含んでいます。 また、MSSのための、より大きい値が与えられたパイプをいっぱいにするのが必要であるユニットのMSSで混雑ウィンドウのサイズを減少させて、したがって、ユニットのMSSで一時的な待ち行列のサイズを減少させるのも、本当です。

5.  Acknowledgements

5. 承認

   This proposal is part of a larger proposal for HighSpeed TCP for TCP
   connections with large congestion windows, and resulted from
   simulations done by Evandro de Souza, in joint work with Deb Agarwal.
   This proposal for Limited Slow-Start draws in part from discussions

シミュレーションからEvandro deスザにして、この提案は大きい混雑ウィンドウであり、結果になるとのTCP接続のためのHighSpeed TCPのための、より大きい提案の一部です、Deb Agarwalとの共同作業で。 株式会社Slow-始めのためのこの提案は議論を一部引き出します。

Floyd                         Experimental                      [Page 4]

RFC 3742     TCP's Slow-Start with Large Congestion Windows   March 2004

フロイド実験的な[4ページ]RFC3742TCPの大きい混雑Windows行進に伴う遅い始めの2004

   with Tom Kelly, who has used a similar modified slow-start in his own
   research with congestion control for high-bandwidth connections.  We
   also thank Tom Dunigan for his experiments with Limited Slow-Start.

トム・ケリーと共に。(トム・ケリーは、高帯域接続に輻輳制御による彼自身の研究における同様の変更された遅れた出発を使用しました)。 また、私たちは株式会社Slow-始めとの彼の実験についてトムDuniganに感謝します。

   We thank Andrei Gurtov, Reiner Ludwig, members of the End-to-End
   Research Group, and members of the Transport Area Working Group, for
   feedback on this document.

私たちはアンドレイGurtovに感謝します、ライナー・ラドウィグ、Endから終わりへのResearch Groupのメンバー、Transport Area作業部会と、フィードバックにおけるオンのメンバーはこのドキュメントをメンバーです。

6.  Security Considerations

6. セキュリティ問題

   This proposal makes no changes to the underlying security of TCP.

この提案はTCPの基本的なセキュリティへの変更を全く行いません。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
             Control", RFC 2581, April 1999.

[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。

   [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte
             Counting (ABC)", RFC 3465, February 2003.

[RFC3465]オールマン、M.、「適切なバイト勘定(ABC)とのTCP輻輳制御」、RFC3465、2003年2月。

7.2.  Informative References

7.2. 有益な参照

   [AD98]    Mohit Aron and Peter Druschel, "TCP: Improving Start-up
             Dynamics by Adaptive Timers and Congestion Control"",
             TR98-318, Rice University, 1998.  URL "http://cs-
             tr.cs.rice.edu/Dienst/UI/2.0/Describe/ncstrl.rice_cs/TR98-
             318/".

[AD98] MohitアロンとピーターDruschel、「TCP:」 「適応型のタイマと輻輳制御で始動力学を改良する」、」、TR98-318、ライス大学、1998 「 http://cs- tr.cs.rice.edu/Dienst/UI/2.0/は/ncstrl.rice_Cs/TR98 318/について説明する」というURL。

   [ASA00]   A. Aggarwal, S. Savage, and T. Anderson, "Understanding the
             Performance of TCP Pacing", Proceedings of the 2000 IEEE
             Infocom Conference, Tel-Aviv, Israel, March, 2000.  URL
             "http://www.cs.ucsd.edu/~savage/".

[ASA00] A.Aggarwal、S.サヴェージ、およびT.アンダーソン、「TCPペースのパフォーマンスを理解しています」、2000年のIEEE Infocomコンファレンス(2000年のテルアビブ(イスラエル)の行進)の議事。 URL" http://www.cs.ucsd.edu/~savage/ "。

   [D02]     T. Dunigan, "Floyd's TCP slow-start and AIMD mods", 2002.
             URL "http://www.csm.ornl.gov/~dunigan/net100/floyd.html".

2002の[D02]T.Duniganと、「フロイドのTCP遅れた出発とAIMDモッズ」 URL" http://www.csm.ornl.gov/~dunigan/net100/floyd.html "。

   [F02]     S. Floyd, "Performance Problems with TCP's Slow-Start",
             2002.  URL "http://www.icir.org/floyd/hstcp/slowstart/".

[F02]S.フロイド、「TCPの遅れた出発に関するパフォーマンス問題」、2002。 URL" http://www.icir.org/floyd/hstcp/slowstart/ "。

   [G00]     A. Gurtov, "TCP Performance in the Presence of Congestion
             and Corruption Losses", Master's Thesis, University of
             Helsinki, Department of Computer Science, Helsinki,
             December 2000.  URL
             "http://www.cs.helsinki.fi/u/gurtov/papers/ms_thesis.html".

[G00]A.Gurtov、「混雑と不正損失の面前でTCPパフォーマンス」、マスターの論文、ヘルシンキ大学、コンピュータサイエンス学部、ヘルシンキ(2000年12月)。 URL" http://www.cs.helsinki.fi/u/gurtov/papers/ms_thesis.html "。

Floyd                         Experimental                      [Page 5]

RFC 3742     TCP's Slow-Start with Large Congestion Windows   March 2004

フロイド実験的な[5ページ]RFC3742TCPの大きい混雑Windows行進に伴う遅い始めの2004

   [H96]     J. C. Hoe, "Improving the Start-up Behavior of a Congestion
             Control Scheme for TCP", SIGCOMM 96, 1996.  URL
             "http://www.acm.org/sigcomm/sigcomm96/program.html".

[H96] J. C. SIGCOMM96、1996、「TCPの輻輳制御計画の始動の振舞いを改良し」て、鍬を入れてください。 URL" http://www.acm.org/sigcomm/sigcomm96/program.html "。

   [KCRP99]  J. Kulik, R. Coulter, D. Rockwell, and C. Partridge, "A
             Simulation Study of Paced TCP", BBN Technical Memorandum
             No. 1218, 1999.  URL
             "http://www.ir.bbn.com/documents/techmemos/index.html".

[KCRP99]J.クリク(R.コールター、D.ロックウェルとC.ヤマウズラ、「歩調を合わせられたTCPのシミュレーション研究」BBNの技術的なメモNo.1218、1999)。 URL" http://www.ir.bbn.com/documents/techmemos/index.html "。

   [MM96]    M. Mathis and J. Mahdavi, "Forward Acknowledgment: Refining
             TCP Congestion Control", SIGCOMM, August 1996.

[MM96] M.マシスとJ.Mahdavi、「承認を進めてください」 「TCP輻輳制御を洗練します」、SIGCOMM、1996年8月。

   [NS]      The Network Simulator (NS). URL
             "http://www.isi.edu/nsnam/ns/".

[ナノ秒] ネットワークシミュレータ(ナノ秒)。 URL" http://www.isi.edu/nsnam/ns/ "。

   [VEGAS]   Vegas Web Page, University of Arizona.  URL
             "http://www.cs.arizona.edu/protocols/".

[ベガ]ベガウェブページ、アリゾナ大学。 URL" http://www.cs.arizona.edu/protocols/ "。

   [VH97]    Vikram Visweswaraiah and John Heidemann, "Rate Based Pacing
             for TCP", 1997.  URL
             "http://www.isi.edu/lsam/publications/rate_based_pacing/".

[VH97]Vikram VisweswaraiahとジョンHeidemann、「TCPのために歩き回りながら基づくレート」、1997 URL" http://www.isi.edu/lsam/publications/rate_based_pacing/ "。

   [WS95]    G. Wright and W. Stevens, "TCP/IP Illustrated", Volume 2,
             Addison-Wesley Publishing Company, 1995.

[WS95] G.ライトとW.スティーブンス、「TCP/IPは例証した」第2巻、会社、1995を発行するアディソン-ウエスリー。

Authors' Address

作者のアドレス

   Sally Floyd
   ICIR (ICSI Center for Internet Research)

サリーフロイドICIR(インターネット調査のためのICSIセンター)

   Phone: +1 (510) 666-2989
   EMail: floyd@icir.org
   URL: http://www.icir.org/floyd/

以下に電話をしてください。 +1 (510) 666-2989 メールしてください: floyd@icir.org URL: http://www.icir.org/floyd/

Floyd                         Experimental                      [Page 6]

RFC 3742     TCP's Slow-Start with Large Congestion Windows   March 2004

フロイド実験的な[6ページ]RFC3742TCPの大きい混雑Windows行進に伴う遅い始めの2004

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to
   rights in RFC documents can be found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard.  Please address the information to the
   IETF at ietf-ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Floyd                         Experimental                      [Page 7]

フロイドExperimentalです。[7ページ]