ゼータTCP

Zeta-TCP ^[1]は、ピアがZeta-TCPであるか他のTCPプロトコルスタックであるかに関係なく、TCPのエンドツーエンドのパフォーマンスを向上させることを目的とした独自の伝送制御プロトコル（TCP）アルゴリズムのセットを指します。言い換えれば、既存のTCPアルゴリズムと互換性があることです。AppEx Networks Corporationによって設計および実装されました。

Zeta-TCP は主に次の改善を提供します。

• 遅延と損失の両方の測定に基づいた輻輳回避。
• 損失検出アルゴリズムが改善されました。
• 逆制御。

ほとんどの TCP スタック実装では、輻輳回避アルゴリズムとしてTCP New Renoまたはそのバリエーション (TCP SACK RFC3517 など) を使用しています。New Reno ベースのアルゴリズムは損失ベースです。損失ベースのアルゴリズムは、パケット損失をネットワークの輻輳の唯一の兆候として扱います。インターネットが進化するにつれ、この仮定は今日ではしばしば過剰になっています。輻輳損失は技術の進歩とともに常に減少していますが、メディアの特性 (ワイヤレス/フェージング チャネルなど)、有線ノイズ/クロストーク、接続の欠陥、ソフトウェア バグなどによるランダム損失は相対的に増加しています。「輻輳」が検出されると (または誤報されると)、New Reno は輻輳ウィンドウ (CWND) を大幅に縮小し、送信速度を急落させます。これは、TCP ベースのアプリケーションが、特にラウンドトリップ遅延時間 ( RTT ) が大きい場合に、サブスクライブされた帯域幅の一部しか使用できないことが多い主な理由の 1 つです。

TCP Vegasとそのバリエーション、特にFAST TCP は、輻輳予測を RTT 測定のみに基づいて行います。このような遅延ベースのアルゴリズムは、損失ベースのアルゴリズムの問​​題を克服し、通常はネットワークの輻輳をより現実的に反映します。ただし、遅延ベースのアルゴリズムには独自の制限があります。

Zeta-TCP は、レイテンシ ベースと損失ベースのアルゴリズムの長所を組み合わせることで、この問題に対処します。RTT の変化と損失率の変化を継続的に測定し、輻輳の可能性を計算します。可能性に基づいて CWND バックオフ スキームが適用されます。可能性が最も高い場合は、長年にわたる大規模な導入ですでに効果的で安定していることが証明されている New Reno のバックオフ スキームが適用されます。

実際のネットワーク環境では、パケット損失が均等に広がることはほとんどなく、むしろ互いに近い間隔で発生する傾向があります。TCP 関連の RFC (New Reno や SACK など) では、最初の損失を高い信頼性で検出する方法が明示的に定義されています。ただし、TCP が SACK を許可して高速回復モードに入った後の損失の検出は、RFC3517 では効率的ではありません。一部の一般的なオペレーティング システムには、同様に最適ではない独自の実装があります。

Zeta-TCP は、すべての unACK/unSACK パケットの損失確率を計算するためのシンプルなアルゴリズムを提供します。パケットは、損失確率が特定のしきい値を超えた場合にのみ再送信されます。同じルールがすべてのパケットの再送信の決定に適用されます。したがって、Zeta-TCP は再送信パケットの数を最小限に抑え、帯域幅の使用率をさらに向上させます。ラボ テストでは、同じ損失率の場合、Zeta-TCP は他の TCP 実装よりも再送信パケット数が大幅に少ないことが確認されています。

Zeta-TCP は、パケット損失が発生する可能性があると疑われる場合に、できるだけ早く正確にパケット損失を検出するメカニズムを開発しました。早期検出により、再送信時に 1 ～ 2 RTT を節約できます。

他のアルゴリズムが送信トラフィックの高速化に重点を置いているのに対し、リバース コントロールは受信の問題に対処しようとします。リバース コントロールは受信データとの接続品質を監視し、接続品質が良好な場合にピアにできるだけ高速で送信するようヒントを与えるアルゴリズムを実行します。また、このアルゴリズムは、他の異常な状況からの実際のパケット損失をより正確に識別し、不要な高速回復をトリガーしないようにする傾向があります。

リバース制御の受信アクセラレーションは、受信速度が送信者、つまりピアによって制御されるという点でヒューリスティックです。ピアに高速送信するようにヒントを与えることしかできません。ヒントを受け入れる TCP スタックもあれば、受け入れないスタックもあります。多くの場合、送信側 (コンテンツ サーバーなど) には、アクセラレーションを制限するレート制限メカニズムがあります。

リバースコントロールは、加速に加えて、着信レートを制限することもできます。加速とは異なり、着信トラフィックの速度を遅くすることは、TCPフロー制御メカニズムで効果的かつ正確です。Zeta-TCPの着信レート制限は、AppEx IPEQの着信フロー制御の基礎となります。^[2]

本稿執筆時点では、Zeta-TCP は Linux ( Netfilterカーネル モジュール)、Microsoft Windows 10 から XP および関連する Windows Server バージョン ( NDIS IM フィルター/NDIS LWF)、および WinCE 用のソフトウェア モジュールとして実装されています。AppEx はプロトコル スタックを変更せず、TCP フローをインターセプトして、そのアルゴリズムをオンザフライで適用します。このアルゴリズムを実装する非侵入的な方法は、より広く受け入れられることを目的としています。欠点は処理のオーバーヘッドが追加されることですが、オーバーヘッドはパフォーマンスの向上と比較すると無視できるほど小さいものです。