トークンバケット、補充速度とバーストの上限を分けて読む

上から白い球が入る薄緑の透明な筒と、下にたまった桃色の球、横の出口から球を受ける薄紫の皿。

通信量を「毎秒1000バイトまで」と決めても、1000バイトを超えるパケットが一度届いたら必ず違反になるとは限りません。短時間のまとまった到着をどこまで認めるかは、平均的な補充速度とは別の条件だからです。トークンバケットは、この二つを分けて表す仕組みです。

一定の速さで増える利用枠をトークンと呼び、ためられる量に上限を設けます。通信が届いたとき、その大きさに見合う枠が残っているかを調べます。ここでは、一つのバケットでパケット全体の枠を要求する単純なモデルを使い、補充速度と上限の役割を追います。

簡単にまとめると?

  • 補充速度は、時間とともに利用枠が戻る速さです。バケット容量は、使わずにためておける枠の上限です。
  • 同じ補充速度でも、容量が大きければ短時間に続けて届くパケットを多く適合と判定できます。通信をいつ送るかは、別の処理です。
  • 枠不足を検出した後に、捨てる・印を付ける・待たせるという対応を混同しないことが、設定を読む手掛かりになります。

速さと容量を、別々の単位で読む

バケットに入っているのは、実際のパケットではなく、通信量を認めるための残高です。ここでは1トークンを1バイト分とします。補充速度Rを1000バイト/秒、容量Bを2000バイトと決めると、残高は1秒に1000バイト分ずつ戻ります。ただし、上限の2000を超えて蓄積しません。

前回の更新からΔt秒たったときの残高は、直前の残高にR×Δtを加え、Bで打ち切ります。続いて長さLバイトのパケットを判定し、残高がL以上ならLを引きます。足りなければ不適合とし、この説明例では残高を減らしません。RFC 3290の付録Aは、こうしたパケット全体の枠を求める厳密な判定と、一時的な借越しを認める判定を区別しています。以下は前者に限った例です。[1]

初期残高も条件の一部です。空から始める場合と、満杯から始める場合では、最初のパケットへの返事が違います。以下では満杯から始め、時間は連続的に扱います。実機のタイマー精度や補充処理の刻みは、この計算には入れていません。

同じ毎秒1000バイトでも、二つ目の返事が変わる

1500バイトのパケットが、開始時刻0秒、0.2秒、1.0秒に届くとします。補充速度はどちらも1000バイト/秒で、容量だけ2000バイトと4000バイトに分けます。図は、この到着列を順番に計算した独自の例です。

補充速度1000バイト毎秒、各パケット1500バイト。容量2000では0秒は適合、0.2秒は残高700で不適合、1秒は適合。容量4000では三つとも適合。
同じ到着時刻・長さ・補充速度で、容量だけを変更した計算。各欄は判定前の残高、判定、判定後の残高を示します。実機の通信速度を測定した結果ではありません。

容量2000の側では、最初のパケットは適合し、残高が500になります。0.2秒後には200増えて700ですが、次の1500バイトには届きません。このパケットは不適合で、残高は700のままです。その後0.8秒で800が加わり、1.0秒時点には1500となるため、三つ目は適合します。

容量4000の側では、最初の後に2500が残り、0.2秒時点では2700です。二つ目も適合して1200が残ります。さらに0.8秒後には2000となり、三つ目を認めた後にも500が残ります。補充速度は変えていないのに、短時間に使える初期の蓄えが違うため、結果が分かれました。

この違いを「容量4000なら常に2倍速い」と読むことはできません。最初の1秒で適合した量は、今回の到着列では3000バイトと4500バイトです。割合は到着の仕方で変わります。また、ここで決めたのは適合判定だけであり、回線上を実際に流れる速度や、受信側での処理完了時間ではありません。

短い区間ほど、蓄えの影響が大きい

単純なトークンバケットに適合する通信量は、長さtの区間で「R×t+B」を上限として捉えられます。RFC 3290の付録A.2に示された関係です。[1] 区間の初めに最大Bの残高があり、その間に最大R×tだけ補充される、と考えると意味を追えます。途中で満杯になって余分な補充を捨てれば、使える量はこの上限より小さくなります。

R=1000、B=2000なら、1秒区間の上限は3000バイト、10秒区間では12000バイトです。区間の長さで割った値は、それぞれ3000バイト/秒と1200バイト/秒になります。長い区間では、最初の蓄えBを区間全体へ割り振った分が小さくなり、補充速度Rの影響が中心になります。短い観測窓でRを上回ったという事実だけでは、不適合とは判断できません。

ただし、この上限を満たす到着列を必ず実回線へ流せる、という保証ではありません。パケットを直列に送る時間、回線の容量、他の通信との競合、後段の待ち行列が別にあります。ここでの式は、単純化した利用枠の関係を表しています。

枠が足りないと分かることと、パケットを捨てること

判定器が不適合を返した後の扱いは、別に決める必要があります。ポリシングでは超過したパケットを落とすなどの制御を行い、シェーピングでは待ち行列を使って送出のタイミングを調整します。RFC 3290は、メータ、破棄、キューなどを別の機能として整理しています。[1]

別の具体例がRFC 2697のsrTCMです。これは共通の補充速度と二つのバケットを使い、パケットに緑・黄・赤の分類を付ける方式です。Color-Blindモードでは、それぞれのバケットにパケット全体を賄う残高があるかを順に確認し、両方とも不足なら赤にします。赤と判定する処理そのものを、送信待ちや破棄と同一視しないことが大切です。[2] 本文の一つのバケットの計算を、この二つのバケットの動作へそのまま置き換えることはできません。

先ほどの700バイトしか残っていない場面で、同じ1500バイトを待たせ、他に枠を使う通信がないと仮定すると、不足800を補うには0.8秒かかります。これは待ち行列を追加した場合の局所的な計算です。最初の例では不適合パケットを待たせていないため、二つのモデルの結果を混ぜてはいけません。実際の待ち時間には、先に並んでいるパケットも関わります。

設定を比べるときに確かめたい条件

容量は、長く休んだ分を無限にためる仕組みではありません。満杯の容量2000なら、さらに10秒待っても残高は2000です。反対に空から満杯まで戻る時間は、今回の条件では容量2000で2秒、容量4000で4秒になります。これは補充時間であり、回線がバーストを送り切る時間ではありません。

パケット単位の厳密な判定では、容量を1000にして1500バイトを照合すると、いくら待っても残高が足りません。RFC 2697も、正のバースト容量はストリームの最大IPパケット長以上にすることを推奨しています。また同文書の通信量の単位は、IPヘッダーを含み、リンク固有のヘッダーは含まないバイト数です。[2] 同じ数字の設定でも、どこからどこまでを数えるかが違えば、同じ制限にはなりません。

比較する際は、補充速度、蓄積上限、初期残高、パケットを丸ごと数える条件、枠不足後の処理を分けて確認します。「毎秒いくら」という一つの数字だけでは、短い集中を許すか、待たせるか、落とすかまで読み取れないためです。

参考資料

  1. RFC Editor, RFC 3290: An Informal Management Model for Diffserv Routers(2002年5月)、3.3、5.1.3、付録A.2–A.3。Informational文書。パケット単位の厳密・緩やかな適合判定を区別しています。
  2. RFC Editor, RFC 2697: A Single Rate Three Color Marker(1999年9月)、2–3節。Informational文書。本文の一バケット例とは異なる、二バケットの分類方式です。ウェブ資料は2026年10月23日確認。