Network Working Group V. Jacobson
Request for Comments: 2598 K. Nichols
Category: Standards Track Cisco Systems
K. Poduri
Bay Networks
June 1999
An Expedited Forwarding PHB
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. We show the generality of this PHB by noting that it can be produced by more than one mechanism and give an example of its use to produce at least one service, a Virtual Leased Line. A recommended codepoint for this PHB is given.
PHB（ホップごとの転送動作）の定義は、Diffservのワーキンググループの仕事の重要な部分です。この文書では、緊急転送と呼ばれるPHBを説明しています。我々は、それが複数のメカニズムによって生成され、少なくとも1つのサービス、仮想専用線を生成するために、その使用例を与えることができることに注目することで、このPHBの一般性を示しています。このPHBのための推奨コードポイントが与えられます。
A pdf version of this document is available at ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf
この文書のPDF版はftp://ftp.ee.lbl.gov/papers/ef_phb.pdfで入手可能です
Network nodes that implement the differentiated services enhancements to IP use a codepoint in the IP header to select a per-hop behavior (PHB) as the specific forwarding treatment for that packet [RFC2474, RFC2475]. This memo describes a particular PHB called expedited forwarding (EF). The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through DS domains. Such a service appears to the endpoints like a point-to-point connection or a "virtual leased line". This service has also been described as Premium service [2BIT].
IPへの差別化サービスの強化を実現するネットワーク・ノードは、そのパケット[RFC2474、RFC2475]のための特定の転送処理としてホップ単位動作（PHB）を選択するためにIPヘッダーでコードポイントを使用します。このメモは優先転送（EF）と呼ばれる特定のPHBを説明しています。 EF PHBは、DSドメインを通じ、低損失、低遅延、低ジッタ、保証帯域幅、エンドツーエンドのサービスを構築するために使用することができます。このようなサービスは、ポイントツーポイント接続または「仮想専用線」のようなエンドポイントに表示されます。また、このサービスは、プレミアムサービス[2BIT]として記載されています。
Loss, latency and jitter are all due to the queues traffic experiences while transiting the network. Therefore providing low loss, latency and jitter for some traffic aggregate means ensuring that the aggregate sees no (or very small) queues. Queues arise when (short-term) traffic arrival rate exceeds departure rate at some node. Thus a service that ensures no queues for some aggregate is equivalent to bounding rates such that, at every transit node, the aggregate's maximum arrival rate is less than that aggregate's minimum departure rate.
ネットワークを通過しながら、ロス、遅延とジッタは、すべてのキューのトラフィックの経験によるものです。したがって、一部のトラフィックの集計のために、低損失、遅延とジッタを提供する集合体は全く（または非常に小さい）のキューを見ないことを確実にすることを意味します。 （短期）トラフィックの到着レートは、いくつかのノードで出発速度を超えた場合、キューが生じます。したがって、いくつかの集計のために何のキューを確保していないサービスは、すべてのトランジットノードで、集約の最大到達率は、その集約の最小出発率よりも小さくなるように、という境界率に相当します。
Creating such a service has two parts:
そのようなサービスを作成するには、2つの部分があります。
1) Configuring nodes so that the aggregate has a well-defined minimum departure rate. ("Well-defined" means independent of the dynamic state of the node. In particular, independent of the intensity of other traffic at the node.)
集合体は、明確に定義された最小出発率を有するように1）ノードの構成。 （「明確に定義された」は、ノードの動的状態の独立を意味する。具体的には、ノードにおける他のトラフィックの強度とは無関係）。
2) Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate.
2）コンディショニングポリシング及びシェーピングを介して集計（）任意のノードにおけるその到着レートは、常に、そのノードの構成最小出発レートよりも小さくなるように。
The EF PHB provides the first part of the service. The network boundary traffic conditioners described in [RFC2475] provide the second part.
EF PHBは、サービスの最初の部分を提供します。 [RFC2475]に記載されたネットワーク境界トラフィックコンディショナーは、第二の部分を提供します。
The EF PHB is not a mandatory part of the Differentiated Services architecture, i.e., a node is not required to implement the EF PHB in order to be considered DS-compliant. However, when a DS-compliant node claims to implement the EF PHB, the implementation must conform to the specification given in this document.
EF PHBは、差別化サービスアーキテクチャの必須部分ではない、すなわち、ノードは、DS準拠と見なされるためにEFのPHBを実装するために必要とされません。 DS準拠のノードは、EFのPHBを実装すると主張しかし、実装は、この文書で与えられた仕様に準拠する必要があります。
The next sections describe the EF PHB in detail and give examples of how it might be implemented. The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97].
次のセクションでは、詳細にEF PHBを記述し、それが実装されるかもしれない方法の例を与えます。キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHOULD"、 "SHOULD NOT"、および[Bradner97]で説明したように解釈されるべきであり、この文書に表示される "MAY"。
The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate. (Behavior at time scales shorter than a packet time at the configured rate is deliberately not specified.) The configured minimum rate MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration).
EF PHBは、任意のDiffServノードから集約のパケットの出発速度が設定速度に等しいかまたは超えなければならない特定のdiffserv集合の転送処理として定義されます。 EFトラフィックが通過するノードを試みる他のトラフィックの強度とは無関係に、この速度を受けるべきです。等しいか、またはそれが設定されたレートで出力リンクMTUサイズのパケットを送信するのに要する時間よりも長い任意の時間間隔で測定したとき、少なくとも設定されたレートを平均すべきです。 （時の動作は意図的に指定されていない設定したレートでパケット時間よりも短いスケール。）設定された最小レートは、（ノードは、不揮発性コンフィギュレーションのためのサポート何らかのメカニズムを使用して）ネットワーク管理者によって設定可能でなければなりません。
If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). Traffic that exceeds this limit MUST be discarded. This maximum EF rate, and burst size if appropriate, MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration). The minimum and maximum rates may be the same and configured by a single parameter.
EF PHBは、他のトラフィック（例えば、プライオリティキュー）の無制限のプリエンプションを可能にするメカニズムによって実装されている場合、実装は、他のトラフィックに与える可能性が損傷EFトラフィックを制限するためにいくつかの手段を含まなければならない（例えば、トークンバケットレートリミッタ） 。この制限を超えるトラフィックは捨てなければなりません。この最大EFレート、バーストサイズ適切な場合には、（ノードは、不揮発性コンフィギュレーションのためのサポート何らかのメカニズムを使用して）ネットワーク管理者によって設定可能でなければなりません。最小および最大速度が同じと単一のパラメータによって構成されてもよいです。
The Appendix describes how this PHB can be used to construct end-to-end services.
付録には、このPHBは、エンドツーエンドのサービスを構築するために使用することができる方法を説明します。
Several types of queue scheduling mechanisms may be employed to deliver the forwarding behavior described in section 2.1 and thus implement the EF PHB. A simple priority queue will give the appropriate behavior as long as there is no higher priority queue that could preempt the EF for more than a packet time at the configured rate. (This could be accomplished by having a rate policer such as a token bucket associated with each priority queue to bound how much the queue can starve other traffic.)
キュースケジューリングメカニズムのいくつかのタイプは、セクション2.1で説明した転送動作を提供し、従ってEF PHBを実装するために使用することができます。シンプルなプライオリティキューは、限り、設定されたレートでパケット時間以上EFを先取りできていない優先度の高いキューがあるように、適切な動作が得られます。 （これは、キューが他のトラフィックを飢えさせることができるどのくらいのバウンドに各優先度キューに関連付けられたトークンバケットとしてレートポリサーを有することによって達成することができます。）
It's also possible to use a single queue in a group of queues serviced by a weighted round robin scheduler where the share of the output bandwidth assigned to the EF queue is equal to the configured rate. This could be implemented, for example, using one PHB of a Class Selector Compliant set of PHBs [RFC2474].
これは、EFキューに割り当てられた出力帯域幅のシェアが設定されたレートに等しい重み付けラウンドロビンスケジューラによってサービスのキューグループ内の1つのキューを使用することも可能です。これは、のPHB [RFC2474]のクラスセレクタ適合セットの1つのPHBを用いて、例えば、実装することができます。
Another possible implementation is a CBQ [CBQ] scheduler that gives the EF queue priority up to the configured rate.
もう一つの可能な実装は、設定されたレートにEFキューの優先順位アップを与えるCBQ [CBQ]スケジューラです。
All of these mechanisms have the basic properties required for the EF PHB though different choices result in different ancillary behavior such as jitter seen by individual microflows. See Appendix A.3 for simulations that quantify some of these differences.
これらのメカニズムのすべてが異なる選択肢が、このような個々のmicroflowsから見ジッタなど、さまざまな補助的な行動につながるもののEFのPHBのために必要な基本的な性質を持っています。これらの違いのいくつかを定量化のシミュレーションについては、付録A.3を参照してください。
Codepoint 101110 is recommended for the EF PHB.
コードポイント101110は、EF PHBのために推奨されます。
Packets marked for EF PHB MAY be remarked at a DS domain boundary only to other codepoints that satisfy the EF PHB. Packets marked for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain.
EF PHBのためにマークされたパケットは、唯一のEF PHBを満たす他のコードポイントにDSドメイン境界で述べられるかもしれません。 EFのPHBのためにマークされたパケットは、降格またはDSドメインで別のPHBに昇格されるべきではありません。
When EF packets are tunneled, the tunneling packets must be marked as EF.
EFパケットがトンネリングされている場合、トンネリングパケットはEFとしてマークする必要があります。
Other PHBs and PHB groups may be deployed in the same DS node or domain with the EF PHB as long as the requirement of section 2.1 is met.
他のPHBおよびPHBグループは限りセクション2.1の要件が満たされるようにEF PHBと同じDSノードまたはドメインに配備されてもよいです。
To protect itself against denial of service attacks, the edge of a DS domain MUST strictly police all EF marked packets to a rate negotiated with the adjacent upstream domain. (This rate must be <= the EF PHB configured rate.) Packets in excess of the negotiated rate MUST be dropped. If two adjacent domains have not negotiated an EF rate, the downstream domain MUST use 0 as the rate (i.e., drop all EF marked packets).
サービス拒否攻撃から自身を保護するために、DSドメインのエッジは、厳密に警察のすべてのEFは、隣接する上流のドメインと交渉レートにパケットをマークしなければなりません。ネゴシエートされたレートを超える（このレートは、<= EF PHB構成率でなければならない。）パケットは廃棄されなければなりません。隣接する二つのドメインがEF率を交渉していない場合、下流のドメインがレート（すなわち、すべてのEFマーキングされたパケットをドロップ）として0を使用しなければなりません。
Since the end-to-end premium service constructed from the EF PHB requires that the upstream domain police and shape EF marked traffic to meet the rate negotiated with the downstream domain, the downstream domain's policer should never have to drop packets. Thus these drops SHOULD be noted (e.g., via SNMP traps) as possible security violations or serious misconfiguration. Similarly, since the aggregate EF traffic rate is constrained at every interior node, the EF queue should never overflow so if it does the drops SHOULD be noted as possible attacks or serious misconfiguration.
EF PHBから構築されたエンドツーエンドのプレミアムサービスは、上流のドメイン警察や形状EFは、下流のドメインと交渉率を満たすために、トラフィックをマークすることを必要とするので、下流のドメインのポリサーは、パケットを廃棄する必要はありません。したがって、これらの液滴は、可能なセキュリティ違反または重大な設定ミスなど（SNMPトラップを介して、例えば）に留意すべきです。集約EFトラフィックレートは、すべての内部ノードで拘束されているので、それがないので、もし同様に、EFキューがオーバーフロードロップは可能な攻撃や深刻な設定ミスとして注目されるべきではないん。
This document allocates one codepoint, 101110, in Pool 1 of the code space defined by [RFC2474].
このドキュメントは[RFC2474]で定義されたコード空間のプール1において、1つのコードポイント、101110を割り当てます。
[Bradner97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブラック、D.、ブレイク、S.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", Work in Progress, ftp://ftp.ee.lbl.gov/papers/dsarch.pdf
[2BIT] K.ニコルズ、V. Jacobson氏、およびL.チャン、「インターネットのための2ビットの差別化サービスアーキテクチャ」が進行中で働いて、ftp://ftp.ee.lbl.gov/papers/dsarch.pdf
[CBQ] S. Floyd 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月。
[RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2415] Poduri、K.とK.ニコルズ、 "増加した初期のTCPウィンドウサイズのシミュレーション研究"、RFC 2415、1998年9月。
[LCN] K. Nichols, "Improving Network Simulation with Feedback", Proceedings of LCN '98, October 1998.
[LCN] K.ニコルズ、 "フィードバックによるネットワークシミュレーションの改善"、LCN '98、1998年10月の議事。
Van Jacobson Cisco Systems, Inc 170 W. Tasman Drive San Jose, CA 95134-1706
ヴァンヤコブソンシスコシステムズ社170 W.タスマン・ドライブサンノゼ、CA 95134-1706
EMail: van@cisco.com
メールアドレス：van@cisco.com
Kathleen Nichols Cisco Systems, Inc 170 W. Tasman Drive San Jose, CA 95134-1706
キャスリーン・ニコルズシスコシステムズ社170 W.タスマン・ドライブサンノゼ、CA 95134-1706
EMail: kmn@cisco.com
メールアドレス：kmn@cisco.com
Kedarnath Poduri Bay Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95052-8185
Kedarnath橋ベイネットワーク株式会社4401グレートアメリカパークウェイサンタクララ、カリフォルニア州95052から8185
EMail: kpoduri@baynetworks.com
メールアドレス：kpoduri@baynetworks.com
Appendix A: Example use of and experiences with the EF PHB
付録A：EFのPHBと例の使用や経験
A.1 Virtual Leased Line Service
A.1仮想専用線サービス
A VLL Service, also known as Premium service [2BIT], is quantified by a peak bandwidth.
また、プレミアムサービス[2BIT]として知らVLLサービスは、ピーク帯域幅によって定量化されます。
A.2 Experiences with its use in ESNET
ESNETでの使用とA.2経験
A prototype of the VLL service has been deployed on DOE's ESNet backbone. This uses weighted-round-robin queuing features of Cisco 75xx series routers to implement the EF PHB. The early tests have been very successful and work is in progress to make the service available on a routine production basis (see ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdf and ftp://ftp.ee.lbl.gov/talks/vj-i2qos-may98.pdf for details).
VLLサービスのプロトタイプは、DOEのESNetバックボーン上に展開されています。これは、EF PHBを実装するには、Cisco 75xxシリーズルータのキューイング機能加重ラウンドロビンを使用しています。 // FTP：初期のテストは非常に成功しているとの仕事はルーチン生産ベースでサービスを利用できるように進行中である（ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdfとftpを参照してください。詳細については、ee.lbl.gov/talks/vj-i2qos-may98.pdf）。
A.3 Simulation Results
A.3のシミュレーション結果
A.3.1 Jitter variation
A.3.1ジッタ変動
In section 2.2, we pointed out that a number of mechanisms might be used to implement the EF PHB. The simplest of these is a priority queue (PQ) where the arrival rate of the queue is strictly less than its service rate. As jitter comes from the queuing delay along the path, a feature of this implementation is that EF-marked microflows will see very little jitter at their subscribed rate since packets spend little time in queues. The EF PHB does not have an explicit jitter requirement but it is clear from the definition that the expected jitter in a packet stream that uses a service based on the EF PHB will be less with PQ than with best-effort delivery. We used simulation to explore how weighted round-robin (WRR) compares to PQ in jitter. We chose these two since they"re the best and worst cases, respectively, for jitter and we wanted to supply rough guidelines for EF implementers choosing to use WRR or similar mechanisms.
セクション2.2では、我々は、機構の数は、EFのPHBを実装するために使用されるかもしれないことを指摘しました。これらの最も単純なものは、キューの到着率は、そのサービス率よりも厳密に小さいプライオリティキュー（PQ）です。ジッタは、パスに沿ってキューイング遅延から来ているように、この実装の機能は、パケットがキューに少しの時間を過ごすため、EF-マークマイクロフローは、彼らの加入率で非常に少ないジッタを参照してくださいということです。 EF PHBは、明示的なジッタ要件はありませんが、EF PHBに基づいてサービスを利用するパケットストリームで予想されるジッタはベストエフォート型の配信よりもPQと少なくなることを定義から明らかです。私たちは、ラウンドロビン（WRR）は、ジッタにPQと比較する方法加重探求するシミュレーションを使用していました。彼らは「それぞれ、最高と最悪のケースを再以来、私たちは、ジッタのために、これらの2を選んだと私たちはWRRまたは類似のメカニズムを使用することを選択EFの実装のためのラフなガイドラインを提供したかったです。
Our simulation model is implemented in a modified ns-2 described in [RFC2415] and [LCN]. We used the CBQ modules included with ns-2 as a basis to implement priority queuing and WRR. Our topology has six hops with decreasing bandwidth in the direction of a single 1.5 Mbps bottleneck link (see figure 6). Sources produce EF-marked packets at an average bit rate equal to their subscribed packet rate. Packets are produced with a variation of +-10% from the interpacket spacing at the subscribed packet rate. The individual source rates were picked aggregate to 30% of the bottleneck link or 450 Kbps. A mixture of FTPs and HTTPs is then used to fill the link. Individual EF packet sources produce either all 160 byte packets or all 1500 byte packets.
我々のシミュレーションモデルは、修飾されたNS-2 [RFC2415]と[LCN]に記載に実装されています。我々は、NS-2プライオリティキューイングとWRRを実装するための基礎として用いて付属CBQモジュールを使用します。私たちのトポロジは、単一の1.5 Mbpsのボトルネックリンクの方向に帯域幅の減少に伴って6つのホップを持っている（図6を参照してください）。ソースは、その加入パケットレートに等しい平均ビットレートでEF-マーキングされたパケットを生成します。パケットは、加入パケットレートでパケット間間隔から+ -10％の変化を用いて製造されます。個々のソース・レートは、ボトルネックリンクの30％または450 kbpsに集計を採取しました。 FTPSおよびHTTPSでは、混合物は、その後、リンクを埋めるために使用されます。個々のEFパケットソースはすべて160のバイトのパケットまたはすべての1500のバイトのパケットのいずれかを生成します。
Though we present the statistics of flows with one size of packet, all of the experiments used a mixture of short and long packet EF sources so the EF queues had a mix of both packet lengths.
私たちは、パケットの1つのサイズとフローの統計情報を提示するもののEFキューは両方のパケット長のミックスを持っていたので、すべての実験は、短期および長期のパケットEF源の混合物を使用しました。
We defined jitter as the absolute value of the difference between the arrival times of two adjacent packets minus their departure times, |(aj-dj) - (ai-di)|. For the target flow of each experiment, we record the median and 90th percentile values of jitter (expressed as % of the subscribed EF rate) in a table. The pdf version of this document contains graphs of the jitter percentiles.
| - （AI-DI）（AJ-DJ）|我々は、2つの隣接するパケットマイナスそれらの出発時刻、到着時間の差の絶対値として、ジッタを定義しました。各実験の目標流量のため、我々は、テーブルのジッタ（加入EF率の％として表される）の中央値及び90パーセンタイルの値を記録します。この文書のPDF版は、ジッタパーセンタイルのグラフが含まれています。
Our experiments compared the jitter of WRR and PQ implementations of the EF PHB. We assessed the effect of different choices of WRR queue weight and number of queues on jitter. For WRR, we define the service-to-arrival rate ratio as the service rate of the EF queue (or the queue"s minimum share of the output link) times the output link bandwidth divided by the peak arrival rate of EF-marked packets at the queue. Results will not be stable if the WRR weight is chosen to exactly balance arrival and departure rates thus we used a minimum service-to-arrival ratio of 1.03. In our simulations this means that the EF queue gets at least 31% of the output links. In WRR simulations we kept the link full with other traffic as described above, splitting the non-EF-marked traffic among the non-EF queues. (It should be clear from the experiment description that we are attempting to induce worst-case jitter and do not expect these settings or traffic to represent a "normal" operating point.)
我々の実験は、EF PHBのWRRとPQ実装のジッタを比較しました。私たちは、WRRキューの重みとジッタのキューの数の異なる選択肢の効果を評価しました。 WRRのために、我々はEFキューのサービスレートなどのサービス・ツー・到着率の比（またはキュー「sの出力リンクの最小株）回EF-マークされたパケットのピーク到着率で割った出力リンクの帯域幅を定義しますWRR重量は正確に我々は1.03の最小サービスへの到着率を使用ので、到着と出発率のバランスをとるように選択される場合は、キューに。結果が安定しません。私たちのシミュレーションでは、これは、EFキューは、少なくとも31％を取得することを意味します前述したように、出力リンクから。WRRシミュレーションでは、非EFキューの中で非EF-マークされたトラフィックを分割、他のトラフィックとの完全なリンクを保った。（それは私たちが誘導しようとしている実験の説明から明らかです最悪の場合のジッタと、これらの設定やトラフィックが「正常な」動作点を表すことを期待しないでください。）
Our first set of experiments uses the minimal service-to-arrival ratio of 1.06 and we vary the number of individual microflows composing the EF aggregate from 2 to 36. We compare these to a PQ implementation with 24 flows. First, we examine a microflow at a subscribed rate of 56 Kbps sending 1500 byte packets, then one at the same rate but sending 160 byte packets. Table 1 shows the 50th and 90th percentile jitter in percent of a packet time at the subscribed rate. Figure 1 plots the 1500 byte flows and figure 2 the 160 byte flows. Note that a packet-time for a 1500 byte packet at 56 Kbps is 214 ms, for a 160 byte packet 23 ms. The jitter for the large packets rarely exceeds half a subscribed rate packet-time, though most jitters for the small packets are at least one subscribed rate packet-time. Keep in mind that the EF aggregate is a mixture of small and large packets in all cases so short packets can wait for long packets in the EF queue. PQ gives a very low jitter.
実験の私たちの最初のセットは、1.06の最小限のサービスへの到着率を使用し、我々は24個のフローとPQの実装にこれらを比較する2から36にEF集合体を構成する個々のマイクロフローの数を変えます。まず、我々は同じ速度で、その後1を1500個のバイトのパケットを、送信が、160個のバイトのパケットを送信する56 Kbpsのの加入率でマイクロフローを調べます。表1は、サブスクライブレートでパケット時間のパーセントで50及び90パーセンタイルのジッタを示しています。図1のプロット1500のバイトフローと図2 160のバイト流れます。 56 Kbpsで1500バイトのパケットのパケット時間は160バイトのパケットを23ミリ秒、214ミリ秒であることに留意されたいです。小さなパケットのための最もジッタが少なくとも一つの加入率、パケット時間あるものの大きなパケットジッタはほとんど、半分のサブスクライブレート・パケット時間を超えません。 EFの集計が非常に短いパケットがEFキューに長いパケットを待つことができ、すべての場合に小規模および大規模パケットの混合物であることを覚えておいてください。 PQは非常に低いジッタを提供します。
Table 1: Variation in jitter with number of EF flows: Service/arrival ratio of 1.06 and subscription rate of 56 Kbps (all values given as % of subscribed rate)
表1：EFの数とジッタの変化はフロー：1.06のサービス/到達率と56 Kbpsの（加入率の％として与えられたすべての値）の加入率
1500 byte pack. 160 byte packet
# EF flows 50th % 90th % 50th % 90th %
PQ (24) 1 5 17 43
2 11 47 96 513
4 12 35 100 278
8 10 25 96 126
24 18 47 96 143
Next we look at the effects of increasing the service-to-arrival ratio. This means that EF packets should remain enqueued for less time though the bandwidth available to the other queues remains the same. In this set of experiments the number of flows in the EF aggregate was fixed at eight and the total number of queues at five (four non-EF queues). Table 2 shows the results for 1500 and 160 byte flows. Figures 3 plots the 1500 byte results and figure 4 the 160 byte results. Performance gains leveled off at service-to-arrival ratios of 1.5. Note that the higher service-to-arrival ratios do not give the same performance as PQ, but now 90% of packets experience less than a subscribed packet-time of jitter even for the small packets.
次は、サービスへの到着率を高める効果を見てください。これは、他のキューに利用可能な帯域幅が同じままもののEFパケットが短い時間のためにキューに入れたままにする必要があることを意味します。この一連の実験ではEF集合におけるフローの数は8で固定し、5（4つの非EFキュー）に待ち行列の総数。表2は、1500と160バイトの流れの結果を示します。 3プロット1500のバイト結果と図4 160のバイトの結果を図。パフォーマンスの向上は1.5のサービス・ツー・到着比で横ばい。高いサービス・ツー・到着比はPQと同じ性能が得られないことに注意してください、しかし、パケットの今90％は小さくても、パケットのためのジッタの加入パケット時間未満体験。
Table 2: Variation in Jitter of EF flows: service/arrival ratio varies, 8 flow aggregate, 56 Kbps subscribed rate
表2：EFのジッタの変動フロー：サービス/到着比が変化し、8流凝集、56 Kbpsの加入率
WRR 1500 byte pack. 160 byte packet
Ser/Arr 50th % 90th % 50th % 90th %
PQ 1 3 17 43
1.03 14 27 100 178
1.30 7 21 65 113
1.50 5 13 57 104
1.70 5 13 57 100
2.00 5 13 57 104
3.00 5 13 57 100
Increasing the number of queues at the output interfaces can lead to more variability in the service time for EF packets so we carried out an experiment varying the number of queues at each output port. We fixed the number of flows in the aggregate to eight and used the minimal 1.03 service-to-arrival ratio. Results are shown in figure 5 and table 3. Figure 5 includes PQ with 8 flows as a baseline.
私たちは、各出力ポートのキューの数を変化させる実験を行ったので、出力インターフェイスでキューの数を増やすと、EFパケットのサービス時間でより多くの変動につながることができます。我々は8個に集約におけるフローの数を固定し、最小1.03サービスへの到着率を用います。結果を図5に示し、表3図5は、ベースラインとして8つのフローにPQを含みます。
Table 3: Variation in Jitter with Number of Queues at Output Interface: Service-to-arrival ratio is 1.03, 8 flow aggregate
表3：出力インタフェースにおけるキューの数とジッタの変化：サービス・ツー・到着比は1.03であり、8流集計
# EF 1500 byte packet
flows 50th % 90th %
PQ (8) 1 3
2 7 21
4 7 21
6 8 22
8 10 23
It appears that most jitter for WRR is low and can be reduced by a proper choice of the EF queue's WRR share of the output link with respect to its subscribed rate. As noted, WRR is a worst case while PQ is the best case. Other possibilities include WFQ or CBQ with a fixed rate limit for the EF queue but giving it priority over other queues. We expect the latter to have performance nearly identical with PQ though future simulations are needed to verify this. We have not yet systematically explored effects of hop count, EF allocations other than 30% of the link bandwidth, or more complex topologies. The information in this section is not part of the EF PHB definition but provided simply as background to guide implementers.
WRRのための最もジッタが低いことが表示され、その加入率に対する出力リンクのEFキューのWRRシェアの適切な選択によって減少させることができます。指摘したようにPQが最良のケースである一方で、WRRは、最悪のケースです。他の可能性はEFキューの固定金利の上限とWFQやCBQを含むが、他のキューの上にそれを優先して。私たちは、将来のシミュレーションはこれを確認するために必要とされるものの、後者はPQとほぼ同じ性能を持つことを期待しています。私たちは、まだ体系的ホップ数、リンク帯域幅の30％以外のEFの割り当て、またはより複雑なトポロジーの影響を調査していません。このセクションの情報は、EFのPHB定義の一部ではなく、単に実装を案内する背景として提供します。
A.3.2 VLL service
A.3.2 VLLサービス
We used simulation to see how well a VLL service built from the EF PHB behaved, that is, does it look like a `leased line' at the subscribed rate. In the simulations of the last section, none of the EF packets were dropped in the network and the target rate was always achieved for those CBR sources. However, we wanted to see if VLL really looks like a `wire' to a TCP using it. So we simulated long-lived FTPs using a VLL service. Table 4 gives the percentage of each link allocated to EF traffic (bandwidths are lower on the links with fewer EF microflows), the subscribed VLL rate, the average rate for the same type of sender-receiver pair connected by a full duplex dedicated link at the subscribed rate and the average of the VLL flows for each simulation (all sender-receiver pairs had the same value). Losses only occur when the input shaping buffer overflows but not in the network. The target rate is not achieved due to the well-known TCP behavior.
私たちは、つまり、それは加入率で `専用線」のように見えるん、EF PHBから構築されたVLLサービスは行儀どれだけ見るためにシミュレーションを使用していました。最後のセクションのシミュレーションでは、EFパケットはいずれもネットワークに落ちなかったし、目標レートは常にそれらのCBRソースのために達成されました。しかし、私たちはVLLは実際にそれを使用してTCPに `ワイヤー」のように見えるかどうかを確認したかったです。だから我々はVLLサービスを利用して長寿命FTPの命名規則をシミュレートしました。表4は、EFトラフィックに割り当てられた各リンクのパーセンテージを与える、加入VLLレートでリンクを専用の全二重で接続された送信者の受信機ペアの同じタイプの平均速度（帯域幅が少なくEFのマイクロフローとのリンクに低いです）加入率とVLLの平均（すべての送信者 - 受信機対が同じ値を持っていた）各シミュレーションに流れます。入力がなく、ネットワーク内のバッファオーバーフローを整形する際に損失が発生するだけ。ターゲット速度は、よく知られているTCPの挙動に達成されません。
Table 4: Performance of FTPs using a VLL service
表4：VLLサービスを使用してFTPの命名規則のパフォーマンス
% link Average delivered rate (Kbps) to EF Subscribed Dedicated VLL 20 100 90 90 40 150 143 143 60 225 213 215
EF購読％のリンクの平均送達レート（Kbpsの）は、専用VLL 20 100 90 90 40 150 143 143 60 225 213 215
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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 assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。