RACKとは何ですか？

Recent Acknowledgment（RACK）は、従来のTCPスタックのように重複した確認応答をカウントするのではなく、セグメントが送信されてからの経過時間に基づいて、そのセグメントが紛失したかどうかを判断するTCP損失検出アルゴリズムです。この変更により、パケットの再順序付けやテールドロップが発生している際にも、損失検出の精度が向上します。また、VersaのVOS TCP最適化機能では、回復を高速化するために、RACKを選択可能な損失検出方法として提供しています。

主なポイント

• RACKは、重複ACKのカウントではなく、経過時間に基づいて失われたTCPセグメントを検出します。
• パケットの順序が入れ替わっても、それをパケット損失と誤認することなく許容します。
• テールロスプローブ（TLP）はRACKと連携して、飛行の終盤におけるデータ損失を検知します。
• RFC 8985 で標準化された RACK-TLP は、現在では最新の TCP スタックで広く採用されています。
• VOS TCP 最適化では、損失検出手法として RACK が選択可能です。

このページの内容： その重要性 ・ 仕組み ・ RACKの構成要素 · RACKとVersa · よくある質問

RACKはなぜ重要なのでしょうか？

従来のTCP損失検出（固定された重複ACK閾値によるもので、後にSACKベースの回復によって改良された）は、単純な経路ではうまく機能しますが、2つの状況では誤った動作をします。再順序付けを損失と誤認し、単に遅延しただけのセグメントを再送信してしまうことがあります。 また、パケットの末尾部分では検知が不可能です。一度、損失したセグメントの後にキューにデータがなくなると、従来のアルゴリズムが必要とする重複ACKをトリガーするものがなくなり、その結果、回復処理はほぼ瞬時に行われる高速再送信ではなく、遅い再送信タイムアウトに切り替わってしまいます。

RACKは、ACKカウントではなく時間を基に推論を行うとともに、テールケースに対応するプローブメカニズムを組み合わせることで、これら2つの課題を解決します。Networks 複数の基盤となるリンクを結合する環境（SD-WANファブリックで日常的に発生する状況）では、クロスパスの再順序化がより頻繁に発生しますが、RACKのそれに対する耐性により、スループットと遅延をより予測可能な状態に保つことができます。

RACKとは何ですか？

送信されるすべてのセグメントには送信タイムスタンプが付与されます。ACKまたはSACKブロックが到着すると、RACKはそれより前に送信され、まだ確認応答を受けていない各セグメントをチェックし、接続の最新の往復時間（RTT）サンプルを基準として、単に順序が入れ替わったのではなく、確実に失われたとみなすべきだけの十分な時間が経過しているかどうかを判断します。 その閾値が「再順序付けウィンドウ」です。未確認の状態が、直近のRTTとほぼ同等の時間以上続いているセグメントは、紛失したとみなされ、直ちに再送信されます。一方、ウィンドウ内に再順序付けされたセグメントのACKが遅れて到着した場合、再送信は行われません。

長期にわたる平均値ではなく、最新のRTTサンプルを使用することで、RACKは遅延の変化に迅速に対応できるようになります。RACK単体では、ACKが到着した時点でのみ評価を行うため、通信が途絶えた場合の処理メカニズムが依然として必要です。これが、RFC 8985において、RACKを単独で定義するのではなく、Tail Loss Probeと組み合わせて定義している理由です。

RACKの構成要素

RFC 8985で標準化されたRACK-TLPは、2つの部分で構成されています。Recent Acknowledgment（RACK）は、前述の時間ベースの検出機能であり、ACKまたはSACKブロックが到着するたびに実行され、経過した送信時間に基づいて、確認応答のないデータが失われたかどうかを判断します。Tail Loss Probe（TLP）は、RACKだけでは対応できないケース、すなわち送信が停止し、損失を検知するための新しいACKが到着しない接続をカバーします。TLPは短いプローブタイマーをセットし、そのタイマーが切れる前にACKが到着しなければ、フィードバックを得るためだけにプローブセグメント（利用可能な場合は新しいデータ、そうでない場合は最後のセグメントの再送信）を送信します。

そのフィードバックにより、データが到着したことが確認されるか、あるいはRACKに対してそのセグメントを損失と宣言するシグナルが送られ、それにより、従来のスタックであれば待機していたであろう、より遅いタイムアウト処理を回避することになります。

RACK &Versa

VersaのVOSTCP最適化機能では、TCP損失検出方法としてRACKを選択可能です。TCP損失検出設定のデフォルトは従来の重複ACKカウントですが、管理者が有効化できる代替手段として「Recent acknowledgment（RACK）」があり、これはIETF仕様に基づく補助的な「Tail Loss Probe」によって実装されています。 SD-WANパスでは、レイテンシの異なる複数の基盤リンクが組み合わされることが多いため、単一の直接パスよりもパケットの順序が乱れることが頻繁に発生します。RACKは、まさにこのような状況において、不必要な再送信を行うことなくこれを許容します。また、WANパスでは、最後のセグメントが損失した場合、完全な再送信タイムアウトが切れるまでフローが停止してしまうため、テールドロップからの回復も重要です。

よくある質問

RACKは、従来のTCPパケット損失検出では解決できなかったどのような問題を解決しているのでしょうか？

重複ACKカウント方式は、順序が乱れたACKが一定数発生した場合をパケット損失とみなすため、通常の順序再編成では誤検知が生じ、またフライトの最後のセグメントが失われた場合には何のシグナルも出ない。これに対し、RACKは経過時間を基準とするため、通常のジッターによって引き起こされる再送信が発生しても、これら両方のケースを正確に検出できる。

RACKは、重複ACKに基づく高速再送信とどのように異なるのでしょうか？

高速再送信では、実際にどれだけの時間が経過したかに関係なく、重複したACKが所定の回数に達すると、パケットの損失とみなします。一方、RACKは、セグメントが送信されてからの経過時間を、その接続の直近の往復時間と比較するため、送信が遅れているパケットや順序が入れ替わったパケットと、真に失われたパケットとを区別することができます。

「テールロスプローブ」とは何ですか？また、RACKとはどのような関係があるのでしょうか？

TLPは、接続側から送信が停止し、損失を検知するための新しいACKが届かなくなった場合に備えて、RACKと連動して機能するメカニズムです。TLPは短いタイマーを起動し、ACKが届かない場合にプローブセグメントを送信することで、RACKが損失を迅速に検知するために必要なフィードバックを生成します。

RACKは、最新のシステムにおけるデフォルトの損失検出アルゴリズムなのでしょうか？

RACK-TLPは2021年にRFC 8985として標準化され、それ以来、Linuxを含む主流のスタックにおいて、デフォルトの損失回復メカニズムとなっています。RACKは、欠落したセグメントを特定するために依然としてSACKの情報に依存しているため、SACKに取って代わるのではなく、SACKと共存しています。

RACKはTCPのSACKに取って代わるのでしょうか？

いいえ。SACK（Selective Acknowledgment）は、どのセグメントが到着したかを送信者に通知するものであり、RACKはその情報を入力として利用します。RACKは、SACKデータと送信タイムスタンプを解釈し、ギャップを「損失」とみなすのに十分な時間が経過したかどうかを判断する決定層であり、SACKそのものの代替となるものではありません。

RACKに関する詳細

さらに詳しく知りたい場合は、私たちが信頼している情報源を以下にご紹介します。

関連用語

RACKについて読んでいるなら、次はこれらもチェックしてみる価値があります。