RFC5033 日本語訳

Network Working Group                                           S. Floyd
Request for Comments: 5033                                     M. Allman
BCP: 133                                                     ICIR / ICSI
Category: Best Current Practice                              August 2007

コメントを求めるワーキンググループS.フロイド要求をネットワークでつないでください: 5033M.オールマンBCP: 133ICIR / ICSIカテゴリ: 最も良い現在の練習2007年8月

              Specifying New Congestion Control Algorithms

新しい輻輳制御アルゴリズムを指定します。

Status of This Memo

このメモの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Abstract

要約

   The IETF's standard congestion control schemes have been widely shown
   to be inadequate for various environments (e.g., high-speed
   networks).  Recent research has yielded many alternate congestion
   control schemes that significantly differ from the IETF's congestion
   control principles.  Using these new congestion control schemes in
   the global Internet has possible ramifications to both the traffic
   using the new congestion control and to traffic using the currently
   standardized congestion control.  Therefore, the IETF must proceed
   with caution when dealing with alternate congestion control
   proposals.  The goal of this document is to provide guidance for
   considering alternate congestion control algorithms within the IETF.

IETFの標準の輻輳制御計画は、様々な環境(例えば、高速ネットワーク)に不十分になるように広く示されました。 最近の研究はIETFの輻輳制御原則とかなり異なっている多くの交互の輻輳制御計画をもたらしました。 世界的なインターネットでこれらの新しい輻輳制御計画を使用すると、可能な分岐は新しい輻輳制御を使用する交通と交通使用への現在標準化された輻輳制御の両方に持たれています。 したがって、交互の輻輳制御提案に対処するとき、IETFは慎重に続かなければなりません。 このドキュメントの目標はIETFの中で交互の輻輳制御がアルゴリズムであると考えるための指導を提供することです。

Floyd & Allman           Best Current Practice                  [Page 1]

RFC 5033      Specifying New Congestion Control Algorithms   August 2007

輻輳制御アルゴリズム2007年8月に新しいフロイドとオールマン最も良い現在の習慣[1ページ]RFC5033指定

1.  Introduction

1. 序論

   This document provides guidelines for the IETF to use when evaluating
   suggested congestion control algorithms that significantly differ
   from the general congestion control principles outlined in [RFC2914].
   The guidance is intended to be useful to authors proposing alternate
   congestion control and for the IETF community when evaluating whether
   a proposal is appropriate for publication in the RFC series.

このドキュメントは[RFC2914]に概説された一般的な輻輳制御原則とかなり異なっている提案された輻輳制御アルゴリズムを評価するときIETFが使用するガイドラインを提供します。 RFCシリーズにおける公表に、提案が適切であるかどうか評価するとき、指導が交互の輻輳制御を提案する作者と、そして、IETF共同体の役に立つことを意図します。

   The guidelines in this document are intended to be consistent with
   the congestion control principles from [RFC2914] of preventing
   congestion collapse, considering fairness, and optimizing the flow's
   own performance in terms of throughput, delay, and loss.  [RFC2914]
   also discusses the goal of avoiding a congestion control "arms race"
   among competing transport protocols.

本書では、ガイドラインが混雑崩壊を防いで、公正を考えて、スループット、遅れ、および損失で流れの自己の性能を最適化する[RFC2914]からの輻輳制御原則と一致させていることを意図します。 また、[RFC2914]は競争しているトランスポート・プロトコルの中で輻輳制御「軍備競争」を避けるという目標について議論します。

   This document does not give hard-and-fast requirements for an
   appropriate congestion control scheme.  Rather, the document provides
   a set of criteria that should be considered and weighed by the IETF
   in the context of each proposal.  The high-order criteria for any new
   proposal is that a serious scientific study of the pros and cons of
   the proposal needs to have been done such that the IETF has a well-
   rounded set of information to consider.

このドキュメントは適切な輻輳制御計画のための厳重な要件を与えません。 むしろ、ドキュメントはそれぞれの提案の文脈のIETFによって考えられて、重さがあるはずである1セットの評価基準を提供します。 どんな新規案件も提案の賛否両論の重大な科学的な調査が、必要があるということであるので、IETFには考えるよく丸いセットの情報があるように、高位評価基準をしました。

   After initial studies, we encourage authors to write a specification
   of their proposals for publication in the RFC series to allow others
   to concretely understand and investigate the wealth of proposals in
   this space.

初期の研究の後に、私たちは、作者が他のものがこのスペースでRFCシリーズにおける公表で提案の富を具体的に理解して、調査するという彼らの提案の仕様を書くよう奨励します。

2.  Document Status

2. ドキュメント状態

   Following the lead of HighSpeed TCP [RFC3649], alternate congestion
   control algorithms are expected to be published as "Experimental"
   RFCs until such time that the community better understands the
   solution space.  Traditionally, the meaning of "Experimental" status
   has varied in its use and interpretation.  As part of this document
   we define two classes of congestion control proposals that can be
   published with the "Experimental" status.  The first class includes
   algorithms that are judged to be safe to deploy for best-effort
   traffic in the global Internet and further investigated in that
   environment.  The second class includes algorithms that, while
   promising, are not deemed safe enough for widespread deployment as
   best-effort traffic on the Internet, but are being specified to
   facilitate investigations in simulation, testbeds, or controlled
   environments.  The second class can also include algorithms where the
   IETF does not yet have sufficient understanding to decide if the
   algorithm is or is not safe for deployment on the Internet.

HighSpeed TCP[RFC3649]のリードに続いて、「実験的な」RFCsとして共同体が解決策スペースを理解しているほうがよいくらいの時間まで交互の輻輳制御アルゴリズムが発行されると予想されます。 伝統的に、「実験的な」状態の意味はその使用と解釈において異なりました。 このドキュメントの一部と、私たちは「実験的な」状態で発行できる2つのクラスの輻輳制御提案を定義します。 一流は世界的なインターネットのベストエフォート型交通に展開するために安全であると判断されて、その環境でさらに調査されるアルゴリズムを含んでいます。 インターネットにおけるベストエフォート型交通として約束している間に広範囲の展開に十分安全であることは考えられないアルゴリズムを含んでいますが、二等はシミュレーション、テストベッド、または制御環境で調査を容易にするために指定されているのを含んでいます。 また、二等はIETFがまだアルゴリズムがそうかどうか決めることができるくらいの理解を持っていないか、または展開には、インターネットで安全でないアルゴリズムを含むことができます。

Floyd & Allman           Best Current Practice                  [Page 2]

RFC 5033      Specifying New Congestion Control Algorithms   August 2007

輻輳制御アルゴリズム2007年8月に新しいフロイドとオールマン最も良い現在の習慣[2ページ]RFC5033指定

   Each alternate congestion control algorithm published is required to
   include a statement in the abstract indicating whether or not the
   proposal is considered safe for use on the Internet.  Each alternate
   congestion control algorithm published is also required to include a
   statement in the abstract describing environments where the protocol
   is not recommended for deployment.  There may be environments where
   the protocol is deemed *safe* for use, but still is not *recommended*
   for use because it does not perform well for the user.

発行されたそれぞれの交互の輻輳制御アルゴリズムが、提案がインターネットにおける使用に安全であることを検討されるかどうかを示す要約に声明を含むのに必要です。 また、発行されたそれぞれの交互の輻輳制御アルゴリズムが、プロトコルが展開のために推薦されないところに環境について説明する要約に声明を含むのに必要です。 そこでは、使用のための*がユーザのためによく振る舞わないので推薦された*ではなく、プロトコルは使用のための*金庫*であると考えられますが、まだある環境がそうです。

   As examples of such statements, [RFC3649] specifying HighSpeed TCP
   includes a statement in the abstract stating that the proposal is
   Experimental, but may be deployed in the current Internet.  In
   contrast, the Quick-Start document [RFC4782] includes a paragraph in
   the abstract stating the mechanism is only being proposed for
   controlled environments.  The abstract specifies environments where
   the Quick-Start request could give false positives (and therefore
   would be unsafe to deploy).  The abstract also specifies environments
   where packets containing the Quick-Start request could be dropped in
   the network; in such an environment, Quick-Start would not be unsafe
   to deploy, but deployment would still not be recommended because it
   could cause unnecessary delays for the connections attempting to use
   Quick-Start.

そのような声明に関する例として、HighSpeed TCPを指定する[RFC3649]は、提案がExperimentalであると述べる要約に声明を含んでいますが、現在のインターネットで配備されるかもしれません。 対照的に、クィック-スタートドキュメント[RFC4782]はメカニズムが制御環境のために提案されているだけであると述べる要約にパラグラフを含んでいます。 要約はクィック-スタート要求が無病誤診(そして、したがって、配備するのは危険である)を与えることができた環境を指定します。 また、要約はネットワークでクィック-スタート要求を含むパケットを落とすことができた環境を指定します。 そのような環境で、クィック-始めは配備するのが危険でないでしょうが、クィック-始めを使用するのを試みる接続のために不要な遅れを引き起こす場合があったので、展開はまだお勧めでないでしょう。

   For authors of alternate congestion control schemes who are not ready
   to bring their congestion control mechanisms to the IETF for
   standardization (either as Experimental or as Proposed Standard), one
   possibility would be to submit an internet-draft that documents the
   alternate congestion control mechanism for the benefit of the IETF
   and IRTF communities.  This is particularly encouraged in order to
   get algorithm specifications widely disseminated to facilitate
   further research.  Such an internet-draft could be submitted to be
   considered as an Informational RFC, as a first step in the process
   towards standardization.  Such a document would also be expected to
   carry an explicit warning against using the scheme in the global
   Internet.

1つの可能性は交互の輻輳制御計画の標準化(Experimentalとした、または、Proposed Standardとした)のためにそれらの混雑制御機構をIETFに持って来る準備ができていない作者に関してはIETFとIRTF共同体の利益のために交互の混雑制御機構を記録するインターネット草稿を提出するだろうことです。 これは、さらなる研究を容易にするためにアルゴリズム仕様を広く広めさせるために特に奨励されます。 Informational RFCであるとみなされるためにそのようなインターネット草稿を提出できました、標準化に向かった過程による第一歩として。 また、そのようなドキュメントが世界的なインターネットで計画を使用しないように明白な警告を運ぶと予想されるでしょう。

   Note: we are not changing the RFC publication process for non-IETF
   produced documents (e.g., those from the IRTF or Independent
   Submissions via the RFC-Editor).  However, we would hope the
   guidelines in this document inform the IESG as they consider whether
   to add a note to such documents.

以下に注意してください。 私たちは非IETFの生産されたドキュメント(例えば、RFC-エディタを通したIRTFか無党派Submissionsからのそれら)のためにRFC公表の過程を変えていません。 しかしながら、私たちは、そのようなドキュメントに注意を追加するかどうか考えるときガイドラインが本書ではIESGに知らせることを望んでいるでしょう。

3.  Guidelines

3. ガイドライン

   As noted above, authors are expected to do a well-rounded evaluation
   of the pros and cons of proposals brought to the IETF.  The following
   are guidelines to help authors and the IETF community.  Concerns that

上で述べたように、作者がIETFにもたらされた提案の賛否両論の幅広い評価をすると予想されます。 ↓これは、作者を助けるガイドラインとIETF共同体です。 それに、関係があります。

Floyd & Allman           Best Current Practice                  [Page 3]

RFC 5033      Specifying New Congestion Control Algorithms   August 2007

輻輳制御アルゴリズム2007年8月に新しいフロイドとオールマン最も良い現在の習慣[3ページ]RFC5033指定

   fall outside the scope of these guidelines are certainly possible;
   these guidelines should not be considered as an all-encompassing
   check-list.

確かに、これらのガイドラインの範囲の外の秋は可能です。 オールの取り囲むチェック・リストであるとこれらのガイドラインをみなすべきではありません。

   (0) Differences with Congestion Control Principles [RFC2914]

(0) 輻輳制御プリンシプルズがある違い[RFC2914]

       Proposed congestion control mechanisms should include a clear
       explanation of the deviations from [RFC2914].

提案された混雑制御機構は[RFC2914]からの逸脱に関する明確な説明を含んでいるはずです。

   (1) Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340].

(1) 標準のTCP、SCTP[RFC2960]、およびDCCP[RFC4340]で影響を与えてください。

       Proposed congestion control mechanisms should be evaluated when
       competing with standard IETF congestion control [RFC2581,
       RFC2960, RFC4340].  Alternate congestion controllers that have a
       significantly negative impact on traffic using standard
       congestion control may be suspect and this aspect should be part
       of the community's decision making with regards to the
       suitability of the alternate congestion control mechanism.

標準のIETF輻輳制御[RFC2581、RFC2960、RFC4340]と競争するとき、提案された混雑制御機構は評価されるべきです。 標準の輻輳制御を使用することでかなり否定的な影響力を交通に持っている交互の混雑コントローラは怪しいかもしれません、そして、この局面は交互の混雑制御機構の適合への尊敬による共同体の意志決定の一部であるべきです。

       We note that this bullet is not a requirement for strict TCP-
       friendliness as a prerequisite for an alternate congestion
       control mechanism to advance to Experimental.  As an example,
       HighSpeed TCP is a congestion control mechanism that is
       Experimental, but that is not TCP-friendly in all environments.
       We also note that this guideline does not constrain the fairness
       offered for non-best-effort traffic.

私たちは、この弾丸が交互の混雑制御機構のための前提条件としての厳しいTCP友情がExperimentalに達するという要件でないことに注意します。 例として、HighSpeed TCPはExperimentalですが、TCPすべての環境でに優しくない混雑制御機構です。 また、私たちは、このガイドラインが非ベストエフォート型の交通のために提供された公正を抑制しないことに注意します。

       As an example from an Experimental RFC, fairness with standard
       TCP is discussed in Sections 4 and 6 of [RFC3649] (HighSpeed TCP)
       and using spare capacity is discussed in Sections 6, 11.1, and 12
       of [RFC3649].

Experimental RFCからの例として、標準のTCPがある公正は[RFC3649](HighSpeed TCP)のセクション4と6で議論されています、そして、[RFC3649]のセクション6、11.1、および12で設備余力を使用するのと議論します。

   (2) Difficult Environments.

(2) 難しい環境。

       The proposed algorithms should be assessed in difficult
       environments such as paths containing wireless links.
       Characteristics of wireless environments are discussed in
       [RFC3819] and in Section 16 of [Tools].  Other difficult
       environments can include those with multipath routing within a
       connection.  We note that there is still much to be desired in
       terms of the performance of TCP in some of these difficult
       environments.  For congestion control mechanisms with explicit
       feedback from routers, difficult environments can include paths
       with non-IP queues at layer-two, IP tunnels, and the like.  A
       minimum goal for experimental mechanisms proposed for widespread
       deployment in the Internet should be that they do not perform
       significantly worse than TCP in these environments.

提案されたアルゴリズムは無線のリンクを含む経路などの難しい環境で評価されるべきです。 [RFC3819]と[ツール]のセクション16で無線の環境の特性について議論します。 他の難しい環境は接続の中に多重通路ルーティングがあるそれらを含むことができます。 私たちは、これらの難しい環境のいくつかにおける、TCPの性能で望まれるために多くがまだあることに注意します。 ルータからの明白なフィードバックがある混雑制御機構のために、難しい環境は層-2における非IP待ち行列、IPトンネル、および同様のものがある経路を含むことができます。 インターネットでの広範囲の展開のために提案された実験メカニズムの最小の目標はこれらの環境におけるTCPよりかなりひどく働かないということであるべきです。

Floyd & Allman           Best Current Practice                  [Page 4]

RFC 5033      Specifying New Congestion Control Algorithms   August 2007

輻輳制御アルゴリズム2007年8月に新しいフロイドとオールマン最も良い現在の習慣[4ページ]RFC5033指定

       While it is impossible to enumerate all the possible "difficult
       environments", we note that the IETF has previously grappled with
       paths with long delays [RFC2488], high delay bandwidth products
       [RFC3649], high packet corruption rates [RFC3155], packet
       reordering [RFC4653], and significantly slow links [RFC3150].
       Aspects of alternate congestion control that impact networks with
       these characteristics should be detailed.

すべての可能な「難しい環境」を列挙するのが不可能である間、私たちは、IETFが以前に長時間の遅延[RFC2488]、高い遅れ帯域幅生成物[RFC3649]、高いパケット不正率[RFC3155]、パケット再命令[RFC4653]、およびかなり遅いリンク[RFC3150]で経路と格闘したことに注意します。 これらの特性があるネットワークに影響を与える交互の輻輳制御の局面は詳細であるべきです。

       As an example from an Experimental RFC, performance in difficult
       environments is discussed in Sections 6, 9.2, and 10.2 of
       [RFC4782] (Quick-Start).

Experimental RFCからの例として、難しい環境における性能は[RFC4782](迅速な始め)のセクション6、9.2、および10.2で議論されています。

   (3) Investigating a Range of Environments.

(3) さまざまな環境を調査すること。

       Similar to the last criteria, proposed alternate congestion
       controllers should be assessed in a range of environments.  For
       instance, proposals should be investigated across a range of
       bandwidths, round-trip times, levels of traffic on the reverse
       path, and levels of statistical multiplexing at the congested
       link.  Similarly, proposals should be investigated for robust
       performance with different queueing mechanisms in the routers,
       especially Random Early Detection (RED) [FJ03] and Drop-Tail.
       This evaluation is often not included in the internet-draft
       itself, but in related papers cited in the draft.

最後の評価基準と同様であることで、提案された交互の混雑コントローラはさまざまな環境で評価されるべきです。 例えば、提案はさまざまな帯域幅、往復の回、逆の経路における交通、および混雑しているリンクの統計的多重化のレベルのレベルの向こう側に調査されるべきです。 同様に、ルータ、特にRandom Early Detection(RED)[FJ03]、およびDrop-テールの中に異なった待ち行列メカニズムがある状態で、提案はロバスト性能のために調査されるべきです。 この評価はインターネット草稿自体にしばしば含まれているのではなく、草稿で引用された関連する書類に含まれています。

       A particularly important aspect of evaluating a proposal for
       standardization is in understanding where the algorithm breaks
       down.  Therefore, particular attention should be paid to
       characterizing the areas where the proposed mechanism does not
       perform well.

どこでアルゴリズムに失敗するかを理解するのにおいて標準化のための提案を評価する特に重要な局面があります。 したがって、提案されたメカニズムがよく振る舞わない領域を特徴付けるのに特別の注意を向けるべきです。

       As an example from an Experimental RFC, performance in a range of
       environments is discussed in Section 12 of [RFC3649] (HighSpeed
       TCP) and Section 9.7 of [RFC4782] (Quick-Start).

Experimental RFCからの例として、さまざまな環境における性能は[RFC3649]のセクション12(HighSpeed TCP)と[RFC4782]のセクション9.7(迅速な始め)で議論されています。

   (4) Protection Against Congestion Collapse.

(4) 混雑崩壊に対する保護。

       The alternate congestion control mechanism should either stop
       sending when the packet drop rate exceeds some threshold
       [RFC3714], or should include some notion of "full backoff".  For
       "full backoff", at some point the algorithm would reduce the
       sending rate to one packet per round-trip time and then
       exponentially backoff the time between single packet
       transmissions if congestion persists.  Exactly when either "full
       backoff" or a pause in sending comes into play will be
       algorithm-specific.  However, as discussed in [RFC2914], this
       requirement is crucial to protect the network in times of extreme
       congestion.

交互の混雑制御機構は、パケット低下率が何らかの敷居[RFC3714]を超えていると発信するのを止めるはずであるべきであるか、または「完全なbackoff」の何らかの概念を含んでいるはずです。 「完全なbackoff」に関しては、何らかのポイントでは、アルゴリズムは、ある往復の時間あたりのパケットに送付レートを低下させて、混雑が持続しているなら、次に、ただ一つのパケット伝送の間で時間を指数関数的にbackoffするでしょう。 発信における「完全なbackoff」かくぎりのどちらかがちょうどいつプレーに入るかはアルゴリズム特有になるでしょう。 しかしながら、[RFC2914]で議論するように、この要件は極端な混雑の時代にネットワークを保護するために重要です。

Floyd & Allman           Best Current Practice                  [Page 5]

RFC 5033      Specifying New Congestion Control Algorithms   August 2007

輻輳制御アルゴリズム2007年8月に新しいフロイドとオールマン最も良い現在の習慣[5ページ]RFC5033指定

       If "full backoff" is used, this bullet does not require that the
       full backoff mechanism must be identical to that of TCP
       [RFC2988].  As an example, this bullet does not preclude full
       backoff mechanisms that would give flows with different round-
       trip times comparable bandwidth during backoff.

「完全なbackoff」が使用されているなら、この弾丸は、完全なbackoffメカニズムがTCP[RFC2988]のものと同じであるに違いないことを必要としません。 例として、この弾丸はbackoffの間にいろいろな丸い旅行時間がある流れに匹敵する帯域幅を与える完全なbackoffメカニズムを排除しません。

   (5) Fairness within the Alternate Congestion Control Algorithm.

(5) 交互の輻輳制御アルゴリズムの中の公正。

       In environments with multiple competing flows all using the same
       alternate congestion control algorithm, the proposal should
       explore how bandwidth is shared among the competing flows.

複数の競争している流れがすべて、同じ交互の輻輳制御アルゴリズムを使用している環境で、提案は帯域幅が競争している流れの中でどう共有されるかを探検するべきです。

   (6) Performance with Misbehaving Nodes and Outside Attackers.

(6) ふらちな事するノードと攻撃者の外でのパフォーマンス。

       The proposal should explore how the alternate congestion control
       mechanism performs with misbehaving senders, receivers, or
       routers.  In addition, the proposal should explore how the
       alternate congestion control mechanism performs with outside
       attackers.  This can be particularly important for congestion
       control mechanisms that involve explicit feedback from routers
       along the path.

提案は交互の混雑制御機構がふらちな事をしている送付者、受信機、またはルータでどう働くかを探検するべきです。 さらに、提案は交互の混雑制御機構が外部の攻撃者と共にどう働くかを探検するべきです。 経路に沿ったルータから明白なフィードバックにかかわる混雑制御機構には、これは特に重要である場合があります。

       As an example from an Experimental RFC, performance with
       misbehaving nodes and outside attackers is discussed in Sections
       9.4, 9.5, and 9.6 of [RFC4782] (Quick-Start).  This includes
       discussion of misbehaving senders and receivers; collusion
       between misbehaving routers; misbehaving middleboxes; and the
       potential use of Quick-Start to attack routers or to tie up
       available Quick-Start bandwidth.

Experimental RFCからの例として、ふらちな事するノードと攻撃者の外の性能は[RFC4782](迅速な始め)のセクション9.4、9.5、および9.6で議論されています。 これはふらちな事をしている送付者と受信機の議論を含んでいます。 ふらちな事するルータの間の共謀。 ふらちな事をしているmiddleboxes。 そして、攻撃ルータ、または、タイアップの利用可能なクィック-スタート帯域幅へのクィック-始めの潜在的使用。

   (7) Responses to Sudden or Transient Events.

(7) 突然の、または、一時的な出来事への応答。

       The proposal should consider how the alternate congestion control
       mechanism would perform in the presence of transient events such
       as sudden congestion, a routing change, or a mobility event.
       Routing changes, link disconnections, intermittent link
       connectivity, and mobility are discussed in more detail in
       Section 17 of [Tools].

提案は、交互の混雑制御機構が突然の混雑、ルーティング変化、または移動性出来事などの一時的事象の面前でどのように働くかを考えるべきです。 さらに詳細に[ツール]のセクション17でルート設定変化、リンクの切断、間欠リンクの接続性、および移動性について議論します。

       As an example from an Experimental RFC, response to transient
       events is discussed in Section 9.2 of [RFC4782] (Quick-Start).

Experimental RFCからの例として、一時的事象への応答は[RFC4782](迅速な始め)のセクション9.2で議論されています。

   (8) Incremental Deployment.

(8) 増加の展開。

       The proposal should discuss whether the alternate congestion
       control mechanism allows for incremental deployment in the
       targeted environment.  For a mechanism targeted for deployment in
       the current Internet, it would be helpful for the proposal to

提案は、交互の混雑制御機構が増加の展開のために狙いに環境を許容するかどうか議論するべきです。 現在のインターネットでの展開のために狙うメカニズムのために、提案において、それは役立っているでしょう。

Floyd & Allman           Best Current Practice                  [Page 6]

RFC 5033      Specifying New Congestion Control Algorithms   August 2007

輻輳制御アルゴリズム2007年8月に新しいフロイドとオールマン最も良い現在の習慣[6ページ]RFC5033指定

       discuss what is known (if anything) about the correct operation
       of the mechanism with some of the equipment installed in the
       current Internet, e.g., routers, transparent proxies, WAN
       optimizers, intrusion detection systems, home routers, and the
       like.

何らかの設備が現在のインターネットにインストールされているメカニズムの正しい操作に関して知られている(どちらかと言えば)こと、例えば、ルータ、透明なプロキシ、WANオプティマイザ、侵入検知システム、家のルータ、および同様のものについて議論してください。

       As a similar concern, if the alternate congestion control
       mechanism is intended only for specific environments (and not the
       global Internet), the proposal should consider how this intention
       is to be carried out.  The community will have to address the
       question of whether the scope can be enforced by simply stating
       the restrictions or whether additional protocol mechanisms are
       required to enforce the scoping.  The answer will necessarily
       depend on the change being proposed.

同様の関心として、交互の混雑制御機構が単に特定の環境(そして、世界的なインターネットでない)のために意図するなら、提案は行われるこの意志がことである方法を考えるべきです。 共同体は単に制限を述べることによって範囲を実施できるかどうか、または追加議定書メカニズムが見ることを実施しなければならないかどうかに関する質問を記述しなければならないでしょう。 答えは必ず提案される変化によるでしょう。

       As an example from an Experimental RFC, deployment issues are
       discussed in Sections 10.3 and 10.4 of [RFC4782] (Quick-Start).

Experimental RFCからの例として、展開問題は[RFC4782](迅速な始め)のセクション10.3と10.4で議論されています。

4.  Minimum Requirements

4. 必要最小限

   This section suggests minimum requirements for a document to be
   approved as Experimental with approval for widespread deployment in
   the global Internet.

このセクションは、広範囲の展開への承認が世界的なインターネットにある状態でドキュメントがExperimentalとして承認されるために必要最小限を示します。

   The minimum requirements for approval for widespread deployment in
   the global Internet include the following guidelines on: (1)
   assessing the impact on standard congestion control, (3)
   investigation of the proposed mechanism in a range of environments,
   (4) protection against congestion collapse, and (8) discussing
   whether the mechanism allows for incremental deployment.

世界的なインターネットでの広範囲の展開への承認のための必要最小限は以下に以下のガイドラインを含んでいます。 (1) (8) 標準の輻輳制御への影響、さまざまな環境、混雑崩壊に対する(4)保護における、提案されたメカニズムの(3)研究を評価して、メカニズムが増加の展開を考慮するかどうか議論すること。

   For other guidelines, i.e., (2), (5), (6), and (7), the author must
   perform the suggested evaluations and provide recommended analysis.
   Evidence that the proposed mechanism has significantly more problems
   than those of TCP should be a cause for concern in approval for
   widespread deployment in the global Internet.

他のガイドライン、すなわち、(2)、(5)、(6)、および(7)のために、作者は、提案された評価を実行して、お勧めの分析を提供しなければなりません。 提案されたメカニズムにはTCPのものよりかなり多くの問題があるという証拠は世界的なインターネットでの広範囲の展開への承認で心配の種であるべきです。

5.  Security Considerations

5. セキュリティ問題

   This document does not represent a change to any aspect of the TCP/IP
   protocol suite and therefore does not directly impact Internet
   security.  The implementation of various facets of the Internet's
   current congestion control algorithms do have security implications
   (e.g., as outlined in [RFC2581]).  Alternate congestion control
   schemes should be mindful of such pitfalls, as well, and should
   examine any potential security issues that may arise.

このドキュメントは、TCP/IPプロトコル群のどんな局面への変化も表さないで、またしたがって、直接インターネットセキュリティに影響を与えません。 インターネットの現在の輻輳制御アルゴリズムの様々な一面の実現には、セキュリティ意味があります(例えば、[RFC2581]に概説されているように)。 交互の輻輳制御計画は、また、そのような落とし穴に心に留めるべきであり、起こるどんな潜在的安全保障問題も調べるべきです。

Floyd & Allman           Best Current Practice                  [Page 7]

RFC 5033      Specifying New Congestion Control Algorithms   August 2007

輻輳制御アルゴリズム2007年8月に新しいフロイドとオールマン最も良い現在の習慣[7ページ]RFC5033指定

6.  Acknowledgments

6. 承認

   Discussions with Lars Eggert and Aaron Falk seeded this document.
   Thanks to Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye,
   Colin Perkins, Pekka Savola, members of TSVWG, and participants at
   the TCP Workshop at Microsoft Research for feedback and
   contributions.  This document also draws from [Metrics].

ラース・エッゲルトとアーロン・フォークとの議論はこのドキュメントに種を蒔きました。 フィードバックと貢献をマイクロソフトResearchでボブ・ブリスコウ、ゴーリーFairhurst、ダグ・リース、Jitendra Padhye、コリン・パーキンス、ペッカSavola、TSVWGのメンバー、およびTCP Workshopの関係者をありがとうございます。 また、このドキュメントは[測定基準]から作成されます。

7.  Normative References

7. 引用規格

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

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

   [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
             2914, September 2000.

[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。

   [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
             Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang,
             L., and V. Paxson, "Stream Control Transmission Protocol",
             RFC 2960, October 2000.

[RFC2960] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(2000年10月)対パクソン

   [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
             Control Protocol (DCCP)", RFC 4340, March 2006.

[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。

8.  Informative References

8. 有益な参照

   [FJ03]    Floyd, S., and Jacobson, V., Random Early Detection
             Gateways for Congestion Avoidance, IEEE/ACM Transactions on
             Networking, V.1 N.4, August 1993.

[FJ03] フロイド、S.とジェーコブソン、V.、輻輳回避のための無作為の早期発見ゲートウェイ、ネットワークのIEEE/ACM取引、V.1 N.4(1993年8月)。

   [Metrics] S. Floyd, Metrics for the Evaluation of Congestion Control
             Mechanisms, Work in Progress, July 2007.

[測定基準] S.フロイド、混雑制御機構の評価のための測定基準は進歩、2007年7月に働いています。

   [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP Over
             Satellite Channels using Standard Mechanisms", BCP 28, RFC
             2488, January 1999.

[RFC2488]のオールマン、M.、手袋製造業者、D.、およびL.サンチェス、「衛星の上の高めるTCPは標準のメカニズムを使用することで精神を集中します」、BCP28、RFC2488、1999年1月。

   [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
             Timer", RFC 2988, November 2000.

[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。

   [RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret,
             "End-to-end Performance Implications of Slow Links", BCP
             48, RFC 3150, July 2001.

[RFC3150] ダウキンズ、S.、モンテネグロ、G.、Kojo、M.、およびV.Magret、「終わりから終わりへの遅いリンクのパフォーマンス含意」、BCP48、RFC3150(2001年7月)。

   [RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N.
             Vaidya, "End-to-end Performance Implications of Links with
             Errors", BCP 50, RFC 3155, August 2001.

[RFC3155] ダウキンズ、S.、モンテネグロ、G.、Kojo、M.、Magret、V.、およびN.Vaidya、「終わりから終わりへの誤りとのリンクのパフォーマンス含意」、BCP50、RFC3155(2001年8月)。

Floyd & Allman           Best Current Practice                  [Page 8]

RFC 5033      Specifying New Congestion Control Algorithms   August 2007

輻輳制御アルゴリズム2007年8月に新しいフロイドとオールマン最も良い現在の習慣[8ページ]RFC5033指定

   [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
             RFC 3649, December 2003.

[RFC3649]フロイド、2003年12月のS.、「大きい混雑WindowsのためのHighSpeed TCP」RFC3649。

   [RFC3714] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
             Control for Voice Traffic in the Internet", RFC 3714, March
             2004.

[RFC3714] フロイド、S.、およびJ.ケンフ、「混雑に関するIAB心配はインターネットの音声トラヒックに制御します」、RFC3714、2004年3月。

   [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig,
             R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood,
             "Advice for Internet Subnetwork Designers", BCP 89, RFC
             3819, July 2004.

[RFC3819]KarnとP.とボルマンとC.とFairhurstとG.とグロースマンとD.とラドウィグとR.とMahdaviとJ.とモンテネグロとG.と接触、J.とL.木、「インターネットサブネットワークデザイナーのためのアドバイス」BCP89、RFC3819(2004年7月)。

   [RFC4653] Bhandarkar, S., Reddy, A. N., Allman, M., and E. Blanton,
             "Improving the Robustness of TCP to Non-Congestion Events",
             RFC 4653, August 2006.

[RFC4653] Bhandarkar、S.、レディ、A.N.、オールマン、M.、およびE.ブラントン、「非混雑出来事にTCPの丈夫さを改良します」、RFC4653(2006年8月)。

   [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
             Start for TCP and IP", RFC 4782, January 2007.

[RFC4782] フロイド、S.、オールマン、M.、ジャイナ教徒、A.、およびP.Sarolahti、「TCPとIPのための迅速な始め」、RFC4782、2007年1月。

   [Tools]   S. Floyd and E. Kohler, Tools for the Evaluation of
             Simulation and Testbed Scenarios, Work in Progress, July
             2007.

[ツール] S.フロイドとE.コーラー(シミュレーションとテストベッドシナリオの評価のためのツール)は進歩、2007年7月に働いています。

Authors' Addresses

作者のアドレス

   Sally Floyd
   ICIR (ICSI Center for Internet Research)
   1947 Center Street, Suite 600
   Berkeley, CA 94704-1198
   Phone: +1 (510) 666-2989
   EMail: floyd@icir.org
   URL: http://www.icir.org/floyd/

フロイドICIR(インターネット調査のためのICSIセンター)1947Center通り、スイート600バークレー、カリフォルニア94704-1198電話を出撃させてください: +1 (510) 666-2989 メールしてください: floyd@icir.org URL: http://www.icir.org/floyd/

   Mark Allman
   ICSI Center for Internet Research
   1947 Center Street, Suite 600
   Berkeley, CA 94704-1198
   Phone: (440) 235-1792
   EMail: mallman@icir.org
   URL: http://www.icir.org/mallman/

マークオールマンICSIは1947Center通り、Suite600バークレー、カリフォルニア94704-1198が電話をする研究をインターネットの中心に置きます: (440) 235-1792 メールしてください: mallman@icir.org URL: http://www.icir.org/mallman/

Floyd & Allman           Best Current Practice                  [Page 9]

RFC 5033      Specifying New Congestion Control Algorithms   August 2007

輻輳制御アルゴリズム2007年8月に新しいフロイドとオールマン最も良い現在の習慣[9ページ]RFC5033指定

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   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.

このドキュメントは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, THE IETF TRUST 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.

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

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に情報を記述してください。

Floyd & Allman           Best Current Practice                 [Page 10]

フロイドとオールマンBest現在の習慣[10ページ]