[要約] RFC 2598は、Expedited Forwarding PHB（Per-Hop Behavior）に関する要約であり、高優先度のトラフィックを効率的に転送するためのガイドラインを提供しています。このRFCの目的は、ネットワーク上でのリアルタイムアプリケーションや音声通信などの遅延に敏感なトラフィックの品質を向上させることです。
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
迅速な転送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.
Copyright（c）The Internet Society（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ワーキンググループの作業の重要な部分です。このドキュメントでは、Expedited Forwardingと呼ばれるPHBについて説明しています。このPHBの一般性は、複数のメカニズムによって生成できることに注意し、少なくとも1つのサービスである仮想リースラインを生成するための使用の例を示します。この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に差別化されたサービス強化を実装するネットワークノードIPヘッダーのコードポイントを使用して、そのパケットの特定の転送処理としてホップごとの動作（PHB）を選択します[RFC2474、RFC2475]。このメモは、Expedited Forwarding（EF）と呼ばれる特定のPHBについて説明しています。EF PHBを使用して、低損失、低遅延、低ジッター、保証された帯域幅、DSドメインを介したエンドツーエンドサービスを構築できます。このようなサービスは、ポイントツーポイント接続や「仮想リースライン」などのエンドポイントに表示されます。このサービスは、プレミアムサービス[2ビット]とも言われています。
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]で説明されているネットワーク境界トラフィックコンディショナーは、2番目の部分を提供します。
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について詳しく説明し、それがどのように実装されるかの例を示します。キーワードは、「必要はない」、「必須」、「必須」、「そうはない」、「そうではない」、およびこのドキュメントに表示される「可能性はありません」は、[bradner97]で説明されているように解釈されます。
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キューに割り当てられた出力帯域幅のシェアが設定されたレートに等しい、加重ラウンドロビンスケジューラがサービスするキューのグループで単一のキューを使用することもできます。これは、たとえば、PHB [RFC2474]のクラスセレクターに準拠したセットの1つのPHBを使用して実装できます。
Another possible implementation is a CBQ [CBQ] scheduler that gives the EF queue priority up to the configured rate.
別の可能な実装は、CBQ [CBQ]スケジューラで、EFキューの優先順位を構成レートまで提供します。
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.
これらのメカニズムにはすべて、EF PHBに必要な基本的な特性がありますが、選択肢が異なると、個々のマイクロフローで見られるジッターなど、異なる補助的な動作が生じます。これらの違いのいくつかを定量化するシミュレーションについては、付録A.3を参照してください。
Codepoint 101110 is recommended for the EF PHB.
CodePoint 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.
セクション2.1の要件が満たされている限り、他のPHBおよびPHBグループは、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構成レートでなければなりません。）ネゴシエートレートを超えるパケットを削除する必要があります。2つの隣接するドメインがEFレートをネゴシエートしていない場合、ダウンストリームドメインはレートとして0を使用する必要があります（つまり、すべてのEFマークされたパケットをドロップします）。
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から構築されたエンドツーエンドのプレミアムサービスでは、上流のドメイン警察とShape 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Black、D.、Blake、S.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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
[2ビット] K.ニコルズ、V。ジェイコブソン、および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. Floyd and V. Jacobson、「パケットネットワークのリンク共有およびリソース管理モデル」、IEEE/ACMトランザクションオンネットワーク、Vol。3いいえ。4、pp。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. Nichols、「初期TCPウィンドウサイズの増加に関するシミュレーション研究」、RFC 2415、1998年9月。
[LCN] K. Nichols, "Improving Network Simulation with Feedback", Proceedings of LCN '98, October 1998.
[LCN] K. Nichols、「フィードバックによるネットワークシミュレーションの改善」、LCN '98の議事録、1998年10月。
Van Jacobson Cisco Systems, Inc 170 W. Tasman Drive San Jose, CA 95134-1706
Van Jacobson Cisco Systems、Inc 170 W. Tasman Drive San Jose、CA 95134-1706
EMail: van@cisco.com
Kathleen Nichols Cisco Systems, Inc 170 W. Tasman Drive San Jose, CA 95134-1706
Kathleen Nichols Cisco Systems、Inc 170 W. Tasman Drive San Jose、CA 95134-1706
EMail: kmn@cisco.com
Kedarnath Poduri Bay Networks, Inc. 4401 Great America Parkway Santa Clara, CA 95052-8185
Kedarnath Poduri Bay Networks、Inc。4401 Great America Parkway Santa Clara、CA 95052-8185
EMail: kpoduri@baynetworks.com
Appendix A: Example use of and experiences with the EF PHB
付録A：EF PHBの使用と経験
A VLL Service, also known as Premium service [2BIT], is quantified by a peak bandwidth.
プレミアムサービス[2ビット]としても知られるVLLサービスは、ピーク帯域幅によって定量化されます。
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バックボーンに展開されています。これは、Cisco 75XXシリーズルーターの加重ラウンドロビンキューイング機能を使用して、EF PHBを実装します。初期のテストは非常に成功しており、日常的な生産ベースでサービスを利用できるように作業が進行中です（ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdfおよびftp：// ftpを参照してください。ee.lbl.gov/talks/vj-i2qos-may98.pdf詳細については）。
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実装者に大まかなガイドラインを提供したかったため、これら2つを選択しました。
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.
シミュレーションモデルは、[RFC2415]および[LCN]に記載されている修正されたNS-2に実装されています。NS-2に含まれるCBQモジュールを、優先キューイングとWRRを実装するための基礎として使用しました。私たちのトポロジーには、単一の1.5 Mbpsボトルネックリンクの方向に帯域幅が減少する6つのホップがあります（図6を参照）。ソースは、サブスクライブされたパケットレートに等しい平均ビットレートでEFマークされたパケットを生成します。パケットは、サブスクライブされたパケットレートでのインターパケット間隔から-10％の変動で生成されます。個々のソースレートは、ボトルネックリンクの30％または450 kbpsに集約されました。次に、FTPとHTTPの混合物を使用してリンクを埋めます。個々の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.
ジッターは、2つの隣接するパケットの到着時間の差の絶対値として、出発時間を差し引いたものとして定義しました|（aj-dj） - （ai-di）|。各実験のターゲットフローについて、テーブルにジッターの中央値と90パーセンタイル値（サブスクライブされたEFレートの％として表される）を記録します。このドキュメントの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キュー（または出力リンクのキューの最小シェア）のサービスレートとして定義します。出力リンク帯域幅をEFマークされたパケットのピーク到着率で割った帯域幅キューで。WRR重量が到着率と出発率のバランスをとるように選択された場合、結果は安定しません。出力リンクのうち。WRRシミュレーションでは、上記のように他のトラフィックでリンクをいっぱいに保ち、非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を使用し、EF凝集体を2から36に構成する個々のマイクロフローの数を変化させます。これらを24フローでPQ実装と比較します。まず、56 kbpsのサブスクライブレートでマイクロフローを調べ、1500バイトパケットを送信し、次に同じレートで160バイトパケットを送信します。表1は、サブスクライブレートでのパケット時間の割合での50パーセンタイルジッターと90パーセンタイルジッターを示しています。図1は、1500バイトのフローと図2 160バイトフローをプロットしています。56 kbpsの1500バイトパケットのパケット時間は214ミリ秒で、160バイトパケット23ミリ秒であることに注意してください。大きなパケットのジッターは、サブスクライブされたレートパケット時間の半分を超えることはめったにありませんが、小さなパケットのほとんどのジッターは少なくとも1つのサブスクライブレートパケット時間です。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
1500バイトパック。160バイトパケット＃EFフロー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
WRR 1500バイトパック。160バイトパケットSER/ARR 50th％90th％50th％90th％PQ 1 3 17 43 14 27 100 178 1.30 7 21 65 113 1.50 5 13 57 104 1.70 5 13 57 100 2.00 257 104 3.00 5 13 57 100 100 100 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
＃EF 1500バイトパケットフロー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シェアを適切に選択することで削減できるようです。前述のように、WRRは最悪の場合ですが、PQが最良のケースです。その他の可能性には、EFキューに固定されたレート制限があるWFQまたはCBQが含まれますが、他のキューよりも優先されます。これを検証するには将来のシミュレーションが必要ですが、後者のパフォーマンスはPQとほぼ同じであると予想しています。ホップカウントの効果、リンク帯域幅の30％以外のEF割り当て、またはより複雑なトポロジーの効果を体系的に調査していません。このセクションの情報は、EF PHB定義の一部ではなく、単に実装者をガイドする背景として提供されます。
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トラフィックに割り当てられた各リンクの割合（帯域幅はEFマイクロフローが少ないリンクでは低くなっています）、サブスクライブVLLレート、完全なデュプレックス専用リンクで接続された同じタイプの送信者レシーバーペアの平均レートはサブスクライブレートと各シミュレーションのVLLフローの平均（すべてのSender-Receiverペアは同じ値でした）。損失は、入力型バッファーがオーバーフローしますが、ネットワーク内ではない場合にのみ発生します。よく知られているTCPの動作により、目標率は達成されません。
Table 4: Performance of FTPs using a VLL service
表4：VLLサービスを使用したFTPSのパフォーマンス
% link Average delivered rate (Kbps)
to EF Subscribed Dedicated 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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。