JP2003198612A

JP2003198612A - パケット通信ネットワークにおけるファイル転送方法

Info

Publication number: JP2003198612A
Application number: JP2001393627A
Authority: JP
Inventors: Masaji Takano; 正次高野; Toshiyuki Ueda; 敏幸上田
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2001-12-26
Filing date: 2001-12-26
Publication date: 2003-07-11

Abstract

(57)【要約】【課題】連続的なパケット損失が発生している状況
で、パケット損失の検出と再転送をより速やかに行う。【解決手段】中継ノードにおいて受信バッファのオー
バーフローとなるべきパケットの全体を損失とするので
はなく、そのパケットのペイロードを廃棄する一方で、
ヘッダ情報のみを切り取り、さらに必要な情報を追加し
た損失通知パケットを受信端末に送り届けることによ
り、輻輳の発生、あるいは、パケット損失の発生を明示
的に通知し、前記パケットの受信とそのＡＣＫをもっ
て、送受信端末は輻輳制御・回避の動作をいち早く開始
するトリガとする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、通信ネットワーク
でのパケットによるファイル転送一般、特に、個別フロ
ーのパケット損失率を小さくし、スループットを最適化
し、輻輳から速やかに回復するために、そのフロー制御
を適切に制御・調整する方法および装置に関するもので
ある。

【０００２】

【従来の技術】（通信サービスはファイルをパケットで
転送すること）通信ネットワークを経由してユーザにサ
ービスを提供することは、テキスト、音声、映像、プロ
グラムといったユーザが所望するさまざまなデータ情報
を、送信側から受信側までファイル形式で転送すること
に多くは帰着される。受信側の装置は、ユーザ端末と呼
ばれる。ユーザ端末とは、データのファイル転送とその
データの再生利用に使用される通信機能を有する機器で
あって、コンピュータ（パソコン）、電話（従来型電
話）、ＩＰ電話、テレビ電話、ファクシミリ、テレビ、
ゲームなどである。一方、送信側であるサービス提供側
は、サーバと呼ばれる通信機器を所有し、ユーザに提供
するデータ情報を蓄積し、ユーザのサービス要求に対し
て所望されたデータ情報をファイル形式で送信する。サ
ーバとユーザ端末は、さまざまな種類の通信回線をリン
クとして互いに接続されていて、これらの接続された通
信回線を通信ネットワークと呼ぶ。通信ネットワークを
介してファイルを転送する形式においては、ファイルを
小さく分割したパケットと呼ばれる単位で、サーバから
ユーザ端末へ送受信を行なうことが通常行なわれてい
る。本明細書では、データ情報の流れに着目して、以下
では、サーバを送信側あるいは送信端末、ユーザ端末を
受信側あるいは受信端末とよぶ。

【０００３】（パケット型通信を行なうネットワークに
必要な装置とその例）通信ネットワークにおいて、パケ
ットを送信側から受信側まで転送するためには、パケッ
ト交換機やルータと呼ばれる中継ノードが必要である。
中継ノードは、複数の通信回線を接続するための機器で
あり、任意の送信側から任意の受信側へのパケットの転
送に対して、それぞれ経路情報を管理しており、パケッ
トを適切な方路の通信回線へ送出する役割を担ってい
る。そのとき、中継ノードはパケットのヘッダ情報を利
用する。ヘッダ情報とは、パケットの通常、先頭部分に
位置する制御・管理用の情報であり、送信側のアドレス
情報と受信側のアドレス情報などの必要な情報を含んで
いるため、パケットを送出すべき方路の選択を正しく行
なうことができる。パケットを利用する通信ネットワー
クには、ＬＡＮ(Local Area Network)で使われるＥｔｈ
ｅｒｎｅｔ（登録商標）や非同期転送モード（ＡＴＭ）
ネットワークなどがある。ただし、パケット長は前者が
可変長であり、後者は固定長である。本発明は、パケッ
ト長が可変長である通信ネットワークを対象とする。

【０００４】（パケットの流量を調整すること）パケッ
トを用いたファイル転送方式において、送信側がパケッ
トを送出する機能は、受信側の受信バッファの大きさや
通信ネットワークのデータ転送速度（帯域）に合わせ
て、パケットの流量を適正に制御・調整するように設計
されている。これをフロー制御と呼ぶ。受信側は、連続
して受信可能なデータ量を送信側にあらかじめ通知し
て、送信側は、その通知にしたがって送出するパケット
の量を制御する。送信側がパケットの到達確認応答（Ａ
ＣＫ）なしに連続して送信できるデータ量のことをウイ
ンドウサイズと呼ぶ。フロー制御は、ウインドウサイズ
制御として実装されていることが多い。

【０００５】（サービス品質の確保には、損失されたパ
ケットの速やかな再送が重要）ユーザが所望するサービ
スによって、サービス提供側が提供すべきサービスの品
質尺度はさまざまに異なる。したがって、そのようなサ
ービスの品質の目標を決めるためには、平均的なスルー
プット、遅延時間、パケット損失率など基本的な品質尺
度を、提供するサービスの内容に合わせて、さまざまな
重み付けで総合的に勘案して評価して決めることが必要
になっている。とくに、近年の通信を利用したアプリケ
ーションやそのサービスの高度化や多様化によって、通
信中に損失となってしまったパケットの速やかな再送信
やそれを実現するためのメカニズムが、高いサービス品
質の提供のために要望されている。

【０００６】例えば、映画などの高画質の映像を鑑賞す
るサービスでは、映像データ情報が所定の符号化速度以
上で継続的に転送され続ける必要がある。これが満足さ
れない場合、映像の一時的フリーズのような現象が起こ
り、映像品質が劣化してユーザに見えるため、ユーザの
サービスに対する満足度は大きく低下する。ユーザ満足
度の高いサービスを提供するため、映像データ情報の適
切な転送速度を維持するためには、そのフロー制御にお
いて、ウインドウサイズがある一定以上の大きさに確保
されることが要求される。一方、ウインドウサイズが大
きすぎるときには、通信ネットワーク上のトラヒックが
集中するポイントの中継ノードにおいて、パケットが受
信バッファに収容しきれなくなり、バッファオーバーフ
ローを起こして、パケットの損失となる。映像情報サー
ビスにおいては、パケット損失もブロック歪みなどのよ
うな映像の劣化となってユーザに見える。一般に、さま
ざまな通信サービスにおいて、ユーザに要求されるサー
ビス品質を達成するためには、ある一定以上の転送速度
を保ちながら、パケット損失はできるだけ起こさないよ
うにウインドウサイズの制御・調整することが要求され
る。また、損失となってしまったパケットは速やかに再
送信されて、受信側において欠落となっている部分を埋
めることが期待される。

【０００７】さらに、ウインドウサイズによって許され
る範囲で送信側からパケットは連続的に送出されるため
に、中継ノードではパケットはバースト的な到着になる
傾向が生じることが知られている。そのため、いったん
輻輳が発生しパケット損失が起こるときは、１個のパケ
ット損失ではなく、バーストとして連続したパケットの
集団のほとんど全体が損失になる現象が発生していて、
パケット損失の問題を深刻にしている。

【０００８】（ＴＣＰの場合）フロー制御としてウイン
ドウサイズ制御を行なう従来技術として、ＴＣＰ(Trans
mission Control Protocol)の実装を取り上げていく。
したがって、ネットワーク・プロトコルの階層構造は、
いわゆるＴＣＰ／ＩＰプロトコル群の４階層を前提とす
る。ＴＣＰは、広くインターネットプロトコルとして利
用されているＴＣＰ／ＩＰプロトコル群のトランスポー
ト層のトランスポート・プロトコルである。ＴＣＰは、
ウインドウサイズ制御の機能を有していて、フロー毎に
自律的に動作している。パケットの送受信において、パ
ケットの損失が発生していないときには、通信ネットワ
ーク上の回線帯域に余裕があると判断して、ファイル転
送効率を上げるためにウインドウサイズを次第に増加さ
せる。具体的には、通常、ＡＣＫを受信するたびに、ウ
インドウサイズを増加させる。ウインドウサイズを増加
させた結果、ついにパケット損失が発生すると、ウイン
ドウサイズを半分に減少させるという基本的な動作原理
に従っている。ここで、ウインドウサイズを減少させる
動作のトリガとなるのは、パケット損失の検出である
が、その検出メカニズムは、受信側から送られるＡＣＫ
に含まれる情報を利用して行なわれる。ただし、パケッ
トと同様にＡＣＫも途中で損失となることがあるため、
ＴＣＰはその対策としてタイムアウトを設定しており、
そのタイムアウトが切れるまでにパケットの確認応答が
なされなければ、つまり、該当するＡＣＫを受信しなけ
れば、そのパケットを再転送することになっている。こ
のタイムアウトを待つ時間の制約を再転送タイムアウト
と呼ぶ。ＴＣＰのスループット性能の観点から見たと
き、再転送タイムアウトが切れるまで、送信側がパケッ
トの送出を滞らせる現象が起こると、転送効率が極端に
低下してしまうので、再転送タイムアウトによるパケッ
ト損失の検出は、ＴＣＰによるスループット性能の劣化
要因となっている。

【０００９】しかし、再転送タイムアウトのメカニズム
を止めてしまうことは、以下の理由から簡単にはできな
い。ＩＰネットワークは、送信側と受信側の組み合わせ
に対して、複数の経路を有する通信ネットワークなの
で、パケットの送信の順番通りに、受信側で受信される
ことが本来保証できない。したがって、ＴＣＰは受信側
が期待している順番と異なったパケットを受信しても、
それにより、パケット損失を検出したと判断し、輻輳制
御・回避の動作を開始することは、必ずしもネットワー
クの効率的な利用につながらないことが知られている。
パケットの損失が起こったのではなくて、受信の順番が
入れ違っただけの場合に、ウインドウサイズを半分にす
るような動作を行なうと、転送効率を大きく下げてしま
う結果になるからである。一方で、転送効率の向上だけ
を追及して、ウインドウサイズをどんどん増加させるだ
けでは、中継ノードの輻輳とパケット損失をすぐに引き
起こしてしまい、スループットはむしろ悪くなってしま
う。

【００１０】（ＴＣＰの輻輳制御・回避アルゴリズム）
このように、ＩＰネットワークにおいて、輻輳やパケッ
ト損失を回避しながら、パケットの転送効率をできるだ
け大きくする目的で、ウインドウサイズ制御を円滑に行
なうようにＴＣＰは実装されている。現在のＴＣＰに実
装されている輻輳制御・回避のためのフロー制御のアル
ゴリズムには、スロースタート・輻輳回避、高速再転
送、高速リカバリなどのメカニズムが組み込まれてい
る。

【００１１】（スロースタート・輻輳回避の説明）スロ
ースタート・輻輳回避の目的は、ネットワークに送出さ
れるパケットの流量を、着信側からのＡＣＫの流量と同
期させて調整することである。このために、ＴＣＰには
ウインドウサイズ制御が導入されている。このウインド
ウのことを輻輳ウインドウとよぶ。送出側の送信バッフ
ァのサイズと受信側の受信バッファのサイズで決まる、
送受信端末間で広告されたウインドウサイズが、記憶メ
モリの意味での制限であるのに対して、輻輳ウインドウ
サイズは、そのときのネットワーク全体のトラヒック見
合いで決まるパケットの送出量の制限であり、できるだ
け多くの量を流し、かつ、輻輳を起こさないことが目標
になる。以下では、輻輳ウインドウサイズの制御のこと
をウインドウ制御とよぶ。ウインドウサイズは、ｃｗｎ
ｄという変数で表現される。ウインドウは、新しいコネ
クションが確立されると、告知されたパケットサイズの
パケット１つに初期化される。ＡＣＫが受けとられるた
びに、ウインドウは１パケット分増加する。送信側はウ
インドウと広告されたウインドウサイズの最小値までパ
ケットを送出することができる。これは、送信側からパ
ケットが送出されて、受信側に到着し、受信側が確認応
答を送出して、送信側に確認応答が到着するまでの往復
時間、ＲＴＴ(Round TripTime)、を有効に使用するため
に、パケット１つではなくて、できるだけ多くのパケッ
トを送出するためのフロー制御である。ネットワークに
送出するパケットの量が限界に達すると、中継ノードで
は受信バッファにおいてオーバーフローが発生し、パケ
ットの損失が起きる。これが、輻輳である。送信側は、
再転送タイムアウト、あるいは、重複ＡＣＫの受信によ
り、パケット損失を検出すると、ネットワークの輻輳を
知り、現行のウインドウサイズの半分がｓｓｔｈｒｅｓ
ｈという変数に保存される。輻輳が、再転送タイムアウ
トによって検出された場合には、ウインドウサイズは１
パケットに設定される。この後、引き続きパケットが受
信側に到着して、確認応答されると、輻輳ウインドウを
増加させるが、スロースタートの場合と、輻輳回避の場
合のどちらかで動作が異なる。ウインドウサイズｃｗｎ
ｄがｓｓｔｈｒｅｓｈと等しいか小さい場合、スロース
タートとなり、そうでない場合、輻輳回避になる。スロ
ースタートでは、確認応答がされるたびに輻輳ウインド
ウを１パケット分増加させる。輻輳回避では、確認応答
がされるたびにウインドウサイズｃｗｎｄに１／ｃｗｎ
ｄを加える。つまり、往復時間単位でみると、スロース
タートでは輻輳ウインドウｃｗｎｄは指数的（２倍）に
増加し、輻輳回避では線形（１増加）に増加する。

【００１２】（高速再転送と高速リカバリの説明）高速
再転送は、損失を検出したパケットについての再転送
を、再転送タイマーが切れる前に行なうためのメカニズ
ムである。インターネットの性質上、重複ＡＣＫがパケ
ットの損失によるものなのか、あるいは、単にパケット
の到着の順序が入れ替わったためなのかを正しく判断す
ることはできない。パケットの到着順序が入れ替わった
ためであれば、１つか２つの重複ＡＣＫしか送られてこ
ないと考えるのが妥当である。そのうちに、到着の順序
が遅れたパケットについての確認応答により、新しいＡ
ＣＫが届くはずだからである。しかし、３つ以上の重複
ＡＣＫを立て続けに受信した場合には、パケットが損失
していると判断することが妥当になってくる。そこで、
再転送タイマーが切れるのを待たないで、損失となった
と考えられるパケットの再転送を行なう。このとき、輻
輳回避は行なうが、スロースタートは行なわない。

【００１３】高速リカバリ・アルゴリズムは、パケット
の損失を示す３つの重複ＡＣＫが受信されたときに、ｓ
ｓｔｈｒｅｓｈを直ちにウインドウサイズを２分の１に
設定する。ただし、それは再転送が行なわれるときまで
有効にならない。一方、ｃｗｎｄは、重複ＡＣＫを受け
取るたびに、パケットサイズ単位で増加し、送信側は、
新しいｃｗｎｄ値によって許可されている範囲で、引き
続きパケットを送出する。これは、ネットワークに残っ
ているパケットや損失で失われてパケットを速やかに受
信するためであり、重複ＡＣＫが終了し、新しいＡＣＫ
が送信側に到着すると、ｃｗｎｄがｓｓｔｈｒｅｓｈに
設定されて、通常の輻輳回避アルゴリズムに動作が引き
継がれる。

【００１４】高速リカバリは、パケット損失を重複ＡＣ
Ｋにより検出した場合、いたずらにフローの流量を減ら
さないためのメカニズムである。というのも、重複ＡＣ
Ｋが受信されることは、損失されたパケットに後続する
パケットで、損失をまぬがれて受信端末に到着したパケ
ットが存在したことを意味している。つまり、フローが
輻輳からすでにやや回復して、パケットの流れが継続し
ていると判断できるからである。したがって、このよう
な場合には、重複ＡＣＫによりスロースタートに移行し
て、ウインドウサイズを小さくした場合、必要以上にフ
ローの流量を減らすことになってしまう可能性が大きい
ため、高速リカバリが採用されている。

【００１５】この他にも、ＴＣＰの輻輳制御・回避アル
ゴリズムの改良バージョンが多数存在するが、いずれに
してもパケット損失を検出するメカニズムは、再転送タ
イムアウト切れか、あるいは、その改善として、重複Ａ
ＣＫの受信をトリガにして起動されるものである。しか
し、前記のように、パケットはバースト的に到着する傾
向にあるため、通信ネットワーク上の輻輳ポイントにお
いて、中継ノードのバッファ溢れによりパケットが損失
となるときには、パケット１個ではすまないで、通常、
バースト的に連続で到着するパケットの多数あるいは全
部が損失となっている場合がかなり多いと考えられる。
したがって、重複ＡＣＫとして確認応答されるパケット
が受信端末に届くまでには以下のような時間が必要とな
っている。つまり、輻輳ポイントにおいて、パケットの
損失という過度の輻輳状態から、重複ＡＣＫとして確認
応答されるパケットが損失をまぬがれて受信側に到着で
きる程度へ、やや輻輳が改善されるまで状態が落ち着く
時間的な経過が必要となっていて、スループット効率の
最適化ができない理由になっていると考えられる。

【００１６】

【発明が解決しようとする課題】これまでＬＡＮ(Local
Area Network)やＷＡＮ(Wide Area Network)におい
て、従来のベストエフォートと呼ばれるサービスクラス
には、遅延時間やパケット損失に対して強い品質要求が
なかったので、ＴＣＰ／ＩＰプロトコル群を利用した転
送によって、提供できる通常の品質が許容されてきた。
しかし、最近においては、通信ネットワークを経由して
提供される通信サービスやアプリケーションが高い品質
を必要とするようになってきている。例えば、高品質の
映像サービスのような場合には、サービスが目標とする
パケット損失率やその再転送要求を、従来のＴＣＰ／Ｉ
Ｐプロトコル群によって、容易に提供・達成できないと
いう問題が顕在化しはじめている。

【００１７】前記のように、現在のＴＣＰウインドウサ
イズ制御の動作原理と輻輳制御・回避のメカニズムで
は、ウインドウサイズを減少させるトリガとして、必然
的にパケット損失を引き起こしてしまう。しかも、この
動作は周期的に繰り返されるため、パケット損失が周期
的に引き起こされることになり、しかも、パケットの送
出にはバースト性があるために、多数のパケットの連続
損失となる傾向があり、結果として、パケット損失率の
値として十分小さい値を達成できなかった。

【００１８】より高い品質の通信サービスをユーザに提
供するために、パケット損失率を小さくするためには、
パケット損失の検出と再転送のメカニズムをより効果が
あるものに改善する必要がある。

【００１９】本発明の目的は、バースト的なパケットの
送出のために、連続的なパケット損失が発生している状
況で、パケット損失の検出と再転送をより速やかに行な
うためのメカニズムに関連する発明である。再転送タイ
ムアウト切れや重複ＡＣＫのようにパケット損失の検出
に時間が比較的に長い点、その時間の間、輻輳制御・回
避の動作が働かない点を解決した、ファイル転送方式と
そのための装置を提供することにある。

【００２０】

【課題を解決するための手段】本発明は、中継ノードに
おいて従来方式では受信バッファのオーバーフローとな
るべきパケットの全体を損失とするのではなく、そのパ
ケットのペイロードを廃棄する一方で、ヘッダ情報のみ
を切り取り、さらに必要な情報を追加した損失通知パケ
ットを受信端末に送り届けることにより、輻輳の発生、
あるいは、パケット損失の発生を明示的に通知し、前記
パケットの受信とそのＡＣＫをもって、送受信端末は輻
輳制御・回避の動作をいち早く開始するトリガとするこ
とを最も主要な特徴とする。従来の技術とは、パケット
損失の発生を明示的に伝えるために、損失となったパケ
ットを特定するためのパケットを送受信端末と中継ノー
ドで交換する点で異なる。

【００２１】（中継ノードの作用）ＴＣＰに実装されて
いる輻輳制御・回避のアルゴリズムの起動に、ある程度
の時間が必要となる理由は、中継ノードにおけるパケッ
ト損失の発生を明確に伝える情報が存在しないために、
パケット損失の検出判断を、再転送タイムアウトや後続
のパケットに対するＡＣＫである重複ＡＣＫに依存して
いるためである。これを解決するために、パケット損失
の発生情報を次のように構成する。つまり、中継ノード
において、輻輳が発生し、パケットが損失となる場合
に、従来のように、パケット全体を廃棄する代わりに、
どのパケットが損失されたかが送受信端末が特定できる
ための手がかり情報として、そのパケットのヘッダ情報
を残して、残りのペイロードの情報を廃棄させたパケッ
トを、中継ノードは受信端末に送出する。また、各種の
輻輳制御・回避アルゴリズムに最低限必要な情報も、そ
のパケットに記入する。さらに、パケットの転送誤りを
補正するためのチェックサムなど、通信ネットワークを
正しく転送されるため必要な処理は施すものとする。上
記のように構成される、特定のパケットの損失発生を受
信端末に通知するためのパケットを損失通知パケットと
呼ぶことにする。

【００２２】通信ネットワークにおけるパケット損失
は、通常、中継ノードの受信バッファに、パケットがバ
ースト的に到着することによって発生する。受信バッフ
ァ容量がオーバーフローしてしまうからである。パケッ
ト全体が受信バッファに収容できないときでも、ヘッダ
情報を主とする前記の損失通知パケットを受信バッファ
に収容することは可能であることがほとんどである。な
ぜなら、パケットのヘッダ情報部分は、パケットのペイ
ロード部分に比べて非常に小さく、通常は、数十分の一
程度の大きさであるため、パケット全体では１個も受信
バッファに入らない場合でも、上記の形式の損失通知パ
ケットならば、数十個も収容できる。したがって、中継
ノードでは、従来、パケット全体の損失となっていたパ
ケットほとんど全てに対して、特定のパケットの損失発
生を通知する損失通知パケットを受信側に送信すること
が可能になる。

【００２３】なお、損失通知パケットを転送する条件
は、上述のパケット全体を受信バッファに収容できない
ときの他に、例えば、受信バッファのあらかじめ定めら
れる割合、例えば９０％以上が使用されたときとするこ
ともできる。

【００２４】（受信端末の作用）損失通知パケットの受
信をトリガにして、受信端末は適切なウインドウサイズ
制御などを行なうことができる。また、同時に、受信端
末は、損失通知パケットに対する確認応答としてのＡＣ
Ｋを送信端末に向けて転送する。そのＡＣＫには、送信
端末が損失となったパケットを特定するための情報と、
輻輳回避のためにウインドウサイズ制御を行なうために
適切な情報を格納する。この損失通知パケットに対する
確認応答を損失通知ＡＣＫと呼ぶことにする。

【００２５】また、送信側が本発明の方式に準拠してお
らず、損失通知パケットに対して適切なウインドウサイ
ズ制御従来方式を行なうことができないときには、つま
り、従来のＴＣＰが実装された送信端末である場合に
は、その送信側の輻輳制御・回避が適切に動作できるた
めに、必要な情報の付加や適切な形式への変換を行なっ
たＡＣＫにより、受信端末は確認応答を行なうことがで
きる。例えば、送信端末がＳＡＣＫ(Selective ACK)を
利用することができるときは、ＳＡＣＫ利用することに
より、本方式に準拠していなくても、送信端末は、効率
よく再送すべきパケットを認識し、再転送やウインドウ
サイズ制御を行なうことができる。さらに、通常のＡＣ
Ｋで確認応答しても動作上は全く支障がないため、既存
のＴＣＰの実装をもつ端末、つまり、すべての端末と通
信は可能である。

【００２６】（送信端末の作用）送信端末は、受信端末
から前記の損失通知ＡＣＫを受信すると、そこに格納さ
れた損失となったパケットを特定するための情報を元
に、再転送タイムアウトが切れるのを待たずに、かつ、
重複ＡＣＫの受信の必要なしに、損失となった特定のパ
ケットだけを速やかに再転送することができる。同時
に、ウインドウサイズを半減させるなど必要かつ適切な
輻輳制御・回避のメカニズムを速やかに実行することが
できる。

【００２７】（送受信端末と中継ノードが連携すること
の作用）上記のように、送受信端末と中継ノードが損失
通知パケットによって、速やかに連携して動作するメカ
ニズムをもつことにより、個別のフローにおいて、パケ
ット損失が少なくなり、あるいは、輻輳状態から時間的
に速やかに回復可能となり、スループットが平均的に向
上することが期待できる。さらに、ネットワーク全体の
利用効率の向上も期待できる。

【００２８】

【発明の実施の形態】図１は、本発明の態様の好適な実
施の形態に係わる、通信ネットワーク（ＴＣＰ／ＩＰプ
ロトコル群によるネットワーク）の模式図である。

【００２９】この図１においては、パケット通信ネット
ワークにおけるファイル転送システムは、送信端末１と
受信端末２と中継ノード３と通信ネットワーク４から構
成され、ファイル６を送信端末１から中継ノード３を介
して受信端末３に転送する。

【００３０】パケット５はペイロード５ａとヘッダ情報
５ｂとを有する。

【００３１】図２は、本発明の態様に係わる、中継ノー
ドの好適な実施の形態のブロック図である。中継ノード
３は、受信バッファ入口部３０と受信バッファ部３１と
転送処理部３２から構成される。

【００３２】図１に、送信端末１が、受信端末２に対し
て通信ネットワーク４を経由したパケットによるデータ
情報の転送を行なうときの実施例を示す。

【００３３】まず、送信端末１が、受信端末２に対して
コネクションの確立要求を行い、このとき同時に、本発
明による方法が送受信の両端末に実装されていることを
確認する。送受信端末の一方でも本発明による方法が実
装されていないときには、従来のＴＣＰの方式にしたが
う。

【００３４】コネクションの確立後、送受信端末間での
パケットの転送が開始される。パケットの損失が発生し
ないで、転送が行なわれているときは、通常のＴＣＰ／
ＩＰのウインドウサイズ制御と同一である。送信端末１
と受信端末２の転送経路上に中継ノード３があり、中継
ノード３において、さまざまな方路からのパケットによ
るトラヒックが集中し、輻輳状態になったものと仮定す
る。

【００３５】図２において、中継ノード３の受信バッフ
ァ３１にパケットが収容できなくなると、従来方式のＴ
ＣＰならば、パケット全体の損失が発生する。本発明の
方式においては、中継ノード３に到着したパケットは、
まず、受信バッファ入口部３０において、いったん保持
され、受信バッファ部３１に収容できるかどうか判断さ
れる。受信バッファ部３１に収容可能であれば、受信し
たパケットをそのまま受信バッファ部３１に送り、受信
バッファ部３１は、受信バッファ入口部３０で必要な処
理をされたパケットを一時的に蓄積し、転送処理部３２
が転送すべきパケットがないときには、前記の一時的に
蓄積したパケットから、何らかの規則に従う順番でパケ
ットを取り出し、転送処理部３２へ渡す。転送処理部３
２に渡されたパケットは、中継ノード３から受信端末２
に向かう方路へ送出される。受信バッファ入口部３０に
おいて、受信バッファ部３１に収容できないと判定され
たパケットについては、そのパケットのペイロード部分
を破棄し、そのパケットのヘッダ情報と、ウインドウサ
イズ制御の輻輳制御・回避に必要な情報から、前記の損
失通知パケット５ｃを構成して、受信バッファ部３１に
収容する。損失通知パケットは、一時的に受信バッファ
部３１に収容された後、転送処理部３２において、中継
ノード３から受信端末２に向かう各方路Ａ，Ｂ，Ｃへ送
出される。このとき、パケットのペイロード部分はヘッ
ダ部分に対して、通常数十倍程度の大きさがあるため、
パケット全体が中継ノードの受信バッファ部３１に収容
できなくとも、ペイロード部分を廃棄することにより、
ほとんどの場合において、受信バッファ部３１に損失通
知パケットの形式で収容することが可能である。したが
って、中継ノードにおいて特定のパケットの損失が発生
したことが、ほとんど確実に受信端末に伝えることがで
きる。

【００３６】損失通知パケットを受信した受信端末２
は、送信端末１へ速やかに上記の損失通知ＡＣＫとして
確認応答を行なう。損失通知ＡＣＫにより、損失された
パケットを特定する情報が送信端末１を伝えることがで
きるので、再転送タイムアウトが切れるのを待たずに、
かつ、重複ＡＣＫの受信の必要もなしに、損失となった
特定のパケットだけを速やかに再転送し、同時に、ウイ
ンドウサイズを減少させるなどの輻輳制御・回避のメカ
ニズムを実行することができる。このように個別のフロ
ー毎の輻輳回避が速やかに実行できることにより、フロ
ーのスループットが平均的に向上することが期待でき
る。ネットワーク全体においても、輻輳が起こりにくく
なり、それからの回復も速やかに行なわれて、利用効率
が改善できることを期待できる。

【００３７】

【発明の効果】以上述べたように、本発明によれば、ほとんど確実に、損失となったパケットを特定するこ
とができる情報を、受信端末、送信端末の両方に、順番
に伝えることができるため、再転送タイムアウト切れを待たず、かつ、重複ＡＣＫ
の受信の必要もなく、パケット損失の検出を速やかに、
かつ、確実に行なうことができ、それにより、輻輳制御・回避のメカニズムを起動させ
ることができるため、フローが輻輳からの回復が速やか
に実現できる。個別のフローが輻輳状態に陥る継続時間が短くなるこ
とにより、パケット損失率やスループットなどの性能が
向上する。個別フローの性能改善により、ネットワーク全体のパ
ケット損失率やスループットの性能が向上する。既存のトランスポート・プロトコルの実装（上記の例
はＴＣＰの実装）との不都合のない通信が可能であり、
しかも、それらとの通信においても性能改善が期待でき
る。

【図面の簡単な説明】

【図１】本発明の態様の好適な実施の形態に係わる、通
信ネットワーク（ＴＣＰ／ＩＰプロトコル群によるネッ
トワーク）の模式図である。

【図２】本発明の態様に係わる、中継ノードの好適な実
施の形態のブロック図である。

【符号の説明】

１送信端末２受信端末３中継ノード４通信ネットワーク５パケット５ａペイロード５ｂヘッダ部５ｃ損失通知パケット６ファイル３０受信バッファ入口部３１受信バッファ部３２転送処理部

Claims

【特許請求の範囲】

【請求項１】通信ネットワークで、送信端末から受信
端末に少なくともひとつの中継ノードを介してパケット
を転送する、パケットのフローを制御するファイル制御
方法において、中継ノードで、当該中継ノードのバッファのオーバーフ
ローが近いときに、受信したパケットを破棄せずに、当該パケットのペイロードの少なくとも一部を破棄し、当該パケットのヘッダ情報の少なくとも一部と、当該パ
ケットを特定するための情報と、当該パケットの適切な
フロー制御を行うために必要な情報を有し、バッファの
オーバーフローが近いことを明示する損失通知パケット
を構成し、該損失通知パケットを受信端末に転送することを特徴と
するファイル転送方法。
【請求項２】前記バッファの９０％以上の容量が使用
されたときに、バッファのオーバーフローが近いと判定
する、請求項１に記載のファイル転送方法。
【請求項３】前記バッファが受信したパケットを収容
できないときに、バッファのオーバーフローが近いと判
定する、請求項１に記載のファイル転送方法。
【請求項４】前記損失通知パケットを受信した受信端
末が、その受信をトリガにして、そのフロー制御におい
て、輻輳制御・回避のメカニズムを起動させることを特
徴とする、請求項１〜３のひとつに記載のファイル転送
方法。
【請求項５】前記損失通知パケットを受信した受信端
末が、損失したパケットを特定するための情報と適切な
フロー制御を行うために必要な情報を付加した、損失を
明示的に通知することを目的とする確認応答（ＡＣＫ）
を構成し、送信端末に確認応答として転送することを特
徴とする、請求項１〜３のひとつに記載のファイル転送
方法。
【請求項６】前記損失通知パケットのＡＣＫを受信し
た送信端末が、その受信をトリガにして、そのフロー制
御において、輻輳制御・回避のメカニズムを起動させる
ことを特徴とする、請求項５に記載のファイル転送方
法。
【請求項７】前記の受信端末のフロー制御がウインド
ウサイズ制御であることを特徴とする請求項４に記載さ
れた方法。
【請求項８】前記受信端末のウインドウサイズ制御の
輻輳制御・回避メカニズムが、スロースタート・輻輳回
避メカニズム、あるいは、高速再転送と高速リカバリ、
あるいは、それらの両方であることを特徴とする請求項
７に記載された方法。
【請求項９】前記の送信端末のフロー制御がウインド
ウサイズ制御であることを特徴とする請求項６に記載さ
れた方法。
【請求項１０】前記送信端末のウインドウサイズ制御
の輻輳制御・回避メカニズムが、スロースタート・輻輳
回避メカニズム、あるいは、高速再転送と高速リカバ
リ、あるいは、それらの両方であることを特徴とする請
求項９に記載された方法。
【請求項１１】パケットを受信バッファに収容できる
かの単純な判別ではなく、その時点で受信バッファ内に
蓄積されているパケットの総量をパラメータとする、確
定的あるいは確率的な判定条件をもとに判定し、前記損
失通知パケットを構成することを特徴とする請求項１〜
３のひとつに記載された方法。
【請求項１２】前記の判定条件が、各フローのユー
ザ、あるいは、アプリケーションが要求している、少な
くとも１個以上のサービス品質パラメータにも依存する
ことを特徴とする請求項１１に記載された方法。
【請求項１３】前記の判定条件が、各フローのユー
ザ、あるいは、アプリケーションが要求している、パケ
ット損失率、あるいは、スループット、あるいは、それ
らの両方に依存することを特徴とする請求項１２に記載
された方法。
【請求項１４】前記の損失通知パケットを、受信バッ
ファに収容できたパケットよりも特に優先的に転送処理
を行なうこと特徴とする請求項１〜３のひとつに記載さ
れた方法。
【請求項１５】前記の損失通知パケットと、受信バッ
ファにそのまま収容したパケットとに対して、転送処理
を行なう順番を、各フローのユーザ、あるいは、アプリ
ケーションが要求している、少なくとも１個以上のサー
ビス品質パラメータに依存して決定することを特徴とす
る請求項１４に記載された方法。
【請求項１６】前記の損失通知パケットを受信した受
信端末が、送信端末が損失通知パケットのＡＣＫの受信
に対する特別の制御に準拠していない場合に、ＴＣＰの
ＳＡＣＫ、あるいは、通常のＡＣＫのうち、送信端末が
準拠しているより高い転送効率の達成を期待できる方を
選択して、送信端末に確認応答することを特徴とする請
求項４に記載された方法。
【請求項１７】前記の損失通知パケットを構成するた
めに、ヘッダ情報から必要最低限の情報だけを選択的に
抽出していることを特徴とする請求項１〜３のひとつに
記載された方法。