RFC 5238：キュー投入はパケット送信の証拠ではない

Summary

RFC 5238 は、DCCP がキューに置いただけで未送信の要求を DTLS が再送しないよう求める。可能なら DCCP が IP 層へ渡した時点で上位タイマーを始める。
受付、下位引き渡し、送信、受信、DCCP 確立、DTLS 進行、アプリ利用可能は別の事実であり、一つのタイムアウトへ統合できない。

DTLS が記録を渡し、DCCP は受け付ける。しかし輻輳制御が送出を待たせる。受付時にタイマーを動かせば、ローカル待機とネットワーク往復が同じ区間になる。期限切れは「応答なし」を示しても、送信済みを示さない。

再送は同じ列に入り、原本の機会を奪う。待機が複製を正当化し、複製が待機を増やす。

RFC 5238 の境界は明確だ。下位層が通知できるなら、DCCP から IP への引き渡しまで DTLS の再送時計を始めない。

DCCP と DTLS はそれぞれ接続手順を持つ。通常は順番に行うが、DTLS 記録を DCCP-Request や Response に入れて一部を重ねられる。

ただし DCCP ハンドシェイクの信頼性は、内包された Application Data を保証しない。サーバーは破棄でき、DCCP 再送は初回のデータを省ける。DTLS は独自の回復を維持する。

その上位記録は DCCP 確立前には通常データとして再送できない。複数の再送が送れないまま積まれないよう、上位タイマーの再開は DCCP 完了後でなければならない。

両層は似たタイムアウトとバックオフを使うが、対象は違う。DCCP の期限切れは DTLS 記録の損失証明ではなく、DTLS の沈黙も直ちにネットワーク損失を特定しない。

大きな DTLS 交渉が DCCP に抑制され、上位期限を超えることがある。そこで追加する再送は確立をさらに遅らせ得る。送信証拠の後の回復と、原本がキューにある間の推測的複製を分ける必要がある。

RFC 5238 は、DCCP パケット番号と DTLS 記録番号に対応がなく、DCCP 同期と DTLS アンチリプレイにも関係がないと明記する。共通の搬送路は共通の意味を作らない。

DTLS 記録は一つの DCCP パケットに収まり、その時点の最大サイズ以下でなければならない。最大値は輻輳状態で変わり得る。

交渉トラフィックは後続サービスの輻輳状態を変える。CCID 2 では大きな交渉が乗法的減少を起こし、アプリが加法的回復を待つ可能性がある。RFC は穏やかな変動が必要な場合に CCID 3 の検討を挙げるが、普遍的優位を主張しない。

安全確立と、アプリ負荷に適した送信状態は別の結論である。

現行製品、実装、導入、トレース、障害、性能値は示されていない。IANA 登録は利用証拠ではなく、後続 DTLS RFC も DCCP 上の採用を証明しない。

IP 層への引き渡しも物理送信、相手の受信、セッション完成ではない。キュー受付より適切な開始点であるにすぎない。

投入、受付、輻輳判断、IP 引き渡し、番号、観測可能な送信、応答、DCCP 状態、DTLS flight、アプリ解放を記録する。各時計の所有者と開始・停止・取消条件を定める。

原本が待機中なら上位複製を抑止し、遅延応答や取消を損失へ書き換えない。Lu Heng の実行現実優先に従えば、API 受付は実行ではない。時計は時間を測るだけでなく交通を作るため、責任者が必要だ。