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 受付は実行ではない。時計は時間を測るだけでなく交通を作るため、責任者が必要だ。

Sources

追加の標準記録

  1. RFC 5238 テキスト
  2. RFC 5238 情報ページ
  3. RFC 5238 Datatracker
  4. RFC 5238 履歴
  5. RFC 5238 正誤表
  6. RFC 5238 被参照記録