要約

  • RFC 1008はISOトランスポートで任意に使えるフロー制御確認を論じた。閉じた信用ウィンドウを開くAKが失われた場合、受信側は短い間隔でAKを再送し、送信側からFCC付きAKを受け取れば止められる。
  • Wayne McCoyの1987年6月の案内には、FCCの実使用経験は報告されていないとある。返答がなければ高速再送は上限で終わり、通常のウィンドウタイマーに戻る。

二つの端末がデータをやり取りしている。受信側のバッファが埋まり、送信側に与える信用がなくなる。送信側は止まる。やがて受信側に空きができ、再開を告げるAKを送る。しかし、その短い知らせだけが消える。送信側は最後に届いた「待て」に忠実だ。受信側は受け入れ可能だと知っている。双方の動作は筋が通っているのに、会話全体は黙り込む。

Wayne McCoyは1987年6月のRFC 1008でこのようなずれを実装者に示した。ISOトランスポートの実装ガイドとして配布された文書で、窓、バッファ、タイマーの実務を扱う。AKはデータを受け取ったという返事だけではない。閉じた窓を開くAKや信用を減らした後の一部のAKは、相手が次にどれだけ送れるかを伝える。そこには小さな許可証が入っている。

そのAKが失われても、空いたバッファは消えない。失われるのは送信側の知識だ。通常のウィンドウタイマーが後で状態を合わせ直す道はあるが、McCoyはそれを比較的長い待ち時間と見た。FCCというフロー制御確認は、その待ちを短くするための任意の方法だった。受信側が重要なAKを短い間隔で繰り返し、相手に状態の確認を求める。送信側がFCCパラメータを含むAKで返せば、高速の繰り返しを止める。

返事がなければ際限なく送り続けるわけではない。決めた回数で止まり、通常のウィンドウタイマーが再び担当する。しかもFCCは任意であり、データ送信側に応答義務はない。McCoyは高速再送中に止まっているウィンドウタイマーを兼用すれば、時計を一つ増やさずに済むと提案した。形式的な説明では読みやすさのため別々に描いた。高速側の間隔は、往復の両方向の遅延を表すErl + Elr程度とする案も示している。

この追加手続きが得かどうかは、実際の条件で変わる。信用がどれほど頻繁に減るか、TPDUがどれほど失われるか、通常のタイマーがどれほど長いか、窓の大きさと既存の応答方針はどうか。制御メッセージを増やせば処理の負担が増す。長く黙っていれば使える受信容量を遊ばせる。McCoyはFCCとAKの高速再送について、効果を判断できる実使用の報告はないと率直に書いた。

フロー制御を信号機に例えるなら、ここでは青に変わった灯りを運転手だけが見逃した。受信側はもう一度知らせ、見えたかどうかを聞くことができる。大事なのは、窓が開いたという事実と、その知らせが送信側に届いたという事実が別物である点だ。通信を再開させるのは空き容量だけではない。相手がその空きを知ったという、小さな証拠でもある。