要約

  • DCCPのCCID 2では、受信履歴を確実に伝えるため、確認パケットへの確認が必要になる。解放されるのは受信側の古いフィードバック状態であり、失われたアプリケーションデータが再送されるわけではない。
  • 双方向のデータ送信がなくなると、通常の通信に便乗していた確認を別途意識する必要がある。静止状態の判定には待ち時間だけでなく、受信履歴が確認済みであることも含まれる。
  • 二段目の確認が失われても、古い状態がしばらく残るだけなので三段目は要らない。CCID 3では確認状態が一般に有界であり、同じ仕組みを一律に要求しない。

データは止まっても報告は続く

AとBが互いにデータを送っているとする。BはAから届いたパケットの状況を報告し、AもBの通信を確認する。受信報告が届いたことを相手に知らせる仕事は、通常の往復に組み込まれている。

そこでBのアプリケーションだけが送信をやめる。Aからのデータは続くため、Bは受信報告を送り続ける。しかしAがデータだけを送るようになると、Bの報告を確認する機会は自動では生まれない。

RFC 4340 は、この移行を独立した問題として扱った。CCID 2を使うBはAck Vectorで受信履歴を知らせる。その履歴をいつまで保持すべきか判断するには、Aがどの報告を受け取ったか知る必要がある。Aが送信を続けているというだけでは、特定の報告が届いた証拠にはならない。

そこでAは、ときどきDCCP-Dataの代わりにDCCP-DataAckを送るなどして、Bの確認を確認する。追加の段階は、通信を無限の応答列にするためではない。終えてよい仕事を明らかにするためにある。

再送しない通信に必要だった正確さ

2006年3月のDCCP関連文書は、データグラムを使いたいアプリケーションにも、共通の輻輳制御を提供しようとした。RFC 4336 の問題設定では、通話の再生時刻を過ぎた音声や、ゲーム内の古い位置は、遅れて届いても役に立たない場合がある。

ネットワークの混雑に応じて送信量を調整する必要はある。それでも次に送れる瞬間に何を載せるかは、アプリケーションが選びたい。DCCPは失われたアプリケーションデータを自動的に再送する責任を引き受けない。必要な選択的回復をアプリケーションが追加する余地まで禁じたわけでもない。

ここで切り離されたのは、データの完全性と、制御に使う情報の確かさだった。古い音声を送り直さないことと、途中で損失や輻輳通知があった事実を送り手に伝えなくてよいことは、同じではない。CCID 2の受信報告は、その違いの上に成り立つ。

番号が付くのはデータだけではない

DCCPはパケットごとにシーケンス番号を進める。アプリケーションデータを持たない純粋な確認も一つの番号を使う。TCPのようにバイトを数えているのではない。

確認番号も、次に期待するバイトの位置ではなく、受信済みの最大のシーケンス番号を示す。それより小さい番号がすべて届いたという意味ではない。間の欠落はオプションとして付くAck Vectorなどで伝える。

Ack Vectorの一バイトは、二ビットの状態と六ビットの連続長からなる。状態には受信済み、ECNの輻輳通知付きで受信済み、予約値、未受信がある。連続長ゼロは一パケット、63は64パケットを表す。確認番号から過去へ向かう同じ状態の並びを、短く記録できる。

ただし圧縮と解放は別の操作である。受信履歴を小さく表せても、送り手が知ったと確認できなければ、受信側には再び伝える理由が残る。小さな記録であることは、不要な記録であることを意味しない。

また、番号の穴をそのままアプリケーションデータの損失に数えてはいけない。穴には制御パケットしか含まれないことがある。NDP Countは、その直前に連続した非データパケットの数を知らせ、対応する機能が有効なら損失区間の判定を助ける。失われた負荷のバイト数を算出する仕組みではない。

記録の窓には出口が要る

受信側には、報告を送り終えたが相手が受け取ったか不明な履歴がある。それに、まだ報告していない履歴が加わる。RFC 4340はこの二つを確認の窓として捉える。新たな受信が窓を広げ、過去の報告への確認が古い部分を窓から外す。

出口がなければ、受信側は接続開始時にまで遡る情報を繰り返し送ることにもなりかねない。受信報告を確実に伝える設計だからこそ、報告済みという一方的な事実だけで責任を終えられない。

RFC 4341 は、動作中の送り手が相手の確認をときどき確認することを必須とし、少なくとも輻輳ウィンドウ一つにつき一度行うことを推奨する。一つ確認が来るたびに専用の応答を直ちに送る、という規則ではない。

両側のアプリケーションが沈黙した場合は、送り手は長く待ってかまわない。積極的なデータ送信が続く場合と、双方が何も送らない場合を混同すると、不要な制御通信を生むか、必要な記録の解放を止めてしまう。

二段目の損失には、違う結果を与える

確認をさらに確認するなら、その確認も必要になるのではないか。この疑問に対する仕様の答えは、二段目だけを確実に届ける仕組みにはしない、というものだった。

二段目が失われると、受信側は古い状態をもう少し長く保持し、再び報告する。送り手にまだ伝わっていない情報を捨ててよいと誤認するのではなく、保留が長引く方向に失敗する。だから三段目の確認を新設しなくてもよい。

損失が無料になるわけではない。状態の保持や反復には費用がかかる。ただし、その費用を延長することと、新たな情報を必ず相手に届ける義務を作ることは異なる。後者を毎段で繰り返さないため、確認の連鎖は有限で済む。

静止を見分ける二つの条件

CCID 2の静止判定には、0.2秒と往復時間の二倍のうち大きい方を使う。しかし、その時間だけ待てば十分なのではない。

新たなデータがその間届かないことに加え、受信したデータすべてを覆うAck Vectorを送り手が確認していなければならない。時間と、残っている報告義務の両方を見る。往復時間が未知なら既定のRTTは0.2秒なので、その二倍は0.4秒になる。固定の200ミリ秒タイマーと説明するのは不正確だ。

二方向が異なるCCIDを使う場合、ある方向の静止を判定する規則と、その静止を受けて反対方向が確認を行う規則は、別々のCCIDに由来する。これは接続全体に一つだけある「アイドル」表示では表し切れない。

遅れて届いた事実を消さない

解放の境界には、もう一つ注意点がある。古いAck Vectorで未受信としたパケットが、その報告を送ったあとに到着する場合だ。その直後に古い報告への確認が来ても、送り手は新しい到着事実をまだ知らない。

そのまま記録を消せば、相手が知っている過去の見方と、こちらが知った新しい見方の差が失われる。RFC 4340の非規範的な附録A.3は、送った確認と履歴を対応させ、必要なら解放境界を抑える実装例を示している。すべての実装に同じバッファ構造を命じているわけではない。

「届いた」と「未受信」という報告の順番も、ネットワーク内で逆転し得る。仕様はそのための状態の組み合わせ方を定める。新しく受信した報告だからといって、そこに含まれる情報まで常に新しいとは限らない。

同じ接続でも、同じ記憶を持つとは限らない

RFC 4342 のCCID 3はTFRCを用い、急激な送信率変動を抑える代わりに、帯域変化への反応が遅くなるという選択をした。基本仕様によれば、その確認状態は一般に有界なので、CCID 2と同じ確認への確認を必要としない。状態もフィードバックも不要だという話ではない。

古い文書を読む際は修正も区別したい。RFC 4342の確認済み正誤表 は、受信率を前回の報告からの全期間ではなく最近のRTTで捉えるよう訂正している。また、データを含まない区間について後続のReceive Rateを無視するなら、無フィードバックのタイマーを再設定してはならないとする。制御パケットを受け取るだけで、必要な情報が更新されたことにはできない。

RFC 4340の正誤表 にも、Ack Ratioのゼロを誤って無効扱いした例や、附録の変数数の訂正がある。2018年の RFC 8311 は、DCCPの三つの輻輳制御プロファイルからECN Nonceの議論を取り除いた。2006年の記述をそのまま現在の実装指示にしてはいけない。

2012年の RFC 6773 が扱ったのは、UDPには対応するがネイティブDCCPには対応しない中間装置との互換性だった。UDPで包めることは、データの信頼性を変更することでも、普及率を示すことでもない。IANAの登録 が示すCCIDの番号も同様に、現実の経路で動いている証拠とは異なる。

この歴史で残るのは、一つの細かな問いである。通信を止めずに古い記憶を手放すには、誰が何を知ったと確認できれば十分なのか。DCCPは、その答えをデータ配送全体の約束にせず、フィードバックの小さな責任として定義した。