要約

  • RFC 1989 は LQR の測定機構を共通化する一方、品質をどう評価し、悪化時に何をするかという運用方針を各実装に委ねた。
  • 送信側の累積カウンター、受信時に保存された観測、その観測を後の報告で返すフィールドを差分比較することで、双方向のパケット・オクテット損失を推定できた。
  • LQR は判決でも認証でもない。方向ごとの交渉、32ビット値の周回、Magic-Number の限定的役割、未規定のセキュリティと復旧手順を別々に扱う必要がある。

正常に開いたリンクが、使えるとは限らない

キャリアは上がっている。LCP も Opened に達している。それでもパケットが落ち続ければ、上位の通信にとっては使えない回線になり得る。代替経路を持つルーターなら切り替えたい。唯一のアクセス回線なら、多少の損失があっても維持したいかもしれない。同じ損失率から同じ結論が出ないのは、実装差ではなく運用条件の差である。

PPP Link Quality Monitoring は 1992 年 5 月の RFC 1333 で文書化され、1996 年 8 月の RFC 1989 がそれを置き換えた。後者は設計の境界を明言する。Link-Quality-Report の形式と利用手順という「mechanism」は PPP が定める。一方、品質を良い・悪いと評価し、その後にどう動くかという「policy」は定めない。

標準が判断を放棄したのではない。相互運用に必要な合意だけを切り出したのである。異なる装置が同じ測定結果を読めれば、安価な予備回線、遅延に敏感な業務、再送可能な転送ごとに別の基準を採用できる。

Quality-Protocol は片方向の依頼だった

品質監視は既定で無効である。報告を受けたい端点は、LCP の Configure-Request にタイプ 4 の Quality-Protocol オプションを入れる。Link Quality Report を示す値は 16 進の c025。相手が Configure-Ack を返すと、その相手は LQR を送ることに同意したことになる。

この約束は方向を持つ。要求側は「こちらへ報告してほしい」と伝えており、自分も同じ報告を返すとは述べていない。両方向は独立に交渉でき、RFC 1661 は方向ごとに異なる品質プロトコルを使うことさえ認めた。ただし、LQR の送信に合意した実装は、自ら報告を要求していなくても、受信した LQR を正しく処理しなければならない。

LQR 用オプションには 4 オクテットの Reporting-Period が加わる。単位は 100 分の 1 秒で、報告間隔の上限を示す。相手はそれより早く送ってよい。ゼロはタイマーを使わず、LQR を受信したら直ちに返すモードである。両端がゼロを選んで互いに最初の一通を待つ状態は、交渉規則で防がれた。

Protocol-Reject が LQR を指定して戻れば、LQR 送信は停止しなければならない。したがって Ack は、その時点で報告義務が成立した証拠である。その後の報告到達や品質判定までを証明するものではない。

相手が見た自分の送信量が戻ってくる

LQR のフィールド名は、報告を要求した受信側から見た名前になっている。PeerOutPackets、PeerOutOctets、PeerOutLQRs は、送信した相手が現在持つ出力カウンターである。受信処理では、ローカルに SaveInPackets、SaveInOctets、破棄、エラー、SaveInLQRs を論理的に付加する。SaveIn は入ってきた線上に存在したデータではなく、受信点での観測だ。

後で反対方向へ報告すると、この保存値は PeerIn... として元の送信者へ戻る。LastOut... は、相手から最後に受け取った「ローカル側が以前送った量」の写しである。端点は相手の現在の送信申告と、相手が以前に保存した受信観測を同じ報告系列の中で比較できる。

各パケットに受領書を付ける方式ではない。累積値の差分を使う。連続する PeerInPackets と LastOutPackets の増分を比べれば、ローカル送信方向の損失を見積もれる。SaveInPackets と PeerOutPackets は受信方向を示す。オクテットでも同様の比較ができ、相手側の破棄やエラーの増分は、物理障害ではなく受信処理の輻輳だった可能性を検討する材料になる。

あくまで推定材料である。カウンターは説明の範囲を狭めるが、相手の申告を認証せず、原因を一つに確定もしない。

実装が違っても同じ数になるようにした

PPP のフレーミングは、ソフトウェア、別プロセス、モデムや専用ハードウェアのいずれにも置ける。非同期エスケープを主プロセスが見ない構成もある。各装置が目の前の物理カウンターをそのまま報告すれば、表現上の差がリンク損失に見えてしまう。

RFC 1989 は測定の参照表現を定めた。FCS 計算に含まれるオクテット、FCS 自体、フレーム当たり 1 個のフラグを数える。追加フラグやエスケープのビット／オクテットは数えない。目的は物理帯域の全消費量ではなく、実装をまたいで再現できる情報量である。InGoodOctets は破棄またはエラーに分類されたフレームのオクテットを含めない。

報告へ挿入する値には、その LQR 自身が増やす予定のパケットとオクテットも含める。値は増え続けるが、32 ビットの上限でゼロへ周回するため、差分計算は周回を認識しなければならない。LCP の確立時に共通の初期値へ戻らないインターフェースカウンターもある。同期に使うのは絶対値ではなく、連続報告間の変化だ。

この厳密さがなければ、片側だけがエスケープを数えたり、周回を負の巨大値として引いたりする。測定規格では、フィールド形式と同じくらい「何を一単位と呼ぶか」が重要だった。

一通の欠落を障害宣言にしなかった

LQR は通常トラフィックより遅れないよう、マルチプレクサで最優先に扱う。それでも頻度を上げれば必ず早く分かるわけではない。良好なリンクでは LQR は余計な通信であり、業務への干渉を最小化すべきだ。長い間隔は変動を平滑化するが、完全断の認識を遅らせる。

非対称障害では直感が逆になる。受信 LQR が届き、送信方向が非常に悪いと示している場合、こちらから報告を増やしても、それら自身が同じ悪い方向で失われる。送信方向は良いが受信方向が悪い場合には、複数回の送信で一部が届き、相手の判断材料を増やせる。

想定時刻に LQR が来ない、または受け取った値が本当に悪い場合でも、少なくとももう一通を送ることが推奨された。アルゴリズムによる決定には最低 2 往復分が必要である。最初の欠落は一時的な高負荷か、LQR そのものの損失かもしれない。

RFC 1989 はヒステリシスを勧め、直近 N 期間のうち K 回成功する方式を例示した。しかし K、N、閾値を標準化しなかった。復旧も未規定である。NCP を閉じて LQR だけを継続し、品質回復後に再設定する案はあるが、経路変更、切断、継続のどれを選ぶかはローカル方針に属した。

c025 には信頼の証明が含まれない

Magic-Number が交渉済みなら、LQR で自分の番号を受け取ることはループバックの兆候になる。未交渉ならフィールドはゼロで、受信側は無視する。これはデータリンク異常の検出補助であり、相手装置や運営主体の本人確認ではない。

RFC 1989 はセキュリティ問題を論じていないと明記する。報告の暗号学的完全性も、カウンター申告の独立した資格証明も定義しない。PPP の認証は別のフェーズとプロトコルで行う。観測点に c025 があれば LQR 形式のパケットがそこへ届いたとは言えるが、値が外部世界の真実であることや、アプリケーション配送の成功までは言えない。

運用記録では、Configure-Request と Ack/Reject、交渉周期、実到着時刻、生カウンター、周回補正、差分、判定基準の版、実行した操作を分けて残すべきだ。「リンク不良」という一つの時刻だけでは、誰の規則が結論を作ったのか消えてしまう。

共通化したのは証拠の入口まで

LQR の歴史的な強さは、完全な自動判断ではなく、合意範囲の小ささにある。要求方法、最大報告間隔、測定点、双方向の観測を返す方法、差分の意味は共有する。サービスが耐えられる損失と、復旧に払える費用は共有しなくてよい。

そのため、二つの実装が異なるヒステリシスや K/N 方式を使っても、同じ LQR を解釈できた。ローカルな革新は中央の許可ではなく、交渉した最小機構を守ることで可能になった。

IANA の c025 登録はプロトコル種別の証拠である。Configure-Ack は報告義務の受諾を示す。差分は損失推定を支え、破棄とエラーは仮説を絞る。そこから先は、ローカル方針が状態を決め、経路、NCP、物理リンク、アプリケーションの記録が結果を検証する。

報告は判断を共有しなかった。判断できるだけの共通言語を共有した。

参照資料