RFC3662 日本語訳
3662 A Lower Effort Per-Domain Behavior (PDB) for DifferentiatedServices. R. Bless, K. Nichols, K. Wehrle. December 2003. (Format: TXT=39029 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
作業部会R.をネットワークでつないでください。コメントを求める要求を祝福してください: 3662年のカールスルーエカテゴリの大学: Tuebingen/ICSI2003年12月の情報のK.ニコルズコンサルタントK.ウェールレ大学
A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services
微分されたサービスのための1ドメインあたり1つの下側の努力の振舞い(PDB)
Status of this Memo
この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.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
このドキュメントは交通が適切に機能しているネットワークに「飢えるかもしれない」(飢餓が厳密に必要ではありませんが)1ドメインあたり1つの微分されたサービスの振舞い(PDB)を提案します。 これはインターネットの「ベストエフォート型」か「正常なインターネットトラフィック」モデルと対照的になっています。そこで、長引いている飢餓はネットワーク問題を示します。この意味で、「正常な「ベストエフォート型」のインターネットトラフィックより低い」優先と共に提案されたPDBの交通を進めます、その結果、PDBを「下側の努力」(LE)と呼びます。 このPDBの使用は、ネットワーク・オペレータが厳密に「最も良い努力」/「標準」か他のすべてのインターネットトラフィックへの交通の効果を制限することを許可します。 このドキュメントは、何らかの例に用途を与えますが、PDBの使用を抑制するようどんな特定のタイプの交通にも提案しません。
1. Description of the Lower Effort PDB
1. 下側の努力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
このドキュメントは他のすべての交通がネットワークリンク帯域幅の消費におけるLE交通の上で優先する十分低い価値(「値」がネットワーク・オペレータによってどんな役に立つ方法でも解釈されるかもしれないところ)の交通に意図する1ドメインあたりの微分されたサービスの振舞い[RFC3086]の呼ばれた「下側の努力」(LE)を提案します。 「低値」交通の1つの可能な解釈が時間内にの低い優先度です。(その優先度は一般に、それが小さい方に重要であることを必ず含意するというわけではありません)。 この観点から、それはそうであることができます。
Bless, et al. Informational [Page 1] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[1ページ]のRFC3662は努力PDB2003年12月に下ろします。
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.
オペレーティングシステムによる過程に、バックグラウンド優先に同等なネットワークであるとみなされます。 このタイプの交通に割り当てられたメモリ(バッファ)リソースがあるかもしれません。
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を届ける公約を全くパケットにしないので、これは「最も良い努力」(ある)交通と異なっています。 対照的に、交通が少なくともいくつかの利用可能なネットワーク資源の暗示している「誠実」委任を受けるということになってください。 このドキュメントは、微分されたサービスドメインのこの「任意」の交通を扱うために1ドメインあたりのLower Effort Differentiated Servicesの振舞い(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]のように定義されます。
2. Applicability
2. 適用性
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.
Lower Effort(LE)PDBは、DSドメインかDS領域の向こう側に非常に非臨界である交通を送るものです。 他の交通が存在しているとき、遅らせられるか、または落とされて、LE PDBのパケットがそうするかもしれない期待があるべきです。 LE PDBの使用はある種類の交通かユーザをオフピークの回に動かすのにネットワーク・オペレータを助けるかもしれません。 さらに、代わりにか、目標がLE集合との競争からの他のすべてのパケット交通を保護することであるときに、LE PDBのために完全にネットワークからのLE交通を禁止しているというわけではない間、パケットを指定できます。 顧客の「正常なインターネット」交通に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です。 そのうえ、また、それは他のPDBsからのすべての未利用資源を利用するかもしれません。
Bless, et al. Informational [Page 2] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[2ページ]のRFC3662は努力PDB2003年12月に下ろします。
3. Technical Specification
3. 仕様書
3.1. Classification and Traffic Conditioning
3.1. 分類と交通調節
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.
イングレスリンクによって課された限界を超えてパケットのレートと炸裂を決定するどんな必要な交通プロフィールもありません。 LE集合を制限するのは、PHBがどんな推進リソースも利用可能でないなら集合のパケットがネットワークで落とされるように構成されるので縁のテクニックを使用することで必要ではありません。 微分されたサービス構造[RFC2475]で、パケットがDSドメインの上流であるとマークされるか、DSドメインの縁にあります。 パケットがDSCPがLE PDBによって使用されている状態でプレ著しい状態で到着するとき、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を設定するマーカーに導くクラシファイアを含まなければなりません。 いいえ他の交通調節が必要です。
3.2. PHB configuration
3.2. PHB構成
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.
Class Selector(CS)PHB[RFC2474]、Experimental/地方のUse(EXP/LU)PHB[RFC2474]かAssured Forwarding(AF)PHB[RFC2597]のどちらかがそうです。PHBとして、LE交通集合のために、使用されます。 このドキュメントは、ドメインの中の使用に正確なDSCPを指定しませんが、代わりにDSCPによって選択されたPHBの必要な特性を指定します。 CS PHBが使用されているなら、Class Selector1(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は推薦されません。
Bless, et al. Informational [Page 3] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[3ページ]のRFC3662は努力PDB2003年12月に下ろします。
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が使用されているなら、この構成がCS1以来の.2RFC2474[RFC2474]が望んでいるセクション4.2.2の“SHOULD"に違反するというメモには、CS0ほどタイムリーでない推進があります。 LE PDBを提供するというオペレータの目標はSHOULDに違反する十分な原因です。 AF PHBが使用されているなら、構成していなければなりませんでした、そして、DSCPは「最小の量の推進リソース」に備えるRFC2597[RFC2597]のセクション2のパラグラフthreeの“MUST"に違反しないようなものを割り当てました。
4. Attributes
4. 属性
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ドメインが他のPDBsの交通でずっしりと充血するのが知られていると、ネットワーク・オペレータは、ドメインからLE PDB出口のいいえ(または、ほんのわずか)、パケットを見ると予想するべきです。 他のどんな存在している交通もないとき、首尾よくドメインに交差するLE集合の割合はネットワークの容量だけによってイングレスLE交通集合に比例して制限されるべきです。
5. Parameters
5. パラメタ
None required.
なにも必要ではありません。
6. Assumptions
6. 仮定
A properly functioning network.
適切に機能しているネットワーク。
7. Example uses
7. 例の用途
o Multimedia applications [this example edited from Yoram Bernet]:
o マルチメディア応用[ヨラムBernetから編集されたこの例]:
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
サービスの質における焦点の大部分がBest Effortより良い属性を獲得するところにあります。 これらのアプローチは過剰がBest Effortに左遷されている状態でこの向上した性能が与えられているマルチメディア交通の量を制御する能力をネットワークマネージャに提供できます。 それがそれが非適応型であり、ボリュームと持続時間で重要である場合があるのでBest Effortに左遷さえされるとき、この余分な交通はネットワーク資源で大破壊を加えることができます。 これらの特性はネットワーク資源を差押えて、その結果、他の、そして、より重要なアプリケーションの性能で妥協することを許可します。
Bless, et al. Informational [Page 4] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[4ページ]のRFC3662は努力PDB2003年12月に下ろします。
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.
Best Effort交通集合にもかかわらず、その使用では、適応型のプロトコル(例えば、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は、ネットワークマネージャがネットワーク資源の損をしているコントロールなしでマルチメディア応用の展開を許すのを可能にします。 または、マルチメディア交通の数量限定がそうするかもしれない、()、Best Effortより良い属性があるPDBsに割り当てられるかもしれなくなってください。 ネットワーク資源でLE PDBにそれを強制することによって大破壊を加えるのを余分なマルチメディア交通を防ぐことができます。
o For Netnews and other "bulk mail" of the Internet.
o Netnewsとインターネットの他の「料金別納郵便」のために。
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.
o これが他のPDBか総合的なネットワークの作戦目的に違反しないときのある他のPDBからの「格下げされた」交通に。 セクション2で注意されるように、LEを格下げされた交通の一般的なケースに使用するべきではありませんが、故意に使用するかもしれません、例えば、マルチキャストが付加価値が付いたDS-サービスと共に使用されて、Neglected予約Subtree問題[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.
o ウェブサーバーから情報を収集しますが、世界的なインターネット検索エンジンによって引き起こされた交通に。
8. Experiences
8. 経験
The authors solicit further experiences for this section. Results from simulations are presented and discussed in Appendix A.
作者はさらなる経験にこのセクションに請求します。 Appendix Aでシミュレーションからの結果について、提示されて、議論します。
9. Security Considerations for LE PDB
9. LE PDBのためのセキュリティ問題
There are no specific security exposures for this PDB. See the general security considerations in [RFC2474] and [RFC2475].
このPDBのためのどんな特定のセキュリティ露出もありません。 [RFC2474]と[RFC2475]で総合証券問題を見てください。
10. History of the LE PDB
10. LE PDBの歴史
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
このPDBという「大量の取り扱い」という前の名前は割引料金で送られた非常に低い優先郵便のための合衆国のPostal Service諸条件で緩く基づきました: 商品が同じ注意で扱われもしませんし、項目と同じタイムリーと共にファーストクラスの送料で届けられもしないところでそれは低い費用配送を指示します。 最終的に、「努力を下ろす」ために名前を変えました、作者と他のDiffServ作業部会のメンバーが、名前が特定のタイプへのPDBの使用に規制を含意しないように、より一般的であるべきであると信じているので
Bless, et al. Informational [Page 5] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[5ページ]のRFC3662は努力PDB2003年12月に下ろします。
of traffic (namely that of bulk data).
交通(すなわち、大量のデータのもの)について。
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.
彼らのインターネットDrafts[LBE]と[LE]のローランドBlessとクラウスウェールレと企業マルチメディア応用のためのヨラムBernetはDiffserv作業部会で「Best Effortより低い」心にわだかまりがあるという概念を最も著しく増加しました。 最初のアプリケーションの1つはマルチキャストグループ[NRS]の中でパケットを述べさせることでした。 したがって、前の議論は新しいPHBの創造に集中しました。 しかしながら、原作者(ブライアンCarpenterとキャサリーン・ニコルズ)は、これが必要でなく、このドキュメントが明確に新しいPHBなしでBest Effortより少なくなる方法を説明するために書かれたと信じています。
11. Acknowledgments
11. 承認
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.
ヨラムBernetはこのドキュメントの「例」セクションにかなりの量のテキストを寄付して、編集するのを手伝った他の役に立つコメントを供給しました。 他のDiffserv WGメンバーは、LE PDBが特に大学でナップスター交通に必要であることを提案しました。 特別な感謝は彼女の大規模な努力のためにAppendix Aで説明されるシミュレーションを実行する際にミレナ・ノイマンのものになります。
Bless, et al. Informational [Page 6] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[6ページ]のRFC3662は努力PDB2003年12月に下ろします。
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.
この付録の意志は異なった実現とPHBsと共に本書では説明される振舞いがあるLower Effort PDBをそれぞれ実感できるのを示すことです。 全体的に見て、それぞれのこれらの異形は、望まれた行動を示していますが、あるトラヒック負荷状況における小異をまた示しています。 この比較で、実現異形の選択はネットワーク・オペレータによっておもしろくなるかもしれません。
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)の3つの主な源があります。 ソースS1はそれぞれ、5回の集められたTCP流れ(A1-A5)を受信機R1-R5に送ります。 それぞれの集められた流れAxは20のTCP接続から成ります、各集合が10msの間でいろいろな周遊旅行時間になって、250ms. Thereが大量の交通の2つの源であるところで。 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
................... . . R1//-R2/S1=**は>[BR1][BR4]=**=>と等しいです。---R3\\//\\\//\-R4****\\\//R5\//\S2は+ + + + =>[BR2]-++-[IR1]=**==と等しいです:、:==[IR2] (大量) //\\//:、: . . :: + . . //\\\\//+S3=:、:==+ + >[BR3][BR5]==>R6(UDP)。|| . . || . . :: .................... || VV R7
Figure 1: A DiffServ domain with different flows
図1: 異なった流れに伴うDiffServドメイン
Bless, et al. Informational [Page 7] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[7ページ]のRFC3662は努力PDB2003年12月に下ろします。
In order to show the benefit of using the LE PDB instead of the normal Best Effort (BE) PDB [RFC3086], different scenarios are used:
正常なBest Effort(ある)PDB[RFC3086]の代わりにLE PDBを使用する利益を示しているために、異なったシナリオは使用されています:
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とB2は異なったPHB実現によるそれらの交通に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
1) 優先権待ち行列(PQ)があるPHB 2) 荷重している公正な待ち行列(WFQ)があるPHB 3) 荷重している赤(WRED)のPHB 4) WFQと赤のPHB
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 PDBのためのリソースが割り当てられないで、すなわち、未利用資源がある場合にだけLE交通が進められるケースを表します。 シナリオC2) -C4、)、LE PDBのために10%の帯域幅シェアを割り当てました。 REDパラメタはw_q=0.1と最大_p=0.2に設定されました。 中、シナリオC2)、いてください。そうすれば、LEとWFQスケジューリングが9:1の重さで用意ができていたので2つのテール低下待ち行列が比率に使用された、: LEになってください。 中、シナリオC3)、200000バイトの総待ち行列の長さは以下の敷居と共に使用されました: 分_、_=19000、最大第_になってください、_=63333、分第_になってください、_LE=2346、最大第_、第=7037 WREDがパケットをマークさせる、microflowの中でパケットに関するa再命令を引き起こさないで、いてください。さもないと、同じくらい中のLEはmicroflowします(例えば、それらの重要性に従って、アプリケーションにパケットをあらかじめマークさせます)。 中、シナリオC4)、各待ち行列に分_の同じ敷居に従った50000バイトの長さがあった、=18000と最大第_、=48000第バイト。 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の間のリンク帯域幅は1200kbit/sに制限されます、その結果、以下の状況のためにネットワークでボトルネックを作成します。 すべての状況で、それぞれの集められた流れAx(S1からRxまで流れる)の中の20のTCP接続がBest Effort PDBを使用しました。 送付者S2は550kbit/sの集められたレートで大量流れB1(R6に100のTCP接続から成る)を伝えましたが、UDP送付者S3は50kbit/sのレートで伝わりました。
Bless, et al. Informational [Page 8] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[8ページ]のRFC3662は努力PDB2003年12月に下ろします。
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% |
状況| I| II| III| IV| ----------------------------+------+------+------+------| 送付者レートS1[kbit/s]| 1200 | 1080 | 1800 | 800 | 送付者レートS2[kbit/s]| 550 | 550 | 550 | 550 | 送付者レートS3[kbit/s]| 50 | 50 | 50 | 50 | 帯域幅IR1->IR2| 1200 | 1200 | 1200 | 1200 | ベストエフォート型負荷(S1)| 100% | 90% | 150% | 67% | リンク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.
状況Iで、未利用資源は全く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パラメタは1番目の上で平均されています。160個のトランスミッション。 私が図2で見せられる状況の結果。 BE PDBが場合B)における大量の流れのB1とB2のトランスミッションに使用されるとき、人は、A1-A5がトランスミッションを許容するためにそれらの送付レートを阻止する流れが流れのB1とB2を膨らませるのを見ることができます。 中、ケースC1) すべてのパケットがIR1の中で落とされるので受信機に伝えられた、その結果、保護しているAxが流れない1つのパケットも、Bxは流れます。 中、ケースC2)、B1とB2はすべてのリソースをリンク帯域幅の10%の構成された限界まで消費しますが、さらに消費するというわけではありません。 C3) また、B1とB2流れのシェアを制限しますが、WFQ正確に制限するというわけではありません。 C4) 当然のAx流れのためのわずかに高いパケット損失を活発な待ち行列管理に示しています。
Bless, et al. Informational [Page 9] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[9ページ]のRFC3662は努力PDB2003年12月に下ろします。
+-------------------------+--------+-----------------------------------+ | | | 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 | +----------------+--------+--------+------+------+------+------+-------+
+-------------------------+--------+-----------------------------------+ | | | PDBとの転送を膨らませてください: | | QoSパラメタ| a) | B) | C) 下側の努力| | |大量がありません。| 最善| 1) 2) 3) 4) | | 流れ|転送|努力| PQ| WFQ| WRED|赤とWFQ| +----------------+--------+--------+------+------+------+------+-------+ | | A1| 240 | 71 | 240 | 214 | 225 | 219 | | | A2| 240 | 137 | 240 | 216 | 223 | 218 | | | A3| 240 | 209 | 240 | 224 | 220 | 217 | | スループット| 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 | +----------------+--------+--------+------+------+------+------+-------+ |総スループット| 標準| 1197 | 669 | 1197 | 1078 | 1084 | 1078 | | [kbit/s]| 大量| - | 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の損失| 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 | +----------------+--------+--------+------+------+------+------+-------+ | 総パケット| 標準| 0 | 14.9 | 0 | 5.2 | 6.1 | 9.0 | | 損失率[%]| 大量| 0 | 11.4 | 100 | 29.5 | 38.2 | 29.7 | +----------------+--------+--------+------+------+------+------+-------+ | 伝えられます。| | | | | | | | | データ[MByte]| 標準| 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
図2: 状況I--最も良いEffort交通は利用可能な帯域幅の100%を使用します。
Bless, et al. Informational [Page 10] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[10ページ]のRFC3662は努力PDB2003年12月に下ろします。
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の結果は図3に示されます。 中、ケースC1)、LE交通はAx流れによって使用されないまさに10%で残りの帯域幅を得ます。 ケースC2)、C4) 同様の結果がC1と比較したショー、)、ケースC3) ところが、A1-A5当然の流れから活発な待ち行列管理までの低下パケットも。
+-------------------------+--------+-----------------------------------+ | | | 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 | +----------------+--------+--------+------+------+------+------+-------+
+-------------------------+--------+-----------------------------------+ | | | PDBとの転送を膨らませてください: | | QoSパラメタ| a) | B) | C) 下側の努力| | |大量がありません。| 最善| 1) 2) 3) 4) | | 流れ|転送|努力| PQ| WFQ| WRED|赤とWFQ| +----------------+--------+--------+------+------+------+------+-------+ | | A1| 216 | 193 | 216 | 216 | 211 | 216 | | | A2| 216 | 171 | 216 | 216 | 211 | 216 | | | A3| 216 | 86 | 216 | 216 | 210 | 216 | | スループット| 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 | +----------------+--------+--------+------+------+------+------+-------+ |総スループット| 標準| 1078 | 672 | 1077 | 1077 | 1053 | 1077 | | [kbit/s]| 大量| - | 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の損失| 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 | +----------------+--------+--------+------+------+------+------+-------+ | 総パケット| 標準| 0 | 14.9 | 0 | 0 | 1.9 | 0 | | 損失率[%]| 大量| - | 12.0 | 28.7 | 29.1 | 35.3 | 29.8 | +----------------+--------+--------+------+------+------+------+-------+ | 伝えられます。| | | | | | | | | データ[MByte]| 標準| 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
図3: 状況II--最も良いEffort交通は利用可能な帯域幅の90%を使用します。
Bless, et al. Informational [Page 11] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[11ページ]のRFC3662は努力PDB2003年12月に下ろします。
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のためのシミュレーションの結果は図4に表現されます。 A1-A5、オーバーロードのため流れによって引き起こされて、パケットはすべての場合で落とされます。 大量の流れのB1とB2は場合B)でそれらの最大のスループットをほとんど得ます。 C1) B1とB2からのすべてのパケットが落とされるといけなくて、人が予想するだろうケースC2、)、C4) 大量のデータのリソース消費は10%の構成されたシェアに制限されます。 再びC3でのWRED実現) WFQ異形ほど正確でなく、IR1を通して以上が交通パスであることをさせます。
+-------------------------+--------+-----------------------------------+ | | | 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 | +----------------+--------+--------+------+------+------+------+-------+
+-------------------------+--------+-----------------------------------+ | | | PDBとの転送を膨らませてください: | | QoSパラメタ| a) | B) | C) 下側の努力| | |大量がありません。| 最善| 1) 2) 3) 4) | | 流れ|転送|努力| PQ| WFQ| WRED|赤とWFQ| +----------------+--------+--------+------+------+------+------+-------+ | | A1| 303 | 136 | 241 | 298 | 244 | 276 | | | A2| 316 | 234 | 286 | 299 | 240 | 219 | | | A3| 251 | 140 | 287 | 259 | 236 | 225 | | スループット| 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 | +----------------+--------+--------+------+------+------+------+-------+ |総スループット| 標準| 1199 | 676 | 1199 | 1079 | 1096 | 1079 | | [kbit/s]| 大量| - | 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の損失| 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 | +----------------+--------+--------+------+------+------+------+-------+ | 総パケット| 標準| 10.4 | 17.3 | 10.3 | 12.2 | 8.2 | 13.4 | | 損失率[%]| 大量| - | 12.4 | 100 | 29.1 | 39.0 | 29.9 | +----------------+--------+--------+------+------+------+------+-------+ | 伝えられます。| | | | | | | | | データ[MByte]| 標準| 22.0 | 12.6 | 22.0 | 20.2 | 20.6 | 20.3 | +----------------+--------+--------+------+------+------+------+-------+
Figure 4: Situation III - Best Effort traffic load is 150%
図4: 状況III--最も良いEffortトラヒック負荷は150%です。
Bless, et al. Informational [Page 12] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[12ページ]のRFC3662は努力PDB2003年12月に下ろします。
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%か400kbit/sがAx流れによって使用されません、そして、結果は図5に記載されています。 大量のデータフローのB1とB2がBE PDBを使用する場合B)では、Ax流れのパケットは落とされますが、ケースC1) -C4) 流れでは、Axは大量の流れのB1とB2から保護されます。 後者は、したがって、使用することによって、BxのためのLE PDBが流れて、400kbit/sの残りの帯域幅だけを得ますが、さらに得るというわけではありません。 Ax流れのパケットはこれらの場合における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 | +----------------+--------+--------+------+------+------+------+-------+
+-------------------------+--------+-----------------------------------+ | | | PDBとの転送を膨らませてください: | | QoSパラメタ| a) | B) | C) 下側の努力| | |大量がありません。| 最善| 1) 2) 3) 4) | | 流れ|転送|努力| PQ| WFQ| WRED|赤とWFQ| +----------------+--------+--------+------+------+------+------+-------+ | | A1| 160 | 140 | 160 | 160 | 160 | 160 | | | A2| 160 | 124 | 160 | 160 | 160 | 160 | | | A3| 160 | 112 | 160 | 160 | 160 | 160 | | スループット| 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 | +----------------+--------+--------+------+------+------+------+-------+ |総スループット| 標準| 798 | 648 | 798 | 798 | 797 | 798 | | [kbit/s]| 大量| - | 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の損失| 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 | +----------------+--------+--------+------+------+------+------+-------+ | 総パケット| 標準| 0 | 10.2 | 0 | 0 | 0 | 0 | | 損失率[%]| 大量| - | 8.0 | 21.0 | 21.7 | 25.0 | 21.2 | +----------------+--------+--------+------+------+------+------+-------+ | 伝えられます。| | | | | | | | | データ[MByte]| 標準| 14.8 | 12.1 | 14.8 | 14.8 | 14.7 | 14.7 | +----------------+--------+--------+------+------+------+------+-------+
Figure 5: Situation IV - Best Effort traffic load is 67%
図5: 状況IV--最も良いEffortトラヒック負荷は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.
概要では、すべての異なったシナリオが、「標準」がLE PDBの交通から交通を有効に保護できるということであることを示します。 どんなパケットもどんな残りの帯域幅も左(LE交通は飢えている)でなくて、またまたはLE PDBの交通でもないなら通り抜けないどちらかがリソースを構成可能な限界まで消費できるだけです。
Bless, et al. Informational [Page 13] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[13ページ]のRFC3662は努力PDB2003年12月に下ろします。
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.
その上、結果は中の交通(例えば、状況IとIIにおける14.9%のパケット損失、状況IVにおける10.2%さえ)がLE PDBを使用することのない状況であったなら「正常な」状態で転送が悪影響を与えることができるそのマスデータを実体化します。
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が保護の望まれた行動を満たすとわかる異形がすべて提示される間の交通になってください、とまた、それらには小さい差異が詳細にあります。 ネットワーク・オペレータには、望まれた行動(LEの効力の証拠の後の表示--この付録の2番目の名称)に合う実現方法を選ぶ機会があります。 例えば、オペレータが完全に混雑の時代にLE交通を飢えさせたいなら、彼らはPQを選ぶかもしれません。 これで、LE交通を完全に飢えさせます、そして、1つのパケットも全荷重かオーバーロードの場合に通らないでしょう。
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のいくらかの少量のスループットを可能にしたがっているネットワーク・オペレータにとって、他の異形の1つは、より良い選択でしょう。
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に閉じ込めることであるときに。
Bless, et al. Informational [Page 14] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[14ページ]のRFC3662は努力PDB2003年12月に下ろします。
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.Carpenter、「彼らのSpecificationのためのDifferentiated Services Per Domain BehaviorsとRulesの定義」RFC3086(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分野)の定義」RFC2474(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.ウィス、「微分されたサービスのための構造」、RFC2475、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は分類する」RFC2597、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.ジェーコブソン、「リンク共有と資源管理はパケット網のためにモデル化します」、Networkingの上のIEEE/ACM Transactions、Vol.3、No.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]が祝福する、9月1999、「ベストエフォート型であるより低い1ホップあたり1つの振舞い」というR.とK.ウェールレは進行中で働いています。
[LE] Bless, R. and K. Wehrle, "A Limited Effort Per-Hop
Behavior", Work in Progress, February 2001.
[LE]が祝福する、2月2001、「1ホップあたり1つの株式会社努力の振舞い」というR.とK.ウェールレは進行中で働いています。
[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.
Communication Networks And Distributed Systems Modeling And Simulationコンファレンス(CNDS2001)、フェニックス(アリゾナ)(米国)のページのProceedingsの[SimKIDS]ウェールレとK.とリーバーとJ.とV.Kahmann、「Serviceの振舞いの任意のQualityを統合する能力があるインターネット接続装置のためのシミュレーションスイート」 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]が祝福する、R.とK.ウェールレ、「インターネットQoS」、ブリスベーン(オーストラリア)のIEEEの国際WorkshopのProceedingsの「微分されたサービスネットワークでコミュニケーションを分類してください」、IEEE Press、ページ 618-625と、2001年5月。
Bless, et al. Informational [Page 15] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[15ページ]のRFC3662は努力PDB2003年12月に下ろします。
Authors' Addresses
作者のアドレス
Roland Bless Institute of Telematics, Universitaet Karlsruhe (TH) Zirkel 2 76128 Karlsruhe Germany
ローランドはテレマティックスの研究所、Universitaetカールスルーエ(TH)ツィルケル2 76128カールスルーエドイツを祝福します。
EMail: bless@tm.uka.de URI: http://www.tm.uka.de/~bless/
メール: bless@tm.uka.de ユリ: http://www.tm.uka.de/~bless/
Kathleen Nichols 325M Sharon Park Drive #214 Menlo Park, CA 94025
メンローパーク、キャサリーンニコルズ325Mシャロン公園ドライブ#214カリフォルニア 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
TuebingenとコンピュータネットワークとMorgenstelle 10c、72076Tuebingen、ドイツと国際Computer Science Institute(ICSI)1947Center通り、バークレー、カリフォルニア 94704、Internet米国のクラウスウェールレ大学
EMail: Klaus.Wehrle@uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/~wehrle/
メール: Klaus.Wehrle@uni-tuebingen.de ユリ: http://net.informatik.uni-tuebingen.de/~wehrle/
Bless, et al. Informational [Page 16] RFC 3662 Lower Effort PDB December 2003
祝福、他 情報[16ページ]のRFC3662は努力PDB2003年12月に下ろします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Bless, et al. Informational [Page 17]
祝福、他 情報[17ページ]
一覧
スポンサーリンク
