[要約] 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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄し、公開する決定はIETFワークとの競合に関するIESGレビューとは別にIETFレビューに基づいていないことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。詳細については、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.
このドキュメントでは、「Simple Best-Effort Traffic」に関するいくつかの観察結果を提示します。このドキュメントの目的のために、サービス品質（QoS）メカニズム、混雑ベースの価格設定、コストベースの公平性、入場管理のカバーされていないインターネットトラフィックとして定義されています。、または同様です。1つの観察結果は、単純なベストエフォルトトラフィックがインターネットで有用な役割を果たし、維持する価値があることです。トラフィックの微分処理は明らかに有用ですが、そのようなメカニズムは、単純なベストエフォルトトラフィックの *交換 *ではなく、単純なベストエフォルトトラフィックに対する *付属物 *として有用であると考えています。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
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.
このドキュメントは、インターネットでのシンプルなベストエフォートトラフィックの役割に関するいくつかの観察結果を提供します。このドキュメントの目的のために、「シンプルなベストエフォートトラフィック」を、ルーターまたはポリサー、エンフォーサー、またはパスに沿った他のミドルボックスのいずれかのフローの *差微分処理 *に依存しないトラフィックとして定義します。入学制御を使用しないでください。「Best-Effort Traffic」というフレーズに含まれている、または含まれていないことについての非生産的なセマンティックな議論を避けるために、「シンプルなベストエフォルトトラフィック」という用語を定義します。「単純なベストエフォートトラフィック」の定義には、ISPS間のペアワイズ契約、ボリュームベースの価格設定、ファイアウォール、幅広いメカニズムなど、現在のインターネットで一般的なメカニズムなど、必ずしも「単純な」トラフィックには含まれていないトラフィックが含まれていることに注意してください。ミドルボックスで。
"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対応のトラフィックは、異なるIntServクラスまたはDiffServクラスのパケットが異なる治療を受けている、混雑したルーターの微分スケジューリングメカニズムに依存しています。同様に、「単純なベストエフォルトトラフィック」とは対照的に、コストベースの公平性[B07]は、混雑したルーターでのトラフィックマーキングの展開（たとえば、明示的な混雑通知（ECN））と、2つの近くのポリシングメカニズムを2つ近くのポリシングメカニズムを必要とする可能性が高いでしょう。接続の終了異なるフローまたは異なる交通クラスでのパケットの差動処理を提供します。Intserv/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]で提起された問題のいずれかまたはすべてに答えたり、哲学や社会科学におけるフローベースの公平性のために「知的遺産」を与えることを試みることはありません。このドキュメントの著者を[B07]の著者との拡張対話にコミットします。このドキュメントは、いくつかの関連するトピックに関する単なる別の視点です。
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.
このセクションでは、微分治療を受けているトラフィックと比較して、シンプルなベストエフォルトトラフィックのクラスの有用性と制限に関するいくつかの観察を行います。
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間のかなり単純なペアワイズの経済関係に依存している経済インフラストラクチャの点で最小限の要求をもたらします。対照的に、セクション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年間、インターネットで機能することが示されていますが、不完全です。Simple Best-Effort Trafficは、シンプルなファイルや電子メール転送、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.
以下で説明するように、シンプルなベストエフォルトトラフィックは最適ではありません。ただし、インターネットでの経験は、単純なベストエフォルトトラフィックのメカニズムに大きな価値があることを示しており、一般にすべてのユーザーがリソースの一部を取得しながら、混雑の崩壊を防ぎます。
We now discuss some limitations of simple best-effort traffic.
ここで、シンプルなベストエフォルトトラフィックのいくつかの制限について説明します。
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].
単純なベストエフォルトトラフィックを保護するための措置を講じることのない単純な微分交通治療の実装の明らかな危険の1つは、より多くのお金を持つユーザーが、混雑の時により少ないお金でユーザーを飢えさせる可能性があることです。これは望ましい目標ではないというかなり広範な合意があるようです。ポジションの範囲のサンプルとして、インターネットソサエティのインターネット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]などで説明したように、インターネットのサービス品質は、独自の制限と困難を抱えています。ここでは、これらの困難についてこれ以上議論するつもりはありません。
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]にはよく知られている問題があります。現在のインターネットでは、これらの懸念に対処するためにエンドツーエンドの混雑制御が依存しています。エンドツーエンドの混雑制御のこの使用には、本質的にエンドホストからの協力が必要です。
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.
シンプルなベストエフォルトトラフィックは、交通量の急増（分配されたサービス拒否（DDO）攻撃、フラッシュクラウドなど）からの突然の凝集渋滞に苦しむ可能性があり、その結果、パスを共有するすべての単純なベストエフォルトトラフィックのパフォーマンスが低下します。深いパケット検査やレート制限トラフィック集合体など、ネットワーク内の突然の凝集渋滞を検出および応答するための幅広いアプローチが提案され、使用されています。混雑したリンクの単純なベストエフォルトトラフィック内で集約を扱うメカニズムの両方について、多くの未解決の質問があります。
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公平性など）、ルーターによって施行された明示的な公平性メカニズムを持つことが可能です（Max-Minのように公正なキューイングとの公平性）、または明示的な公正メカニズムがまったくないトラフィッククラス（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]、または流量レートの公平性を近似するためのメカニズムに関する他の無数の問題の長所と短所に対処していません。Le Boudecのレート適応、混雑制御、および公平性に関するチュートリアルは、これらの問題のいくつかを紹介します[B00]。
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].
フローレートの公平性の限界は多く、文献に長い歴史があることに注意してください。これらの制限については、次のセクションで説明します。シンプルなベストエフォルトトラフィックとラフなフローレートの公平性の利点はめったに議論されませんが、これは *利益が存在しないことを意味しません。このセクションでは、フローレートの公平性の利点について説明します。上記のシンプルなベストエフォルトトラフィックの有用な側面の多くは、大まかなフローレートの公平性の有用な側面としても認められていることに注意してください。大まかなフローレートの公平性を備えたシンプルなベストエフォルトトラフィックのために、ウィンストンチャーチルからの民主主義に関する引用が思い浮かびます。
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.
Simple Best-Effortトラフィックの大まかなフローレートの公平性に基づくシステムは、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).
大まかなフローレートの公平性とシンプルなベストエフォートトラフィックに基づくシステムは、すべてのユーザーが利用可能な帯域幅をシェアする合理的なチャンスを提供します。これは、今日のインターネットユーザー（上記で説明したように）に非常に高く評価されている品質のようです。
This section discusses some of the limitations of flow-rate fairness for simple best-effort traffic.
このセクションでは、シンプルなベストエフォルトトラフィックに対するフローレートの公平性の制限の一部について説明します。
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つは、執行の難しさです。フローレートの公平性を実装する可能性の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.
主に現在のインターネットの操作方法である2番目の可能性は、接続、パケット、およびバイトのほとんどが同様の輻輳制御メカニズムを使用して接続に属している単純な最良のトラフィックになります（この場合、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.
3番目の可能性は、輸送プロトコルの混雑制御メカニズム、混雑したルーター、ミドルボックス、または他のメカニズムのいずれかである程度の施行を伴うフローレートの公平性を備えた単純なベストエフォルトトラフィックです[MBFIPS01] [MF01][SSZ03]。さまざまなプレーヤー（ISP、ベンダー、顧客、標準団体、政治エンティティなど）の間のインセンティブが多少揃っているというかなりの約束があるように思われ、フローのためのさまざまな執行メカニズムの展開に関するさらなる進展がなされると思われます。 - シンプルなベストエフォルトトラフィックの公平性を評価します。もちろん、これはフローレートの公平性または関連する公平な目標の完全に信頼性が高く遍在する施行に変わる可能性は低いので、この分野の純粋主義者にとってこれは満足のいくものではない可能性があります。ただし、ほとんどのシステムが標準的な混雑制御を使用するように促し続けるだけで十分かもしれません。
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.
フローベースの公平性の2番目の制限は、単純なベストエフォルトトラフィックに望まれるべきフローベースの公平性の正確な形態について、研究、基準、または技術コミュニティ内にコンセンサスがないように見えることです。この領域は、アプリケーション、輸送プロトコル、およびインターネットインフラストラクチャが進化するため、非常に流動的です。
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）との2つの永続的な接続を維持すべきではないことを指定しています。ピアツーピアトラフィックの場合、異なるオペレーティングシステムは、ピアツーピア接続の最大数に異なる制限があります。Windows XP Proの同時ピアツーピア接続は10の制限です。WindowsXPホーム（クライアント用）の制限は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トラフィックでは、複数の混雑したルーターをトラバースするフローは、1つの混雑したルーターのみを横断する同じ往復時間での流れよりも、より高いパケットドロップレートを受け取るため、スループットが低いことが十分に確立されています[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]？また、公平な目標が1秒あたりのバイトの観点からある場合、これにはパケットヘッダー（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]?
* ユニキャストvs.マルチキャスト：ユニキャストとマルチキャストトラフィックの間に公平な目標はどうあるべきか[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?
* 公平性の精度：公平性の目標はどれほど正確であるべきですか？Flow Perlowのスケジューリングから適切なベンチマークをスケジュールすることから可能な精度はありますか？それとも、TCPがFIFOスケジューリングを超えるTCPフローによって達成される複数の往復時間にわたるより良いTouchstoneは大まかな公平性ですか？または、異なる輸送プロトコルを使用して、フロー間の数桁以上のさらに大まかな公平性の目標ですか？
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つの問題は、時間の経過とともに公平性を統合する方法に関するものです。たとえば、単純なベストエフォルトトラフィックの場合、長いフローは短いフローよりも1秒あたりの帯域幅を少なくする必要がありますか？コストベースの公平性やQoSベースのトラフィックの場合、コストがフローまたはセッションの寿命の関数であるシナリオがあるため、完全に実行可能であると思われます。また、QoS対応トラフィックのコストがフローまたはセッションの寿命に依存しないシナリオがある場合も、アクセスリンクの帯域幅のみによって測定されるプライベートイントラネットの場合、そのイントラネットは、特定のQOを受信することが保証されています）。
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.
ただし、単純なベストエフォルトトラフィックの場合、現在の大まかな公平性の形式は許容できるように見えますが、これはセッションの長さとは無関係です。つまり、現在のインターネットでは、1つのTCP接続を10時間開くユーザー *が、そのTCP接続中に、10分間、10分間のTCP接続を開くユーザーと同じ平均スループットを1秒あたりのビットで受け取る可能性があります。その後、オフラインになります。同様に、毎日10時間オンラインでオンラインであるユーザーは、毎日10分間オンラインであるユーザーとほぼ同じコストを支払うことができます。それは私たちには受け入れられるようです。ユーザーとISPの間の他の価格設定メカニズムも受け入れられるようです。現在のインターネットには、ユーザーとISPの間の幅広い価格設定メカニズムが含まれており、最良のトラフィックが含まれています。
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.
シンプルなベストエフォートサービスの利点の1つは、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]。インフラストラクチャへのインターロッキング変更を展開する問題は、インターネットの基礎となるアーキテクチャに一部起因するため、必ずしも簡単な修正がありません。「インターネットの建築原理」というタイトルのRFC 1958で説明されているように、「幸いなことに、誰もインターネットを所有しておらず、集中制御がなく、誰もそれをオフにすることができない」[RFC1958]。政治的および経済的文脈によって課される困難を含む、インターネットインフラストラクチャに変更を加えることの困難のいくつかは、他の場所で議論されています（例：[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]。REECNに基づくコストベースのスキームは、ルーターでのECNマークの展開、接続の両端のポリサー、および渋滞を含むペアワイズ経済関係の変更を含む、難しい展開パスを持つ可能性が高いようです。メトリック[B07]。一部のインフラストラクチャの展開の問題は、IETF [MBONED]に独自のワーキンググループを持っているため、十分に困難です。
This section discusses IETF documents relating to simple best-effort service and flow-rate fairness.
このセクションでは、Simple Best-Effortサービスとフローレートの公平性に関する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：1984年から、「IP/TCPの混雑制御」というタイトルのNagleのRFC 896は、混雑の崩壊の問題を提起し、「渋滞の取り扱いの改善が現在必須である」と述べています[RFC896]。RFC 896は、当時存在する唯一のプライベートTCP/IPロングホールネットワーク（1984年にフォードモーターカンパニーのネットワークである唯一のプライベートTCP/IPロングホールネットワークのコンテキストで書かれています。TCPでの小さなパケットの送信を最小限に抑えるためのナグルアルゴリズムを導入することに加えて、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無反応の流れに関する2309：RFC 2309、「インターネットでのキュー管理と輻輳回避に関する推奨事項」というタイトルのエンドツーエンドの研究グループの情報文書には、次の推奨事項が含まれています。混雑通知に反応しない、または応答性が高いがTCPよりも攻撃的なメカニズムの設計に貢献する研究、工学、測定の取り組み。[RFC2309]。
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の標準トラックドキュメントであるRFC 2616は、「永続的な接続を使用するクライアントは、特定のサーバーに維持する同時接続の数を制限する必要がある」（セクション8.1.4の[セクション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：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のRFCS：統合サービスと差別化されたサービスのためのQoSメカニズムの開発のIETFには長い歴史があります[RFC2212、RFC2475]。これらには、低程度のトラフィックから最良のトラフィックを保護するために使用できるドメインごとの行動の低下が含まれます[RFC3662]。
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の公平性（加算増加乗法減少）混雑制御は、1987年にCHIUとJainによって研究されました。この場合、各ユーザーまたはフローがボトルネック帯域幅の等しい割り当てを得ると公平性が最大化されます[CJ89]。ヴァン・ジェイコブソンの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".
渋滞ベースの価格設定：ネットワークでの混雑ベースの価格設定に関する初期の論文の1つは、Mackie-MasonとVarian [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]は、混雑が非常に低い場合でも、使用料は有意なレベルにとどまる必要があると主張しています。
This document does not propose any new mechanisms for the Internet, and so does not require any security considerations.
このドキュメントは、インターネットの新しいメカニズムを提案していないため、セキュリティ上の考慮事項は必要ありません。
This document represents the views of the two authors on the role of simple best-effort traffic in the Internet.
このドキュメントは、インターネットでのシンプルなベストエフォルトトラフィックの役割に関する2人の著者の見解を表しています。
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.
Ran Atkinson、Roland Bless、Bob Briscoe、Mitchell Erblich、Ted Faber、Frank Kelly、Tim Shephard、およびこの文書に関するフィードバックについては、トランスポートエリアワーキンググループのメンバーに感謝します。
[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。Le 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.ベル、繁栄の失敗：QoSと運用ネットワーキングの文化、IP Qosの再訪に関するACM Sigcommワークショップの議事録：私たちは何を学んだのか、なぜWe Care？、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 Computer Communication Review、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] Chiu、D.-M。、およびJain、R.、コンピューターネットワーク、コンピューターネットワーク、ISDNシステムにおける混雑回避のための増加および減少アルゴリズムの分析、V。17、pp。1-14、1989。DECテクニカルレポート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、Sascha D. Meinrath、およびScott O. Bradner、The（Un）Economic Internet？、IEEE Internet Computing、Vol。11、いいえ。3、pp。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] Churchill、W.、Speech、House of Commons、1947年11月11日。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. DeMers、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] Floyd、S.、Packet-Switched Networksの複数の混雑したゲートウェイとの接続パート1：一元配置トラフィック、コンピューター通信レビュー、Vol.21、No.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、Unicast FlowsとMulticast Flowsの間の共有、Best-Effort Networks、Computer Communications、v.27 N.4、pp。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] Floyd、S.、Handley、M.、Padhye、J。、およびWidmer、J、Unicast Applicationsの方程式ベースのうっ血制御、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.
[FJ92] Packet-Switched Gateways、Floyd、S。およびJacobson、V.、InternetWorking：Research and Experience、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.ハーンと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] Henderson、T.R.、E。Sahouria、S。McCanne、およびR.H. Katz、1998年11月、Globecom、GlobecomのTCP混雑回避の公平性の向上について。
[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イニシアチブ：インターネットは（まだ）すべての人にとって、
[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. Kelly、Bersty Connectionsの充電と会計、L。W。McKnightおよびJ. P. Bailey、編集者、インターネット経済学。MIT Press、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. Kelly、A。MaullooおよびD. Tan、通信ネットワークのレート制御：影の価格、比例公平性、安定性。Journal of the Operational Research Society 49、pp。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. Zhang、ベストエフォートサービスのための混雑制御：新しいパラダイムが必要な理由、IEEEネットワーク、Vol。10、pp。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. Medina、M。Allman、およびS. Floyd、インターネットでの輸送プロトコルの進化の測定、コンピューターコミュニケーションレビュー、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。Floyd、J。Ioannidis、V。Paxson、および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 Deployment Working Group、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] Mahajan、R。、およびFloyd、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-MasonとH. Varian、インターネットの価格設定、1993年5月、JFK School of Internetへのパブリックアクセスに関する会議で。
[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ヒントWebサイト、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] Nagle、J。、「IP/TCPインターネットワークスの混雑制御」、RFC 896、1984年1月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958] Carpenter、B.、ed。、「インターネットの建築原理」、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.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、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] 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。、およびL. Zhang、「インターネットでのキュー管理と混雑回避に関する推奨事項」、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「Distementiated Serviceの建築」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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] Huston、G。、「IP QoSアーキテクチャの次のステップ」、RFC 2990、2000年11月。
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001.
[RFC3124] Balakrishnan、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] Bless、R.、K。Nichols、およびK. Wehrle、「差別化されたサービスのドメインごとの挙動（PDB）の低い」、RFC 3662、2003年12月。
[RFC3714] Floyd, S., Ed., and J. Kempf, Ed., "IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet", RFC 3714, March 2004.
[RFC3714] Floyd、S.、ed。、およびJ. Kempf、ed。、「インターネットでの音声トラフィックの混雑コントロールに関するIABの懸念」、RFC 3714、2004年3月。
[RFC5166] Floyd, S., Ed., "Metrics for the Evaluation of Congestion Control Mechanisms", RFC 5166, March 2008.
[RFC5166] Floyd、S.、ed。、「混雑制御メカニズムの評価のためのメトリック」、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。Clark、D。Estrin、およびS. Herzog、コンピューターネットワークの価格設定：研究アジェンダの再形成、ACM Computer Communication Review、vol。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. Stoica、S。Shenker、およびH. Zhang、コアステートレスフェアキューイング：高速ネットワークでの公正帯域幅の割り当て、ネットワーキングに関するIEEE/ACMトランザクションの概算のスケーラブルなアーキテクチャ：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] Zhang、T.、P。Osterberg、およびYouzhi Xu、Multicast-Favorable Max-Min Fairness-マルチキャストの公平性の一般的な定義、マルチメディアアプリケーションの分散フレームワーク、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/
Sally Floyd ICSI Center for Internet Research 1947 Center Street、Suite 600 Berkeley、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バークレー、カリフォルニア州94704-1198電話：（440）235-1792メール：mallman@icir.org url：http：//www.icir.org/mallman/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。