RFC 5290 - Comments on the Usefulness of Simple Best-Effort Traffic 日本語訳

URL : https://tools.ietf.org/html/rfc5290
タイトル : RFC 5290 - シンプルなベストエフォートトラフィックの有用性に関するコメント
翻訳編集 : 自動生成

Network Working Group                                           S. Floyd
Request for Comments: 5290                                     M. Allman
Category:  Informational                                            ICSI
                                                               July 2008

        Comments on the Usefulness of Simple Best-Effort Traffic

Status of This Memo

このメモのステータス

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

IESG Note

IESG注意

The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work.

このRFCの内容は、IETFによって考慮一度だったので、それが進行または公開されたIETF仕事で現在IETFの作業に似ていてもよいです。

This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.

このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、このRFCのフィットネスの知識を否認し、公開する決定がIETF仕事との競合のためのIESGレビューとは別にIETFレビューに基づいていないことを指摘しています。 RFC Editorはその裁量でこの文書を公開することを選択しました。詳細については、RFC 3932を参照してください。

Abstract

抽象

This document presents some observations on "simple best-effort traffic", defined loosely for the purposes of this document as Internet traffic that is not covered by Quality of Service (QOS) mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like. One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping. While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as *adjuncts* to simple best-effort traffic, not as *replacements* of simple best-effort traffic. A second observation is that for simple best-effort traffic, some form of rough flow-rate fairness is a useful goal for resource allocation, where "flow-rate fairness" is defined by the goal of equal flow rates for different flows over the same path.

このドキュメントでは、サービス品質（QOS）メカニズム、輻輳ベースの価格設定、コストベースの公正性、入学制御によって覆われていないインターネットトラフィックとして、この文書の目的のために緩やかに定義された、「シンプルなベストエフォート型トラフィック」にいくつかの所見を提示します、など。一つの観察は、単純なベストエフォート型トラフィックは、インターネットに便利な役割を果たし、かつ維持する価値があるということです。トラフィックの異なる待遇を明確に役立つことができますが、私たちは、補助剤は、単純なベストエフォート型トラフィックに、いないシンプルなベストエフォート型トラフィックの*交換*と* *このようなメカニズムが有用であると考えています。第2の観察は、単純なベストエフォート型のトラフィックのために、粗い流量公平性のいくつかのフォームは、「流量公平性」が同じ以上の異なるフローの等しい流量の目標によって定義されたリソース割り当て、のために有用な目標であるということです道。

Table of Contents

   1. Introduction ....................................................2
   2. On Simple Best-Effort Traffic ...................................3
      2.1. The Usefulness of Simple Best-Effort Traffic ...............4
      2.2. The Limitations of Simple Best-Effort Traffic ..............4
           2.2.1. Quality of Service (QoS) ............................4
           2.2.2. The Avoidance of Congestion Collapse and the
                  Enforcement of Fairness..............................6
           2.2.3. Control of Traffic Surges ...........................6
   3. On Flow-Rate Fairness for Simple Best-Effort Traffic ............6
      3.1. The Usefulness of Flow-Rate Fairness .......................7
      3.2. The Limitations of Flow-Rate Fairness ......................8
           3.2.1. The Enforcement of Flow-Rate Fairness ...............8
           3.2.2. The Precise Definition of Flow-Based Fairness .......9
   4. On the Difficulties of Incremental Deployment ..................11
   5. Related Work ...................................................12
      5.1. From the IETF .............................................12
      5.2. From Elsewhere ............................................13
   6. Security Considerations ........................................14
   7. Conclusions ....................................................14
   8. Acknowledgements ...............................................14
   9. Informative References .........................................14

1. Introduction

1. はじめに

This document gives some observations on the role of simple best-effort traffic in the Internet. For the purposes of this document, we define "simple best-effort traffic" as traffic that does not *rely* on the *differential treatment* of flows either in routers or in policers, enforcers, or other middleboxes along the path and that does not use admissions control. We define the term "simple best-effort traffic" to avoid unproductive semantic discussions about what the phrase "best-effort traffic" does or does not include. We note that our definition of "simple best-effort traffic" includes traffic that is not necessarily "simple", including mechanisms common in the current Internet such as pairwise agreements between ISPs, volume-based pricing, firewalls, and a wide range of mechanisms in middleboxes.

このドキュメントはインターネットで簡単なベストエフォート型トラフィックの役割について、いくつかの観測を提供します。このドキュメントの目的のために、私たちは、*それがないルータまたはパスに沿っポリサー、執行者、またはその他のミドルボックス内のいずれかの流れの*異なる待遇*に*依存しないトラフィックとして、「シンプルなベストエフォート型トラフィック」を定義します入学コントロールを使用していません。私たちは、句「ベストエフォート型トラフィックが」ないか、含まれていないものについては非生産的な意味的な議論を避けるために、用語「シンプルなベストエフォート型トラフィック」を定義します。私たちは、「シンプルなベストエフォート型トラフィック」の私達の定義は、このようなISPは、ボリュームベースの価格設定、ファイアウォール、およびメカニズムの広い範囲とのペアごとの契約として、現在のインターネットでの一般的なメカニズムを含めて、必ずしも「シンプル」ではないトラフィックが含まれていることに注意してくださいミドルボックスインチ

"Simple best-effort traffic" in the current Internet uses end-to-end transport protocols (e.g., TCP, UDP, or others), with minimal requirements of the network in terms of resource allocation. However, other implementations of simple best-effort service would be possible, including those that would rely on Fair Queueing or some other form of per-flow scheduling in congested routers. Our intention is to define "simple best-effort traffic" to include the dominant traffic class in the current Internet.

現在のインターネットでは「シンプルなベストエフォート型トラフィックは、」資源配分の観点からネットワークの最小要件とエンドツーエンドのトランスポートプロトコル（例えば、TCP、UDP、またはその他）、使用しています。しかし、シンプルなベストエフォート型サービスの他の実装は、均等化キューイングや輻輳したルータでのフローごとのスケジューリングの他のいくつかの形式に依存しているということも含め、可能です。私たちの目的は、現在のインターネットでの支配的なトラフィッククラスを含めるために、「シンプルなベストエフォート型トラフィック」を定義することです。

In contrast to "simple best-effort traffic", intserv- or diffserv-enabled traffic relies on differential scheduling mechanisms at congested routers, with packets from different intserv or diffserv classes receiving different treatment. Similarly, in contrast to "simple best-effort traffic", cost-based fairness [B07] would most likely require the deployment of traffic marking (e.g., Explicit Congestion Notification (ECN)) at congested routers, along with policing mechanisms near the two ends of the connection providing differential treatment for packets in different flows or in different traffic classes. Intserv/diffserv, cost-based fairness, and congestion-based pricing could also require more complex pairwise economic relationships among Internet Service Providers (ISPs), and between end-users and ISPs.

「シンプルなベストエフォート型トラフィック」とは対照的に、intserv-またはDiffServの対応のトラフィックは、異なる治療を受けて異なるイントサーブまたはDiffServのクラスからのパケットを、混雑ルータの差動スケジューリングメカニズムに依存しています。同様に、「シンプルなベストエフォート型トラフィック」とは対照的に、コストベースの公正[B07]は、最も可能性の高いトラフィックマーキングの展開を必要とする（例えば、明示的輻輳通知（ECN））2近くポリシングメカニズムと一緒に混雑ルータで、異なるフローまたは異なるトラフィッククラス内のパケットのための差分処理を提供する接続の両端。イントサーブ/ DiffServの、コストベースの公正性、および輻輳ベースの価格設定は、インターネットサービスプロバイダ（ISP）の間、およびエンドユーザーとISP間のより複雑なペアごとの経済的な関係をも必要とする可能性があります。

This document suggests that it is important to retain the class of "simple best-effort traffic" (though hopefully augmented by a wider deployment of other classes of service). Further, this document suggests that some form of rough flow-rate fairness is an appropriate goal for simple best-effort traffic. We do not argue in this document that flow-rate fairness is the *only possible* or *only desirable* resource allocation goal for simple best-effort traffic. We maintain, however, that it is an appropriate resource allocation goal for simple best-effort traffic in the current Internet, evolving from the Internet's past of end-point congestion control.

この文書は、（うまくいけば、サービスの他のクラスの広い展開によって増大が）、「シンプルなベストエフォート型トラフィック」のクラスを維持することが重要であることを示唆しています。さらに、このドキュメントはラフ流量公平性のいくつかのフォームが簡単なベストエフォート型トラフィックに適切な目標であることを示唆しています。私たちは、流量公平性は、単純なベストエフォート型トラフィックのための*のみ可能*または*のみ望ましい*資源配分の目標である。この文書で主張しません。我々は、エンドポイントの輻輳制御のインターネットの過去から進化し、それが現在のインターネットでは、単純なベストエフォートトラフィックに適切な資源配分の目標であること、しかし、維持します。

This document was motivated by [B07], a paper titled "Flow Rate Fairness: Dismantling a Religion" that asserts in the abstract that "comparing flow rates should never again be used for claims of fairness in production networks." This document does not attempt to be a rebuttal to [B07], or to answer any or all of the issues raised in [B07], or to give the "intellectual heritage" for flow-based fairness in philosophy or social science, or to commit the authors of this document to an extended dialogue with the author of [B07]. This document is simply a separate viewpoint on some related topics.

この文書は、[B07]、「流量フェアネス：宗教解体」と題した論文によって動機づけられた「比較流量が再び生産ネットワークにおける公正性の主張のために使用すべきではありません」という抽象的に主張しますこの文書では、[B07]に反論することを試みていない、または[B07]で提起された問題のいずれかまたは全てに答えるために、あるいは哲学や社会科学におけるフローベースの公平性のための「知的遺産」を与えるために、またはそれに[B07]の著者との対話拡張にこの文書の著者をコミットします。この文書では、単にいくつかの関連トピックに関する別の視点です。

2. On Simple Best-Effort Traffic

シンプルなベストエフォートトラフィック2.

This section makes some observations on the usefulness and limitations of the class of simple best-effort traffic, in comparison with traffic receiving differential treatment.

このセクションでは、トラフィック受け差動治療と比較して、簡単なベストエフォートトラフィックのクラスの有用性と限界に関するいくつかの観測を行います。

2.1. The Usefulness of Simple Best-Effort Traffic

2.1. シンプルなベストエフォート型トラフィックの有用性

We now list some useful aspects of simple best-effort traffic.

私たちは今、単純なベストエフォート型トラフィックのいくつかの有用な側面をリストアップ。

Minimal technical demands on the network infrastructure:

ネットワークインフラストラクチャ上で最小限の技術的な要求：

Simple best-effort traffic, as implemented in the current Internet, makes minimal technical demands on the infrastructure. There are no technical requirements for scheduling, queue management, or enforcement mechanisms in routers.

シンプルなベストエフォート型トラフィックは、現在のインターネットで実施されるように、インフラストラクチャ上の最小限の技術的な要求を行います。ルータには技術的なスケジューリングのための要件、キュー管理、または執行メカニズムがありません。

Minimal demands in terms of economic infrastructure:

経済インフラの面で最低限の要求：

Simple best-effort traffic makes minimal demands in terms of economic infrastructure, relying on fairly simple pair-wise economic relationships among ISPs, and between a user and its immediate ISP. In contrast, Section 4 discusses some of the difficulties in the incremental deployment of infrastructure for additional classes of service.

シンプルなベストエフォート型トラフィックはISPの間、およびユーザとその直接ISP間のかなり単純なペアワイズの経済関係を頼っ、経済インフラの面で最低限の要求を行います。これとは対照的に、第4節では、サービスの追加クラスのためのインフラの増分展開の難しさのいくつかを説明します。

Usefulness in the real world:

現実世界での有用性：

Simple best-effort traffic has been shown to work in the Internet for the past 20 years, however imperfectly. Simple best-effort traffic has supported everything from simple file and e-mail transfer and web traffic to video and audio streaming and voice communications.

シンプルなベストエフォート型トラフィックは、しかし、不完全、過去20年間、インターネットで働くことが示されています。シンプルなベストエフォート型トラフィックは、単純なファイルや電子メールの転送やWebトラフィックからのビデオとオーディオのストリーミングおよび音声通信にすべてをサポートしてきました。

As discussed below, simple best-effort traffic is not optimal. However, experience in the Internet has shown that there has been significant value in the mechanism of simple best-effort traffic, generally allowing all users to get a portion of the resources while still preventing congestion collapse.

以下に述べるように、シンプルなベストエフォート型トラフィックは最適ではありません。しかし、インターネットでの経験は、一般的に、まだ輻輳崩壊を防止しながら、すべてのユーザーがリソースの一部を取得することができ、簡単なベストエフォート型トラフィックのメカニズムに大きな価値があったことを示しています。

2.2. The Limitations of Simple Best-Effort Traffic

2.2. シンプルなベストエフォート型トラフィックの制限

We now discuss some limitations of simple best-effort traffic.

私たちは今、単純なベストエフォート型トラフィックのいくつかの制限について説明します。

2.2.1. Quality of Service (QoS)

2.2.1. サービスの品質（QoS）

Some users would be happy to pay for more bandwidth, less delay, less jitter, or fewer packet drops. It is desirable to accommodate such goals within the Internet architecture while preserving a sufficient amount of bandwidth for simple best-effort traffic.

一部のユーザーは、より多くの帯域幅、遅延が少なく、少ないジッタ、または少ないパケットドロップのために支払うために幸せになります。単純なベストエフォートトラフィックのために帯域幅の十分な量を維持しながら、インターネットアーキテクチャ内でそのような目標に対応することが望ましいです。

One of the obvious dangers of simple differential traffic treatment implementations that do not take steps to protect simple best-effort traffic would be that the users with more money *could* starve users with less money in times of congestion. There seems to be fairly widespread agreement that this would not be a desirable goal. As a sample of the range of positions, the Internet Society's Internet 2020 Initiative, titled "The Internet is (still) for Everyone", states that "we remain committed to the openness that ensures equal access and full participation for every user" [Internet2020].

より多くのお金を持つユーザーは、* *混雑の時代に少ないお金をユーザーに飢えることができることになり、単純なベストエフォート型トラフィックを保護するための措置を講じていないシンプルな差動トラフィック処理の実装の明白な危険の一つ。これは望ましい目標ではないことをかなり広範囲に合意があるようです。位置の範囲のサンプルとして、「インターネットはみんなのために（まだ）である」というタイトルのインターネット協会のインターネットイニシアティブ2020年には、「私たちはすべてのユーザーのための平等なアクセスと完全参加を保証開放性にコミットしたまま」と述べている[Internet2020 ]。

The wide-ranging discussion of "network neutrality" in the United States includes advocates of several positions, including that of "absolute non-discrimination" (with no QoS considerations), "limited discrimination without QoS tiering" (no fees charged for higher-quality service), and "limited discrimination and tiering" (including higher fees allowed for QoS) [NetNeutral]. The proponents of "network neutrality" are opposed to charging based on content (e.g., based on applications or the content provider).

米国では、「ネットワークの中立性」の幅広い議論は、「QoSの階層化せずに限られた差別」（なしのQoS配慮した）「絶対非差別」、のことなど、いくつかの位置の提唱者、設定（高に課金なし料を含み高品質のサービス）、およびQoSに許さ高い費用を含む「限定差別や階層化」（）[NetNeutral]。「ネットワーク中立性」の支持者は、コンテンツに基づいて、充電に対向する（例えば、アプリケーションまたはコンテンツプロバイダに基づいて）。

As the "network neutrality" discussion makes clear, there are many voices in the discussion that would disagree with a resource allocation goal of maximizing the combined aggregate utility (advocated in [B07a]), particularly where a user's utility is measured by the user's willingness to pay. "You get what you pay for" ([B07], page 5) does not appear to be the consensus goal for resource allocation in the community or in the commercial or political realms of the Internet. However, there is a reasonable agreement that higher-priced services, as an adjunct to simple best-effort traffic, can play an important role in helping to finance the Internet infrastructure.

「ネットワーク中立性」の議論が明らかにしたように、（[B07a]で提唱）合成凝集効用を最大化するリソース割り当て目標に反対になる議論に多くの声があり、特にユーザのユーティリティは、ユーザの意思によって測定されます支払います。「あなたは何を支払うを取得します」（[B07]は、5ページ）は、コミュニティ内やインターネットの商業や政治レルムで資源配分のためのコンセンサス目標ではありません。しかし、シンプルなベストエフォート型トラフィックの補助として、サービスをより高価格の合理的な合意がある、インターネットインフラの資金調達を支援する上で重要な役割を果たすことができます。

Briscoe argues for cost-fairness [B07], so that senders are made accountable for the congestion they cause. There are, of course, differences of opinion about how well cost-based fairness could be enforced, and how well it fits the commercial reality of the Internet, with [B07] presenting an optimistic view. Another point of view, e.g., from an earlier paper by Roberts titled "Internet Traffic, QoS, and Pricing", is that "many proposed schemes are overly concerned with congestion control to the detriment of the primary pricing function of return on investment" [R04].

送信者は、それらが引き起こす渋滞のために責任を作られるようにブリスコーは、費用対公正[B07]のために主張しています。そこもちろん、どれだけコストベースの公正性に関する意見の相違が施行される可能性があり、あり、そしてどれだけそれが[B07]は楽観的な見方を提示して、インターネットの商用現実に適合します。以前題しロバーツによる論文「インターネットのトラフィック、QoS、および価格」からの眺め、例えば、のもう一つのポイントは、[「多くの提案スキームは投資収益の主な価格決定機能を犠牲に輻輳制御と過度に懸念している」ということですR04]。

With *only* simple best-effort traffic, there would be fundamental limitations to the performance that real-time applications could deliver to users. In addition to the obvious needs for high bandwidth, low delay or jitter, or low packet drop rates, some applications would like a fast start-up, or to be able to resume their old high sending rate after a relatively long idle period, or to be able to rely on a call-setup procedure so that the application is not even started if network resources are not sufficient. There are severe limitations to how effectively these requirements can be accommodated by simple best-effort service in a congested environment. Of course, Quality of Service architectures for the Internet have their own limitations and difficulties, as discussed in [RFC2990] and elsewhere. We are not going to discuss these difficulties further here.

*のみ*シンプルなベストエフォート型トラフィックでは、リアルタイム・アプリケーションは、ユーザーに届けることができ、パフォーマンスへの根本的な限界があるだろう。高帯域幅、低遅延やジッタ、または低パケットドロップ率のための明白なニーズに加えて、いくつかのアプリケーションは、高速起動をしたいと思い、あるいは比較的長いアイドル期間の後、古い高い送信レートを再開できるようにする、またはネットワークリソースが十分でない場合は、アプリケーションも起動されないように、呼設定手順に頼ることができるようにします。これらの要件は、混雑した環境でシンプルなベストエフォート型のサービスで対応することができる方法を効果的に厳しい制限があります。 [RFC2990]にし、他の場所で説明したようにもちろん、インターネットのサービス・アーキテクチャの品質は、自分の限界や困難を抱えています。私たちは、ここでさらに、これらの困難を議論するつもりはありません。

2.2.2. The Avoidance of Congestion Collapse and the Enforcement of Fairness

2.2.2. 輻輳崩壊の回避と公正の施行

As discussed in Section 3.2 below, there are well-known problems with the enforcement of fairness and the avoidance of congestion collapse [RFC2914] with simple best-effort traffic. In the current Internet, end-to-end congestion control is relied upon to deal with these concerns; this use of end-to-end congestion control essentially requires cooperation from end-hosts.

以下のセクション3.2で説明したように、公正の施行とシンプルなベストエフォート型トラフィックで混雑崩壊[RFC2914]の回避と、よく知られている問題があります。現在のインターネットでは、エンドツーエンドの輻輳制御は、これらの懸念に対処するために頼っています。エンドツーエンドの輻輳制御のこの使用は、本質的にエンドホストからの協力を必要とします。

2.2.3. Control of Traffic Surges

2.2.3. トラフィックの制御が急増します

Simple best-effort traffic can suffer from sudden aggregate congestion from traffic surges (e.g., Distributed Denial of Service (DDoS) attacks, flash crowds), resulting in degraded performance for all simple best-effort traffic sharing the path. A wide range of approaches for detecting and responding to sudden aggregate congestion in the network has been proposed and used, including deep packet inspection and rate-limiting traffic aggregates. There are many open questions about both the goals and mechanisms of dealing with aggregates within simple best-effort traffic on congested links.

シンプルなベストエフォート型トラフィックは、トラフィックからの突然の集計渋滞に苦しむことができますパスを共有するすべてのシンプルなベストエフォートトラフィックのパフォーマンスが低下、（例えば、サービス拒否（DDoS攻撃）攻撃、フラッシュ群衆を分散）サージ。検出およびネットワークの急激な凝集輻輳に応答するためのアプローチの広い範囲が提案され、ディープパケットインスペクションと律速トラフィック凝集体を含む、使用されてきました。輻輳したリンク上で簡単なベストエフォート型トラフィックの中に骨材を扱うの両方の目標とメカニズムについて多くの未解決の問題があります。

3. On Flow-Rate Fairness for Simple Best-Effort Traffic

シンプルなベストエフォート型トラフィックの流量公正3.

This section argues that rough flow-rate fairness is an acceptable goal for simple best-effort traffic. We do not, however, claim that flow-rate fairness is necessarily an *optimal* fairness goal or resource allocation mechanism for simple best-effort traffic. Simple best-effort traffic and flow-rate fairness are in general not about optimality, but instead are about a low-overhead service (best-effort traffic) along with a rough, simple fairness model (flow-rate fairness).

このセクションでは、大まかな流量公平性は、単純なベストエフォート型トラフィックのために許容可能な目標であると主張しています。私たちは、しかし、その流量公平性は必ずしも簡単なベストエフォート型トラフィックのための*最適*公平性の目標や資源配分メカニズムであると主張していません。シンプルなベストエフォート型トラフィックおよび流量公平性がない最適に関する一般的であるが、代わりにラフ、簡単な公平性モデル（流量公平性）と一緒に低オーバーヘッドのサービス（ベストエフォートトラフィック）に関するものです。

Within simple best-effort traffic, it would be possible to have explicit fairness mechanisms that are implemented by the end-hosts in the network (as in proportional fairness or TCP fairness), explicit fairness mechanisms enforced by the routers (as in max-min fairness with Fair Queueing), or a traffic class with no explicit fairness mechanisms at all (as in the Internet before TCP congestion control).

シンプルなベストエフォート型トラフィックの中で、（プロポーショナルフェアネスまたはTCP公平性のように）ネットワーク内のエンドホストによって実装され、明示的な公平性の機構を有することが可能であろう、ルーターによって強制明示的な公平性メカニズム（最大 - 最小のようにTCPの輻輳制御の前に、インターネットのように、すべての明示的な公平性メカニズムとの均等化キューイングとの公平性）、またはトラフィッククラス（）。

This document does *not* address the issues about the implementation of flow-rate fairness. In the current Internet, rough flow-rate fairness is achieved by the fact that *most* of the traffic in the

このドキュメントは、* *流量公平性の実装に関する問題に対処しません。現在のインターネットでは、大まかな流量公平性に交通の*最も*事実によって達成され、

Internet uses TCP, and *most* of the TCP connections in fact use conformant TCP congestion control [MAF05]. However, rough flow-rate fairness could also be achieved by the use of per-flow scheduling at congested routers [DKS89] [LLSZ96], by related router mechanisms [SSZ03], or by congestion-controlled transport protocols other than TCP. This document does not address the pros and cons of TCP-friendly congestion control, equation-based congestion control [FHPW00], or any of the myriad of other issues concerning mechanisms for approximating flow-rate fairness. Le Boudec's tutorial on rate adaption, congestion control, and fairness gives an introduction to some of these issues [B00].

インターネットは、TCPを使用し、* TCPコネクションの*ほとんどは、実際に準拠したTCP輻輳制御[MAF05]を使用します。しかし、粗い流量公平性も[DKS89] [LLSZ96]、関連するルータメカニズム[SSZ03]によって、またはTCP以外の輻輳制御トランスポートプロトコルにより輻輳ルータにフローごとのスケジューリングを使用することによって達成することができます。このドキュメントでは、TCPフレンドリーな輻輳制御、方程式ベースの輻輳制御[FHPW00]、または流量の公平性を近似するためのメカニズムに関する他の問題の無数のいずれかの長所と短所を解決しません。速度整合、輻輳制御、および公平性ルBoudecのチュートリアルでは、これらの問題[B00]のいくつかを紹介しています。

3.1. The Usefulness of Flow-Rate Fairness

3.1. 流量公正の有用性

We note that the limitations of flow-rate fairness are many, with a long history in the literature. We discuss these limitations in the next section. While the benefits of simple best-effort traffic and rough flow-rate fairness are rarely discussed, this does *not* mean that benefits do not exist. In this section, we discuss the benefits of flow-rate fairness. We note that many of the useful aspects of simple best-effort traffic discussed above also qualify as useful aspects of rough flow-rate fairness. For simple best-effort traffic with rough flow-rate fairness, the quote from Winston Churchill about democracy comes to mind: "Democracy is the worst form of government except all those other forms that have been tried from time to time" [C47].

私たちは、流量公平性の制限は文学で長い歴史を持つ、多くのしていることに注意してください。私たちは、次のセクションでこれらの制限を議論します。シンプルなベストエフォートトラフィックとラフ流量公平性のメリットはほとんど議論されていないが、これは* *メリットが存在しないという意味ではありません。このセクションでは、流量公平性のメリットを議論します。私たちは、上述の単純なベストエフォート型トラフィックの有益な側面の多くはまた、ラフ流量公平性として有用な側面を修飾することに注意してください。ラフ流量公正性とシンプルなベストエフォート型トラフィックの場合、民主主義についてのウィンストン・チャーチルからの引用が頭に浮かぶ：[C47]「民主主義は随時試みられているすべてのそれらの他の形態を除き、政府の最悪の形です」。

Minimal technical demands on the network infrastructure:

ネットワークインフラストラクチャ上で最小限の技術的な要求：

First, the rough flow-rate fairness for best-effort traffic provided by TCP or other transport protocols makes minimal technical demands on the infrastructure, as TCP's congestion control algorithms are wholly implemented in the end-hosts. However, mechanisms for *enforcement* of the flow-rate fairness *would* require some support from the infrastructure.

TCPの輻輳制御アルゴリズムは、完全にエンドホストに実装されているように、まず、TCPまたはその他のトランスポートプロトコルが提供するベストエフォート型トラフィックのための大まかな流れレートの公平性、インフラに最小限の技術的な要求を行います。しかし、流量公平性の*執行*のためのメカニズムは、* *インフラからいくつかの支援を必要とします。

Minimal demands in terms of economic infrastructure:

経済インフラの面で最低限の要求：

A system based on rough flow-rate fairness for simple best-effort traffic makes minimal demands in terms of economic relationships among ISPs or between users and ISPs. In contrast, Section 4 discusses some of the difficulties in the incremental deployment of infrastructure for cost-based fairness or other fairness mechanisms.

シンプルなベストエフォート型トラフィックの大まかな流量公平性に基づいたシステムは、ISPの間またはユーザーとISP間の経済関係の面で最低限の要求を行います。対照的に、第4節では、コストベースの公平性または他の公平メカニズムのためのインフラの増分展開の困難のいくつかを論じています。

Usefulness in the real world:

現実世界での有用性：

The current system -- based on rough flow-rate fairness and simple best-effort traffic -- has shown its usefulness in the real world.

現在のシステム - ラフ流量公平性とシンプルなベストエフォート型トラフィックに基づいては - 現実の世界でその有用性を示しています。

Getting a share of the available bandwidth:

利用可能な帯域幅のシェアを取得します：

A system based on rough flow-rate fairness and simple best-effort traffic gives all users a reasonable chance of getting a share of the available bandwidth. This seems to be a quality that is much appreciated by today's Internet users (as discussed above).

ラフ流量公平性とシンプルなベストエフォート型トラフィックに基づくシステムは、すべてのユーザーに利用可能な帯域幅のシェアを得るための合理的な機会を与えてくれます。これは、（上述のように）ずっと今日のインターネットユーザーによって理解される品質であるように思われます。

3.2. The Limitations of Flow-Rate Fairness

3.2. 流量公正の制限事項

This section discusses some of the limitations of flow-rate fairness for simple best-effort traffic.

このセクションでは、単純なベストエフォートトラフィックの流量公平性のいくつかの制限について説明します。

3.2.1. The Enforcement of Flow-Rate Fairness

3.2.1. 流量公正の施行

One of the limitations of rough flow-rate fairness is the difficulty of enforcement. One possibility for implementing flow-rate fairness would be an infrastructure designed from the start with a requirement for ubiquitous per-flow scheduling in routers. However, when starting with an infrastructure such as the current Internet with best-effort traffic largely served by First-In First-Out (FIFO) scheduling in routers and a design preference for intelligence at the ends, enforcement of flow-rate fairness is difficult at best. Further, a transition to an infrastructure that provides actual flow-rate fairness for best-effort traffic enforced in routers would be difficult.

ラフ流量公平性の制限の1つは、施行の難しさです。流量公平性を実現するための一つの可能性は、ルータにおけるユビキタスフローごとのスケジューリングのための要件に最初から設計されたインフラストラクチャになります。しかし、そのような大部分が提供するベストエフォートトラフィックと、現在のインターネットのようなインフラで始まるときは、先入れ先出し（FIFO）スケジューリングルータ内及び端部のインテリジェンスのためのデザインの好み、流量公平性の施行は困難です最高の状態で。さらに、ルータに施行ベストエフォートトラフィックのために実際の流量公平性を提供し、インフラストラクチャへの移行は難しいだろう。

A second possibility, which is largely how the current Internet is operated, would be simple best-effort traffic where most of the connections, packets, and bytes belong to connections using similar congestion-control mechanisms (in this case, those of TCP congestion control), with few if any enforcement mechanisms. Of course, when this happens, the result is a rough approximation of flow-rate fairness, with no guarantees that the simple best-effort traffic will continue to be dominated by connections using similar congestion-control mechanisms or that users or applications cannot game the system for their benefit. That is our current state of affairs. The good news is that the current Internet continues to successfully carry traffic for many users. In particular, we are not aware of reports of frequent congestion collapse, or of the Internet being dominated by severe congestion or intolerable unfairness.

現在のインターネットを操作する方法を大幅にある第二の可能性は、パケット、接続のほとんど、そしてバイトが同様の輻輳制御メカニズム（この場合は、TCPの輻輳制御のそれらを使用した接続に属し、単純なベストエフォート型トラフィックになります）、いずれの実施メカニズムであれば、いくつかと。この問題が発生した場合は、当然、結果はシンプルなベストエフォート型トラフィックは、同様の輻輳制御メカニズムを使用して接続するか、ユーザーやアプリケーションがゲームではないことを支配され続けるという保証で、流量公平性の荒い近似であります自分の利益のためのシステム。それは事務の私たちの現在の状態です。良いニュースは、現在のインターネットが正常に多くのユーザーのトラフィックを運ぶために続けていることです。特に、我々は頻繁に混雑崩壊の報告を認識していない、またはインターネットの深刻な輻輳や耐え難い不公平によって支配されています。

A third possibility would be simple best-effort traffic with flow-rate fairness provided by the congestion control mechanisms in the transport protocols, with some level of enforcement, either in congested routers, in middleboxes, or by other mechanisms [MBFIPS01] [MF01] [SSZ03]. There seems to us to be considerable promise that incentives among the various players (ISPs, vendors, customers, standards bodies, political entities, etc.) will align somewhat, and that further progress will be made on the deployment of various enforcement mechanisms for flow-rate fairness for simple best-effort traffic. Of course, this is not likely to turn in to a fully reliable and ubiquitous enforcement of flow-rate fairness, or of any related fairness goals, for simple best-effort traffic, so this is not likely to be satisfactory to purists in this area. However, it may be enough to continue to encourage most systems to use standard congestion control.

第三の可能性は、輻輳ルータにおいて、中間装置で、又は他の機構のいずれかによって、施行のあるレベルで、トランスポートプロトコルの輻輳制御メカニズムによって提供される流量公平性を持つ単純なベストエフォートトラフィックであろう[MBFIPS01] [MF01] 【SSZ03]。そこやや整列する様々なプレーヤー間のインセンティブ（ISPは、ベンダー、顧客、標準化団体、政治的な実体など）のかなりの約束であることを私たちに思われ、その更なる進展は、フローのための様々な実施メカニズムの展開について説明しますシンプルなベストエフォート型トラフィックのため-rate公平さ。もちろん、これは簡単なベストエフォート型のトラフィックのために、または任意の関連する公正目標の、流量の公正性を完全に信頼性の高い、ユビキタス執行に変わりそうにないので、これはこの領域で純粋主義者に満足のいく可能性が高いではありません。しかし、標準の輻輳制御を使用するほとんどのシステムを奨励し続けるには十分かもしれません。

3.2.2. The Precise Definition of Flow-Based Fairness

3.2.2. フローベースのフェアネスの正確な定義

A second limitation of flow-based fairness is that there is seemingly no consensus within the research, standards, or technical communities about the precise form of flow-based fairness that should be desired for simple best-effort traffic. This area is very much still in flux, as applications, transport protocols, and the Internet infrastructure evolve.

フローベースの公正さの第二の制限は、一見単純なベストエフォート型トラフィックのために望まれるべきでフローベースの公正さの正確な形態に関する研究、標準化、または技術コミュニティ内のコンセンサスがないことです。このエリアには、アプリケーション、トランスポートプロトコル、およびインターネットインフラの進化として、フラックスに非常にまだあります。

Some of the areas where there is a range of opinions about the desired goals for rough flow-based fairness for simple best-effort traffic include the following:

シンプルなベストエフォート型トラフィックのための大まかな流れをベースと公正のために所望の目標についての意見の範囲があるエリアの一部には、次のものがあります。

* Granularity: What is the appropriate fairness granularity? That is, for flow-based fairness, what is the definition of a 'flow'? (This question has been explicitly posed in [RFC2309], [RFC2914], and many other places.) Should fairness be assessed on a per-connection basis? Should fairness take into account multiple connections between a pair of end-hosts (e.g., as suggested by [RFC3124])? If congestion control applies to each individual connection, what controls (if any) should constrain the number of connections opened between a pair of end-hosts? As an example, RFC 2616 specifies that with HTTP 1.1, a single-user client SHOULD NOT maintain more than two persistent connections with any server or proxy [RFC2616] (Section 8.1.4). For peer-to-peer traffic, different operating systems have different limitations on the maximum number of peer-to-peer connections; Windows XP Pro has a limit of ten simultaneous peer-to-peer connections, Windows XP Home (for the client) has a limit of five, and an OS X client has a limit of ten [P2P].

*粒度：適切な公正の粒度は何ですか？それは、「フロー」の定義が何であるかを、フローベースの公平性を、ありますか？（この質問は、明示的に[RFC2309]、[RFC2914]、および他の多くの場所で提起されました。）公正性は、接続ごとに評価されるべきでしょうか？公平性を考慮にエンドホスト（例えば、[RFC3124]によって示唆されるように）の対の間の複数の接続を取る必要がありますか？輻輳制御は、個々の接続に適用される場合、どのような（もしあれば）を制御することは、エンドホストのペア間に開かれた接続の数を制限する必要がありますか？一例として、RFC 2616は、HTTP 1.1、シングルユーザクライアントは、任意のサーバまたはプロキシ[RFC2616]（セクション8.1.4）とつ以上の永続的な接続を維持しないように指定します。ピア・ツー・ピア・トラフィックのために、異なるオペレーティングシステムは、ピア・ツー・ピア接続の最大数に異なる制限を有します。 Windows XPはProが10同時ピアツーピア接続の制限があり、Windows XPのホーム（クライアント用）は5の限界があり、OS Xクライアントは、10 [P2P]の制限があります。

* RTT fairness: What is the desired relationship between flow bandwidth and round-trip times, for simple best-effort traffic? As shown in Section 3.3 of [FJ92], it would be straightforward to modify TCP's congestion control algorithms so that flows with similar packet drop rates but different round-trip times would receive roughly the same throughput. This question is further studied in [HSMK98]. It remains an open question what would be the desired relationship between throughput and round-trip times for simple best-effort traffic, particularly for applications or transport protocols using some form of feedback-based congestion control.

* RTT公平性：シンプルなベストエフォート型トラフィックのためのフローの帯域幅とラウンドトリップ時間との間の所望の関係は、何ですか？ [FJ92]のセクション3.3に示されているのと同様のパケットドロップ率が異なる往復時間はほぼ同じスループットを受信するとそれが流れるように、TCPの輻輳制御アルゴリズムを修正することは簡単であろう。この質問は、さらに[HSMK98]で研究されています。これは、特に、フィードバックベースの輻輳制御のいくつかのフォームを使用してアプリケーションやトランスポートプロトコルのために、シンプルなベストエフォート型トラフィックのスループットとの往復時間の間の所望の関係がどうなるか未解決の問題のまま。

* Multiple congested routers: What is the desired relationship between flow bandwidth and the number of congested routers along the path, for simple best-effort traffic? It is well established that for TCP traffic in particular, flows that traverse multiple congested routers receive a higher packet drop rate, and therefore lower throughput, than flows with the same round-trip time that traverse only one congested router [F91]. There is also a long-standing debate between max-min fairness [HG86] and proportional fairness [KMT98], and no consensus within the research community on the desired fairness goals in this area.

*複数の混雑ルータ：シンプルなベストエフォートトラフィックのフローの帯域幅と、パスに沿って混雑ルータの数との間の所望の関係は、何ですか？特にTCPトラフィックに対して、複数の輻輳ルータを通過するフローがより高いパケット損失率、したがってより低いスループットを受け取ることが唯一の輻輳ルータ[F91]を横切る同一のラウンドトリップ時間と流れるよりも、それは十分に確立されています。最大 - 最小公平[HG86]とプロポーショナルフェアネス[KMT98]、およびこの分野で必要な公正の目標に研究コミュニティ内のコンセンサスとの長年の議論もあります。

* Bursty vs. smooth traffic: What is the desired relationship between flow bandwidth and the burstiness in the sending rate of the flow? Is it a goal for a bursty flow to receive the same average or maximum bandwidth as a flow with a smooth sending rate? How does the goal depend on the time scale of the burstiness of the flow [K96]? For instance, a flow that is bursty on time scales of less than a round-trip time has different dynamics than a flow that is bursty on a time scale of seconds or minutes.

*スムーズな交通対バースト性：フローの送信レートでのフローの帯域幅とバーストとの間の所望の関係は何ですか？なめらかな送信レートを有するフローと同じ平均または最大帯域幅を受け取るために、バースト的な流れの目標ですか？どのような目標は、[K96]フローのバースト性の時間スケールに依存していますか？例えば、往復時間未満の時間スケールでバースト性のある流れは、秒または分の時間スケールでのバースト性のあるフローとは異なるダイナミクスを持っています。

* Packets or bytes: Should the rough fairness goals be in terms of packets per second or bytes per second [RFC3714]? And if the fairness goals are in terms of bytes per second, does this include the bandwidth used by packet headers (e.g., TCP and IP headers)?

*パケットまたはバイトが：ラフな公平性の目標は、秒あたりのパケットまたは第二の[RFC3714]あたりのバイト数の面でべきか？公平性の目標は、秒あたりのバイト数の面である場合と、これは、パケットヘッダ（例えば、TCPおよびIPヘッダ）が使用する帯域幅が含まれていますか？

* Different transport protocols: Should the transport protocol used (e.g., UDP, TCP, SCTP, DCCP) or the application affect the rough fairness goals for simple best-effort traffic?

*さまざまなトランスポートプロトコルに：万一使用されるトランスポートプロトコル（例えば、UDP、TCP、SCTP、DCCP）またはアプリケーションは、シンプルなベストエフォート型トラフィックのためのラフな公平性の目標に影響を与えますか？

* Unicast vs. multicast: What should the fairness goals be between unicast and multicast traffic [FD04] [ZOX05]?

マルチキャスト対*ユニキャスト：公平性の目標は、ユニキャストおよびマルチキャストトラフィック[FD04] [ZOX05]の間で何をすべきですか？

* Precision of fairness: How precise should the fairness goals be? Is the precision that is possible from per-flow scheduling the right benchmark? Or, is a better touchstone the rough fairness over multiple round-trip times achieved by TCP flows over FIFO scheduling? Or, is a goal of even more rough fairness of an order of magnitude or more between flows using different transport protocols right?

*公正の精度は：どのように正確、公平性の目標はすべきですか？フローごとの右のベンチマークをスケジュールから可能である精度がありますか？それとも、より良い試金石は、TCPによって達成複数の往復時間は、FIFOスケジューリング上を流れの上にラフ公正ているのですか？または、右の異なるトランスポートプロトコルを使用して、フロー間の桁以上の、よりラフな公正の目標ですか？

There is a range of literature for each of these topics, and we have not attempted to cite it all above. Rough flow-based fairness for simple best-effort traffic could evolve with a range of possibilities for fairness in terms of round-trip times, the number of congested routers, packet size, or the number of receivers per flow. (Further discussion can be found in [RFC5166].)

そここれらの各トピックについての文献の範囲であり、我々は上記のすべてを引用しようとしていません。シンプルなベストエフォート型トラフィックのための大まかな流れをベースと公平性が往復時間、混雑ルータの数、パケットサイズ、またはフローごとの受信者数の面で公平性のための可能性の範囲で進化することができます。（さらなる議論は[RFC5166]に見出すことができます。）

Fairness over time:

時間をかけてフェアネス：

One issue raised in [B07] concerns how fairness should be integrated over time. For example, for simple best-effort traffic, should long flows receive less bandwidth in bits per second than short flows? For cost-based fairness or for QoS-based traffic, it seems perfectly viable for there to be some scenarios where the cost is a function of flow or session lifetime. It also seems viable for there to be some scenarios where the cost of QoS-enabled traffic is independent of flow or session lifetime (e.g., for a private Intranet that is measured only by the bandwidth of the access link, but where any traffic sent on that Intranet is guaranteed to receive a certain QoS).

[B07]で提起された1つの問題は、公平性が時間をかけて統合する方法に関するものです。例えば、シンプルなベストエフォートトラフィックのために、長いフローは、短期フローよりも秒あたりのビット数が少ない帯域幅を受け取りますか？コストベースの公平性のためか、QoSベースのトラフィックのために、コストが流れたり、セッションの有効期間の関数であるいくつかのシナリオが存在することは完全に可能なようです。そこにのみアクセスリンクの帯域幅によって測定されたプライベートイントラネットのためのQoS対応トラフィックのコストが流れたり、セッションの有効期間とは独立したいくつかのシナリオ（例えば、することも可能なようだが、すべてのトラフィックは、上のどこ送らそのイントラネット）は、特定のQoSを受け取ることが保証されます。

However, for simple best-effort traffic, the current form of rough fairness seems acceptable, with fairness that is independent of session length. That is, in the current Internet, a user who opens a single TCP connection for ten hours *might* receive the same average throughput in bits per second, during that TCP connection, as a user who opens a single TCP connection for ten minutes and then goes off-line. Similarly, a user who is online for ten hours each day *might* receive the same throughput in bits per second, and pay roughly the same cost, as a user who is online for ten minutes each day. That seems acceptable to us. Other pricing mechanisms between users and ISPs seem acceptable also. The current Internet includes a wide range of pricing mechanisms between users and ISPs for best-effort traffic.

しかし、シンプルなベストエフォートトラフィックのために、ラフな公正の現在のフォームは、セッションの長さとは独立した公正で、許容できると思われます。それは、現在のインターネットにおいては、10時間のための単一のTCP接続を開き、ユーザーは* * 10分間、単一のTCP接続をオープンしたユーザーとして、そのTCP接続時に、ビット毎秒で同じ平均スループットを受け取ることがありますその後、オフラインになりました。同様に、10時間毎日のためにオンラインであるユーザー*かもしれない*秒あたりのビット数で同じスループットを受け取り、そして10分、毎日のためにオンラインであるユーザーとして、ほぼ同じコストを支払います。それは私たちに許容可能なようです。ユーザーとISP間の他の価格決定メカニズムも許容できるようです。現在のインターネットはベストエフォート型トラフィックのためのユーザーとISP間価格決定メカニズムの広い範囲を含みます。

4. On the Difficulties of Incremental Deployment

インクリメンタル展開の難し4.

One of the advantages of simple best-effort service is that it is currently operational in the Internet, along with the rough flow-rate fairness that results from the dominance of TCP's congestion control.

シンプルなベストエフォート型サービスの利点の一つは、それがTCPの輻輳制御の優位性から得られるラフ流量公正とともに、インターネットで現在動作しているということです。

While additional classes of service would clearly be of use in the Internet, the deployment difficulties of such mechanisms have been non-trivial [B03]. The problems of deploying interlocking changes to the infrastructure do not necessarily have an easy fix as they stem in part from the underlying architecture of the Internet. As explained in RFC 1958 titled "Architectural Principles of the Internet": "Fortunately, nobody owns the Internet, there is no centralized control, and nobody can turn it off" [RFC1958]. Some of the difficulties of making changes in the Internet infrastructure, including the difficulties imposed by the political and economic context, have been discussed elsewhere (e.g., [CMB07]). The difficulty of making changes to the Internet infrastructure is in contrast to the comparative ease in making changes in Internet applications.

サービスの追加クラスは明らかに、インターネットでの使用であろうが、そのようなメカニズムの導入の難しさは、非自明[B03]となっています。彼らはインターネットの基盤となるアーキテクチャから部分的に幹としてインフラストラクチャに連動変更の配備の問題は必ずしも容易では修正を持っていません。 [RFC1958]「幸いなことに、誰もがインターネットを所有していない、そこには集中制御されていない、と誰もがそれをオフにすることはできません」：1958題し、「インターネットの建築の原則は、」RFCで説明したように。政治的および経済的文脈によって課される問題を含むインターネット・インフラストラクチャの変化を、製造の難しさのいくつかは、（例えば、[CMB07]）他の場所で議論されています。インターネットインフラストラクチャに変更を加えることの難しさは、インターネットアプリケーションの変更を行うことで、比較的容易とは対照的です。

The difficulties of deployment for end-to-end intserv or diffserv mechanisms are well-known, having in part to do with the difficulties of deploying the required economic infrastructure [B03]. It seems likely that cost-based schemes based on re-ECN could also have a difficult deployment path, involving the deployment of ECN-marking at routers, policers at both ends of a connection, and a change in pairwise economic relationships to include a congestion metric [B07]. Some infrastructure deployment problems are sufficiently difficult that they have their own working groups in the IETF [MBONED].

エンドツーエンドのIntServやDiffServの機構の配置の難しさは、必要な経済インフラ[B03]を展開する問題に関係する部分に有する、よく知られています。接続の両端のポリサー、再ECNに基づいて、コストベースのスキームはまた、ルータでECNマーキングの導入を含む、難しい展開パスを持つことができる可能性が高いようで、混雑を含むようにペアごとの経済関係の変化メトリック[B07]。いくつかのインフラ配備の問題は、彼らがIETF [MBONED]で自分のワーキンググループを持っていることを十分に困難です。

5. Related Work

5.関連研究

5.1. From the IETF

5.1. IETFから

This section discusses IETF documents relating to simple best-effort service and flow-rate fairness.

このセクションでは、単純なベストエフォート型のサービスと流量公正性に関するIETF文書について説明します。

RFC 896 on congestion control: Nagle's RFC 896 titled "Congestion Control in IP/TCP", from 1984, raises the issue of congestion collapse, and says that "improved handling of congestion is now mandatory" [RFC896]. RFC 896 was written in the context of a heavily loaded network, the only private TCP/IP long-haul network in existence at the time (that of Ford Motor Company, in 1984). In addition to introducing the Nagle algorithm for minimizing the transmission of small packets in TCP, RFC 896 considers the effectiveness of ICMP Source Quench for congestion control, and comments that future gateways should be capable of defending themselves against obnoxious or malicious hosts. However, RFC 896 does not raise the question of fairness between competing users or flows.

輻輳制御に関するRFC 896：NagleのRFC 896名称「IP / TCPにおける輻輳制御」、1984年からは、輻輳崩壊の問題を提起し、[RFC896]「渋滞の処理を改善することが必須になりました」と述べています。 RFC 896は、負荷の高いネットワークの文脈で書かれた、当時の現存する唯一のプライベートTCP / IP長距離ネットワーク（1984年のフォード・モーター・カンパニーのこと）。 TCPの小さなパケットの送信を最小化するNagleアルゴリズムを導入することに加えて、RFC 896は、輻輳制御のためのICMPソースクエンチの有効性を考慮し、そして将来のゲートウェイが不快な又は悪質なホストに対して自身を守ることができなければならないことをコメントしています。しかし、RFC 896は、競合するユーザーまたはフロー間の公平性の問題を提起しません。

RFC 2309 on unresponsive flows: RFC 2309, an Informational document from the End-to-End Research Group titled "Recommendations on Queue Management and Congestion Avoidance in the Internet" from 2000, contains the following recommendation: "It is urgent to begin or continue research, engineering, and measurement efforts contributing to the design of mechanisms to deal with flows that are unresponsive to congestion notification or are responsive but more aggressive than TCP" [RFC2309].

無応答フロー上のRFC 2309：RFC 2309、2000年からエンドツーエンドの研究グループと題した「インターネットの待ち行列管理と輻輳回避に関する提言」からの情報文書は、以下の推奨事項が含まれています：「開始または継続することが急務であります[RFC2309]「輻輳通知に応答しないか、応答が、TCPよりも攻撃的であるフローに対処するためのメカニズムの設計に貢献する研究、エンジニアリング、および測定の努力。

RFC 2616 on opening multiple connections: RFC 2616, the standards-track document for HTTP/1.1, specifies that "clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server" (Section 8.1.4 of [RFC2616]).

複数の接続開くのRFC 2616：RFC 2616は、HTTP / 1.1のための標準化過程文書は、「持続的な接続を使用するクライアントは、彼らが特定のサーバーに維持する同時接続数を制限すべきである」ことを指定します（[のセクション8.1.4 RFC2616]）。

RFC 2914 on congestion control principles: RFC 2914, a Best Current Practice document, from 2000 titled "Congestion Control Principles", discusses the issues of preventing congestion collapse, maintaining some form of fairness for best-effort traffic, and optimizing a flow's performance in terms of throughput, delay, and loss for the flow in question. In the discussion of fairness, RFC 2914 outlines policy issues concerning the appropriate granularity of a "flow", and acknowledges that end nodes can easily open multiple concurrent flows to the same destination. RFC 2914 also discusses open issues concerning fairness between reliable unicast, unreliable unicast, reliable multicast, and unreliable multicast transport protocols.

輻輳制御の原則にRFC 2914：RFC 2914は、2000年から最も良い現在の練習の文書は、「輻輳制御原則を」と題し、輻輳崩壊を防ぐベストエフォート型トラフィックのための公正性のいくつかのフォームを維持し、かつ、フローのパフォーマンスを最適化する問題について説明します問題のフローのスループット、遅延、および損失の観点から。公平性の議論では、RFC 2914「フロー」の適切な粒度に関するポリシーの問題を概説し、エンドノードが容易に同じ宛先への複数の同時フローを開くことができることを認めます。 RFC 2914はまた、信頼性の高いユニキャスト、信頼できないユニキャスト、信頼性の高いマルチキャスト、および信頼性の低いマルチキャストトランスポートプロトコル間の公平性に関する未解決の問題について説明します。

RFC 3714 on the amorphous problem of fairness: Section 3.3 of RFC 3714, an Informational document from the IAB (Internet Architecture Board) discussing congestion control for best-effort voice traffic, has a discussion of "the amorphous problem of fairness", discussing complicating issues of packet sizes, round-trip times, application-level functionality, and the like [RFC3714].

公正性のアモルファス問題のRFC 3714：RFC 3714のセクション3.3には、ベストエフォート型の音声トラフィックの輻輳制御を議論IAB（インターネットアーキテクチャ委員会）からの情報文書は、「公正性のアモルファス問題」の議論があり、複雑に議論パケットサイズ、往復時間、アプリケーションレベルの機能、など[RFC3714]の問題。

RFCs on QoS: There is a long history in the IETF of the development of QoS mechanisms for integrated and differentiated services [RFC2212, RFC2475]. These include lower effort per-domain behaviors that could be used to protect best-effort traffic from lower-priority traffic [RFC3662].

QoSの上のRFC：統合と差別化されたサービスのためのQoSメカニズムの開発のIETF [RFC2212、RFC2475]で長い歴史があります。これらは、優先順位の低いトラフィック[RFC3662]からベストエフォートトラフィックを保護するために使用することができ低く努力ドメインごとの行動が含まれます。

5.2. From Elsewhere

5.2. 他の場所から

This section briefly mentions some of the many papers in the literature on best-effort traffic or on fairness for competing flows or users. [B07] also has a section on some of the literature regarding fairness in the Internet.

このセクションでは、簡単にフローまたはユーザを競合するためにベストエフォート型トラフィック上または公正に関する文献の多くの論文のいくつかを言及しています。 [B07]もインターネットで公平に関する文献のいくつかのセクションを有しています。

Fairness with AIMD: Fairness with AIMD (Additive Increase Multiplicative Decrease) congestion control was studied by Chiu and Jain in 1987, where fairness is maximized when each user or flow gets equal allocations of the bottleneck bandwidth [CJ89]. Van Jacobson's 1988 paper titled "Congestion Avoidance and Control" defined TCP's AIMD-based congestion control mechanisms [J88].

AIMDと公平：AIMDと公平性（添加剤は乗法増減）輻輳制御は、各ユーザまたはフローがボトルネック帯域幅[CJ89]の等しい割り当てを取得するときの公平性が最大化される、1987年チウジャイナによって研究されました。「輻輳回避とコントロール」というタイトルヴァンヤコブソン1988論文は、TCPのAIMDベースの輻輳制御メカニズム[J88]を定義しました。

Fair Queueing: The 1989 paper on Fair Queueing by Demers et al. promoted Fair Queueing scheduling at routers as providing fair allocation of bandwidth, lower delay for low-bandwidth traffic, and protection from ill-behaved sources [DKS89].

フェアキューイング：デマーズらの均等化キューイングの1989年論文。フェア・キューイングは、下の低帯域幅トラフィックの遅延、および、動作不良の源[DKS89]からの保護を、帯域幅の公正な配分を提供するものとして、ルータでのスケジューリング昇格。

Congestion-based pricing: One of the early papers on congestion-based pricing in networks is the 1993 paper titled "Pricing the Internet" by MacKie-Mason and Varian [MV93]. This paper proposed a "Smart Market" to price congestion in real time, with a per-packet charge reflecting marginal congestion costs. Frank Kelly's web page at [Proportional] has citations to papers on proportional fairness, including [K97] titled "Charging and Rate Control for Elastic Traffic".

輻輳ベースの価格設定：ネットワークの輻輳ベースの価格設定に関する初期の論文の一つMACKIE・メイソンとバリアン[MV93]で「インターネットをプライシング」と題した1993紙です。本論文では限界混雑コストを反映したパケットごとの担当で、リアルタイムでの価格渋滞に「スマート・マーケット」を提案しました。 [プロポーショナル]でフランク・ケリーのWebページには、「弾性トラフィック用の充電とレート制御」というタイトル[K97]を含む比例公平、上の論文に引用されています。

Other papers on pricing in computer networks include [SCEH96], which is in part a critique of some of the pricing proposals in the literature at the time. [SCEH96] argues that usage charges must remain at significant levels even if congestion is extremely low.

コンピュータネットワークにおける価格設定上の他の論文は、一部は一度文学の価格提案のいくつかの批判である[SCEH96]を、含まれています。 [SCEH96]利用料金は、輻輳が極めて低い場合であっても有意なレベルで維持しなければならないと主張しています。

6. Security Considerations

6.セキュリティの考慮事項

This document does not propose any new mechanisms for the Internet, and so does not require any security considerations.

このドキュメントはインターネットのための新たな仕組みを提案していない、ので、すべてのセキュリティ上の考慮を必要としません。

7. Conclusions

7、結論

This document represents the views of the two authors on the role of simple best-effort traffic in the Internet.

このドキュメントはインターネットで簡単なベストエフォート型トラフィックの役割について2人の著者の見解を表しています。

8. Acknowledgements

8.謝辞

We thank Ran Atkinson, Roland Bless, Bob Briscoe, Mitchell Erblich, Ted Faber, Frank Kelly, Tim Shephard, and members of the Transport Area Working Group for feedback on this document.

私たちは、この文書についてのフィードバックのために、ローランドは祝福、ボブ・ブリスコー、ミッチェルErblich、テッド・フェーバー、フランク・ケリー、ティム・シェパード、交通地域ワーキンググループのメンバーを蘭アトキンソンに感謝します。

9. Informative References

9.参考文献

[B00] J.-Y. Le Boudec, Rate adaptation, Congestion Control and Fairness: A Tutorial, 2000. URL "http://citeseer.ist.psu.edu/boudec00rate.html" or "http://ica1www.epfl.ch/PS_files/LEB3132.pdf".

[B00] J.-Y.ルBoudec、レート適応、輻輳制御と公平性：チュートリアル、2000年URL「http://citeseer.ist.psu.edu/boudec00rate.html」または「http://ica1www.epfl.ch/PS_files/LEB3132。 PDF」。

[B03] G. Bell, Failure to Thrive: QoS and the Culture of Operational Networking, Proceedings of the ACM SIGCOMM Workshop on Revisiting IP QoS: What Have We Learned, Why Do We Care?, pp. 115-120, 2003, URL "http://doi.acm.org/10.1145/944592.944595".

[B03] G.ベル、成長障害：再考IP QoSの上のQoSおよびオペレーショナル・ネットワーキングの文化、ACM SIGCOMMワークショップの議事録を：私たちはなぜ我々は？PPケアください、学んだ、115-120、2003、URLを。 "http://doi.acm.org/10.1145/944592.944595"。

[B07] B. Briscoe, Flow Rate Fairness: Dismantling a Religion, ACM SIGCOMM Computer Communication Review, V.37 N.2, April 2007.

[B07] B.ブリスコー、流量フェアネス：宗教、ACM SIGCOMMコンピュータコミュニケーションレビュー、V.37 N.2、2007年4月に解体。

[B07a] B. Briscoe, "Flow Rate Fairness: Dismantling a Religion", Work in Progress, July 2007.

[B07a] B.ブリスコー、「流量フェアネス：宗教を解体」、進歩、2007年7月の作業。

[CJ89] Chiu, D.-M., and Jain, R., Analysis of the Increase and Decrease Algorithms for Congestion Avoidance in Computer Networks, Computer Networks and ISDN Systems, V. 17, pp. 1-14, 1989. [The DEC Technical Report DEC-TR-509 was in 1987.]

[CJ89]チウ、D.-M.、ジャイナ、R.、増加の分析とコンピュータネットワークにおける輻輳回避のためのアルゴリズムを減らし、コンピュータネットワークとISDNシステム、V. 17頁。1-14、1989年には、[ 12月テクニカルレポートDEC-TR-509は、1987年にありました]

[CMB07] kc claffy, Sascha D. Meinrath, and Scott O. Bradner, The (un)Economic Internet?, IEEE Internet Computing, vol. 11, no. 3, pp. 53--58, May 2007. URL "http://www.caida.org/publications/papers/2007/ieeecon/".

【CMB07] KC claffy、サシャD. Meinrath、スコットO.ブラドナー、（UN）経済インターネット?, IEEEインターネットコンピューティング、巻。 11、ありません。 3頁。53--58、2007年5月URL "http://www.caida.org/publications/papers/2007/ieeecon/"。

[C47] Churchill, W., speech, House of Commons, November 11, 1947. URL "http://www.askoxford.com/quotations/827?view=uk".

[C47]チャーチル、W.、スピーチ、下院、11月11日、1947年URL "http://www.askoxford.com/quotations/827?view=uk"。

[DKS89] A. Demers, S. Keshav, and S. Shenker, Analysis and Simulation of a Fair Queueing Algorithm, SIGCOMM, 1989.

【DKS89] A.デマーズ、S. Keshav、およびS. Shenker、分析および均等化キューイングアルゴリズムのシミュレーション、SIGCOMM、1989。

[F91] Floyd, S., Connections with Multiple Congested Gateways in Packet-Switched Networks Part 1: One-way Traffic, Computer Communication Review, Vol.21, No.5, October 1991.

[F91]フロイド、S.、パケット交換ネットワーク内の複数の混雑のゲートウェイとの接続パート1：一方通行、コンピュータコミュニケーションレビュー、Vol.21、第5号、1991年10月。

[FD04] F. Filali and W. Dabbous, Fair Bandwidth Sharing between Unicast and Multicast Flows in Best-Effort Networks, Computer Communications, V.27 N.4, pp. 330-344, March 2004.

[FD04] F. FilaliとW. Dabbous、ユニキャストとマルチキャストの間の公平な帯域幅の共有は、ベストエフォート型のネットワーク、コンピュータ通信、V. 27 N.4、頁330から344まで、2004年3月に流れます。

[FHPW00] Floyd, S., Handley, M., Padhye, J., and Widmer, J, Equation-Based Congestion Control for Unicast Applications, SIGCOMM, August 2000.

【FHPW00]フロイド、S.、ハンドレー、M.、Padhye、J.、およびウィドマー、ユニキャストアプリケーションのJは、式ベースの輻輳制御、SIGCOMM、2000年8月。

[FJ92] On Traffic Phase Effects in Packet-Switched Gateways, Floyd, S. and Jacobson, V., Internetworking: Research and Experience, V.3 N.3, September 1992.

パケット交換ゲートウェイ、フロイド、S.とヤコブソンにおける交通相影響について[FJ92]、V.、インターネットワーキング：研究と経験、V.3 N.3、1992年9月。

[HG86] E. Hahne and R. Gallager, Round Robin Scheduling for Fair Flow Control in Data Communications Networks, IEEE International Conference on Communications, June 1986.

[HG86] E. HahneとR.ギャラガー、データ通信ネットワークにおける公正フロー制御のためのラウンドロビンスケジューリング、通信に関するIEEE国際会議、1986年6月。

[HSMK98] Henderson, T.R., E. Sahouria, S. McCanne, and R.H. Katz, On Improving the Fairness of TCP Congestion Avoidance, Globecom, November 1998.

【HSMK98]ヘンダーソン、T。R.、E. Sahouria、S. McCanne、及びR.H.カッツ、TCPの輻輳回避の公平性を向上させる上で、GLOBECOM、1998年11月。

[Internet2020] Internet Society, An Internet 2020 Initiative: The Internet is (still) for Everyone, 2007. URL "http:// www.isoc.org/orgs/ac/cms/uploads/docs/2020_vision.pdf".

[Internet2020]インターネット協会、インターネットイニシアティブ2020は：インターネットは2007年URL "：// www.isoc.org/orgs/ac/cms/uploads/docs/2020_vision.pdfのhttp"、みんなのために（まだ）です。

[J88] V. Jacobson, Congestion Avoidance and Control, SIGCOMM '88, August 1988.

[J88] V.ヤコブソン、輻輳回避とコントロール、SIGCOMM '88、1988年8月。

[K96] F. Kelly, Charging and Accounting for Bursty Connections, In L. W. McKnight and J. P. Bailey, editors, Internet Economics. MIT Press, 1997.

[K96] F.ケリー、L. W.マックナイトおよびJ. P.ベイリー、編集者、インターネット経済において、充電及びバースト性接続の会計。 MITプレス、1997。

[K97] F. Kelly, Charging and Rate Control for Elastic Traffic, European Transactions on Telecommunications, 8:33--37, 1997.

[K97] F.ケリー、弾性交通、通信、8欧州の取引のための充電とレートコントロール：33--37、1997。

[KMT98] F. Kelly, A. Maulloo and D. Tan, Rate Control in Communication Networks: Shadow Prices, Proportional Fairness and Stability. Journal of the Operational Research Society 49, pp. 237-252, 1998. URL "http://citeseer.ist.psu.edu/kelly98rate.html".

[KMT98] F.ケリー、A. MaullooとD.タン、通信ネットワークにおけるレート制御：シャドウ価格は、プロポーショナルフェアネスと安定性。オペレーショナルリサーチ学会49誌、頁237から252まで、1998年URL「http://citeseer.ist.psu.edu/kelly98rate.html」。

[LLSZ96] C. Lefelhocz, B. Lyles, S. Shenker, and L. Zhang, Congestion Control for Best-effort Service: Why We Need a New Paradigm, IEEE Network, vol. 10, pp. 10-19, Jan. 1996.

[LLSZ96] C. Lefelhocz、B. Lyles、S. Shenker、およびL.チャン、ベストエフォート型サービスのための輻輳制御：私たちは新しいパラダイム、IEEEネットワーク、容積が必要な理由。 10頁10-19、1996年1月。

[MAF05] A. Medina, M. Allman, and S. Floyd, Measuring the Evolution of Transport Protocols in the Internet, Computer Communications Review, April 2005.

[MAF05] A.メディナ、M.オールマン、およびS.フロイド、インターネットに転送プロトコルの進化を測定する、コンピュータコミュニケーションレビュー、2005年4月。

[MBFIPS01] R. Manajan, S. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and S. Shenker, Controlling High Bandwidth Aggregates in the Network, Computer Communications Review, V.32 N.3, July 2002.

[MBFIPS01] R. Manajan、S. Bellovin氏、S.フロイド、J. Ioannidis、V.パクソン、およびS. Shenker、ネットワーク、コンピュータコミュニケーションレビュー、V.32 N.3、2002年7月の制御高帯域幅集約。

[MBONED] MBONE Deployment Working Group, URL "http://www.ietf.org/html.charters/mboned-charter.html".

[MBONED] MBONE展開ワーキンググループ、URL "http://www.ietf.org/html.charters/mboned-charter.html"。

[MF01] Mahajan, R., and Floyd, S., Controlling High-Bandwidth Flows at the Congested Router, ICNP 2001, November 2001.

[MF01]マハジャン、R.、およびフロイド、S.は、高帯域幅を制御する混雑ルータ、ICNP 2001、2001年11月で流れます。

[MV93] J. K. MacKie-Mason and H. Varian, Pricing the Internet, in the conference on Public Access to the Internet, JFK School of Government, May 1993.

[MV93] J. K. MACKIE-メイソンとH.バリアン、インターネットへのパブリックアクセスに関する会議、政府、1993年5月のJFK学校で、インターネット価格設定。

[NetNeutral] Network Neutrality, Wikipedia. URL "http://en.wikipedia.org/wiki/Net_neutrality".

[NetNeutral]ネットワーク中立性、ウィキペディア。 URL "http://en.wikipedia.org/wiki/Net_neutrality"。

[P2P] "Maximum Number of Peer-to-Peer Connections", MAC OS X Hints web site, February 2007, URL "http://forums.macosxhints.com/showthread.php?t=67237".

[P2P]「ピア・ツー・ピア接続の最大数」、MAC OS Xは、ウェブサイトをヒント、2007年2月、URL「http://forums.macosxhints.com/showthread.php?t=67237」。

[Proportional] Kelly, F., papers on Proportional Fairness. URL "http://www.statslab.cam.ac.uk/~frank/pf/".

[比例]ケリー、F.、プロポーショナルフェアネス上の紙。 URL "http://www.statslab.cam.ac.uk/~frank/pf/"。

[R04] J. Roberts, Internet Traffic, QoS, and Pricing, Proceedings of the IEEE, V.92 N.9, September 2004.

[R04] J.ロバーツ、インターネットトラヒック、QoS、および価格設定、IEEEの議事録、V.92 N.9、2004年9月。

[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.

[RFC896]ネーグル、J.、 "IP / TCPインターネットワークにおける輻輳制御"、RFC 896、1984年1月。

[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.

[RFC1958]大工、B.、エド。、 "インターネットの建築原則"、RFC 1958、1996年6月。

[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.

[RFC2212] Shenker、S.、ヤマウズラ、C.、およびR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。

[RFC2309] Braden, B., 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]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.

[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。

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

[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。

[RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990, November 2000.

[RFC2990]ヒューストン、G.、 "IP QoSのアーキテクチャーのための次のステップ"、RFC 2990、2000年11月。

[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.

[RFC3124]バラクリシュナン、H.とS. Seshan、 "輻輳管理"、RFC 3124、2001年6月。

[RFC3662] Bless, R., K. Nichols, and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.

[RFC3662]は、R.、K.ニコルズ、およびK. Wehrleの、RFC 3662、2003年12月 "ドメイン単位の行動差別化サービスのための（PDB）下部努力を" 祝福します。

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

[RFC3714]フロイド、S.、エド。、およびJ.ケンプ、エド。、 "インターネットでの音声トラフィックのための輻輳制御に関するIAB心配"、RFC 3714、2004年3月。

[RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion Control Mechanisms", RFC 5166, March 2008.

[RFC5166]フロイド、S.、エド。、RFC 5166、2008年3月 "輻輳制御機構の評価のためのメトリクス"。

[SCEH96] Shenker, D. D. Clark, D. Estrin, and S. Herzog, Pricing in Computer Networks: Reshaping the Research Agenda, ACM Computer Communication Review, vol. 26, April 1996.

[SCEH96] Shenker、D. D.クラーク、D. Estrin、およびS.ヘルツォーク、コンピュータネットワークにおける価格：研究アジェンダ、ACMコンピュータコミュニケーションレビュー、巻をリシェイプ。 26、1996年4月。

[SSZ03] I. Stoica, S. Shenker, and H. Zhang, Core-Stateless Fair Queueing: a Scalable Architecture to Approximate Fair Bandwidth Allocations in High-speed Networks, IEEE/ACM Transactions on Networking 11(1): 33-46, 2003.

【SSZ03】I.ストイカ、S. Shenker、およびH.チャン、コアステートレスフェアキューイング：高速ネットワークにおける公平な帯域幅割り当てを近似するスケーラブルなアーキテクチャ、ネットワーク11上のIEEE / ACMトランザクション（1）：33-46 2003年。

[ZOX05] Zhang, T., P. Osterberg, and Youzhi Xu, Multicast-favorable Max-Min Fairness - a General Definition of Multicast Fairness, Distributed Frameworks for Multimedia Applications, February 2005.

[ZOX05]チャン、T.、P. Osterberg、およびYouzhi徐、マルチキャスト、良好なマックスミン公正 - マルチキャストフェアネスの一般的な定義は、マルチメディアアプリケーション、2005年2月のためのフレームワークを分散します。

Authors' Addresses

著者のアドレス

Sally Floyd ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA EMail: floyd@icir.org URL: http:/www.icir.org/floyd/

インターネットリサーチのためのサリーフロイドICSIセンター1947センターストリート、スイート600バークレー、CA 94704 USA電子メール：floyd@icir.org URLます。http：/www.icir.org/floyd/

Mark Allman International Computer Science Institute 1947 Center Street, Suite 600 Berkeley, CA 94704-1198 Phone: (440) 235-1792 EMail: mallman@icir.org URL: http://www.icir.org/mallman/

マーク・オールマン国際コンピュータサイエンス研究所1947センターストリート、スイート600バークレー、CA 94704から1198電話：（440）235から1792 Eメール：mallman@icir.org URL：http://www.icir.org/mallman/

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（2008）。

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に及びhttp://www.rfc-editor.org/copyright.htmlに含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

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リポジトリから。

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