要約

  • SCTP の部分信頼性拡張は、送信を断念したメッセージのために、受信側が後続のデータを待たせ続ける問題を扱う。
  • FORWARD TSN による進行には、実際に届いたデータだけでなく、待つ必要がなくなった欠番も含まれる。進行位置は、内容の受領を一律に証明するものではない。
  • 期限や再送回数は送信側の判断基準であり、到着済みの内容を取り消したり、受信アプリケーションの有効期限を自動的に決めたりはしない。

最初に、同じ寿命を与えた A と B を分ける

部分信頼性の境界は、二つのメッセージを対にすると見えやすい。メッセージ A は送信キューに入り、寿命が尽きた時点でもまだ TSN を割り当てられていない。メッセージ B は同じ送信方針を持つが、すでに TSN を得ており、最初の送信が試みられたか、複製がネットワーク中にある可能性がある。その後で寿命が尽きる。

A と B はどちらも送信側で「もう試みない」と判断され得る。しかし、相手に残す状態は違う。A は共有の番号を一度も占めないため、受信側に欠番を作らない。B を黙って消せば、受信側はその TSN が遅れているのか、失われたのか、永久に来ないのかを区別できない。B には、相手も理解できる限定された前進手続きが要る。

これは特定の障害記録ではなく、仕様の規則を比べるため、A と B を対にした比較試験である。大切なのは「期限切れ」という同じラベルではなく、その判断が共有状態へ入る前か後かである。

A の試験：番号がなければ、相手に穴はない

初期の SCTP 基本仕様には、部分信頼性拡張より前からユーザーデータの寿命があった。寿命内に最初の送信を開始できなければ、その仕事を取りやめて上位層へ通知できる。一方、期限内に一度でも送信を試みたデータは、基本サービスでは引き続き信頼性のある送信として扱う必要があった。この境界は後継の基本仕様にも残っている。

実装上の注記は、TSN の割り当てを遅らせる方法を示す。簡単な実装では、TSN を与えた時点を送信への約束とみなしてもよい。A の寿命を番号付与前に検査し、すでに切れていれば、TSN を付けずに断念して上位層へ知らせる。受信側には A のための gap がないので、FORWARD TSN で待機を解除する必要もない。

ここから分かるのは、寿命がもともと存在したことと、送信開始後の断念が可能になったことを分ける必要があるという点だ。初期の寿命は、主として新しい送信責任を引き受けるかどうかを決めた。2004 年の拡張は、すでに共有番号へ入った仕事を途中で終えるために、別の規則を加えた。

A の試験で受信側に進行通知が現れたなら、試験条件か実装の説明を疑うべきである。番号を与えていないメッセージは、相手が越えるべき番号付きの穴を作れない。

B の試験を始める前に、使用可能性を協議する

B を途中で断念する手続きは、片側の実装能力だけでは有効にならない。RFC 3758 では、アソシエーションの確立時に INIT と INIT ACK を通じて対応を知らせる。機能を実装していても、このアソシエーションで対応を広告しない端点は、部分信頼性が有効であるかのように振る舞えない。相手が対応しない場合、FORWARD TSN を送ってはならない。

上位層は未対応を知らされ、確立を断念するか、部分信頼性なしで続けるかを選べる。したがって、この比較試験には「双方が対応を広告した組」と「一方が広告しない組」が必要になる。後者で通信が成立したことは、期限後の送信断念まで成立した証拠ではない。

協議されるのは、相手が欠番をどう越えるかという共通手続きである。受信側は、B が時間、再送回数、または別の許された送信方針のどれで断念されたかまで知る必要はない。ローカルな理由を共有プロトコルの状態変更へ変換する部分だけが、両側の合意を必要とする。

B の送信側試験：前進可能点は、累積確認ではない

B の TSN を送信側で断念すると、そのデータは未完了の送信から外れ、内部手続きでは finally acknowledged に相当する扱いを受ける。しかし、これは相手からの受領証ではない。断念したバイトを部分確認済みバイトへ加えたり、それによって輻輳ウィンドウを広げたりしてはならない。送らなくて済んだ仕事を、ネットワークが運んだ仕事として計上できないからだ。

メッセージが分割されていれば、一つの断念は同じユーザーメッセージに属する全 TSN に及ぶ。片方の断片だけを諦め、残りから完全なメッセージを作れるかのように扱うことはできない。必要な輻輳処理や再送タイムアウト処理も消えない。

送信側には二つの位置が残る。実際の累積確認点（actual cumulative acknowledgment）は、相手が実際に累積確認した位置である。Advanced.Peer.Ack.Point は、連続する放棄済み TSN を規則に従って越えた、ローカルな前進可能点である。後者を前者の別名にしてはならない。

仕様の送信側例では、actual cumulative acknowledgment は 102、103 と 104 は断念済み、105 は未確認で断念もされておらず、106 は確認済みである。Advanced.Peer.Ack.Point は 104 まで進めるが、信頼性を保った 105 を越えて 106 へは行けない。後ろの確認は、手前の未解決な責任を消さない。

前進可能点が実際の累積確認点を上回るとき、送信側は FORWARD TSN でその境界を共有できる。この通知自体も失われ得るため、送信側は関連する T3-rtx タイマーを動かし、満了時に前進条件を再検討する。一回送ったことと、相手が前進したことは別の観測である。

B の受信側試験：欠席と到着を足して進む

受信側の仕様例は、先ほどの送信側例とは別の配置である。累積位置は 102、103 が欠け、104 と 105 は受信済み、106 は欠け、107 は受信済みとする。103 まで越えてよい FORWARD TSN を受けると、受信側はまず 103 へ進み、すでに持っている 104 と 105 を使って 105 まで進む。

この進行は、103 が届いたという意味ではない。103 は待つ必要がなくなり、104 と 105 は実際に届いていた。二種類の事実が同じ累積位置に寄与している。106 は受信も断念通知もないため、107 があってもその先へ進めない。これが、信頼性を保った gap を FORWARD TSN が越えられないという受信側の検査点になる。

古い、または現在位置と同じ FORWARD TSN を受けても、累積位置は後退しない。ただし、以前の SACK が失われた可能性があるため、新たな SACK を返すことはある。試験は「値が変わらなかった」を無反応と決めつけず、必要な確認が返ったかも観測する。

受信側が越えた後に対象の DATA が遅れて到着すれば、規則上は重複として捨てられる。逆に、B の複製が FORWARD TSN より先に届き、すでにアプリケーションへ渡されていることも、送信側の寿命だけでは排除できない。断念は receiver deadline ではなく、到着済み内容の recall でもない。

B が順序と再構成に残したものを片づける

TSN の累積位置が進んでも、メッセージの再構成状態は自動的に健全にはならない。B が複数断片からなり、新しい累積位置以下の TSN が欠けたままなら、完全な再構成はできない。その不完全な状態を取り除き、部分配送が始まっていた場合には、完結しないことを上位層へ知らせるべきである。状態を解放することは、すでに部分的に渡した内容を取り戻すことではない。

ordered stream では、完全に届いた後続メッセージも、B の順番を待って止まる可能性がある。FORWARD TSN は、断念された ordered data に対応するストリームとメッセージ順序の情報を運び、後続を解放できる。unordered data をこの ordered stream 用の項目へ入れてはならない。部分信頼性と順序の有無は別の選択である。

ストリーム順序番号でアプリケーションの欠落を見つける方法も、対象ストリームの全メッセージが順序付きであることを前提とする。順序なしの通信へ一般化はできない。B の試験では、TSN の前進、再構成の破棄、順序付き配送の再開を別々に記録し、どれか一つを「受信完了」と呼ばないことが重要になる。

時計は、期限の瞬間に相手へ割り込まない

時間による部分信頼性では、TSN 付与前だけでなく、番号付きデータの送信または再送前にも寿命を確認する。B がそこで期限切れなら、断念と前進手続きの候補になる。実装は他の都合のよい時点でも検査でき、メッセージごとのタイマーや、期限ちょうどの割り込みを要求されない。上位層は SCTP へ渡した後にその寿命を変更できない。

したがって、送信側の時計は「これ以上試みる価値」を判断するが、受信側が内容をいつまで有効とみなすかは決めない。すでに送信された B が通知より先に届く順序は、仕様から考えられる仮想例であって、観測された事故ではない。古い状態を拒む必要があるアプリケーションは、版、時刻、世代など、受信時の別の条件を持たなければならない。

A/B の形を保ったまま、後の方針を試す

資料性のソケット API は、完全な信頼性と時間による部分信頼性を方針と値で区別し、時間値をミリ秒で表す。ただし、その記述は全実装で数値定数、ABI、初期設定が同じだという保証ではない。

後の拡張は、DATA チャンクごとの再送回数を制限する方針を加えた。メッセージを構成するどれか一つが許容回数を超えて再送されることになると、メッセージ全体を断念する。高速再送とタイマー再送の双方を数える。上限ゼロは、最初の再送が必要になったときに断念する意味であり、初回送信の禁止でも一回の成功の証明でもない。

もう一つの方針は、新しいメッセージに送信バッファを譲るため、同じアソシエーション内の低い優先度のメッセージを断念できるようにする。完全に信頼性のあるメッセージは、この方式の候補より上に置かれる。これは送信端点のバッファ選択であって、ネットワーク転送や受信側処理の優先順位ではない。

資料性の統計は、メッセージのどの部分も送信しないまま断念したものと、一部でも送信した後に断念したものを分ける。チャンクではなくユーザーメッセージを数えるため、一片でも出た B は後者になる。この区分は A/B 試験に有用だが、特定実装が必ず公開しているとは限らない。

WebRTC のデータチャネル仕様は、そのスタックに時間と有限再送の部分信頼性を要求する。ordered/unordered と full/partial reliability は別々の軸であり、チャネルは逆方向の SCTP ストリーム対を使う。層は SCTP over DTLS over ICE/UDP で、DTLS が SCTP パケット全体を保護する。この要求は現在のブラウザー普及率を示すものではなく、ネイティブ SCTP の全ストリームへ同じ既定方針を与えるものでもない。

A は共有番号の手前で終わる。B は番号を持ったため、送信側の断念だけでは終われず、相手が安全に待機を解除するところまで検査しなければならない。この対を崩さなければ、方針や実行環境が変わっても、「送信をやめた」と「相手が受け取った」を混同せずに済む。

参照資料

  • RFC 2960：当初の送信インターフェースと寿命。
  • RFC 3758：部分信頼性と双方の前進処理。
  • RFC 4960：基本仕様の後継における期限の扱い。
  • RFC 6458：方針と値を指定する資料性ソケット API。
  • RFC 7496：再送上限、バッファ優先度、断念統計。
  • RFC 8831：WebRTC データチャネルの要求と層構成。
  • RFC 9260：2022 年の基本 SCTP インターフェース。