G.1.1 再送によって発生する輻輳

各ノードからの各仮想サーキットには，送信ウィンドウ・サイズが割り当てられます。このウィンドウ・サイズは，リモート・ノードへの送信を待機できるパケットの数を示します (たとえば，確認応答 [ACK] を受信するまでに，仮想サーキットの反対側のノードに送信できるパケットの数)。

特定の仮想サーキットのウィンドウ・サイズが 8 の場合，送信側は最大 8 つのパケットを連続して送信できますが，9 番目のパケットを送信する前に，すでに送信した 8 つのパケットのうち，少なくとも最初のパケットが到着したことを示す ACK を受信するまで待たなければなりません。

ACK が受信されない場合，時間切れが発生し，パケットは損失したものと解釈され，再送が必要になります。再送パケットに対し他の時間切れが発生した場合にはタイムアウト時間間隔が大幅に延ばされ，パケットはもう一度再送されます。同じパケットの再送が何度も発生すると，仮想サーキットは切断されます。

ここでは，OpenVMS VAX バージョン 6.0 または OpenVMS AXP バージョン 1.5 以降で実行されている PEDRIVER に関して説明しています。

再送メカニズムでは，Van Jacobson がインターネットの TCP プロトコルに対してもともと開発したアルゴリズムが採用されており，ウィンドウ・サイズと再送の時間切れの間隔をネットワークの条件に適合させることにより，以前のメカニズムより大幅に改善されています。

• パケットが紛失したために時間切れが発生すると，直ちにウィンドウのサイズが縮小され，ネットワークの負荷が削減されます。輻輳が軽減した場合だけ，ウィンドウ・サイズの拡大が認められます。さらに，パケットの損失が発生すると，ウィンドウ・サイズは 1 に縮小され，そのまま変更されないため，それまで送信されていたすべてのパケットに肯定応答があるまでは，送信側は一度に 1 つのパケットしか送信できなくなります。
  この状況が発生した後，以前のサイズの半分までは，ウィンドウを迅速に拡大することが認められます。サイズが半分になると，ウィンドウ・サイズの拡大の速度はかなりゆるやかになり，構成変数 (たとえばアダプタ・バッファ数やリモート・ノードの受信順序替えキャッシュの最小) によって決定される最大値に到達するまで，使用可能なネットワーク・キャパシティを活用できるようになります。

• 再送時間切れの間隔は，仮想サーキットを通じて送信されるパケットの実際のラウンド・トリップ時間と，この平均値の偏差を測定することにより設定されます。このため，PEDRIVER は，ほとんどのネットワークでパケットの損失に対してより適切に応答できるようになりますが，実際のラウンド・トリップ遅延時間が確実に長いネットワークでは，途中で時間切れが発生するのを回避します。アルゴリズムによって，平均遅延を最大数秒以内になるように調整することができます

G.1.2 HELLO マルチキャスト・データグラム

PEDRIVER は，ノードに接続されている各ネットワーク・アダプタを通じて定期的に HELLO データグラムをマルチキャストします。 HELLO データグラムには，以下の 2 つの目的があります。

• 送信側の存在を他のノードに通知することにより，チャネルと仮想サーキットを形成できるようにします。

• 通信が確立された後，それをオープンしたままにしておくのに役立ちます。

HELLO データグラムによる輻輳や HELLO データグラムの紛失は，接続の確立を妨げたり，接続を破壊する可能性があります。 表 G-1 では，HELLO データグラムの輻輳の原因になる条件や，PEDRIVER が問題の回避にどのように役立つかについて説明しています。この結果，HELLO データグラムの同期化の可能性がかなり低下し，HELLO データグラムによる輻輳も低下します。

表 G-1 HELLO データグラムの輻輳の原因になる条件

輻輳の原因になる条件	PEDRIVER が輻輳を回避する方法
新しいノードから HELLO データグラムを受信するすべてのノードが直ちに応答しなかった場合，新しいノードの受信ネットワーク・アダプタは，HELLO データグラムによってオーバーランする可能性があり，一部のデータグラムが紛失することになり，接続を確立できない場合がある。これは特に，大規模なクラスタで発生する可能性が高い。	以下のバージョンを実行しているノードでこの問題を回避するには，以下の操作を行う。 VMS バージョン 5.5--2 またはそれ以前のバージョンを実行しているノードでは，HELLO データグラムを受信するノードは，応答する前に最大 1 秒の間隔でランダムに遅延を発生させる。 OpenVMS VAX バージョン 6.0 またはそれ以降のバージョン，または OpenVMS AXP バージョン 1.5 またはそれ以降のバージョンを実行しているノードでは，大規模な OpenVMS Cluster システムをサポートするために，このランダムな遅延時間は最大 2 秒になっている。
ネットワーク内の多くのノードの同期がとられ，同時にまたはほとんど同時に HELLO データグラムを送信する場合，受信側のノードは一部のデータグラムを紛失し，チャネルを時間切れにすることがある。	VMS バージョン 5.5--2 またはそれ以前のバージョンを実行しているノードでは，PEDRIVER は 3 秒おきに各アダプタで HELLO データグラムをマルチキャストするため， HELLO データグラムによる輻輳が発生する可能性が高くなる。 OpenVMS VAX バージョン 6.0 またはそれ以降のバージョン，または OpenVMS AXP バージョン 1.5 またはそれ以降のバージョンを実行しているノードでは，PEDRIVER は HELLO データグラム・マルチキャストをランダムに分散させることにより，HELLO データグラムによる輻輳の発生を防止している。HELLO データグラムは約 3 秒ごとに各アダプタでマルチキャストされるが，一度にすべてのアダプタでマルチキャストされるわけではない。1 台のノードに複数のネットワーク・アダプタが接続されている場合，PEDRIVER は HELLO データグラム・マルチキャストを分散させて，3 秒間隔の毎秒，どれかのアダプタで HELLO データグラムを送信する。 さらに，正確に 3 秒ごとにマルチキャストするのではなく，PEDRIVER は約 1.6〜3 秒の範囲で HELLO データグラムのマルチキャストの間隔を変更して，マルチキャスト間隔の平均時間を 3 秒から約 2.3 秒に変更する。

G.1.3 HELLO IP ユニキャストおよび IP マルチキャスト・データグラム

PEDRIVER は，各 IP マルチキャスト・アドレスに対して定期的に 1 つつの IP マルチキャストと 1 つの IP ユニキャストを送信します。これらのユニキャストおよびマルチキャスト・メッセージは， PE$IP_CONFIG.DAT ファイルでアップデートされなければなりません。 HELLO データグラムは次の 2 つの役目を果たします。

• 送信側の存在を他のノードに知らせることにより，チャネルと仮想サーキットを形成できるようにします。

• 通信が確立された後，通信をオープンな状態で維持するのに役立ちます。

HELLO データグラムによる輻輳や HELLO データグラムの喪失は，接続の確立を妨げたり，接続を破壊する可能性があります。

---

索引

目次