要約

  • RMTの後段が前段の状態修正を必要とすると、Prestoは入口へペイロードのない疑似セグメントを注入し、通常の前向きロジックで更新する。
  • その通過はトランスポート内部の証拠にすぎない。実データ、DMA、ホスト通知、ソケット結果、アプリケーションの受領を一つの成功にまとめてはならない。

戻れないパイプラインで後方更新を行う

CPU上のTCP処理は同じメモリーを読み直せる。RMTではpacket header vectorが固定stageを一方向に進み、可変状態はstage-localである。乱順序区間の穴が実セグメントで閉じたとき、受信側はnext-seqとavailを更新すべきだが、閉鎖を示すooo-headは下流でしか確認できない。

Presto論文の解決策は、実セグメントを再循環させることではない。下流から入口へ小さな合成レコードをmirrorする。疑似セグメントはアプリケーションpayloadを持たず、新たに連続したsequence rangeだけを表す。各stageはそれを通常のin-order segmentとして扱い、next-seqを進め、availを減らし、OOO区間を消す。後方書き込みは、別の前向きイベントへ置き換わる。

したがって疑似セグメントは状態変更の権限を持つが、利用者バイトの再送ではない。アプリケーションがデータを読み、処理し、永続化したことも示さない。

楽観更新の後には確定判定がある

基本の受信窓追跡では、まずnext-seqを楽観的に進め、その後availを更新してwindow境界を確定する。送信者が広告窓を超えれば、セグメントは破棄され、control planeが状態を復元する。復元中は負のavailが後続を止め、zero windowを通知する。payloadが受理されるのは最終検証の後である。

疑似セグメントも一回の生成で完了しない。輻輳で落ちればOOO区間は残り、次のtriggerが再注入する。論文はこれをeventual consistencyと呼ぶ。途中のin-order trafficが窓を進めた場合、通常のtrimが重複prefixを除き、二重計上を防ぐ。重要なのは発行記録ではなく、状態の収束である。

DMA、通知、アプリケーションは別の面

Prestoは乱順序データを含むreceived payloadをDMAでhost memoryへ置ける。Application NotificationはlibPrestoに、消費可能な最高の連続offsetを知らせる。穴が閉じた場合、通知は後続の疑似セグメントmergeより先に出ることがある。

DMAはbufferへの書き込み、notificationはlibraryへの公開、socketはAPI結果を証明する。アプリケーションが実際に読んで結果を確定したかは、アプリケーション固有のreceiptが必要だ。TCP ACKも保存や業務完了を証明しない。

この成果はACM SIGCOMM 2026で発表され、DOIは10.1145/3789240.3829111である。公開リポジトリとAPNIC上の著者解説は検証可能性を高めるが、独立再現、一般配備、普遍的互換性を意味しない。

監査では実セグメントID、推測、下流判定、修正trigger、疑似セグメントの由来とepoch、状態更新、再送/再構成、DMA、host通知、socket結果、application receipt、rollbackを別々に結ぶ必要がある。

出典