RFC3247 日本語訳
3247 Supplemental Information for the New Definition of the EF PHB(Expedited Forwarding Per-Hop Behavior). A. Charny, J. Bennet, K.Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C.Kalmanek, K. Ramakrishnan. March 2002. (Format: TXT=53786 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Charny
Request for Comments: 3247 Cisco Systems, Inc.
Category: Informational J.C.R. Bennett
Motorola
K. Benson
Tellabs
J.Y. Le Boudec
EPFL
A. Chiu
Celion Networks
W. Courtney
TRW
S. Davari
PMC-Sierra
V. Firoiu
Nortel Networks
C. Kalmanek
AT&T Research
K.K. Ramakrishnan
TeraOptic Networks
March 2002
コメントを求めるワーキンググループA.シャルニーの要求をネットワークでつないでください: 3247年のシスコシステムズInc.カテゴリ: 情報のJ.のY.Le Boudec EPFL A.チウCelion C.R.ベネットモトローラK.ベンソンTellabs J.ネットワークW.コートニーTRW S.Davari PMC-連峰V.FiroiuノーテルネットワークC.Kalmanek AT&Tは2002年3月にK.K.Ramakrishnan TeraOpticネットワークについて研究します。
Supplemental Information for the New Definition
of the EF PHB (Expedited Forwarding Per-Hop Behavior)
EF PHBの新しい定義のための補足的情報(1ホップあたりの完全優先転送の振舞い)
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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document was written during the process of clarification of RFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revised EF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures.
このドキュメントはRFC2598の明確化の過程「完全優先転送PHB」の間、「完全優先転送PHB」というEFに関する訂正明細書の公表にそんなに導かれた状態で書かれました。 第一の動機は改訂されたEF定義とその特性に追加説明を供給しています。 ドキュメントは、いくつかのよく知られているスケジューラとルータ構造のための新しい定義の数字のパラメタの計算のためにまた、追加実現の例を提供して、何らかの指導を与えます。
Charny, et. al. Informational [Page 1] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[1ページ]情報のRFC3247補足的情報行進
Table of Contents
目次
1 Introduction ........................................... 2
2 Definition of EF PHB ................................... 3
2.1 The formal definition .................................. 3
2.2 Relation to Packet Scale Rate Guarantee ................ 6
2.3 The need for dual characterization of EF PHB ........... 7
3 Per Packet delay ....................................... 9
3.1 Single hop delay bound ................................. 9
3.2 Multi-hop worst case delay ............................. 10
4 Packet loss ............................................ 10
5 Implementation considerations .......................... 11
5.1 The output buffered model with EF FIFO at the output. .. 12
5.1.1 Strict Non-preemptive Priority Queue ................... 12
5.1.2 WF2Q ................................................... 13
5.1.3 Deficit Round Robin (DRR) .............................. 13
5.1.4 Start-Time Fair Queuing and Self-Clocked Fair Queuing .. 13
5.2 Router with Internal Delay and EF FIFO at the output ... 13
6 Security Considerations ................................ 14
7 References ............................................. 14
Appendix A. Difficulties with the RFC 2598 EF PHB Definition .. 16
Appendix B. Alternative Characterization of Packet Scale Rate
Guarantee ......................................... 20
Acknowledgements .............................................. 22
Authors' Addresses ............................................ 22
Full Copyright Statement ...................................... 24
1つの序論… EF PHBの2 2定義… 3 2.1 公式の定義… 3 パケットスケールレート保証との2.2関係… 6 2.3 EF PHBの二元的な特殊化の必要性… 1Packetあたり7 3は延着します… 9 3.1 ただ一つのホップ遅れは付きました… 9 3.2 マルチホップ最悪の場合遅れ… 10 4 パケットの損失… 10 5 実現問題… 11 5.1 出力は出力におけるEF FIFOのモデルをバッファリングしました。 .. 12 5.1 .1 厳しい非割込み型優先待ち行列… 12 5.1 .2 WF2Q… 13 5.1 .3 赤字連続(DRR)… 13 5.1 .4 開始時刻の公正な列を作りと自己によって時間を計られた公正な列を作り。 13 出力におけるInternal DelayとEF FIFOがある5.2ルータ… 13 6 セキュリティ問題… 14 7つの参照箇所… 14 RFC2598EF PHB定義における付録A.困難。 16 パケットスケールレート保証の付録B.代替手段特殊化… 20の承認… 22人の作者のアドレス… 22 完全な著作権宣言文… 24
1. Introduction
1. 序論
The Expedited Forwarding (EF) Per-Hop Behavior (PHB) was designed to be used to build a low-loss, low-latency, low-jitter, assured bandwidth service. The potential benefits of this service, and therefore the EF PHB, are enormous. Because of the great value of this PHB, it is critical that the forwarding behavior required of and delivered by an EF-compliant node be specific, quantifiable, and unambiguous.
1ホップあたりのExpedited Forwarding(EF)Behavior(PHB)は低い損失を組み込むのに使用されるように設計されました、低遅延、低いジターです、確実な帯域幅サービス。 このサービスの潜在的利益、およびしたがって、EF PHBは巨大です。 このPHBのかなりの値のために、振舞いが必要であり、EF対応することのノードで提供した推進が特定で、定量化可能で、明白であることは、批判的です。
Unfortunately, the definition of EF PHB in the original RFC2598 [10] was not sufficiently precise (see Appendix A and [4]). A more precise definition is given in [6]. This document is intended to aid in the understanding of the properties of the new definition and provide supplemental information not included in the text of [6] for sake of brevity.
残念ながら、オリジナルのRFC2598[10]とのEF PHBの定義は十分正確ではありませんでした。(Appendix Aと[4])を見てください。 [6]で、より正確な定義を与えます。 このドキュメントは、新しい定義の特性の理解で支援して、[6]のテキストに含まれていなかった補足的情報を簡潔さの目的に提供することを意図します。
This document is outlined as follows. In section 2, we briefly restate the definition for EF PHB of [6]. We then provide some additional discussion of this definition and describe some of its properties. We discuss the issues associated with per-packet delay
このドキュメントは以下の通り概説されています。 セクション2で、私たちは[6]のEF PHBのために簡潔に定義を言い直します。 私たちは、次に、この定義の何らかの追加議論を提供して、いくつかの特性について説明します。 私たちは1パケットあたりの遅れに関連している問題について議論します。
Charny, et. al. Informational [Page 2] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[2ページ]情報のRFC3247補足的情報行進
and loss in sections 3 and 4. In section 5 we discuss the impact of known scheduling architectures on the critical parameters of the new definition. We also discuss the impact of deviation of real devices from the ideal output-buffered model on the magnitude of the critical parameters in the definition.
そして、セクション3と4の損失。 セクション5で、私たちは新しい定義に関する臨界パラメータで知られているスケジューリング構造の影響について議論します。 また、私たちは定義における、臨界パラメータの大きさの理想的な出力でバッファリングされたモデルからの実際の装置の逸脱の影響について議論します。
2. Definition of EF PHB
2. EF PHBの定義
2.1. The formal definition
2.1. 公式の定義
An intuitive explanation of the new EF definition is described in [6]. Here we restate the formal definition from [6] verbatim.
新しいEF定義の直感的な説明は[6]で説明されます。 ここで、私たちは[6]から公式の定義を逐語的に言い直します。
A node that supports EF on an interface I at some configured rate R MUST satisfy the following equations:
何らかの構成されたレートRにおける私が以下の方程式を満たさなければならないインタフェースのEFを支えるノード:
d_j <= f_j + E_a for all j>0 (eq_1)
すべてのj>0のためのd_j<=f_j+E(eq_1)
where f_j is defined iteratively by
f_jが繰り返しに定義されるところ
f_0 = 0, d_0 = 0
f_0 = 0、d_0 = 0
f_j = max(a_j, min(d_j-1, f_j-1)) + l_j/R, for all j > 0 (eq_2)
f_jはすべてのj>0のために+ 最大(_j、分(__d j-1、f j-1))l_j/Rと等しいです。(eq_2)
In this definition:
この定義で:
- d_j is the time that the last bit of the j-th EF packet to
depart actually leaves the node from the interface I.
- d_jが最終が噛み付いた時間である、j、-、去るEFパケットは実際にインタフェースからのノードをIに第残します。
- f_j is the target departure time for the j-th EF packet to
depart from I, the "ideal" time at or before which the last bit
of that packet should leave the node.
- f_jが出発が調節する目標である、j、-、噛み付いたことにおいて最終がどれに噛み付くかの前にI、「理想的な」時間から出発するパケットがノードを残すはずであるEF第パケット。
- a_j is the time that the last bit of the j-th EF packet
destined to the output I actually arrives at the node.
- EFパケットは出力に運命づけられました。a_jが最終が噛み付いた時間である、j、-、私は実際にノードに第到着します。
- l_j is the size (bits) of the j-th EF packet to depart from I.
l_j is measured on the IP datagram (IP header plus payload) and
does not include any lower layer (e.g. MAC layer) overhead.
- l_jがサイズ(ビット)である、j、-、I.l_jを去るEFパケットは、IPデータグラム(IPヘッダープラスペイロード)の上に測定されて、少しの下層(例えば、MACは層にする)オーバーヘッドも第含んでいません。
- R is the EF configured rate at output I (in bits/second).
- RによるEFが出力I(ビット/秒の)でレートを構成したということです。
- E_a is the error term for the treatment of the EF aggregate.
Note that E_a represents the worst case deviation between
actual departure time of an EF packet and ideal departure time
of the same packet, i.e. E_a provides an upper bound on (d_j -
f_j) for all j.
- EはEF集合の処理のための誤差項です。 EがEFパケットの実際の出発時間と同じパケットの理想的な出発時間の最悪の場合逸脱を表して、すなわち、Eが(d_j--f_j)ですべてのjに上限を提供することに注意してください。
Charny, et. al. Informational [Page 3] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[3ページ]情報のRFC3247補足的情報行進
- d_0 and f_0 do not refer to a real packet departure but are
used purely for the purposes of the recursion. The time origin
should be chosen such that no EF packets are in the system at
time 0.
- d_0とf_0は、本当のパケット出発について言及しませんが、再帰の目的に純粋に使用されます。 時間の起源が選ばれるべきであるので、EFパケットが全く時0にシステムにありません。
- for the definitions of a_j and d_j, the "last bit" of the
packet includes the layer 2 trailer if present, because a
packet cannot generally be considered available for forwarding
until such a trailer has been received.
- _jとd_jの定義のために、存在しているなら、パケットの「最後のビット」は層の2トレーラを含んでいます、推進に利用可能であるとそのようなトレーラを受け取るまで一般にパケットを考えることができないので。
An EF-compliant node MUST be able to be characterized by the range of possible R values that it can support on each of its interfaces while conforming to these equations, and the value of E_a that can be met on each interface. R may be line rate or less. E_a MAY be specified as a worst-case value for all possible R values or MAY be expressed as a function of R.
EF対応することのノードはそれがこれらの方程式に従っている間にそれぞれのインタフェースで支持できる可能なR値の範囲、および各インタフェースで満たすことができるEの値で特徴付けることができなければなりません。 Rは、ライン料率か以下であるかもしれません。 E5月は、すべての可能なRのための最悪の場合値が評価するように指定されるか、またはRの機能として言い表されるかもしれません。
Note also that, since a node may have multiple inputs and complex internal scheduling, the j-th EF packet to arrive at the node destined for a certain interface may not be the j-th EF packet to depart from that interface. It is in this sense that eq_1 and eq_2 are unaware of packet identity.
また、それに注意してください、ノードには複数の入力と複雑な内部のスケジューリングがあるかもしれないのでj、-、あるインタフェースに運命づけられたノードに到着するEFパケットが第そうでない、j、-、そのインタフェースを去るEF第パケット。 この意味で、eq_1とeq_2がパケットのアイデンティティに気づかないということです。
In addition, a node that supports EF on an interface I at some configured rate R MUST satisfy the following equations:
添加、インタフェースのEFを支えるノードでは、何らかの構成されたレートRにおける私は以下の方程式を満たさなければなりません:
D_j <= F_j + E_p for all j>0 (eq_3)
D_j<はすべてのj>0のためにF_j+E_pと等しいです。(eq_3)
where F_j is defined iteratively by
F_jが繰り返しに定義されるところ
F_0 = 0, D_0 = 0
F_0 = 0、D_0 = 0
F_j = max(A_j, min(D_j-1, F_j-1)) + L_j/R, for all j > 0 (eq_4)
F_jはすべてのj>0のために+ 最大(_j、分(__D j-1、F j-1))L_j/Rと等しいです。(eq_4)
In this definition:
この定義で:
- D_j is the actual departure time of the individual EF packet
that arrived at the node destined for interface I at time A_j,
i.e., given a packet which was the j-th EF packet destined for
I to arrive at the node via any input, D_j is the time at which
the last bit of that individual packet actually leaves the node
from the interface I.
- D_jがすなわちそうするパケットを考えて、時A_jにインタフェースIに運命づけられたノードに到着した個々のEFパケットの実際の出発時間である、j、-、私がどんな入力でもノードに到着するように運命づけられたEFパケット、D_jはその個々のパケットの最後のビットが実際にインタフェースからのノードをIに出る第時です。
- F_j is the target departure time for the individual EF packet
that arrived at the node destined for interface I at time A_j.
- F_jは時A_jにインタフェースIに運命づけられたノードに到着した個々のEFパケットのための目標出発時間です。
Charny, et. al. Informational [Page 4] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[4ページ]情報のRFC3247補足的情報行進
- A_j is the time that the last bit of the j-th EF packet
destined to the output I to arrive actually arrives at the
node.
- EFパケットは出力にIを運命づけました。A_jが最終が噛み付いた時間である、j、-、到着するのは実際にノードに第到着します。
- L_j is the size (bits) of the j-th EF packet to arrive at the
node that is destined to output I. L_j is measured on the IP
datagram (IP header plus payload) and does not include any
lower layer (e.g. MAC layer) overhead.
- L_jがサイズ(ビット)である、j、-、I.L_jを出力するために運命づけられているノードに到着するEFパケットは、IPデータグラム(IPヘッダープラスペイロード)の上に測定されて、少しの下層(例えば、MACは層にする)オーバーヘッドも第含んでいません。
- R is the EF configured rate at output I (in bits/second).
- RによるEFが出力I(ビット/秒の)でレートを構成したということです。
- E_p is the error term for the treatment of individual EF
packets. Note that E_p represents the worst case deviation
between the actual departure time of an EF packet and the ideal
departure time of the same packet, i.e. E_p provides an upper
bound on (D_j - F_j) for all j.
- E_pは個々のEFパケットの処理のための誤差項です。 E_pがEFパケットの実際の出発時間と同じパケットの理想的な出発時間の最悪の場合逸脱を表して、すなわち、E_pが(D_j--F_j)ですべてのjに上限を提供することに注意してください。
- D_0 and F_0 do not refer to a real packet departure but are
used purely for the purposes of the recursion. The time origin
should be chosen such that no EF packets are in the system at
time 0.
- D_0とF_0は、本当のパケット出発について言及しませんが、再帰の目的に純粋に使用されます。 時間の起源が選ばれるべきであるので、EFパケットが全く時0にシステムにありません。
- for the definitions of A_j and D_j, the "last bit" of the
packet includes the layer 2 trailer if present, because a
packet cannot generally be considered available for forwarding
until such a trailer has been received.
- A_jとD_jの定義のために、存在しているなら、パケットの「最後のビット」は層の2トレーラを含んでいます、推進に利用可能であるとそのようなトレーラを受け取るまで一般にパケットを考えることができないので。
It is the fact that D_j and F_j refer to departure times for the j-th packet to arrive that makes eq_3 and eq_4 aware of packet identity. This is the critical distinction between the last two equations and the first two.
それがD_jとF_jが出発時間を参照する事実である、j、-、到着するeq_3とeq_4をパケットのアイデンティティを意識するようにする第パケット。 これは最後の2つの方程式と最初の2の重大な区別です。
An EF-compliant node SHOULD be able to be characterized by the range of possible R values that it can support on each of its interfaces while conforming to these equations, and the value of E_p that can be met on each interface. E_p MAY be specified as a worst-case value for all possible R values or MAY be expressed as a function of R. An E_p value of "undefined" MAY be specified.
EF対応することのノードSHOULD、それがこれらの方程式に従っている間にそれぞれのインタフェースで支持できる可能なR値の範囲、および各インタフェースで満たすことができるE_pの値で特徴付けることができてください。 E_p5月は、すべての可能なRのための最悪の場合値が評価するように指定されるか、または指定されていて、「未定義」の5月のR.An E_p価値の関数として言い表されるかもしれません。
Finally, there is an additional recommendation in [6] that an EF compliant node SHOULD NOT reorder packets within a micorflow.
最終的に、追加推薦がaの中のEF対応することのノードSHOULD NOT追加注文パケットがmicorflowする[6]にあります。
The definitions described in this section are referred to as aggregate and packet-identity-aware packet scale rate guarantee [4],[2]. An alternative mathematical characterization of packet scale rate guarantee is given in Appendix B.
そして、このセクションで説明された定義が集合と呼ばれる、パケットのアイデンティティ意識する、パケットスケールレート保証[4]、[2]。 Appendix Bでパケットスケールレート保証の代替の数学の特殊化を与えます。
Charny, et. al. Informational [Page 5] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[5ページ]情報のRFC3247補足的情報行進
2.2. Relation to Packet Scale Rate Guarantee
2.2. パケットスケールレート保証との関係
Consider the case of an ideal output-buffered device with an EF FIFO at the output. For such a device, the i-th packet to arrive to the device is also the i-th packet to depart from the device. Therefore, in this ideal model the aggregate behavior and packet-identity-aware characteristics are identical, and E_a = E_p. In this section we therefore omit the subscript and refer to the latency term simply as E.
出力におけるEF FIFOがある理想的な出力でバッファリングされた装置に関するケースを考えてください。 そのような装置のためにi、-、また、装置に到着するパケットが第そうである、i、-、装置を去る第パケット。 そして、したがって、この理想では、集合振舞いをモデル化してください、パケットのアイデンティティ意識する、特性は同じであり、EはE_pと等しいです。 このセクションでは、私たちは、したがって、添字を省略して、単にEとして潜在用語を述べます。
It could be shown that for such an ideal device the definition of section 2.1 is stronger than the well-known rate-latency curve [2] in the sense that if a scheduler satisfies the EF definition it also satisfies the rate-latency curve. As a result, all the properties known for the rate-latency curve also apply to the modified EF definition. However, we argue below that the definition of section 2.1 is more suitable to reflect the intent of EF PHB than the rate- latency curve.
そのような理想的な装置のためにセクション2.1の定義が周知のレート潜在カーブ[2]よりまた、スケジューラがEF定義を満たすならレート潜在カーブを満たすという意味に強いのをそれを示すことができました。 その結果、また、レート潜在カーブで知られているすべての特性が変更されたEF定義に適用されます。 しかしながら、私たちは、以下でEF PHBの意図を反映するのにおいてセクション2.1の定義がレート潜在カーブより適当であると主張します。
It is shown in [2] that the rate-latency curve is equivalent to the following definition:
[2]では、レート潜在カーブが以下の定義に同等であることが示されます:
Definition of Rate Latency Curve (RLC):
レート潜在カーブ(RLC)の定義:
D(j) <= F'(j) + E (eq_5)
D(j)<はF'(j)+E'と等しいです。(eq_5)
where
どこ
F'(0)=0, F'(j)=max(a(j), F'(j-1))+ L(j)/R for all j>0 (eq_6)
'F'(0)=0、F'(j)はすべてのj>0のために+ 最大(a(j)、F'(j-1))L(j)/Rと等しいです。(eq_6)
It can be easily verified that the EF definition of section 2.1 is stronger than RLC by noticing that for all j, F'(j) >= F(j).
容易に、セクション2.1のEF定義がRLCよりすべてのj、F'(j)>=F(j)'のためにそれに気付くことによって強いことを確かめることができます。
It is easy to see that F'(j) in the definition of RLC corresponds to the time the j-th departure should have occurred should the EF aggregate be constantly served exactly at its configured rate R. Following the common convention, we refer to F'(j) as the "fluid finish time" of the j-th packet to depart.
RLCの定義におけるF'(j)が時間に対応するのがわかるのが簡単である、j、-、EF集合が絶えずちょうど構成されたレートR.Followingの一般的なコンベンションに役立たれているなら出発が起こるべきであり、私たちが「流体終了時刻」にF'(j)について第言及する、j、-、去る第パケット。
The intuitive meaning of the rate-latency curve of RLC is that any packet is served at most time E later than this packet would finish service in the fluid model.
RLCのレート潜在カーブの直感的な意味はどんなパケットもほとんどの時間このパケットが流体モデルにおけるサービスを終えるだろうよりE後半に役立たれているということです。
For RLC (and hence for the stronger EF definition) it holds that in any interval (0,t) the EF aggregate gets close to the desired service rate R (as long as there is enough traffic to sustain this rate). The discrepancy between the ideal and the actual service in this interval depends on the latency term E, which in turn depends on the
そして、RLC、(したがって、より強いEF定義) それに関して、EF集合が得るどんな間隔(0、t)でも必要なサービスに閉じる船倉はRを評定します(交通がこのレートを支えるほどある限り)。 この間隔の中の理想的なサービスと実際のサービスの間の食い違いは潜在諸条件Eでよります。(順番に、それは、よります)。
Charny, et. al. Informational [Page 6] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[6ページ]情報のRFC3247補足的情報行進
scheduling implementation. The smaller E, the smaller the difference between the configured rate and the actual rate achieved by the scheduler.
実現の計画をします。 E、より小さいのは構成されたレートと実際のレートの違いがスケジューラで実現したより小さいです。
While RLC guarantees the desired rate to the EF aggregate in all intervals (0,t) to within a specified error, it may nevertheless result in large gaps in service. For example, suppose that (a large number) N of identical EF packets of length L arrived from different interfaces to the EF queue in the absence of any non-EF traffic. Then any work-conserving scheduler will serve all N packets at link speed. When the last packet is sent at time NL/C, where C is the capacity of output link, F'(N) will be equal to NL/R. That is, the scheduler is running ahead of ideal, since NL/C < NL/R for R < C. Suppose now that at time NL/C a large number of non-EF packets arrive, followed by a single EF packet. Then the scheduler can legitimately delay starting to send the EF packet until time F'(N+1)=(N+1)L/R + E - L/C. This means that the EF aggregate will have no service at all in the interval (NL/C, (N+1)L/R + E - L/C). This interval can be quite large if R is substantially smaller than C. In essence, the EF aggregate can be "punished" by a gap in service for receiving faster service than its configured rate at the beginning.
RLCが指定された誤りへのすべての間隔(0、t)のEF集合に必要なレートを保証している間、それにもかかわらず、それは使用中の状態で大穴をもたらすかもしれません。 例えば、長さLの同じEFパケットの(多く)Nがどんな非EF交通がないとき異なったインタフェースからEF待ち行列まで到着したと仮定してください。 そして、どんな仕事を保存するスケジューラもリンク速度ですべてのNパケットに役立つでしょう。 時間NL/C(Cは出力リンクの容量である)に最後のパケットを送るとき、F'(N)はNL/R'と等しくなるでしょう。 すなわち、スケジューラは理想を凌いでいます、現在の多くの非EFパケットが到着する時代NL/Cに単一のEFパケットで続いたR<C.SupposeのためのNL/C<NL/R以来。 '次に、スケジューラは、時間F'(N+1)=(N+1)L/R+EまでEFパケットを送り始めるのを合法的に遅らせることができます--L/C。 これは、EF集合が間隔(L/R+E--NL/C、(N+1)L/C)にサービスを全く持たないことを意味します。 RがC.In本質、EF集合であることができるより実質的に始めに構成されたレートより速いサービスを受けるのに、使用中のギャップによって「罰せられた」状態で小さいなら、この間隔はかなり大きい場合があります。
The new EF definition alleviates this problem by introducing the term min(D(j-1), F(j-1)) in the recursion. Essentially, this means that the fluid finishing time is "reset" if that packet is sent before its "ideal" departure time. As a consequence of that, for the case where the EF aggregate is served in the FIFO order, suppose a packet arrives at time t to a server satisfying the EF definition. The packet will be transmitted no later than time t + Q(t)/R + E, where Q(t) is the EF queue size at time t (including the packet under discussion)[4].
新しいEF定義は、再帰における用語分(D(j-1)、F(j-1))を導入することによって、この問題を軽減します。 本質的には、これは、「理想的な」出発時間の前にそのパケットを送るなら流体の仕上げの時間を「リセットすること」を意味します。 その結果として、EF集合が先入れ先出し法オーダーで役立たれているケースには、パケットがEF定義を満たしながらサーバへの時間tに到着すると仮定してください。 パケットは時間t+Q(t)/R+Eによって伝えられるでしょう。そこでは、Q(t)が時間t(議論でパケットを含んでいます)[4]でEF待ち行列サイズです。
2.3. The need for dual characterization of EF PHB
2.3. EF PHBの二元的な特殊化の必要性
In a more general case, where either the output scheduler does not serve the EF packets in a FIFO order, or the variable internal delay in the device reorders packets while delivering them to the output (or both), the i-th packet destined to a given output interface to arrive to the device may no longer be the i-th packet to depart from that interface. In that case the packet-identity-aware and the aggregate definitions are no longer identical.
出力スケジューラは出力(ともに)にそれらを渡している間、先入れ先出し法オーダーでEFパケットに役立つか、または装置追加注文パケットで可変内部の遅れに役立たないより一般的な場合でi、-、装置に到着するように与えられた出力インタフェースに運命づけられたパケットがもう第ないかもしれない、i、-、そのインタフェースを去る第パケット。 そして、その場合、パケットのアイデンティティ意識する、集合定義はもう同じではありません。
The aggregate behavior definition can be viewed as a truly aggregate characteristic of the service provided to EF packets. For an analogy, consider a dark reservoir to which all arriving packets are placed. A scheduler is allowed to pick a packet from the reservoir in a random order, without any knowledge of the order of packet
本当に集合のサービスの特性がEFパケットに提供されたので、集合振舞い定義を見ることができます。 類推には、すべて到着しているパケットが置かれる暗い貯水池を考えてください。 スケジューラは貯水池からパケットをランダムに選ぶことができます、パケットの注文に関する少しも知識なしで
Charny, et. al. Informational [Page 7] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[7ページ]情報のRFC3247補足的情報行進
arrivals. The aggregate part of the definition measures the accuracy of the output rate provided to the EF aggregate as a whole. The smaller E_a, the more accurate is the assurance that the reservoir is drained at least at the configured rate.
到着。 定義の集合部分は全体でEF集合に提供された出力率の精度を測定します。 より小さいEであり、貯水池が少なくとも構成された速度で排出されるという保証は、より正確です。
Note that in this reservoir analogy packets of EF aggregate may be arbitrarily reordered. However, the definition of EF PHB given in [6] explicitly requires that no packet reordering occur within a microflow. This requirement restricts the scheduling implementations, or, in the reservoir analogy, the order of pulling packets out of the reservoir to make sure that packets within a microflow are not reordered, but it still allows reordering at the aggregate level.
この貯水池の中では、EF集合の類推パケットが任意に再命令されるかもしれないことに注意してください。 しかしながら、[6]で明らかに与えられているEF PHBの定義は、パケット再命令でないのがmicroflowの中に起こるのを必要とします。 または、この要件は貯水池類推(パケットを貯水池から取り出すのがmicroflowの中のパケットが再命令されませんが、集合レベルで再命令するのをまだ許容しているのを確実にする命令)でスケジューリング実現を制限します。
Note that reordering within the aggregate, as long as there is no flow-level reordering, does not necessarily reflect a "bad" service. Consider for example a scheduler that arbitrates among 10 different EF "flows" with diverse rates. A scheduler that is aware of the rate requirements may choose to send a packet of the faster flow before a packet of the slower flow to maintain lower jitter at the flow level. In particular, an ideal "flow"-aware WFQ scheduler will cause reordering within the aggregate, while maintaining packet ordering and small jitter at the flow level.
流れ平らな再命令がない限り、集合の中で再命令するのが必ず「悪い」サービスを反映するというわけではないことに注意してください。 例えば、10の異なったEFの中で仲裁するスケジューラがさまざまのレートで「流れる」と考えてください。 レート要件を意識しているスケジューラは、流れレベルで下側のジターを維持するために、より遅い流れのパケットの前により速い流れのパケットを送るのを選ぶかもしれません。 特に、理想的な「流れ」意識しているWFQスケジューラは流れレベルでパケット注文と小さいジターを維持している間、集合の中の再命令を引き起こすでしょう。
It is intuitively clear that for such a scheduler, as well as for a simpler FIFO scheduler, the "accuracy" of the service rate is crucial for minimizing "flow"-level jitter. The packet-identity-aware definition quantifies this accuracy of the service rate.
「流れ」レベルジターを最小にするのに、そのようなスケジューラ、および、より簡単な先入れ先出し法スケジューラに関して、サービス率の「精度」が重要であることは、直観的に明確です。 パケットのアイデンティティ意識する、定義はサービス率のこの精度を定量化します。
However, the small value of E_a does not give any assurances about the absolute value of per-packet delay. In fact, if the input rate exceeds the configured rate, the aggregate behavior definition may result in arbitrarily large delay of a subset of packets. This is the primary motivation for the packet-identity-aware definition.
しかしながら、Eの小さい値は1パケットあたりの遅れの絶対値に関してどんな保証も与えません。 事実上、入力率が構成されたレートを超えているなら、集合振舞い定義はパケットの部分集合の任意に大きい遅れをもたらすかもしれません。 これが第一の動機である、パケットのアイデンティティ意識する、定義。
The primary goal of the packet-aware characterization of the EF implementation is that, unlike the aggregate behavior characterization, it provides a way to find a per-packet delay bound as a function of input traffic parameters.
EF実現のパケット意識している特殊化の第一の目標は集合振舞い特殊化と異なって1パケットあたり1つの遅れが入力交通パラメタの関数として制限されているのがわかる方法を提供するということです。
While the aggregate behavior definition characterizes the accuracy of the service rate of the entire EF aggregate, the packet-identity- aware part of the definition characterizes the deviation of the device from an ideal server that serves the EF aggregate in FIFO order at least at the configured rate.
集合振舞い定義は全体のEF集合のサービス率の精度を特徴付けますが、定義のパケットアイデンティティ意識している部分は少なくとも構成されたレートでの先入れ先出し法オーダーにおけるEF集合に役立つ理想的なサーバからの装置の逸脱を特徴付けます。
The value of E_p in the packet-identity-aware definition is therefore affected by two factors: the accuracy of the aggregate rate service
中のE_pの値、パケットのアイデンティティ意識する、したがって、定義は2つの要素で影響を受けます: 集合レートサービスの精度
Charny, et. al. Informational [Page 8] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[8ページ]情報のRFC3247補足的情報行進
and the degree of packet reordering within the EF aggregate (under the constraint that packets within the same microflow are not reordered). Therefore, a sub-aggregate aware device that provides an ideal service rate to the aggregate, and also provides an ideal rate service for each of the sub-aggregates, may nevertheless have a very large value of E_p (in this case E_p must be at least equal to the ratio of the maximum packet size divided by the smallest rate of any sub aggregate). As a result, a large value of E_p does not necessarily mean that the service provided to EF aggregate is bad - rather it may be an indication that the service is good, but non- FIFO. On the other hand, a large value of E_p may also mean that the aggregate service is very inaccurate (bursty), and hence in this case the large value of E_p reflects a poor quality of implementation.
そして、EF集合(同じmicroflowの中のパケットが再命令されないという規制での)の中のパケット再命令の度。 したがって、それにもかかわらず、それぞれのサブ集合のための理想的なレートサービスを集合への理想的なサービス率に提供して、また提供するサブ集合の意識している装置はE_pの非常に大きい値を持っているかもしれません(この場合E_pは最大の割られる中でどんな潜水艦集合のレートも最もわずかであるパケットサイズの比率と少なくとも等しくなければなりません)。 その結果、E_pの大きい値は、必ずEF集合に提供されたサービスが悪いことを意味するというわけではありません--むしろそれはサービスが良いのにもかかわらずの、非先入れ先出し法であるという指示であるかもしれません。 他方では、また、E_pの大きい値は、集合サービスが非常に不正確であることを(bursty)意味するかもしれません、そして、したがって、この場合、E_pの大きい値は実現の劣った品質を反映します。
As a result, a large number of E_p does not necessarily provide any guidance on the quality of the EF implementation. However, a small value of E_p does indicate a high quality FIFO implementation.
_結果、多くのEで、pは必ずEF実現の品質で少しの指導も提供するというわけではありません。 しかしながら、E_pの小さい値は高品質の先入れ先出し法実現を示します。
Since E_p and E_a relate to different aspects of the EF implementation, they should be considered together to determine the quality of the implementation.
E_pとEがEF実現の異なった局面に関連するので、彼らが実現の品質を決定すると一緒に考えられるべきです。
3. Per Packet delay
3. Packet遅れ単位で
The primary motivation for the packet-identity-aware definition is that it allows quantification of the per-packet delay bound. This section discusses the issues with computing per-packet delay.
第一の動機、パケットのアイデンティティ意識する、定義は1パケットあたりの遅れバウンドの定量化を許すということです。 このセクションは1パケットあたりの遅れを計算するのに問題に取り組みます。
3.1. Single hop delay bound
3.1. ただ一つのホップ遅れは付きました。
If the total traffic arriving to an output port I from all inputs is constrained by a leaky bucket with parameters (R, B), where R is the configured rate at I, and B is the bucket depth (burst), then the delay of any packet departing from I is bounded by D_p, given by
すべての入力から出力ポートIに到着する総交通が水漏れするバケツによってRがIで構成されたレートであるパラメタ(R、B)で抑制されて、Bがバケツの深さ(押し破かれる)であるなら、Iから出発するどんなパケットの遅れもD_pで、与えた状態で境界があります。
D_p = B/R + E_p (eq_7)
D_pは+ B/R E_pと等しいです。(eq_7)
(see appendix B).
(付録Bを見ます。)
Because the delay bound depends on the configured rate R and the input burstiness B, it is desirable for both of these parameters to be visible to a user of the device. A PDB desiring a particular delay bound may need to limit the range of configured rates and allowed burstiness that it can support in order to deliver such bound. Equation (eq_7) provides a means for determining an acceptable operating region for the device with a given E_p. It may also be useful to limit the total offered load to a given output to some rate R_1 < R (e.g. to obtain end-to-end delay bounds [5]). It
遅れバウンドが構成されたレートRと入力burstiness Bによるので、装置のユーザにとって、これらのパラメタの両方が目に見えるのは、望ましいです。 特定の遅れバウンドを望んでいるPDBは、それがそのようなバウンドを提供するために支持できる構成されたレートと許容burstinessの範囲を制限する必要があるかもしれません。 方程式(eq_7)は装置のために許容できる操作領域を決定するための手段を与えられたE_pに供給します。 また、総提供された負荷をいくらかのレートR_1<Rへの与えられた出力に制限するのも役に立つかもしれません。(例えば、終わらせる終わりを入手するのは領域[5])を遅らせます。 それ
Charny, et. al. Informational [Page 9] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[9ページ]情報のRFC3247補足的情報行進
is important to realize that, while R_1 may also be a configurable parameter of the device, the delay bound in (eq_7) does not depend on it. It may be possible to get better bounds explicitly using the bound on the input rate, but the bound (eq_7) does not take advantage of this information.
それがわかるために重要です、また、R_1は装置の構成可能なパラメタであるかもしれませんが、(eq_7)に向かっている遅れはそれによりません。 入力率で明らかにバウンドを使用するより良い領域を手に入れるのが可能であるかもしれませんが、バウンド(eq_7)はこの情報を利用しません。
3.2. Multi-hop worst case delay
3.2. マルチホップ最悪の場合遅れ
Although the PHB defines inherently local behavior, in this section we briefly discuss the issue of per-packet delay as the packet traverses several hops implementing EF PHB. Given a delay bound (eq_7) at a single hop, it is tempting to conclude that per-packet bound across h hops is simply h times the bound (eq_7). However, this is not necessarily the case, unless B represents the worst case input burstiness across all nodes in the network.
PHBは本来の地方の振舞いを定義しますが、このセクションで、パケットがEF PHBを実行するいくつかのホップを横断するとき、私たちは簡潔に1パケットあたりの遅れの問題について議論します。 単一のホップの遅れバウンド(eq_7)を考えて、結論すると、、hホップの向こう側に縛られたパケットが単にh回であることは誘惑しています。制限された(eq_7。) しかしながら、これは必ずそうであるというわけではありません、Bがネットワークにおけるすべてのノードの向こう側に最悪の場合入力burstinessを表さない場合。
Unfortunately, obtaining such a worst case value of B is not trivial. If EF PHB is implemented using aggregate class-based scheduling where all EF packets share a single FIFO, the effect of jitter accumulation may result in an increase in burstiness from hop to hop. In particular, it can be shown that unless severe restrictions on EF utilization are imposed, even if all EF flows are ideally shaped at the ingress, then for any value of delay D it is possible to construct a network where EF utilization on any link is bounded not to exceed a given factor, no flow traverses more than a specified number of hops, but there exists a packet that experiences a delay more than D [5]. This result implies that the ability to limit the worst case burstiness and the resulting end-to-end delay across several hops may require not only limiting EF utilization on all links, but also constraining the global network topology. Such topology constraints would need to be specified in the definition of any PDB built on top of EF PHB, if such PDB requires a strict worst case delay bound.
残念ながら、Bのそのような最悪の場合値を得るのは些細ではありません。 EF PHBがすべてのEFパケットがただ一つの先入れ先出し法を共有するところで集合クラスベースのスケジューリングを使用することで実行されるなら、ジッタ累積の効果はホップからホップまでのburstinessの増加をもたらすかもしれません。 EF利用の厳しい制限が課されない場合すべてのEF流れがそして、組み立てるのが可能である遅れDのどんな値のためにもイングレスで理想的に形成されても特に、どんなリンクにおけるEF利用があるネットワークが与えられた要素を超えないようにバウンドしたのをそれを指定された数のホップより流れ横断がないことでさらに示すことができますが、遅れをD[5]よりもう少し経験するパケットは存在しています。 この結果は、いくつかのホップの向こう側に最悪の場合burstinessと終わりから終わりへの結果として起こる遅れを制限する能力が、すべてのリンクの上にEF利用を制限するだけではなく、世界的なネットワークトポロジーを抑制もするのを必要とするかもしれないのを含意します。 そのようなトポロジー規制は、EF PHBの上に造られたどんなPDBの定義でも指定される必要があるでしょう、そのようなPDBが厳しい最悪の場合遅れバウンドを必要とするなら。
4. Packet loss
4. パケット損失
Any device with finite buffering may need to drop packets if the input burstiness becomes sufficiently high. To meet the low loss objective of EF, a node may be characterized by the operating region in which loss of EF due to congestion will not occur. This may be specified as a token bucket of rate r <= R and burst size B that can be offered from all inputs to a given output interface without loss.
入力burstinessが十分高くなるなら、有限バッファリングがあるどんな装置も、パケットを落とす必要があるかもしれません。 EFの低い損失目的を満たすために、ノードは混雑によるEFの損失が発生しない操作領域によって特徴付けられるかもしれません。 レートr<の象徴バケツがRと損失なしですべての入力から与えられた出力インタフェースまで提供できる放出量Bと等しいときに、これは指定されるかもしれません。
However, as discussed in the previous section, the phenomenon of jitter accumulation makes it generally difficult to guarantee that the input burstiness never exceeds the specified operating region for nodes internal to the DiffServ domain. A no-loss guarantee across multiple hops may require specification of constraints on network
しかしながら、前項で議論するように、ジッタ累積の現象で、入力burstinessがDiffServドメインへの内部のノードのために指定された操作領域を決して超えていないのを保証するのが一般に、難しくなります。 複数のホップの向こう側の損失がない保証はネットワークで規制の仕様を必要とするかもしれません。
Charny, et. al. Informational [Page 10] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[10ページ]情報のRFC3247補足的情報行進
topology which are outside the scope of inherently local definition of a PHB. Thus, it must be possible to establish whether a device conforms to the EF definition even when some packets are lost.
本来のPHBの地方の定義の範囲の外にあるトポロジー。 したがって、いくつかのパケットが無くなるときさえ、装置がEF定義に一致しているかどうか証明するのは可能であるに違いありません。
This can be done by performing an "off-line" test of conformance to equations (eq_1)- (eq_4). After observing a sequence of packets entering and leaving the node, the packets which did not leave are assumed lost and are notionally removed from the input stream. The remaining packets now constitute the arrival stream and the packets which left the node constitute the departure stream. Conformance to the equations can thus be verified by considering only those packets that successfully passed through the node.
方程式(eq_1)に順応の「オフライン」のテストを実行することによって、これができます--(eq_4。) パケットの系列がノードを入力して、残しているのを観測した後に、いなくならなかったパケットを、無くなると思って、入力ストリームから概念的に取り除きます。 残っているパケットは現在到着の流れを構成します、そして、ノードを残したパケットは出発の流れを構成します。 その結果、それらの唯一のパケットがノードを首尾よく通り抜けるそれであると考えることによって、方程式への順応について確かめることができます。
Note that specification of which packets are lost in the case when loss does occur is beyond the scope of the definition of EF PHB. However, those packets that were not lost must conform to the equations definition of EF PHB in section 2.1.
損失が発生するときパケットが場合で失われている仕様がEF PHBの定義の範囲を超えていることに注意してください。 しかしながら、失われなかったそれらのパケットはセクション2.1でEF PHBの方程式定義に従わなければなりません。
5. Implementation considerations
5. 実現問題
A packet passing through a router will experience delay for a number of reasons. Two familiar components of this delay are the time the packet spends in a buffer at an outgoing link waiting for the scheduler to select it and the time it takes to actually transmit the packet on the outgoing line.
ルータを通り抜けるパケットは様々な意味で遅れを経験するでしょう。 この遅れの2つの身近なコンポーネントがパケットがスケジューラがそれを選択するのを待つ出発しているリンクとわざわざそれが実際に引き出し線の上でパケットを伝えるバッファで過ごす時間です。
There may be other components of a packet's delay through a router, however. A router might have to do some amount of header processing before the packet can be given to the correct output scheduler, for example. In another case a router may have a FIFO buffer (called a transmission queue in [7]) where the packet sits after being selected by the output scheduler but before it is transmitted. In cases such as these, the extra delay a packet may experience can be accounted for by absorbing it into the latency terms E_a and E_p.
例えば、正しい出力スケジューラにパケットを与えることができる前に. ルータがどのようにいくらかの量のヘッダー処理をしなければならないかもしれなくても、ルータを通してパケットの遅れの他のコンポーネントがあるかもしれません。 別の場合におけるルータには、先入れ先出し法バッファがあるかもしれません。(出力スケジューラによって選択された後にもかかわらず、それが伝えられる前を除いて、[7]) パケットが座るところにトランスミッション待ち行列を回収しました。 これらなどの場合では、pという潜在用語のEとE_までそれを吸収することによって、パケットが経験するかもしれない余分な遅れを説明できます。
Implementing EF on a router with a multi-stage switch fabric requires special attention. A packet may experience additional delays due to the fact that it must compete with other traffic for forwarding resources at multiple contention points in the switch core. The delay an EF packet may experience before it even reaches the output- link scheduler should be included in the latency term. Input- buffered and input/output-buffered routers based on crossbar design may also require modification of their latency terms. The factors such as the speedup factor and the choice of crossbar arbitration algorithms may affect the latency terms substantially.
ルータでマルチステージスイッチ織物でEFを実行するのは特別な注意を必要とします。 パケットはスイッチコアで複数の主張ポイントでリソースを転送するための他の交通と競争しなければならないという事実のため追加遅れを経験するかもしれません。 出力リンクスケジューラに達する前にさえEFパケットが経験するかもしれない遅れは潜在用語に含まれるべきです。 また、横木デザインに基づく入力のバッファリングされて出力で入力/バッファリングされたルータは彼らの潜在用語の変更を必要とするかもしれません。スピードアップ要素や横木仲裁アルゴリズムの選択などの要素は実質的に潜在用語に影響するかもしれません。
Charny, et. al. Informational [Page 11] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[11ページ]情報のRFC3247補足的情報行進
Delay in the switch core comes from two sources, both of which must be considered. The first part of this delay is the fixed delay a packet experiences regardless of the other traffic. This component of the delay includes the time it takes for things such as packet segmentation and reassembly in cell based cores, enqueueing and dequeuing at each stage, and transmission between stages. The second part of the switch core delay is variable and depends on the type and amount of other traffic traversing the core. This delay comes about if the stages in the core mix traffic flowing between different input/output port pairs. Thus, EF packets must compete against other traffic for forwarding resources in the core. Some of this competing traffic may even be traffic from other, non-EF aggregates. This introduces extra delay, that can also be absorbed by the latency term in the definition.
スイッチコアの遅れは2つのソースから来ます。その両方を考えなければなりません。 この遅れの最初の部分はパケットがもう片方の交通にかかわらず経験する固定遅れです。 遅れのこのコンポーネントはそれがセルに基づいているコア、各段階でenqueueingとデキューすること、およびステージの間のトランスミッションでパケット分割や再アセンブリなどのものにかかる時間を含んでいます。 スイッチコア遅れの第二部は、可変であり、コアを横断する他の交通のタイプと量に頼っています。 コアのステージが異なった入力/出力ポート組の間を流れる交通を混ぜるなら、この遅れは生じます。 したがって、EFパケットはコアでリソースを転送するための他の交通を競争しなければなりません。 この競争している交通のいくつかが他の、そして、非EFの集合からの交通でさえあるかもしれません。 これは余分な遅れを導入します、また、それが潜在用語で定義に没頭できます。
To capture these considerations, in this section we will consider two simplified implementation examples. The first is an ideal output buffered node where packets entering the device from an input interface are immediately delivered to the output scheduler. In this model the properties of the output scheduler fully define the values of the parameters E_a and E_p. We will consider the case where the output scheduler implements aggregate class-based queuing, so that all EF packets share a single queue. We will discuss the values of E_a and E_p for a variety of class-based schedulers widely considered.
このセクションのこれらの問題を得るために、私たちは、2の簡易型の実現が例であると考えるつもりです。 1番目は入力インタフェースから装置に入るパケットがすぐに出力スケジューラに果たされる理想的算出量のバッファリングされたノードです。 このモデルでは、出力スケジューラの特性はパラメタEとE_pの値を完全に定義します。 私たちは出力スケジューラが集合クラスベースの列を作りを実行するケースを考えるつもりです、すべてのEFパケットがただ一つの待ち行列を共有するように。 私たちは広く考えられたさまざまなクラスベースのスケジューラのためにEとE_pの値について議論するつもりです。
The second example will consider a router modeled as a black box with a known bound on the variable delay a packet can experience from the time it arrives to an input to the time it is delivered to its destination output. The output scheduler in isolation is assumed to be an aggregate scheduler where all EF packets share a single FIFO queue, with a known value of E_a(S)=E_p(S)=E(S). This model provides a reasonable abstraction to a large class of router implementations.
2番目の例は知られているバウンドがパケットがそれが入力に到達する時からそれが目的地出力に渡される時まで経験できる可変遅れにある状態でブラックボックスとしてモデル化されたルータを考えるでしょう。 出力スケジューラはすべてのEFパケットがただ一つの先入れ先出し待ち行列を共有するところの集合スケジューラであると分離して思われます、E(S)=E_p(S)=E(S)の知られている値で。 このモデルは多人数のクラスのルータ実現に合理的な抽象化を提供します。
5.1. The output buffered model with EF FIFO at the output.
5.1. 出力は出力におけるEF FIFOのモデルをバッファリングしました。
As has been mentioned earlier, in this model E_a = E_p, so we shall omit the subscript and refer to both terms as latency E. The remainder of this subsection discusses E for a number of scheduling implementations.
私たちは、より早くこのモデルE=E_pで言及されたように潜在E.として添字を省略して、両方の用語を参照するつもりです。この小区分の残りは多くのスケジューリング実現のためにEについて議論します。
5.1.1. Strict Non-preemptive Priority Queue
5.1.1. 厳しい非割込み型優先待ち行列
A Strict Priority scheduler in which all EF packets share a single FIFO queue which is served at strict non-preemptive priority over other queues satisfies the EF definition with the latency term E = MTU/C where MTU is the maximum packet size and C is the speed of the output link.
すべてのEFパケットが他の待ち行列より厳しい非割込み型優先権に役立っているただ一つの先入れ先出し待ち行列を共有するStrict PriorityスケジューラはMTUが最大のパケットサイズであり、Cが出力リンクの速度である潜在用語E=MTU/CにEF定義を満たします。
Charny, et. al. Informational [Page 12] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[12ページ]情報のRFC3247補足的情報行進
5.1.2. WF2Q
5.1.2. WF2Q
Another scheduler that satisfies the EF definition with a small latency term is WF2Q described in [1]. A class-based WF2Q scheduler, in which all EF traffic shares a single queue with the weight corresponding to the configured rate of the EF aggregate satisfies the EF definition with the latency term E = MTU/C+MTU/R.
小さい潜在用語にEF定義を満たす別のスケジューラは[1]で説明されたWF2Qです。 クラスベースのWF2Qスケジューラ。(そこで、すべてのEF交通が集合がMTU/C+MTU/Rと等しいのを潜在用語EによるEF定義に満たすEFの構成されたレートに対応する重さとただ一つの待ち行列を共有します)。
5.1.3. Deficit Round Robin (DRR)
5.1.3. 赤字連続(DRR)
For DRR [12], E can be shown to grow linearly with N*(r_max/r_min)*MTU, where r_min and r_max denote the smallest and the largest rate among the rate assignments of all queues in the scheduler, and N is the number of queues in the scheduler.
DRR[12]に関しては、r_分とr_最大がスケジューラのすべての待ち行列のレート課題の中で指示する中で最も小さくレート最も大きいN*(r_最大/r_分)*MTU、およびNと共に直線的になるのが、スケジューラの待ち行列の数であることをEを示すことができます。
5.1.4. Start-Time Fair Queuing and Self-Clocked Fair Queuing
5.1.4. 開始時刻の公正な列を作りと自己によって時間を計られた公正な列を作り
For Start-Time Fair Queuing (SFQ) [9] and Self-Clocked Fair Queuing (SCFQ) [8] E can be shown to grow linearly with the number of queues in the scheduler.
Start-時間Fair Queuing(SFQ)[9]とSelfによって時間を計られたFair Queuing(SCFQ)[8]に関しては、待ち行列の数がスケジューラにある状態で直線的になるようにEを示すことができます。
5.2. Router with Internal Delay and EF FIFO at the output
5.2. 出力におけるInternal DelayとEF FIFOがあるルータ
In this section we consider a router which is modeled as follows. A packet entering the router may experience a variable delay D_v with a known upper bound D. That is, 0<=D_v<=D. At the output all EF packets share a single class queue. Class queues are scheduled by a scheduler with a known value E_p(S)=E(S) (where E(S) corresponds to the model where this scheduler is implemented in an ideal output buffered device).
このセクションでは、私たちは、モデル化されるルータは以下の通りであると考えます。 ルータに入るパケットは知られている上限D.がある可変遅れDを経験するかもしれません。Thatがあって、0<はD<=Dと等しいです。 出力のときに、すべてのEFパケットがただ一つのクラス待ち行列を共有します。 クラス待ち行列は知られている値のE_p(S)=E(S)(E(S)がこのスケジューラが理想的算出量のバッファリングされた装置で実行されるモデルに文通されるところ)と共にスケジューラによって予定されています。
The computation of E_p is more complicated in this case. For such device, it can be shown that E_p = E(S)+2D+2B/R (see [13]).
E_pの計算はこの場合より複雑です。 そのような装置に関して、E_pがE(S)+2D+2B/Rと等しいのをそれを示すことができます。([13])を見てください。
Recall from the discussion of section 3 that bounding input burstiness B may not be easy in a general topology. In the absence of the knowledge of a bound on B one can bound E_p as E_p = E(S) + D*C_inp/R (see [13]).
セクション3の議論から、バウンドしている入力burstiness Bが一般的なトポロジーで簡単でないかもしれないと思い出してください。 B1におけるバウンドに関する知識がないときE_pとしての制限されたE_pはE(S)+D*C_inp/Rと等しいことができます。([13])を見てください。
Note also that the bounds in this section are derived using only the bound on the variable portion of the interval delay and the error bound of the output scheduler. If more details about the architecture of a device are available, it may be possible to compute better bounds.
また、このセクションの領域が間隔遅れの可変部分と出力スケジューラの誤りバウンドのときにバウンドだけを使用することで引き出されることに注意してください。 装置の構造に関するその他の詳細が利用可能であるなら、より良い領域を計算するのは可能であるかもしれません。
Charny, et. al. Informational [Page 13] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[13ページ]情報のRFC3247補足的情報行進
6. Security Considerations
6. セキュリティ問題
This informational document provides additional information to aid in understanding of the EF PHB described in [6]. It adds no new functions to it. As a result, it adds no security issues to those described in that specification.
この情報のドキュメントは、[6]で説明されたEF PHBの理解で支援するために追加情報を提供します。 それはどんな新しい機能もそれに加えません。 その結果、それはその仕様で説明されたものに安全保障問題を全く加えません。
7. References
7. 参照
[1] J.C.R. Bennett and H. Zhang, "WF2Q: Worst-case Fair Weighted
Fair Queuing", INFOCOM'96, March 1996.
[1] J.C.R.ベネットとH.チャン、「WF2Q:」 INFOCOM1996年3月96年の「最悪の場合の公正な均等化キューイング。」
[2] J.-Y. Le Boudec, P. Thiran, "Network Calculus", Springer Verlag
Lecture Notes in Computer Science volume 2050, June 2001
(available online at http://lcawww.epfl.ch).
[2] J.-Y。 Le Boudec(P.Thiran)は「微積分学をネットワークでつなぎます」、第2050コンピュータScience巻におけるSpringer Verlag Lecture Notes、2001年6月、(利用可能である、 http://lcawww.epfl.ch のオンライン、)
[3] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[4] J.C.R. Bennett, K. Benson, A. Charny, W. Courtney, J.Y. Le
Boudec, "Delay Jitter Bounds and Packet Scale Rate Guarantee
for Expedited Forwarding", Proc. Infocom 2001, April 2001.
[4] J.C.R.ベネット、K.ベンソン、A.シャルニー、W.コートニー、J.Y.Le Boudecは「完全優先転送のためのジター領域とパケットスケールレート保証を遅らせます」、Proc。 2001年4月のInfocom2001。
[5] A. Charny, J.-Y. Le Boudec "Delay Bounds in a Network with
Aggregate Scheduling". Proc. of QoFIS'2000, September 25-26,
2000, Berlin, Germany.
[5] A.シャルニー、J.-Y。 Le Boudecは「集合スケジューリングでネットワークで領域を遅らせます」。 Proc QoFIS'2000, September 25-26、2000、ベルリン(ドイツ)について。
[6] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K.,
Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V.,
Kalmanek, C., Ramakrishnan, K.K. and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March
2002.
[6] デイビーとB.とシャルニーとA.とベイカーとF.とベネットとJ.C.R.とベンソンとK.とBoudecとJ.とチウとA.とコートニーとW.とDavariとS.とFiroiuとV.とKalmanekとC.とRamakrishnanとK.K.と2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[7] T. Ferrari and P. F. Chimento, "A Measurement-Based Analysis of
Expedited Forwarding PHB Mechanisms," Eighth International
Workshop on Quality of Service, Pittsburgh, PA, June 2000.
[7]T.フェラーリとP.F.Chimento、「完全優先転送PHBメカニズムの測定ベースの分析」、サービスの質(ピッツバーグ(PA)2000年6月)に関する第8国際ワークショップ。
[8] S.J. Golestani. "A Self-clocked Fair Queuing Scheme for Broad-
band Applications". In Proceedings of IEEE INFOCOM'94, pages
636-646, Toronto, CA, April 1994.
[8] S.J.Golestani。 「BroadバンドApplicationsのためのSelfによって時間を計られたFair Queuing Scheme。」 IEEE INFOCOM94年、636-646ページのProceedings、トロントカリフォルニア、1994年4月に。
[9] P. Goyal, H.M. Vin, and H. Chen. "Start-time Fair Queuing: A
Scheduling Algorithm for Integrated Services". In Proceedings
of the ACM-SIGCOMM 96, pages 157-168, Palo Alto, CA, August
1996.
[9]P.Goyal、H.M.ヴィン、およびH.チェン。 「以下を列に並ばせる開始時刻フェア」 「統合サービスのためのスケジューリングアルゴリズム。」 ACM-SIGCOMM96のProceedings、157-168ページ、パロアルト(カリフォルニア)1996年8月に。
[10] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
Forwarding PHB", RFC 2598, June 1999.
[10] ジェーコブソンとV.とニコルズとK.とK.Poduri、「完全優先転送PHB」、RFC2598 1999年6月。
Charny, et. al. Informational [Page 14] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[14ページ]情報のRFC3247補足的情報行進
[11] Jacobson, V., Nichols, K. and K. Poduri, "The 'Virtual Wire'
Behavior Aggregate", Work in Progress.
[11] 仮想のワイヤ'振舞い集合」というジェーコブソン、V.、ニコルズ、K.、およびK.Poduriは進行中で働いています。
[12] M. Shreedhar and G. Varghese. "Efficient Fair Queuing Using
Deficit Round Robin". In Proceedings of SIGCOMM'95, pages
231-243, Boston, MA, September 1995.
[12] M.ShreedharとG.Varghese。 「赤字連続を使用する効率的な公正な列を作り。」 SIGCOMM95年、231-243ページのProceedings、ボストンMA、1995年9月に。
[13] Le Boudec, J.-Y., Charny, A. "Packet Scale Rate Guarantee for
non-FIFO Nodes", Infocom 2002, New York, June 2002.
[13]Le Boudec、J.-Y.、シャルニー、A. 「非先入れ先出し法ノードのためのパケットスケールレート保証」、Infocom2002、ニューヨーク2002年6月。
Charny, et. al. Informational [Page 15] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[15ページ]情報のRFC3247補足的情報行進
Appendix A. Difficulties with the RFC 2598 EF PHB Definition
RFC2598EF PHB定義における付録A.困難
The definition of the EF PHB as given in [10] states:
[10] 州の与えられるとしてのEF PHBの定義:
"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 [the EF PHB departure rate] 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."
「EF PHBはどんなdiffservノードからの集合のパケットの出発率も構成可能なレートを等しくなければならない、または超えなければならない特定のdiffserv集合に関する推進処理と定義されます。」 EF交通SHOULDはトランジットにノードを試みるいかなる他の交通の強度の如何にかかわらずこのレートを受け取ります。 「それ、構成されたレートで、等しいかそれが出力リンクMTUを送るわざわざがパケットを大きさで分けたより長いどんな時間間隔にわたっても測定されると[EF PHB出発率]SHOULDが少なくとも構成されたレートを平均する、」
A literal interpretation of the definition would consider the behaviors given in the next two subsections as non-compliant. The definition also unnecessarily constrains the maximum configurable rate of an EF aggregate.
定義の字義通りの解釈は不従順であるとして次の2つの小区分で与えられた振舞いを考えるでしょう。 また、定義は不必要にEF集合の最大の構成可能なレートを抑制します。
A.1 Perfectly-Clocked Forwarding
A.1は推進の完全に時間を計りました。
Consider the following stream forwarded from a router with EF- configured rate R=C/2, where C is the output line rate. In the illustration, E is an MTU-sized EF packet while x is a non-EF packet or unused capacity, also of size MTU.
EFが構成されていることのルータレートR=C/2から進められた以下の流れを考えてください。そこでは、Cが出力ライン料率です。 イラストでは、xは、サイズまたMTUについて非EFパケットか設備余力ですが、EはMTUサイズのEFパケットです。
E x E x E x E x E x E x...
|-----|
E x E x E x E x E x E x.。 |-----|
The interval between the vertical bars is 3*MTU/C, which is greater than MTU/(C/2), and so is subject to the EF PHB definition. During this interval, 3*MTU/2 bits of the EF aggregate should be forwarded, but only MTU bits are forwarded. Therefore, while this forwarding pattern should be considered compliant under any reasonable interpretation of the EF PHB, it actually does not formally comply with the definition of RFC 2598.
縦棒の間隔は3*MTU/Cです。(そのCは、MTU/(C/2)より優れているので、EF PHB定義を受けることがあります)。 この間隔の間、EF集合の3*MTU/2ビットを進めるべきですが、MTUビットだけを進めます。 したがって、この推進パターンがEF PHBのどんな理に適った解釈でも言いなりになると考えられるべきである間、それは実際に正式にRFC2598の定義に従いません。
Note that this forwarding pattern can occur in any work-conserving scheduler in an ideal output-buffered architecture where EF packets arrive in a perfectly clocked manner according to the above pattern and are forwarded according to exactly the same pattern in the absence of any non-EF traffic.
この推進パターンがどんな仕事を保存するスケジューラにもEFパケットが上のパターンに従って完全に時間を計られた方法で到着して、まさに同じパターンに応じてどんな非EF交通がないとき進められる理想的な出力でバッファリングされた構造で起こることができることに注意してください。
Trivial as this example may be, it reveals the lack of mathematical precision in the formal definition. The fact that no work-conserving scheduler can formally comply with the definition is unfortunate, and appears to warrant some changes to the definition that would correct this problem.
この例は些細であるかもしれませんが、それは公式の定義における、数学の精度の不足を明らかにします。 どんな仕事を保存するスケジューラも正式に定義に従うことができないという事実は、不幸であり、この問題を修正する定義へのいくつかの変化を保証するように見えます。
Charny, et. al. Informational [Page 16] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[16ページ]情報のRFC3247補足的情報行進
The underlying reason for the problem described here is quite simple - one can only expect that the EF aggregate is served at configured rate in some interval where there is enough backlog of EF packets to sustain that rate. In the example above the packets come in exactly at the rate at which they are served, and so there is no persistent backlog. Certainly, if the input rate is even smaller than the configured rate of the EF aggregate, there will be no backlog as well, and a similar formal difficulty will occur.
ここで説明された問題の基本的な理由はかなり簡単です--人は、EF集合がEFパケットのそのレートを支えることができるくらいの予備があるいくつかの間隔で構成されたレートで役立たれていると予想できるだけです。 例では、上に、ちょうどそれらが役立たれている速度でパケットを入らせるので、そして、どんなしつこい予備もありません。 確かに、入力率がEF集合の構成されたレートよりさらにわずかであるなら、また、予備が全くないでしょう、そして、同様の正式な困難は起こるでしょう。
A seemingly simple solution to this difficulty might be to require that the EF aggregate is served at its configured rate only when the queue is backlogged. However, as we show in the remainder of this section, this solution does not suffice.
この困難の外観上簡単な解決策は待ち行列がバックログされるときだけ、EF集合が構成されたレートで役立たれているのが必要であることであるかもしれません。 しかしながら、私たちがこのセクションの残りで示すように、この解決策は十分ではありません。
A.2 Router Internal Delay
A.2のルータの内部の遅れ
We now argue that the example considered in the previous section is not as trivial as it may seem at first glance.
私たちは、現在、前項で考えられた例が一見したところでは見えるかもしれないほど些細でないと主張します。
Consider a router with EF configured rate R = C/2 as in the previous example, but with an internal delay of 3T (where T = MTU/C) between the time that a packet arrives at the router and the time that it is first eligible for forwarding at the output link. Such things as header processing, route look-up, and delay in switching through a multi-layer fabric could cause this delay. Now suppose that EF traffic arrives regularly at a rate of (2/3)R = C/3. The router will perform as shown below.
パケットがルータに到着する時間と進めるそれが最初に出力リンクで適任である時間の間でEFがあるルータが前の例にもかかわらず、3Tの内部の遅れでレートR=C/2を構成した(TはそこでMTU/Cと等しい)と考えてください。 マルチ層の織物を通して切り替わるヘッダー処理、ルートルックアップ、および遅れのようなものはこの遅れを引き起こす場合がありました。 今度は、EF交通が定期的に(2/3) R=C/3のレートに達すると仮定してください。 ルータは以下に示すように働くでしょう。
EF Packet Number 1 2 3 4 5 6 ...
EFパケットNo.1 2 3 4 5 6…
Arrival (at router) 0 3T 6T 9T 12T 15T ...
到着(ルータにおける)0 3T 6T 9T 12T 15T…
Arrival (at scheduler) 3T 6T 9T 12T 15T 18T ...
到着(スケジューラの)3T 6T 9T 12T 15T 18T…
Departure 4T 7T 10T 13T 16T 19T ...
出発4T 7T 10T 13T 16T 19T…
Again, the output does not satisfy the RFC 2598 definition of EF PHB. As in the previous example, the underlying reason for this problem is that the scheduler cannot forward EF traffic faster than it arrives. However, it can be easily seen that the existence of internal delay causes one packet to be inside the router at all times. An external observer will rightfully conclude that the number of EF packets that arrived to the router is always at least one greater than the number of EF packets that left the router, and therefore the EF aggregate is constantly backlogged. However, while the EF aggregate is continuously backlogged, the observed output rate is nevertheless strictly less that the configured rate.
一方、出力はEF PHBのRFC2598定義を満たしません。 前の例のように、この問題の基本的な理由はスケジューラが到着するより速く交通をEFに送ることができないということです。 しかしながら、容易に、ルータには1つのパケットが内部の遅れの存在でいつもあるのを見ることができます。 外部の観察者は、ルータに到着したEFパケットの数が少なくともいつもルータを出て、したがってEF集合を出たEFパケットの数が絶えずバックログされるよりすばらしい1つであると正しく結論を下すでしょう。 しかしながら、EFである間、集合は絶え間なくバックログされます、それにもかかわらず、観測された出力率が厳密により少ないです。構成は評価します。
Charny, et. al. Informational [Page 17] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[17ページ]情報のRFC3247補足的情報行進
This example indicates that the simple addition of the condition that EF aggregate must receive its configured rate only when the EF aggregate is backlogged does not suffice in this case.
この例は、EF集合がバックログされるときだけ、EF集合が構成されたレートを受け取らなければならないという条件の簡単な添加がこの場合十分でないことを示します。
Yet, the problem described here is of fundamental importance in practice. Most routers have a certain amount of internal delay. A vendor declaring EF compliance is not expected to simultaneously declare the details of the internals of the router. Therefore, the existence of internal delay may cause a perfectly reasonable EF implementation to display seemingly non-conformant behavior, which is clearly undesirable.
しかし、ここで説明された問題は実際には基本的に重要です。 ほとんどのルータには、ある量の内部の遅れがあります。 EFが承諾であると宣言する業者が同時にルータのインターナルの詳細を宣言しないと予想されます。 したがって、完全に合理的なEF実現は内部の遅れの存在で、外観上非conformantの振舞いを見せるかもしれません。(それは、明確に望ましくありません)。
A.3 Maximum Configurable Rate and Provisioning Efficiency
A.3の最大の構成可能なレートと効率に食糧を供給すること。
It is well understood that with any non-preemptive scheduler, the RFC-2598-compliant configurable rate for an EF aggregate cannot exceed C/2 [11]. This is because an MTU-sized EF packet may arrive to an empty queue at time t just as an MTU-sized non-EF packet begins service. The maximum number of EF bits that could be forwarded during the interval [t, t + 2*MTU/C] is MTU. But if configured rate R > C/2, then this interval would be of length greater than MTU/R, and more than MTU EF bits would have to be served during this interval for the router to be compliant. Thus, R must be no greater than C/2.
それがよく理解されている、どんな非割込み型スケジューラがあるそれ、もRFC2598対応する、EF集合の構成可能なレートはC/2[11]を超えることができません。 これはちょうどMTUサイズの非EFパケットがサービスを始めるようにMTUサイズのEFパケットが時tに空の待ち行列に到達するかもしれないからです。 間隔[t、t+2*MTU/C]の間に進めることができたEFビットの最大数はMTUです。 しかし、構成されたレートR>C/2であるなら、この間隔は、MTU/Rより大きい長さがあって、ルータが対応であるためにMTU EFビットがこの間隔の間、役立たれなければならないだろうより多くでしょう。 したがって、RはC/2以下であるに違いありません。
It can be shown that for schedulers other than PQ, such as various implementations of WFQ, the maximum compliant configured rate may be much smaller than 50%. For example, for SCFQ [8] the maximum configured rate cannot exceed C/N, where N is the number of queues in the scheduler. For WRR, mentioned as compliant in section 2.2 of RFC 2598, this limitation is even more severe. This is because in these schedulers a packet arriving to an empty EF queue may be forced to wait until one packet from each other queue (in the case of SCFQ) or until several packets from each other queue (in the case of WRR) are served before it will finally be forwarded.
PQ以外のWFQの様々な実現などのスケジューラに関して、最大の対応する構成されたレートが50%よりはるかにわずかであるかもしれないことを示すことができます。 例えば、SCFQ[8]に関して、最大の構成されたレートはC/Nを超えることができません。そこでは、Nがスケジューラの待ち行列の数です。 RFC2598のセクション2.2で言いなりになるとして言及されたWRRに関しては、この制限はさらに厳しいです。 これは空のEF待ち行列に到達するパケットがこれらのスケジューラで最終的に互いからの1つの待ち行列(SCFQの場合における)か互いからの待ち行列(WRRの場合における)がそれの前に役立たれているいくつかのパケットまでのパケットを進めるまでやむを得ず待つかもしれないからです。
While it is frequently assumed that the configured rate of EF traffic will be substantially smaller than the link bandwidth, the requirement that this rate should never exceed 50% of the link bandwidth appears unnecessarily limiting. For example, in a fully connected mesh network, where any flow traverses a single link on its way from source to its destination there seems no compelling reason to limit the amount of EF traffic to 50% (or an even smaller percentage for some schedulers) of the link bandwidth.
頻繁にEF交通の構成された速度がリンク帯域幅より実質的にさらにわずかになると思われますが、このレートがリンク帯域幅の50%を決して超えるべきでないという要件は、不必要に制限しながら、現れます。 例えば、完全に接続された網目状ネットワークでは、リンク帯域幅の50%(または、いくつかのスケジューラのためのさらにわずかな百分率)へのEF交通の量を制限するやむにやまれない理由は全く見えません。そこでは、どんな流れもソースから目的地への途中に単一のリンクを横断します。
Another, perhaps even more striking example is the fact that even a TDM circuit with dedicated slots cannot be configured to forward EF packets at more than 50% of the link speed without violating RFC 2598
別のもの、恐らくさらに多くの顕著な例がリンク速度の50%以上でRFC2598に違反しないでパケットをEFに送るためにひたむきなスロットがあるTDMサーキットさえ構成できないという事実です。
Charny, et. al. Informational [Page 18] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[18ページ]情報のRFC3247補足的情報行進
(unless the entire link is configured for EF). If the configured rate of EF traffic is greater than 50% (but less than the link speed), there will always exist an interval longer than MTU/R in which less than the configured rate is achieved. For example, suppose the configured rate of the EF aggregate is 2C/3. Then the forwarding pattern of the TDM circuit might be
(全体のリンクがEFのために構成されない場合。) EF交通の構成された速度が50%(リンク速度よりそれほど)以上であるなら、間隔は構成されたレート以下が達成されるMTU/Rより長い間、いつも存在するでしょう。 例えば、EF集合の構成されたレートが2C/3であると仮定してください。 そして、TDMサーキットの推進パターンはそうです。
E E x E E x E E x ...
|---|
E E x E E x E E x… |---|
where only one packet is served in the marked interval of length 2T = 2MTU/C. But at least 4/3 MTU would have to be served during this interval by a router in compliance with the definition in RFC 2598. The fact that even a TDM line cannot be booked over 50% by EF traffic indicates that the restriction is artificial and unnecessary.
1つのパケットだけが長さの著しい間隔で役立たれているところでは、2Tは2MTU/Cと等しいです。 しかし、少なくとも4/3MTUはRFC2598との定義に従ってこの間隔の間、ルータによって役立たれなければならないでしょう。 TDM線さえ予約できないというEF交通による50%以上の事実は、制限が人工であって不要であることを示します。
A.4 The Non-trivial Nature of the Difficulties
困難のA.4の重要な本質
One possibility to correct the problems discussed in the previous sections might be to attempt to clarify the definition of the intervals to which the definition applied or by averaging over multiple intervals. However, an attempt to do so meets with considerable analytical and implementation difficulties. For example, attempting to align interval start times with some epochs of the forwarded stream appears to require a certain degree of global clock synchronization and is fraught with the risk of misinterpretation and mistake in practice.
前項で議論した問題を修正する1つの可能性が、定義が適用された間隔の定義をはっきりさせる試みか複数の間隔にわたって平均することによって、あるかもしれません。 しかしながら、そうする試みは分析するのと実現のかなりの困難に遭います。 例えば、進められた流れのいくつかの時代に間隔スタート回数を一直線にするのを試みるのは、ある度のグローバルな時計同期を必要とするように見えて、実際には誤解と誤りのリスクについて悲惨です。
Another approach might be to allow averaging of the rates over some larger time scale. However, it is unclear exactly what finite time scale would suffice in all reasonable cases. Furthermore, this approach would compromise the notion of very short-term time scale guarantees that are the essence of EF PHB.
別のアプローチはレートが何らかのより大きいタイムスケールの上平均するのを許容することであるかもしれません。 しかしながら、どんな有限タイムスケールがすべての妥当な場合で十分であるかは、まさに不明瞭です。 その上、このアプローチはEF PHBの本質である非常に短期的なタイムスケール保証の概念で妥協するでしょう。
We also explored a combination of two simple fixes. The first is the addition of the condition that the only intervals subject to the definition are those that fall inside a period during which the EF aggregate is continuously backlogged in the router (i.e., when an EF packet is in the router). The second is the addition of an error (latency) term that could serve as a figure-of-merit in the advertising of EF services.
また、私たちは2つの簡単なフィックスの組み合わせについて調査しました。 1番目は定義を条件とした唯一の間隔がEF集合がルータで絶え間なくバックログされる(すなわち、いつ、ルータにはEFパケットがありますか)期間に低下するものであるという条件の添加です。 2番目はフィギュア・オブ・メリットとしてEFサービスの広告で勤めることができた誤り(潜在)用語の添加です。
With the addition of these two changes the candidate definition becomes as follows:
これらの2回の変化の添加によると、候補定義は以下の通りになります:
Charny, et. al. Informational [Page 19] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[19ページ]情報のRFC3247補足的情報行進
In any interval of time (t1, t2) in which EF traffic is continuously backlogged, at least R(t2 - t1 - E) bits of EF traffic must be served, where R is the configured rate for the EF aggregate and E is an implementation-specific latency term.
EF交通が絶え間なくバックログされる時間(t1、t2)のどんな間隔でも、少なくともEF交通のR(t2--t1--E)ビット(RはEF集合の構成されたレートである)に役立たなければなりません、そして、Eは実現特有の潜在用語です。
The "continuously backlogged" condition eliminates the insufficient- packets-to-forward difficulty while the addition of the latency term of size MTU/C resolves the perfectly-clocked forwarding example (section A.1), and also removes the limitation on EF configured rate.
サイズMTU/Cの潜在用語の添加は、完全に時間を計られた推進の例(セクションA.1)を決議して、また、構成されたEFで制限を取り除きますが、「絶え間なくバックログされた」状態は不十分な進めるパケット困難を排除します。レート。
However, neither fix (nor the two of them together) resolves the example of section A.2. To see this, recall that in the example of section A.2 the EF aggregate is continuously backlogged, but the service rate of the EF aggregate is consistently smaller than the configured rate, and therefore no finite latency term will suffice to bring the example into conformance.
しかしながら、どちらのフィックス(または、それらの2つが一緒にいる)もセクションA.2に関する例を決議しません。 これを見るには、セクションA.2に関する例では、EF集合が絶え間なくバックログされますが、EF集合のサービス率が例を順応に運び込むように構成されたレートが十分ですが、したがって、どんな有限潜在期間も十分でないというよりも一貫してわずかであると思い出してください。
Appendix B. Alternative Characterization of Packet Scale Rate Guarantee
パケットスケールレート保証の付録B.代替手段特殊化
The proofs of several bounds in this document can be found in [13]. These proofs use an algebraic characterization of the aggregate definition given by (eq_1), (eq_2), and packet identity aware definition given by (eq_3), (eq_4). Since this characterization is of interest on its own, we present it in this section.
[13]で本書ではいくつかの領域の証拠を見つけることができます。 これらの証拠は(eq_1)、(eq_2)与えられた、集合定義、および(eq_3)、(eq_4)与えられたパケットのアイデンティティの意識している定義の代数的な特殊化を使用します。 この特殊化がそれ自身のところでおもしろいので、私たちはこのセクションにそれを示します。
Theorem B1. Characterization of the aggregate definition without
f_n.
定理B1。 fのない集合定義の特殊化。
Consider a system where packets are numbered 1, 2, ... in order of arrival. As in the aggregate definition, call a_n the n-th arrival time, d_n - the n-th departure time, and l_n the size of the n-th packet to depart. Define by convention d_0=0. The aggregate definition with rate R and latency E_a is equivalent to saying that for all n and all 0<=j<= n-1:
到着の順にパケットが番号付の1、2であるシステムを考えてください。 集合定義のように、出発するn番目のパケットのサイズにd--第n到着時間のa、出発時間、およびn番目のlに電話をしてください。 コンベンションdで、_0=0を定義してください。 jすべてのnとすべての0<のためのそれ=<がn-1と等しいと言うのにレートRと潜在Eがある集合定義は同等です:
d_n <= E_a + d_j + (l_(j+1) + ... + l_n)/R (eq_b1)
d<はE+d_j+(l_(j+1)+…+l)/Rと等しいです。(eq_b1)
or
または
there exists some j+1 <= k <= n such that
k<いくらかのj+1<==nは存在しています。
d_n <= E_a + a_k + (l_k + ... + l_n)/R (eq_b2)
+ d<=Eは_k+(l_k+…+l)/Rです。(eq_b2)
Charny, et. al. Informational [Page 20] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[20ページ]情報のRFC3247補足的情報行進
Theorem B2. Characterization of packet-identity-aware definition
without F_n.
定理B2。 特殊化、パケットのアイデンティティ意識する、Fのない定義。
Consider a system where packets are numbered 1, 2, ... in order of arrival. As in the packet-identity-aware definition, call A_n, D_n the arrival and departure times for the n-th packet, and L_n the size of this packet. Define by convention D_0=0. The packet identity aware definition with rate R and latency E_p is equivalent to saying that for all n and all 0<=j<= n-1:
到着の順にパケットが番号付の1、2であるシステムを考えてください。 同じくらい中、パケットのアイデンティティ意識する、定義、n番目のパケットのための到着と出発時間にA、Dに電話をして、このパケットのサイズにLに電話をしてください。 コンベンションDで、_0=0を定義してください。 すべてのnとすべての0<のためのそれがj<と等しいと言うのにレートRと潜在E_pがある定義が同等であることを意識しているパケットのアイデンティティはn-1と等しいです:
D_n <= E_p + D_j + (L_{j+1} + ... + L_n)/R (eq_b3)
D<がE_p+D_j+と等しい、(L_j+1、+…+L)/R(eq_b3)
or
または
there exists some j+1 <= k <= n such that
k<いくらかのj+1<==nは存在しています。
D_n <= E_p + A_k + (L_k + ... + L_n)/R (eq_b4)
+ E D<=_pは_k+(L_k+…+L)/Rです。(eq_b4)
For the proofs of both Theorems, see [13].
両方のTheoremsの証拠に関しては、[13]を見てください。
Charny, et. al. Informational [Page 21] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[21ページ]情報のRFC3247補足的情報行進
Acknowledgements
承認
This document could not have been written without Fred Baker, Bruce Davie and Dimitrios Stiliadis. Their time, support and insightful comments were invaluable.
フレッド・ベイカー、ブルース・デイビー、およびデーメートリオスStiliadisなしでこのドキュメントを書くことができませんでした。 彼らの時間、サポート、および洞察に満ちたコメントは非常に貴重でした。
Authors' Addresses
作者のアドレス
Anna Charny Cisco Systems 300 Apollo Drive Chelmsford, MA 01824
アンナシャルニーシスコシステムズ300アポロDriveチェルムズフォード、MA 01824
EMail: acharny@cisco.com
メール: acharny@cisco.com
Jon Bennett Motorola 3 Highwood Drive East Tewksbury, MA 01876
ジョン・ベネット・モトローラ3Highwoodのドライブの東テュークスベリー、MA 01876
EMail: jcrb@motorola.com
メール: jcrb@motorola.com
Kent Benson Tellabs Research Center 3740 Edison Lake Parkway #101 Mishawaka, IN 46545
46545におけるケントベンソンTellabsリサーチセンター3740エディソンミシワカ湖公園道路#101
EMail: Kent.Benson@tellabs.com
メール: Kent.Benson@tellabs.com
Jean-Yves Le Boudec ICA-EPFL, INN Ecublens, CH-1015 Lausanne-EPFL, Switzerland
ジーン-イヴLe Boudecイカ-EPFL、旅館Ecublens、CH-1015ローザンヌ-EPFL、スイス
EMail: jean-yves.leboudec@epfl.ch
メール: jean-yves.leboudec@epfl.ch
Angela Chiu Celion Networks 1 Sheila Drive, Suite 2 Tinton Falls, NJ 07724
ニュージャージー ネットワーク1シェイラが運転するアンジェラチウCelion、2つのスイートTinton滝、07724
EMail: angela.chiu@celion.com
メール: angela.chiu@celion.com
Charny, et. al. Informational [Page 22] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[22ページ]情報のRFC3247補足的情報行進
Bill Courtney TRW Bldg. 201/3702 One Space Park Redondo Beach, CA 90278
ビルコートニーTRW Bldg. リドンドビーチ、201/3702 oneスペースParkカリフォルニア 90278
EMail: bill.courtney@trw.com
メール: bill.courtney@trw.com
Shahram Davari PMC-Sierra Inc 411 Legget Drive Ottawa, ON K2K 3C9, Canada
K2K 3C9、カナダのShahram Davari PMC-連峰Inc411Legget Driveオタワ
EMail: shahram_davari@pmc-sierra.com
メール: shahram_davari@pmc-sierra.com
Victor Firoiu Nortel Networks 600 Tech Park Billerica, MA 01821
ビルリカ、ビクタFiroiuノーテルネットワーク600の科学技術のPark MA 01821
EMail: vfiroiu@nortelnetworks.com
メール: vfiroiu@nortelnetworks.com
Charles Kalmanek AT&T Labs-Research 180 Park Avenue, Room A113, Florham Park NJ
チャールズKalmanek AT&T研究室Research180Parkアベニュー、余地のA113、Florham Parkニュージャージー
EMail: crk@research.att.com
メール: crk@research.att.com
K.K. Ramakrishnan TeraOptic Networks, Inc. 686 W. Maude Ave Sunnyvale, CA 94086
K.K.Ramakrishnan TeraOpticはInc.686W.モード・Aveサニーベル、カリフォルニア 94086をネットワークでつなぎます。
EMail: kk@teraoptic.com
メール: kk@teraoptic.com
Charny, et. al. Informational [Page 23] RFC 3247 Supplemental Information March 2002
etシャルニー、アル。 2002年の[23ページ]情報のRFC3247補足的情報行進
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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 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機能のための基金は現在、インターネット協会によって提供されます。
Charny, et. al. Informational [Page 24]
etシャルニー、アル。 情報[24ページ]
一覧
スポンサーリンク
