Network Working Group R. Bless
Request for Comments: 3662 Univ. of Karlsruhe
Category: Informational K. Nichols
Consultant
K. Wehrle
Univ. of Tuebingen/ICSI
December 2003
A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services
差別化サービスのための低努力ドメイン単位の行動（PDB）
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document proposes a differentiated services per-domain behavior (PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best-effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic.
この文書では、正常に機能し、ネットワーク内のトラフィックが「飢餓」であってもよい（飢餓は必須ではありませんが）差別化されたサービス、ドメインごとの行動（PDB）を提案しています。これは、インターネットの「ベストエフォート」または長期の飢餓は、ネットワークの問題を示す「通常のインターネットトラフィック」モデルとは対照的です。この意味で、提案されたPDBのトラフィックは、このようにPDBが「低級努力」（LE）と呼ばれ、通常の「ベストエフォート」のインターネットトラフィックよりも「下」を優先的に転送されます。このPDBの使用は厳密に「ベストエフォート」/「ノーマル」または他のすべてのインターネットトラフィック上のトラフィックの影響を制限するために、ネットワークオペレータが可能になります。この文書では、使用していますが、トラフィックの特定のタイプにPDBの使用を制約提案していないいくつかの例を示します。
This document proposes a differentiated services per-domain behavior [RFC3086] called "Lower Effort" (LE) which is intended for traffic of sufficiently low value (where "value" may be interpreted in any useful way by the network operator), in which all other traffic takes precedence over LE traffic in consumption of network link bandwidth. One possible interpretation of "low value" traffic is its low priority in time, which does not necessarily imply that it is generally of minor importance. From this viewpoint, it can be considered as a network equivalent to a background priority for processes in an operating system. There may or may not be memory (buffer) resources allocated for this type of traffic.
この文書は、ここで、（「値」は、ネットワークオペレータによって任意の有用な方法で解釈されてもよい）十分に低い値のトラフィックのために意図されている「低級エフォート」（LE）と呼ばれる差別化サービスごとのドメイン挙動[RFC3086]を提案しています他のすべてのトラフィックは、ネットワークのリンク帯域幅の消費にLEのトラフィックよりも優先されます。 「低い値」トラフィックの一つの可能な解釈は、必ずしもそれはあまり重要では一般的であることを意味するものではない、時間にその低優先度です。この観点からは、オペレーティング・システムにおけるプロセスの背景優先順位に相当するネットワークとみなすことができます。またはこのタイプのトラフィックのために割り当てられたメモリ（バッファ）のリソースがあってもなくてもよいです。
Some networks carry traffic for which delivery is considered optional; that is, packets of this type of traffic ought to consume network resources only when no other traffic is present. Alternatively, the effect of this type of traffic on all other network traffic is strictly limited. This is distinct from "best-effort" (BE) traffic since the network makes no commitment to deliver LE packets. In contrast, BE traffic receives an implied "good faith" commitment of at least some available network resources. This document proposes a Lower Effort Differentiated Services per-domain behavior (LE PDB) [RFC3086] for handling this "optional" traffic in a differentiated services domain.
ネットワークによっては配達がオプションと見なされているのトラフィックを運びます。つまり、このタイプのトラフィックのパケットは、他のトラフィックが存在しない場合にのみ、ネットワークリソースを消費するべきです。また、他のすべてのネットワークトラフィック上のトラフィックのこのタイプの効果は厳しく制限されています。ネットワークは、LEのパケットを配信する義務はないので、これは「ベストエフォート」（BE）トラフィックとは区別されます。これとは対照的に、トラフィックは、少なくともいくつかの利用可能なネットワークリソースの暗黙の「善意」のコミットメントを受信BE。この文書では、差別化されたサービスドメインで、この「オプション」のトラフィックを処理するための低努力差別化サービス、ドメインごとの行動（LE PDB）[RFC3086]を提案しています。
There is no intrinsic reason to limit the applicability of the LE PDB to any particular application or type of traffic. It is intended as an additional tool for administrators in engineering networks.
任意の特定のアプリケーションまたはトラフィックの種類にLE PDBの適用可能性を制限するための固有の理由はありません。これは、エンジニアリング・ネットワークの管理者のための追加のツールとして意図されています。
Note: where not otherwise defined, terminology used in this document is defined as in [RFC2474].
注意：別段の定義がない場合、本文書で使用される用語は[RFC2474]で定義した通りです。
A Lower Effort (LE) PDB is for sending extremely non-critical traffic across a DS domain or DS region. There should be an expectation that packets of the LE PDB may be delayed or dropped when other traffic is present. Use of the LE PDB might assist a network operator in moving certain kinds of traffic or users to off-peak times. Alternatively, or in addition, packets can be designated for the LE PDB when the goal is to protect all other packet traffic from competition with the LE aggregate, while not completely banning LE traffic from the network. An LE PDB should not be used for a customer's "normal internet" traffic, nor should packets be "downgraded" to the LE PDB for use as a substitute for dropping packets that ought to simply be dropped as unauthorized. The LE PDB is expected to be applicable to networks that have some unused capacity at some times of day.
下の努力（LE）PDBはDSドメインまたはDSの地域全体で非常に重要でないトラフィックを送信するためです。他のトラフィックが存在するときLE PDBのパケットが遅延または削除することができる期待があるべきです。 LE PDBの使用はオフピーク時間にトラフィックやユーザーの特定の種類を移動するには、ネットワークオペレータを支援する可能性があります。あるいは、またはさらに、パケットは目標が完全にネットワークからLEトラフィックを禁止されていないが、LEの集約との競争から、他のすべてのパケットのトラフィックを保護するためにあるときLE PDBのために指定することができます。 LE PDBは、顧客の「通常のインターネット」トラフィックのために使用すべきではない、また、パケットがあるべき単に不正としてドロップされるべきパケットをドロップの代用として使用するためにLE PDBに「格下げ」。 LE PDBは、その日のいくつかの回でいくつかの未使用の容量を持っているネットワークへの応用が期待されています。
This is a PDB that allows networks to protect themselves from selected types of traffic rather than giving a selected traffic aggregate preferential treatment. Moreover, it may also exploit all unused resources from other PDBs.
これは、ネットワークではなく、選択したトラフィックの集約優遇を与えるよりも、選択したタイプのトラフィックから身を守ることを可能にするPDBです。さらに、それはまた、他のPDBからすべての未使用のリソースを利用することができます。
There are no required traffic profiles governing the rate and bursts of packets beyond the limits imposed by the ingress link. It is not necessary to limit the LE aggregate using edge techniques since its PHB is configured such that packets of the aggregate will be dropped in the network if no forwarding resources are available. The differentiated services architecture [RFC2475] allows packets to be marked upstream of the DS domain or at the DS domain's edge. When packets arrive pre-marked with the DSCP used by the LE PDB, it should not be necessary for the DS domain boundary to police that marking; further (MF) classification for such packets would only be required if there was some reason for the packets to be marked with a different DSCP.
入口リンクによる制限を超えたパケットのレートとバーストを律する必要なトラフィックプロファイルはありません。そのPHB無し転送リソースが利用可能でない場合、集約のパケットがネットワークにドロップされるように構成されているので、エッジの技術を使用してLEの凝集を制限する必要はありません。差別化サービスアーキテクチャ[RFC2475]はパケットがDSドメインの上流またはDSドメインのエッジでマークされることを可能にします。パケットはLE PDBが使用するDSCPで事前マーク到着すると、それはマーキングすることを警察にDSドメイン境界のために必要ではありません。異なるDSCPでマークするパケットのためのいくつかの理由があった場合は、さらにこのようなパケットのために（MF）の分類にのみ必要とされるであろう。
If there is not an agreement on a DSCP marking with the upstream domain for a DS domain using the LE PDB, the boundary must include a classifier that selects the appropriate LE target group of packets out of all arriving packets and steers them to a marker that sets the appropriate DSCP. No other traffic conditioning is required.
LE PDBを使用してDSドメインの上流のドメインとマーキングDSCPの合意がない場合は、境界が全て到着するパケットのうち、パケットの適切なLEターゲットグループを選択し、そのマーカーにそれらを操縦する分類器を含める必要があります適切なDSCPを設定します。他のトラフィック調整は必要ありません。
Either a Class Selector (CS) PHB [RFC2474], an Experimental/Local Use (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597] may be used as the PHB for the LE traffic aggregate. This document does not specify the exact DSCP to use inside a domain, but instead specifies the necessary properties of the PHB selected by the DSCP. If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested.
いずれかのクラスセレクタ（CS）PHB [RFC2474]、実験/ローカル使用（EXP / LU）PHB [RFC2474]、または保証転送（AF）PHB [RFC2597]はLEトラフィック集約のためのPHBとして使用することができます。この文書では、ドメイン内で使用するために、正確なDSCPを指定し、代わりにDSCPによって選択されたPHBの必要なプロパティを指定しません。 CS PHBを使用する場合は、クラスセレクタ1（DSCP = 001000）が提案されています。
The PHB used by the LE aggregate inside a DS domain should be configured so that its packets are forwarded onto the node output link when the link would otherwise be idle; conceptually, this is the behavior of a weighted round-robin scheduler with a weight of zero.
リンクがアイドル状態であろう場合に、そのパケットがノードの出力リンクに転送されるように、DSドメイン内のLE集合体によって使用されるPHBを構成すべきです。概念的に、これはゼロの重みで重み付けラウンドロビンスケジューラの動作です。
An operator might choose to configure a very small link share for the LE aggregate and still achieve the desired goals. That is, if the output link scheduler permits, a small fixed rate might be assigned to the PHB, but the behavior beyond that configured rate should be that packets are forwarded only when the link would otherwise be idle. This behavior could be obtained, for example, by using a CBQ [CBQ] scheduler with a small share and with borrowing permitted. A PHB that allows packets of the LE aggregate to send more than the configured rate when packets of other traffic aggregates are waiting for the link is not recommended.
オペレータは、LEの集計のために非常に小さいリンク共有を構成し、所望の静止目標を達成することを選択するかもしれません。これは、出力リンクスケジューラが許すならば、小さな固定金利は、PHBに割り当てられることがありますが、その設定されたレートを超えた行動は、パケットが、リンクがアイドル状態になるときにのみ転送されるようにする必要があります。この動作は、例えば、小さいシェア及び許可借入金とCBQ [CBQスケジューラを使用することによって、得ることができました。 LE集合体のパケットが他のトラフィックの凝集体のパケットがリンクを待っている設定されたレートよりも多くを送信することができますPHBは推奨されません。
If a CS PHB is used, note that this configuration will violate the "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will have a less timely forwarding than CS0. An operator's goal of providing an LE PDB is sufficient cause for violating the SHOULD. If an AF PHB is used, it must be configured and a DSCP assigned such that it does not violate the "MUST" of paragraph three of section 2 of RFC 2597 [RFC2597] which provides for a "minimum amount of forwarding resources".
CS PHBを使用する場合、この構成はRFC 2474のセクション4.2.2.2の「SHOULD」を違反することに注意してください[RFC2474] CS1以来CS0未満タイムリーな転送を持っています。 LE PDBを提供する事業者の目標はSHOULDに違反するのに十分な原因です。 AF PHBが使用される場合、それは構成されなければならず、DSCPは、「転送リソースの最小量」を提供するRFC 2597のセクション2の段落3の「MUST」[RFC2597]を違反しないように割り当てられます。
The ingress and egress flow of the LE aggregate can be measured but there are no absolute or statistical attributes that arise from the PDB definition. A particular network operator may configure the DS domain in such a way that a statistical metric can be associated with that DS domain. When the DS domain is known to be heavily congested with traffic of other PDBs, a network operator should expect to see no (or very few) packets of the LE PDB egress from the domain. When there is no other traffic present, the proportion of the LE aggregate that successfully crosses the domain should be limited only by the capacity of the network relative to the ingress LE traffic aggregate.
LE集合体の入口および出口流量を測定することができるが、PDB定義から生じる絶対的又は統計的属性が存在しません。特定のネットワークオペレータは、統計的なメトリックがそのDSドメインに関連付けることができるように、DSドメインを構成することができます。 DSドメインが他のPDBのトラフィックが非常に輻輳であることが知られている場合は、ネットワークオペレータは、ドメインからLE PDB出口のない（または非常に少ない）パケットを見ていないことを期待すべきです。他のトラフィックが存在しない場合、正常領域を横切るLE凝集体の割合は、入力LEトラフィック集約に対するネットワークの容量によって制限されるべきです。
None required.
不要です。
A properly functioning network.
正常に機能してネットワーク。
o Multimedia applications [this example edited from Yoram Bernet]:
マルチメディアアプリケーション[Yoram Bernetから編集されたこの例] O：
Many network managers want to protect their networks from certain applications, in particular, from multimedia applications that typically use such non-adaptive protocols as UDP.
多くのネットワーク管理者は通常、UDPのような非適応プロトコルを使用するマルチメディアアプリケーションから、特に、特定のアプリケーションからネットワークを保護したいです。
Most of the focus in quality-of-service is on achieving attributes that are better than Best Effort. These approaches can provide network managers with the ability to control the amount of multimedia traffic that is given this improved performance with excess relegated to Best Effort. This excess traffic can wreak havoc with network resources even when it is relegated to Best Effort because it is non-adaptive and because it can be significant in volume and duration. These characteristics permit it to seize network resources, thereby compromising the performance of other, more important applications that are included in the Best Effort traffic aggregate but that use adaptive protocols (e.g., TCP). As a result, network managers often simply refuse to allow multimedia applications to be deployed in resource constrained parts of their network.
サービス品質における焦点のほとんどは、ベストエフォートよりも優れている属性を達成することにあります。これらのアプローチは、ベストエフォートに追いやら過剰でこの性能向上を与えているマルチメディアトラフィックの量を制御する能力をネットワーク管理者に提供することができます。この過剰なトラフィックが、それは、ボリュームと持続時間に大きくなる可能性があるため、それは非適応ですので、それはベストエフォートに追いやられている場合でも、ネットワークリソースに大混乱をもたらすことができます。これらの特性は、それによってベストエフォートトラフィックの集計に含まれている他、より多くの重要なアプリケーションのパフォーマンスを犠牲にすること、ネットワークリソースをつかむためにそれを許すが、それは、適応型のプロトコル（例えば、TCP）を使用します。その結果、ネットワーク管理者は、多くの場合、単にマルチメディア・アプリケーションは、ネットワークのリソースに制約の部分に展開することを可能にすることを拒否する。
The LE PDB enables a network manager to allow the deployment of multimedia applications without losing control of network resources. A limited amount of multimedia traffic may (or may not) be assigned to PDBs with attributes that are better than Best Effort. Excess multimedia traffic can be prevented from wreaking havoc with network resources by forcing it to the LE PDB.
LE PDBは、ネットワークリソースの制御を失うことなく、マルチメディアアプリケーションの展開を可能にするために、ネットワーク管理を可能にします。マルチメディアトラフィックの限られた量は（またはしない場合があります）ベストエフォートよりも優れている属性を持つのPDBに割り当てることができます。過剰マルチメディアトラフィックは、LE PDBにそれを強制することにより、ネットワークリソースと大混乱をwreakingを防止することができます。
o For Netnews and other "bulk mail" of the Internet.
ネットニュースやインターネットの他の「バルクメール」については、O。
o For "downgraded" traffic from some other PDB when this does not violate the operational objectives of the other PDB or the overall network. As noted in section 2, LE should not be used for the general case of downgraded traffic, but may be used by design, e.g., when multicast is used with a value-added DS-service and consequently the Neglected Reservation Subtree problem [NRS] arises.
これは、他のPDBまたはネットワーク全体の運用目的に違反していない場合、Oのためにいくつかの他のPDBからのトラフィックを「格下げ」。セクション2で述べたように、LEは、ダウングレードトラフィックの一般的な場合に使用されるべきではなく、設計によって使用されてもよい、例えば、マルチキャストが付加価値DS-サービスで使用されたとき、その結果放置予約サブツリーの問題[NRS]発生します。
o For content distribution, peer-to-peer file sharing traffic, and the like.
コンテンツ配信のためにOトラフィックを共有し、ピア・ツー・ピアのファイル、などが挙げられます。
o For traffic caused by world-wide web search engines while they gather information from web servers.
彼らはWebサーバから情報を収集しながら、ワールドワイドウェブ検索エンジンによって引き起こされたトラフィックについては、O。
The authors solicit further experiences for this section. Results from simulations are presented and discussed in Appendix A.
著者は、このセクションの更なる経験を募ります。シミュレーションの結果は、付録Aに提示し、議論されています
There are no specific security exposures for this PDB. See the general security considerations in [RFC2474] and [RFC2475].
このPDBのための特定のセキュリティ・エクスポージャーはありません。 [RFC2474]と[RFC2475]での一般的なセキュリティの考慮事項を参照してください。
The previous name of this PDB, "bulk handling", was loosely based on the United States' Postal Service term for very low priority mail, sent at a reduced rate: it denotes a lower-cost delivery where the items are not handled with the same care or delivered with the same timeliness as items with first-class postage. Finally, the name was changed to "lower effort", because the authors and other DiffServ Working Group members believe that the name should be more generic in order to not imply constraints on the PDB's use to a particular type of traffic (namely that of bulk data).
このPDBの以前の名前は、「バルクハンドリング」、緩く減少した速度で送られた非常に低い優先度のメールのための米国の郵政公社の用語に基づいていた：それは項目がで処理されていない低コストの配信を表し、同じケアやファーストクラスの郵便料金との項目と同じ適時に配信。著者およびその他のDiffServワーキンググループのメンバーは、名前が（つまりそのバルクのトラフィックの特定のタイプにPDBの使用上の制約を意味するものではないために、より汎用的であることを信じているから最後に、名前が、「下の努力」に変更されましたデータ）。
The notion of having something "lower than Best Effort" was raised in the Diffserv Working Group, most notably by Roland Bless and Klaus Wehrle in their Internet Drafts [LBE] and [LE] and by Yoram Bernet for enterprise multimedia applications. One of its first applications was to re-mark packets within multicast groups [NRS]. Therefore, previous discussions centered on the creation of a new PHB. However, the original authors (Brian Carpenter and Kathleen Nichols) believe this is not required and this document was written to specifically explain how to get less than Best Effort without a new PHB.
「ベストエフォートより低い」何かを持っていることの概念は最も有名なローランドが祝福して彼らのインターネットドラフト[LBE]と[LE]でクラウスWehrleのことで、エンタープライズのマルチメディアアプリケーションのためのYoram Bernetにより、Diffservの作業部会で育ちました。その最初のアプリケーションの一つは、マルチキャストグループ内の再マークパケット[NRS]でした。そのため、以前の議論は新しいPHBの作成を中心に。しかし、原作者（ブライアン・カーペンターとキャスリーン・ニコルズ）これは必須ではないと信じて、この文書は、特に新しいPHBずにベストエフォート未満を取得する方法を説明するために書かれました。
Yoram Bernet contributed significant amounts of text for the "Examples" section of this document and provided other useful comments that helped in editing. Other Diffserv WG members suggested that the LE PDB is needed for Napster traffic, particularly at universities. Special thanks go to Milena Neumann for her extensive efforts in performing the simulations that are described in Appendix A.
Yoram Bernetは、このドキュメントの「例」セクションのテキストを大量に貢献し、編集に貢献し、他の有益なコメントを提供しました。その他のDiffserv WGメンバーはLE PDBは、特に大学で、ナップスターのトラフィックのために必要であることを示唆しました。特別な感謝は、付録Aに記載されているシミュレーションを実行する際に、彼女の広範囲な努力をミレーナノイマンに行きます
Appendix A. Experiences from a Simulation Model
シミュレーションモデルから付録A.体験
The intention of this appendix is to show that a Lower Effort PDB with a behavior as described in this document can be realized with different implementations and PHBs respectively. Overall, each of these variants show the desired behavior but also show minor differences in certain traffic load situations. This comparison could make the choice of a realization variant interesting for a network operator.
この付録の意図は、この文書に記載されているように挙動を有する下部エフォートPDBは、それぞれ異なる実装とのPHBを用いて実現することができることを示すことです。全体的に、これらの変異体のそれぞれは、望ましい挙動を示すだけでなく、特定のトラフィック負荷の状況ではマイナーな違いを示します。この比較は、ネットワークオペレータのための興味深い実現の変異体の選択をすることができます。
A.1. Simulation Environment
A.1。シミュレーション環境
The small DiffServ domain shown in Figure 1 was used to simulate the LE PDB. There are three main sources of traffic (S1-S3) depicted on the left side of the figure. Source S1 sends five aggregated TCP flows (A1-A5) to the receivers R1-R5 respectively. Each aggregated flow Ax consists of 20 TCP connections, where each aggregate experiences a different round trip time between 10ms and 250ms. There are two sources of bulk traffic. B1 consists of 100 TCP connections sending as much data as possible to R6 and B2 is a single UDP flow also sending as much as possible to R7.
図1に示されている小のDiffServドメインはLE PDBをシミュレートするために使用しました。図の左側に示されているトラフィックの三つの主要なソース（S1-S3）があります。ソースS1は、それぞれの受信機R1-R5に5つの集約TCPフロー（A1-A5）を送信します。各集約フローAxが各凝集体が10ミリ秒と250ミリ秒の間で異なる往復時間を経験する20のTCP接続からなります。バルクトラフィックの二つのソースがあります。 B1はR6に、できるだけ多くのデータを送信100回のTCP接続で構成され、B2はまた、R7にできるだけ送信単UDPフローです。
...................
. . R1
. . /
. . /-R2
. . /
S1==**=>[BR1] [BR4]==**==>---R3
. \\ // . \
. \\ // . \-R4
. ** ** . \
. \\ // . R5
. \\ // .
S2=++=>[BR2]-++-[IR1]==**==++==::==[IR2] .
(Bulk) . // \\ .
. // :: .
. :: \\ .
. // ++ .
.// \\.
S3==::==>[BR3] [BR5]==++==>R6
(UDP) . . ||
. . ||
. . ::
.................... ||
VV
R7
Figure 1: A DiffServ domain with different flows
図1：異なるフローとのDiffServドメイン
In order to show the benefit of using the LE PDB instead of the normal Best Effort (BE) PDB [RFC3086], different scenarios are used:
LE PDB代わりに通常ベストエフォート（BE）PDB [RFC3086]を使用することの利点を示すために、さまざまなシナリオが使用されます。
A) B1 and B2 are not present, i.e., the "normal" situation without bulk data present. A1-A5 use the BE PDB.
A）B1およびB2は、本バルクデータのない、すなわち、「正常な」状況は存在しません。 A1-A5は、BE PDBを使用しています。
B) B1 and B2 use the BE PDB for their traffic, too.
B）B1とB2は、あまりにも、そのトラフィックに対してBE PDBを使用しています。
C) B1 and B2 use LE PDB for their traffic with different PHB implementations:
C）B1と異なるPHBの実装とそのトラフィックのためB2使用LE PDB：
1) PHB with Priority Queueing (PQ)
2) PHB with Weighted Fair Queueing (WFQ)
3) PHB with Weighted RED (WRED)
4) PHB with WFQ and RED
C1) represents the case where there are no allocated resources for the LE PDB, i.e., LE traffic is only forwarded if there are unused resources. In scenarios C2)-C4), a bandwidth share of 10% has been allocated for the LE PDB. RED parameters were set to w_q=0.1 and max_p=0.2. In scenario C2), two tail drop queues were used for BE and LE and WFQ scheduling was set up with a weight of 9:1 for the ratio of BE:LE. In scenario C3), a total queue length of 200000 bytes was used with the following thresholds: min_th_BE=19000, max_th_BE=63333, min_th_LE=2346, max_th=7037. WRED allows to mark packets with BE or LE within the same microflow (e.g., letting applications pre-mark packets according to their importance) without causing a reordering of packets within the microflow. In scenario C4), each queue had a length of 50000 bytes with the same thresholds of min_th=18000 and max_th=48000 bytes. WFQ parameters were the same as in C2).
C1）、未使用のリソースがある場合、すなわち、LEトラフィックのみ転送され、LE PDBのための割り当てられたリソースが存在しない場合を示します。シナリオC2）-C4）において、10％の帯域幅割当は、LE PDBのために割り当てられています。 REDパラメータが= 0.1及びmax_p = 0.2 w_qするように設定しました。 BEの比が1：シナリオC2）において、二つのテールドロップキューはBEとLEとWFQスケジューリングのために使用されたが、9の重量で設定したLE。 min_th_BE = 19000、max_th_BE = 63333、min_th_LE = 2346、MAX_TH = 7037：シナリオC3）において、200000バイトの合計キュー長は、次のしきい値とを使用しました。 WREDは、マイクロフロー内のパケットの並び替えを引き起こすことなく（例えば、その重要度に応じてアプリケーションプリマークパケットをさせる）同じマイクロフロー内にあるか、LEでパケットをマークすることを可能にします。シナリオC4）において、各キューは、同じMIN_TH = 18000のしきい値とMAX_TH = 48000バイトで50000バイトの長さを有していました。 WFQパラメータ）C2と同じでした。
The link bandwidth between IR1 and IR2 is limited to 1200 kbit/s, thus creating the bottleneck in the network for the following situations. In all situations, the 20 TCP connections within each aggregated flow Ax (flowing from S1 to Rx) used the Best Effort PDB. Sender S2 transmitted bulk flow B1 (consisting of 100 TCP connections to R6) with an aggregated rate of 550 kbit/s, whereas the UDP sender S3 transmitted with a rate of 50 kbit/s.
IR1とIR2との間のリンクの帯域幅は、このように次のような状況のために、ネットワークのボトルネックを作成し、1200キロビット/秒に制限されています。すべての状況において、各集約フローAxの内の20個のTCP接続（S1からのRxに流れる）はベストエフォートPDBを使用します。 UDP送信者S3は50キロビット/秒の速度で送信に対し、送信者S2は、550キロビット/秒の凝集速度と（R6 100個のTCP接続からなる）は、バルク流B1を送信しました。
The following four different situations with varying traffic load for the Ax flows (at application level) were simulated.
（アプリケーションレベルで）AXフローのトラフィック負荷を変化させると、以下の4つの異なる状況がシミュレートされました。
Situation | I | II | III | IV |
----------------------------+------+------+------+------|
Sender Rate S1 [kbit/s] | 1200 | 1080 | 1800 | 800 |
Sender Rate S2 [kbit/s] | 550 | 550 | 550 | 550 |
Sender Rate S3 [kbit/s] | 50 | 50 | 50 | 50 |
Bandwidth IR1 -> IR2 | 1200 | 1200 | 1200 | 1200 |
Best Effort Load (S1) | 100% | 90% | 150% | 67% |
Total load for link IR1->IR2| 150% | 140% | 200% | 117% |
In situation I, there are no unused resources left for the B1 and B2 flows. In situation II, there is a residual bandwidth of 10% of the bottleneck link between IR1 and IR2. In situation III, the traffic load of A1-A5 is 50% higher than the bottleneck link capacity. In situation IV, A1-A5 consume only 2/3 of the bottleneck link capacity. B1 and B2 require together 50% of the bottleneck link capacity.
状況で、私は、B1とB2の流れのために残された未使用のリソースはありません。状況IIにおいて、IR1及びIR2の間のボトルネックリンクの10％の残存帯域幅があります。状況IIIでは、A1-A5のトラフィック負荷がボトルネックリンクの容量よりも50％高くなっています。状況IVでは、A1-A5は、ボトルネックリンクの容量の2/3のみを消費します。 B1とB2は一緒にボトルネックリンクの容量の50％を必要としています。
The simulations were performed with the freely available discrete event simulation tool OMNeT++ and a suitable set of QoS mechanisms [SimKIDS]. Results from the different simulation scenarios are discussed in the next section.
シミュレーションは、自由に利用可能な離散事象シミュレーションツールOMNeT ++およびQoSメカニズム[SimKIDS]の適切なセットを用いて行きました。異なるシミュレーションシナリオからの結果は、次のセクションで説明されています。
A.2. Simulation Results
A.2。シミュレーション結果
QoS parameters listed in the following tables are averaged over the first 160s of the transmission. Results of situation I are shown in Figure 2. When the BE PDB is used for transmission of bulk flows B1 and B2 in case B), one can see that flows A1-A5 throttle their sending rate to allow transmission of bulk flows B1 and B2. In case C1), not a single packet is transmitted to the receiver because all packets get dropped within IR1, thereby protecting Ax flows from Bx flows. In case C2), B1 and B2 consume all resources up to the configured limit of 10% of the link bandwidth, but not more. C3) also limits the share of B1 and B2 flows, but not as precisely as with WFQ. C4) shows slightly higher packet losses for Ax flows due to the active queue management.
以下の表に記載されているQoSパラメータは、送信の最初160Sにわたって平均化されます。状況の結果は、私はBE PDBバルクの送信に使用される場合、図2に示され、一方はそれはA1-A5は、その送信速度は、バルクの送信を可能にするようにスロットル流れ、B1とB2を流れる見ることができる）ケースBのB1とB2を流れるされています。すべてのパケットがIR1内落とし得るので、ケースC1）ではなく、単一のパケットを受信機に送信され、それによって斧を保護するのBXフローから流れます。ケースC2）において、B1及びB2は、設定リンク帯域幅の10％の限界ではなく、それ以上までのすべてのリソースを消費します。 C3）もなくとして正確WFQと同様に、B1及びB2の流れのシェアを制限します。 C4）Axは、アクティブキュー管理に起因する流れのためにわずかに高いパケット損失を示しています。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 240 | 71 | 240 | 214 | 225 | 219 |
| | A2 | 240 | 137 | 240 | 216 | 223 | 218 |
| | A3 | 240 | 209 | 240 | 224 | 220 | 217 |
| Throughput | A4 | 239 | 182 | 239 | 222 | 215 | 215 |
| [kbit/s] | A5 | 238 | 70 | 238 | 202 | 201 | 208 |
| | B1 | - | 491 | 0 | 82 | 85 | 84 |
| | B2 | - | 40 | 0 | 39 | 31 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1197 | 669 | 1197 | 1078 | 1084 | 1078 |
| [kbit/s] | bulk | - | 531 | 0 | 122 | 116 | 122 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 0 | 19.3 | 0 | 6.3 | 5.7 | 8.6 |
| | A2 | 0 | 17.5 | 0 | 6.0 | 5.9 | 8.9 |
| | A3 | 0 | 10.2 | 0 | 3.2 | 6.2 | 9.1 |
| Paket Loss | A4 | 0 | 12.5 | 0 | 4.5 | 6.6 | 9.3 |
| [%] | A5 | 0 | 22.0 | 0 | 6.0 | 5.9 | 9.0 |
| | B1 | - | 10.5 | 100 | 33.6 | 38.4 | 33.0 |
| | B2 | - | 19.6 | 100 | 19.9 | 37.7 | 22.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 14.9 | 0 | 5.2 | 6.1 | 9.0 |
| Loss Rate [%] | bulk | 0 | 11.4 | 100 | 29.5 | 38.2 | 29.7 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 21.9 | 12.6 | 21.9 | 19.6 | 20.3 | 20.3 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 2: Situation I - Best Effort traffic uses 100% of the
available bandwidth
Results of situation II are shown in Figure 3. In case C1), LE traffic gets exactly the 10% residual bandwidth that is not used by the Ax flows. Cases C2) and C4) show similar results compared to C1), whereas case C3) also drops packets from flows A1-A5 due to active queue management.
状況IIの結果）は、ケースC1は、図3に示されている、LEトラフィックはアックスフローによって使用されていない正確に10％の残留帯域幅を取得します。ケースC3）も起因アクティブキュー管理に流れA1-A5からのパケットをドロップし、一方、ケースC2）及びC4）は、）C1と比較して同様の結果を示しています。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 216 | 193 | 216 | 216 | 211 | 216 |
| | A2 | 216 | 171 | 216 | 216 | 211 | 216 |
| | A3 | 216 | 86 | 216 | 216 | 210 | 216 |
| Throughput | A4 | 215 | 121 | 215 | 215 | 211 | 215 |
| [kbit/s] | A5 | 215 | 101 | 215 | 215 | 210 | 215 |
| | B1 | - | 488 | 83 | 83 | 114 | 84 |
| | B2 | - | 39 | 39 | 39 | 33 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1078 | 672 | 1077 | 1077 | 1053 | 1077 |
| [kbit/s] | bulk | - | 528 | 122 | 122 | 147 | 122 |
+----------------+--------+--------+------+------+------+----+-+-------+
| | A1 | 0 | 9.4 | 0 | 0 | 1.8 | 0 |
| | A2 | 0 | 14.6 | 0 | 0 | 2.0 | 0 |
| | A3 | 0 | 22.4 | 0 | 0 | 2.1 | 0 |
| Paket Loss | A4 | 0 | 15.5 | 0 | 0 | 1.8 | 0 |
| [%] | A5 | 0 | 17.4 | 0 | 0 | 1.9 | 0 |
| | B1 | - | 11.0 | 32.4 | 32.9 | 35.7 | 33.1 |
| | B2 | - | 21.1 | 20.3 | 20.7 | 34.0 | 22.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 14.9 | 0 | 0 | 1.9 | 0 |
| Loss Rate [%] | bulk | - | 12.0 | 28.7 | 29.1 | 35.3 | 29.8 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 19.8 | 12.8 | 19.8 | 19.8 | 19.5 | 19.8 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 3: Situation II - Best Effort traffic uses 90% of the
available bandwidth
Results of simulations for situation III are depicted in Figure 4. Due to overload caused by flows A1-A5, packets get dropped in all cases. Bulk flows B1 and B2 nearly get their maximum throughput in case B). As one would expect, in case C1) all packets from B1 and B2 are dropped, in cases C2) and C4) resource consumption of bulk data is limited to the configured share of 10%. Again the WRED implementation in C3) is not as accurate as the WFQ variants and lets more BE traffic pass through IR1.
状況IIIのためのシミュレーションの結果は、原因が流れA1-A5によって引き起こされる過負荷に図4に描かれている、パケットはすべての場合に落とします。バルク流れB1及びB2に近い）ケースBでの最大スループットを得ます。予想されるように、ケースC1）のB1とB2からのすべてのパケットは、ケースC2に、ドロップされる）とバルクデータのC4）リソース消費を10％のシェア構成に限定されます。 C3で再びWREDの実装）WFQバリアントほど正確ではなく、よりIR1を通過するトラフィックのパスBEことができます。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 303 | 136 | 241 | 298 | 244 | 276 |
| | A2 | 316 | 234 | 286 | 299 | 240 | 219 |
| | A3 | 251 | 140 | 287 | 259 | 236 | 225 |
| Throughput | A4 | 168 | 84 | 252 | 123 | 209 | 219 |
| [kbit/s] | A5 | 159 | 82 | 132 | 101 | 166 | 141 |
| | B1 | - | 483 | 0 | 83 | 73 | 83 |
| | B2 | - | 41 | 0 | 38 | 31 | 38 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 1199 | 676 | 1199 | 1079 | 1096 | 1079 |
| [kbit/s] | bulk | - | 524 | 0 | 121 | 104 | 121 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 9.6 | 17.6 | 12.1 | 9.3 | 8.6 | 12.8 |
| | A2 | 8.5 | 13.6 | 8.4 | 9.8 | 8.1 | 14.5 |
| | A3 | 8.8 | 18.7 | 7.7 | 11.6 | 7.8 | 13.6 |
| Paket Loss | A4 | 14.9 | 22.3 | 11.2 | 18.9 | 8.2 | 12.4 |
| [%] | A5 | 12.8 | 19.0 | 15.6 | 19.7 | 8.3 | 14.3 |
| | B1 | - | 11.9 | 100 | 32.1 | 39.5 | 33.0 |
| | B2 | - | 17.3 | 100 | 22.5 | 37.7 | 22.8 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 10.4 | 17.3 | 10.3 | 12.2 | 8.2 | 13.4 |
| Loss Rate [%] | bulk | - | 12.4 | 100 | 29.1 | 39.0 | 29.9 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 22.0 | 12.6 | 22.0 | 20.2 | 20.6 | 20.3 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 4: Situation III - Best Effort traffic load is 150%
図4：現状III - ベストエフォートトラフィック負荷が150％です
In situation IV, 33% or 400 kbit/s are not used by Ax flows and the results are listed in Figure 5. In case B) where bulk data flows B1 and B2 use the BE PDB, packets of Ax flows are dropped, whereas in cases C1)-C4) flows Ax are protected from bulk flows B1 and B2. Therefore, by using the LE PDB for Bx flows, the latter get only the residual bandwidth of 400 kbit/s but not more. Packets of Ax flows are not affected by Bx traffic in these cases.
状況IVは、33％又は400キロビット/秒をアックスフローによって使用されず、結果は、ケースBでは、図5に記載されている）は、バルクデータB1とB2は、BE PDBを使用して流れる場合、アックス・フローのパケットは、一方、廃棄されケースC1）C4）に斧をバルクから保護されて流れB1とB2を流れます。したがって、BXは流れるためLE PDBを使用することにより、後者は400キロビット/秒の唯一の残留帯域幅ではなく、多くを得ます。アックス・フローのパケットは、これらの場合にBxのトラフィックの影響を受けません。
+-------------------------+--------+-----------------------------------+
| | | Bulk Transfer with PDB: |
| QoS Parameter | A) | B) | C) Lower Effort |
| |No bulk | Best | 1) 2) 3) 4) |
| Flows |transfer|Effort| PQ | WFQ | WRED |RED&WFQ|
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 160 | 140 | 160 | 160 | 160 | 160 |
| | A2 | 160 | 124 | 160 | 160 | 160 | 160 |
| | A3 | 160 | 112 | 160 | 160 | 160 | 160 |
| Throughput | A4 | 160 | 137 | 160 | 160 | 159 | 160 |
| [kbit/s] | A5 | 159 | 135 | 159 | 159 | 159 | 159 |
| | B1 | - | 509 | 361 | 362 | 364 | 362 |
| | B2 | - | 43 | 40 | 39 | 38 | 40 |
+----------------+--------+--------+------+------+------+------+-------+
|Total Throughput| normal | 798 | 648 | 798 | 798 | 797 | 798 |
| [kbit/s] | bulk | - | 551 | 401 | 401 | 402 | 401 |
+----------------+--------+--------+------+------+------+------+-------+
| | A1 | 0 | 9.2 | 0 | 0 | 0 | 0 |
| | A2 | 0 | 12.2 | 0 | 0 | 0 | 0 |
| | A3 | 0 | 14.0 | 0 | 0 | 0 | 0 |
| Paket Loss | A4 | 0 | 9.3 | 0 | 0 | 0 | 0 |
| [%] | A5 | 0 | 6.6 | 0 | 0 | 0 | 0 |
| | B1 | - | 7.3 | 21.2 | 21.8 | 25.0 | 21.3 |
| | B2 | - | 14.3 | 19.4 | 20.7 | 24.5 | 20.7 |
+----------------+--------+--------+------+------+------+------+-------+
| Total Packet | normal | 0 | 10.2 | 0 | 0 | 0 | 0 |
| Loss Rate [%] | bulk | - | 8.0 | 21.0 | 21.7 | 25.0 | 21.2 |
+----------------+--------+--------+------+------+------+------+-------+
| Transmitted | | | | | | | |
| Data [MByte] | normal | 14.8 | 12.1 | 14.8 | 14.8 | 14.7 | 14.7 |
+----------------+--------+--------+------+------+------+------+-------+
Figure 5: Situation IV - Best Effort traffic load is 67%
図5：現状IV - ベストエフォートトラフィック負荷が67％です
In summary, all the different scenarios show that the "normal" BE traffic can be protected from traffic in the LE PDB effectively. Either no packets get through if no residual bandwidth is left (LE traffic is starved), or traffic of the LE PDB can only consume resources up to a configurable limit.
要約すると、すべての異なるシナリオが「正常な」BEトラフィックが効果的LE PDBのトラフィックから保護することができることを示しています。いずれか全くパケットが残存帯域幅が残っていない場合（LEトラフィックは飢餓される）を介して取得していない、またはLE PDBのトラフィックは、設定限界までリソースを消費することができます。
Furthermore, the results substantiate that mass data transfer can adversely affect "normal" BE traffic (e.g., 14.9% packet loss in situations I and II, even 10.2% in situation IV) in situations without using the LE PDB.
さらに、結果は、大量のデータ転送に悪影響LE PDBを使用せずに状況でトラフィック（例えば、14.9％のパケット状況におけるロスIおよびII、状況IVでさえ10.2％）、「ノーマル」に影響することができることを実証します。
Thus, while all presented variants of realizing the LE PDB meet the desired behavior of protecting BE traffic, they also show small differences in detail. A network operator has the opportunity to choose a realization method to fit the desired behavior (showing this is - after the proof of LE's efficacy - the second designation of this appendix). For instance, if operators want to starve LE traffic completely in times of congestion, they could choose PQ. This causes LE traffic to be completely starved and not a single packet would get through in case of full load or overload.
LE PDBを実現するすべての提示変異体はBEトラフィックを保護する目的の動作を満たしつつ、彼らはまた、詳細に小さな違いを示します。ネットワークオペレータは、（ - LEの有効性を証明した後 - この付録の第二の指定を、これをされ示す）は、所望の動作に合わせて実現方法を選択する機会を持っています。事業者は、混雑の時代に完全LEトラフィックを餓死したい場合例えば、彼らはPQを選択することができます。これは、LEトラフィックが完全に不足することが原因ではなく、単一のパケットは、全負荷や過負荷の場合に通じなるだろう。
On the other hand, for network operators who want to permit some small amount of throughput in the LE PDB, one of the other variants would be a better choice.
一方、LE PDBにスループットのいくつかの小さな量を許可するネットワークオペレータのために、他の変異体の一つは、より良い選択です。
Referring to this, the WFQ implementation showed a slightly more robust behavior with PQ, but had problems with synchronized TCP flows. WRED behavior is highly dependent on the actual traffic characteristics and packet loss rates are often higher compared to other implementations, while the fairness between TCP connections is better. The combined solution of WFQ with RED showed the overall best behavior, when an operator's intent is to keep a small but noticeable throughput in the LE PDB.
これを参照すると、WFQの実装はPQと少しより堅牢な挙動を示したが、同期したTCPフローに問題がありました。 WRED動作はTCPコネクション間の公平性が優れている一方で、他の実装に比べて高いことが多いです実際のトラフィック特性やパケット損失率に大きく依存しています。 REDとWFQの統合ソリューションは、オペレータの意図は、LE PDBに小さいが顕著なスループットを維持することであるとき、全体的に最良の挙動を示しました。
Normative References
引用規格
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC3086]ニコルズ、K.とB.大工、「自分仕様のための差別化サービスドメイン単位の行動とルールの定義」、RFC 3086、2001年4月。
[RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
Informative References
参考文献
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[CBQ] Floyd, S. and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol. 3, No. 4, pp. 365-386, August 1995.
[CBQ]フロイド、S.とV. Jacobson氏、「パケットネットワークのリンクを共有し、リソース管理モデル」、ネットワーキング、巻上のIEEE / ACM取引。 3、第4号、頁365から386まで、1995年8月。
[LBE] Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop Behavior", Work in Progress, September 1999.
[LBE]、R.とK. Wehrleの、「A低いよりベストエフォートホップ単位動作」、進歩、1999年9月で仕事を祝福。
[LE] Bless, R. and K. Wehrle, "A Limited Effort Per-Hop Behavior", Work in Progress, February 2001.
[LE]は進歩、2001年2月作品、「限定エフォートホップ単位動作を」R.及びK. Wehrleのブレス。
[SimKIDS] Wehrle, K., Reber, J. and V. Kahmann, "A simulation suite for Internet nodes with the ability to integrate arbitrary Quality of Service behavior", in Proceedings of Communication Networks And Distributed Systems Modeling And Simulation Conference (CNDS 2001), Phoenix (AZ), USA, pp. 115-122, January 2001.
[SimKIDS] Wehrleの、K.、REBER、J.およびV. Kahmann、通信ネットワークの議事分散システムのモデリングとシミュレーション会議（CNDSで、「サービスの振る舞いの任意の品質を統合する能力を持つインターネットノードのためのシミュレーション・スイート」 2001）、フェニックス（AZ）、USA、頁115-122、2001年1月。
[NRS] Bless, R. and K. Wehrle, "Group Communication in Differentiated Services Networks", in Proceedings of IEEE International Workshop on "Internet QoS", Brisbane, Australia, IEEE Press, pp. 618-625, May 2001.
[NRS]は、 "インターネットのQoS"、ブリスベン、オーストラリア、IEEEプレス、頁618-625、2001年5月に、R.およびIEEE国際ワークショップの議事録ではK. Wehrleの、 "差別化サービスネットワークにおけるグループ通信" を、祝福します。
Authors' Addresses
著者のアドレス
Roland Bless Institute of Telematics, Universitaet Karlsruhe (TH) Zirkel 2 76128 Karlsruhe Germany
ローランドは、テレマティクスの研究所、カールスルーエ大学（TH）Zirkel 2 76128カールスルーエドイツを祝福します
EMail: bless@tm.uka.de URI: http://www.tm.uka.de/~bless/
電子メール：bless@tm.uka.de URI：http://www.tm.uka.de/~bless/
Kathleen Nichols 325M Sharon Park Drive #214 Menlo Park, CA 94025
キャスリーン・ニコルズ325Mシャロンパークドライブ＃214メンロパーク、CA 94025
EMail: knichols@ieee.org
メールアドレス：knichols@ieee.org
Klaus Wehrle University of Tuebingen, Computer Networks and Internet Morgenstelle 10c, 72076 Tuebingen, Germany & International Computer Science Institute (ICSI) 1947 Center Street, Berkeley, CA, 94704, USA
チュービンゲン、コンピュータネットワークおよびインターネットMorgenstelle 10cは、72076チュービンゲン、ドイツ・国際コンピュータ科学研究所（ICSI）1947センターストリート、バークレー、CA、94704、USAのクラウスWehrleの大学
EMail: Klaus.Wehrle@uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/~wehrle/
電子メール：Klaus.Wehrle@uni-tuebingen.de URI：http://net.informatik.uni-tuebingen.de/~wehrle/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。