要約

  • RFC 3758は放棄条件を上位サービスに委ね、FORWARD TSNをシーケンス空間を前へ進める共通の合図にした。
  • Timed reliabilityでも、期限が切れた瞬間にSCTPスタックが必ずメッセージを調べるとは限らない。

期限は切れた。それでもSCTPスタックがそのメッセージを確認するのは次の処理機会かもしれない。RFC 3758が示したのは、期限の意味と期限を検出する実装時刻が同じとは限らない、という境界だ。

2004年のこの拡張は、SCTPを一律に不確実な転送へ変えたわけではない。上位層がメッセージ単位で、どれだけ送信・再送を続けるかを指定できるようにした。双方が関連付けの確立時にFORWARD TSN対応を示せば、送信側はあるメッセージを追い続けるのをやめ、受信側へ累積TSN位置を進めるよう伝えられる。順序付きデータではストリーム内のシーケンス番号も使い、欠落の後ろで待たされていたメッセージを解放する。

ここで重要なのは、放棄を決める方針と、線上で順序を回復する制御情報が別だという点だ。受信側は送信側が期限切れ、再送回数の上限、あるいは別のサービス規則のどれを使ったか知る必要がない。どのTSNをもう待たなくてよいか、どのストリーム上のメッセージが先へ進めるかが分かればよい。FORWARD TSNはアプリの判断理由ではなく、その結果だけを表す。

期限の例では、旧来のルールとの差が見える。RFC 2960のSCTPでは、lifetimeはまだ初回送信されていない古いデータを送らないための値だった。初回送信が期限内に済めば、そのメッセージは通常の信頼転送として扱われ、再送が続く。RFC 3758のtimed reliabilityはこの制約を外し、すでにTSNが割り当てられたメッセージも期限切れ後に放棄できるようにした。

ただし、これは各メッセージに独立したタイマーを設け、満了時刻そのものに処理を走らせる規定ではない。送信側はTSNを割り当てる前に期限を調べ、すでにTSNがある場合は送信・再送の前に評価する。さらにRFC 3758は、タイマーをメッセージごとに維持する必要はないと説明する。TSN割り当て、送信、再送タイマーの満了など、既にスタックが処理している時点で確認できる。実装は別の都合のよい機会にも評価でき、期限到達と同時に調べる義務はない。

そのためlifetimeを受け付けるAPIだけでは、厳密なリアルタイム期限の保証にならない。値は、評価されたメッセージがまだ送信対象かどうかを決めるが、スタックが評価を行う瞬間まで規定するとは限らない。期限に敏感なアプリケーションは、何を「期限」と呼ぶのか、スタックの評価遅延をどう扱うのかをサービス仕様に明記する必要がある。

メッセージがどこまで進んだかも関係する。TSN割り当て前に放棄すれば、受信側が飛び越える穴を作らずに済む。割り当て後なら、送信側はデータを放棄済みにし、必要に応じてFORWARD TSNで相手を進める。断片化されたメッセージでは、一つのチャンクを放棄すると残りのチャンクも同時に放棄しなければならない。TSNは関連付け全体の順序を作り、ストリームシーケンス番号は各ストリームの配信順を作る。FORWARD TSNは二つの順序台帳をつなぐが、欠けたペイロードを受信済みに偽装しない。

これは配信確認ではない。FORWARD TSNは送信側が特定TSNの再送をやめ、受信側にその番号を越えるよう求めた証拠である。放棄されたデータが到着したこと、後続メッセージをアプリが受理したこと、あるいはサービスがエンドツーエンドの期限を守ったことは示さない。輻輳制御も残る。放棄データを輻輳ウィンドウの増加に使ってはならず、再送が発生した場合に必要な輻輳調整も無効にはならない。

関連付け単位の機能交渉も前提だ。相手がFORWARD TSNをサポートしなければ、その関連付けで部分信頼性は利用できない。依存するアプリケーションは交渉結果を受け取り、開始をやめるか、別のサービスにするか決めなければならない。ローカルスタックに機能があることと、通信相手も使えることは同じではない。

RFC 7496は後年、再送回数の制限と優先度に基づく追加方針を定めた。条件が増えてもFORWARD TSNを共通機構にできることが、この設計の核である。いつ放棄するかはサービスが決め、放棄後の順序の進め方はトランスポートが決める。

出典