JP4794672B2 - 通信方法 - Google Patents

Description

本発明は、所定の通信プロトコルに従って処理動作を行う、送信側と受信側（sender and receiver）の間のデータ・ユニット式通信（data unit oriented communication）を実施する通信方法に関する。

データ・ユニット式通信はよく知られている。データ・ユニット式通信においては、データの量（an amount of data）が１つ又は２つ以上のデータ・ユニットに分割される。この場合、それらのデータ・ユニットの構造は、通信を行っている送信側と受信側が遵守する通信プロトコルによって定義される。そのプロトコルは、具体的情報（specific information）をどのように符号化すべきかということと、送信側及び／又は受信側が具体的情報に対してどのように反応（react（対応））し得るかということも定義するものである。また、データ・ユニット式通信は、パケット交換通信（packet exchange communication）としても知られている。具体的なプロトコルとの関係において用いられるデータ・ユニットは、例えば、パケット、フレーム（frames）、セグメント（segments）等のような異なる呼び名を有する点には注意されたい。本説明（the present description）においては、便宜上、“データ・ユニット”の用語がデータ・ユニット式通信で用いられるすべてのタイプのユニットを総称的に指すものとする。

信頼性（reliability）を高めるために多くの通信プロトコルが利用している機能（feature（特徴））としては、受信したデータについて受信確認（acknowledging）を行う機能がある。より具体的には、既定プロトコル（the given protocol）の送信側ないし送信側ピア（sending peer）がデータ・ユニットを送出すると共に、既定プロトコルの受信側ないし受信側ピア（receiving peer）が適切な受信確認データ・ユニット（acknowledgment data units）の返送によって正しい受信がなされた旨の受信確認をする（正しい受信がなされたことを通知する）。このようにして、その送信側ピアは、送信したデータ・ユニットが正しく受信もされたということを知らされ、これによって送るべき（送信すべき）さらなるデータ・ユニットのフロー制御（flow control）を調整できることになる。受信確認データ・ユニットを利用するプロトコルの一例としては、一連のＴＣＰ／ＩＰプロトコル（the TCP/IP protocol suite）の一部である、いわゆる伝送制御プロトコル（ＴＣＰ(transmission control protocol)）が挙げられる。

伝送制御プロトコル及び一連のＴＣＰ／ＩＰプロトコルについては、例えば、“TCP/IP Illustrated, Volume 1 - The Protocols”by W. Richard Stevens, Addison-Wesley, 1994 においてよく説明されている。

データ・ユニットないし受信確認データ・ユニットが消失することもあり得るという事実に対処するため、多くのプロトコルではタイムアウト機能（time-out feature）を備えている。そのタイムアウト機能とは、データが送られる時にタイムアウト期間（time-out period）を設定すると共に、そのタイムアウト期間が終了する時刻までにその具体的データ（the specific data）が受信確認をされなかった場合、タイムアウト応答の手順（time-out response procedure）を開始することを予定したものである。ＴＣＰにおいて、タイムアウト応答とは、受信確認されなかったデータを再送信すること（retransmitting）と、１つ又は２つ以上のフロー制御パラメータをリセットすることとにある（受信確認されなかったデータを再送信することと、１つ又は２つ以上のフロー制御パラメータをリセットすることとによってなされる）。

一例として、ＴＣＰでは、窓単位（window-based）のフロー制御を利用している。ＴＣＰは、送るべき与えられた数のバイトをいわゆるセグメントに分割するバイト式プロトコル（byte oriented protocol）であり、その送られたデータの記録（record）をバイトとの関係で保持する、すなわち、どのバイトまでデータが送信されたかという観点で送られたデータの記録を保持し、かつ、受信されたデータの記録もバイトとの関係で保持する。すなわち、どのバイトまでデータが受信されたかという観点で受信されたデータの記録を保持する。受信確認メッセージとの関連においてセグメントのフローを制御する最も簡単なやり方としては、セグメントを送信し、そして最後に送信したセグメントが受信確認されるまで次のセグメントを送信しないようにすることが挙げられよう。しかし、そのようなフロー制御の方法はあまり効率的でない。既に述べたように、ＴＣＰは、窓単位のフロー制御を利用するものであり、その窓単位のフロー制御は、スライド窓によるフロー制御（flow control according to sliding windows）とも呼ばれている。上述の W. Richard Stevens による著書においては、この概念についてもよく説明されている。

図２は、そのスライド窓の概念を例示的に図解したものである。図から分かるように、この例では、総量８１９２バイトの送信が行われているところであり、そのバイト総量が８つのセグメントに分割されている。セグメントの送信は送信窓（send window）に従って制御され、この場合において、送信窓の左端（left end）は、それらのセグメント中の送信されかつ既に受信確認がなされたデータによって定義される。図２の例では、これが２０４８バイトまでのデータ、すなわち、セグメント１及び２となっている。送信窓の長さ（length）の調整とそれによる窓の右端（right end）の調整は制御手順の問題であり、ここでは詳細に説明をする必要はない。

送信窓は、その対応する受信確認未済分（acknowledgment outstanding）を有し得るデータの量を定義する。図２の例において、４０９６バイトまでのデータ、すなわち、セグメント３及び４は、送信はされたが受信確認は未だされておらず、そして、かかる送信はされたが受信確認はされていないセグメントと送信窓の右端との間の差（difference）は、使用可能窓（usable window）、すなわち、如何なる受信確認をもさらに受信することなくなお送信してもよいこととされるデータを定義する。その結果として、図２の例においては、セグメント５及び６についてはこの時点でさらに送信することとしてもよいが、セグメント７及び８については窓が右に移動したときに送信できるのみとなる。窓が右に移動するということが起こるのは、さらなるセグメントの受信確認がなされて左端が右へ移動するようになった場合、及び／又は、送信窓の長さが増大した場合である。

さらに、留意すべき点として、ＴＣＰは累積的受信確認（cumulative acknowledgment）を提供する、すなわち、一つの受信確認メッセージが複数のセグメントをカバーし得る（may cover（複数セグメントについての受信確認メッセージとなり得る））ので、セグメントとセグメントに対する受信確認との間に一対一の対応往復通信（one-to-one correspondence）がない。一例としては、図２中に示したデータ量についての受信側ピアは、４、０９６までのバイトの一受信確認を送信し、その受信確認メッセージがセグメント３及び４の双方をカバーするものとなるようにすることができる。

送信側ピアで使用する送信窓は、いわゆる申告窓ないし通告窓（offered or advertised window）によって定められることになるのが通例である。その申告窓ないし通告窓とは、受信側ピアによって送信側ピアに対して与えられるデータの長さ（data length）である。これにより、受信側ピアは、送信側ピアが一度にいくつのセグメントを送信するかを支配する（influence（左右する））ことができ、通常は受信側ピアの受信バッファを基準として通告窓が計算されることになる。また、通告窓は、受信側ピアが送信する受信確認毎に、それらの受信確認によって変更し得る動的パラメータ（dynamic parameter）である。

通告窓以外には、いわゆる輻湊窓（congestion window）を定義することも知られている。その輻湊窓とは、低速スタート（slow start）、輻湊回避（congestion avoidance）、高速再送信及び高速復帰（fast recovery）等のようないくつかの輻湊制御ルーチンとの関連において使用されるものである（例えば、上述の W. Richard Stevens による著書を再度参照されたい。）。輻湊窓は、送信側ピアが保持する記録であり、かつ、送信側ピアと受信側ピアの間の接続手順における輻湊を考慮することを意図したものである。通常の制御メカニズムでは、送信窓が通告窓及び輻湊窓のうちのより小さいものに定義されることになる。

通告窓は、受信側ピアによって課される（imposed）フロー制御であるのに対し、輻湊窓は、輻湊を考慮に入れるためのメカニズムとして、送信側ピアによって課されるフロー制御である。

広い意味で言えば、輻湊窓は、適応フロー制御パラメータ（adaptive flow control parameter）の一例である。ＴＣＰにおいて、上述したタイムアウト応答は、輻湊窓を一つのセグメントにリセットすることと、次にその結果として一つのセグメントを送るだけとする、すなわち、受信確認がされずにそれによってタイムアウトを生じさせたセグメントを再送信する、ということとによってなされる。その後、送信側ピアは、再送信した当該セグメントの受信確認を待つ。

適応フロー制御パラメータの別の例としては、例えばＴＣＰではＲＴＯ（Retransmission Time Out）と呼ばれている、タイムアウト期間それ自体が挙げられる。ＲＴＯは、タイムアウトに応じるものとして倍になる。

既に述べたように、タイムアウト機能は、データ消失検出のメカニズム（data loss detection mechanism）である。データ消失検出のメカニズムは他にもある。別の例としては、複製受信確認（duplicate acknowledgments）の受信に応じた（応答した）ＴＣＰにおけるデータ・ユニットの再送信が挙げられる。このメカニズムについて以下に簡潔に説明する。

既に述べたように（例えば図２参照）、送られるデータ量はシーケンス（sequence）に分割される。従来におけるＴＣＰの実現手段（implementations）は、受信側ピアが既定バイト（a given byte）までの一定のデータ量（一定数の連続するセグメント）について受信と受信確認とをした場合に、その受信側ピアがそのシーケンスにおける次のデータを期待する（予期して待ち受ける）ように、予め構成されている（arranged）。例えば、セグメント４までのセグメントが受信された場合には、セグメント４についての受信確認がなされると共に受信側ピアがセグメント５の受信を期待する。その後、受信側ピアがセグメント５とは異なるさらなるデータ・ユニット（例えばセグメント６、７及び８）を受信すると、受信側ピアは、それが受信するそれぞれのデータ・ユニットに対してセグメント４の受信確認をし続ける。その結果として、送信側ピアは、複製受信確認を受信する。一般的に、ＴＣＰは、次のような方法で実現される。すなわち、送信側ピアが複製受信確認の数をカウントし、そして、一定の閾値（例えば３）に達した場合には、複製受信確認が受信されたデータ・ユニットの、シーケンスにおける次のデータ・ユニットを再送信する。

本発明の目的は、送られたデータの受信確認を規定すると共にタイムアウト機能ないし複製受信確認の応答機能（duplicate acknowledgment response function）等のようなデータ消失検出機能を規定する通信プロトコルを利用したシステムにおける通信を改良することである。

この目的は、特許請求の範囲に記載した方法によって達成される。

本発明によれば、通信中の送信側は、データ消失検出のメカニズムを始動させる（triggers（トリガーする））イベント（event）に応答して応答手順を実施し、前記応答手順が、フロー制御において使用される適応パラメータを適応化する（adapting（適応させる））ための、少なくとも２つの異なるモードを含むものとなっている。これにより、本発明の方法及び装置は、それらの始動イベントの管理（management of triggering events（トリガーとなるイベントの管理））において非常に柔軟なもの（柔軟性の高いもの）となっており、そして特に、始動イベントの様々な発生の可能性がある原因（potential causes）に応じて前記応答手順を選択し得るような形態で実現し、与えられる状況に対して正しい応答の対策（correct responsive measures）を発動し得るようにすることができ、かつ、それによって、データ消失検出のメカニズムを始動した後で生じ得る状況を実際には悪化させる（aggravate）可能性のある対策を回避することができる。

前記データ消失検出のメカニズムは、データ消失を検出することが可能なメカニズムである。例としては、タイムアウトのメカニズムや複製受信確認のメカニズムが挙げられる。勿論、本発明は、あらゆる適切なデータ消失検出のメカニズムに対しても適用することとしてよい。

本発明によれば、応答手順は、フロー制御において使用される適応パラメータを適応化するための、少なくとも２つの異なるモードを含む。好ましい実施形態を構成する一つの例としては、それぞれタイムアウト又は所定数（predetermined number（予め定めた数））の複製受信確認（例えば上述したように３つの複製受信確認）という異なる原因と関連付けられた、２つのモードがある。より具体的には、第１のモードがデータ・ユニットの消失と関連付けられたものとなっており、かつ、第２のモードが接続手順における過度の遅延（excessive delay along the connection）と関連付けられたものとなっている。２つの異なるモードを利用することにより、タイムアウト又は複製受信確認という原因に対して適切となるようにパラメータを適応化することが可能である。それ故に、そのフロー制御手順は、１つ又は２つ以上の評価及び判定の過程（evaluation and judgment steps）を含むことになり、その評価及び判定の過程においては、始動イベントが認定され（qualified）、例えば、イベントを生じさせたものに関してカテゴリー化（categorization）が実施される。その後、この特徴付け（characterization）の結果に応じて、適切な応答手順を作動することとしてもよい。上記例の場面においては、タイムアウト又は複製受信確認がデータ・ユニットの消失によって発生したと判断される（determined）場合には、データ・ユニットの消失に対する公知の応答手順を実行することとしてもよく、例えば、あらゆるタイムアウトないしいくつかの複製受信確認の受信がデータ・ユニットの消失によって発生するものとみなす、在来のＴＣＰから知られている手順を実行するようにしてもよい。しかし、この実施形態によれば、第２のモードがあり、タイムアウト又は複製受信確認が接続手順における過度の遅延によって発生したと判断される場合には、過度遅延応答手順（excessive delay response procedure）を実行することとし、その過度遅延応答手順は、通常ではデータ・ユニットの消失に対する応答手順とは異なるものとなる。

より具体的には、後のより詳細な説明においても述べるように、データ・ユニットが消失したとの判定に対しては、伝送速度（transmission rate）を減少させることによって応えることとし、それによってさらなる輻湊を回避する。他方、接続手順における過度の遅延がある場合には、仮定したデータ・ユニットの消失に応じて取られる対策が有効なものとはならず、それどころか逆に、それらがその過度の遅延を発生させている問題を実際には悪化させる可能性もある。したがって、過度の遅延に対する応答手順は、通常は異なるものとし、例えば、伝送速度を以前のレベルに維持することを含めるが、その一方でタイムアウト期間を増やすことを含めることとして、さらなる余計な（不要な）再送信を回避するようにする。

勿論、本発明は、様々な始動イベントの原因に対する任意の数のモードないし応答手順を備えるものとして実現してもよい。モードの数と各モードにおいて取る具体的な対策は、勿論具体的な状況に応じて定める。すなわち、モードの数と各モードにおいて取る具体的な対策は、選択したプロトコル、与えられた通信の状況等に応じて定める。

本発明の一つの重要な特徴（aspect）は、データ消失検出のメカニズムがデータ消失を検出することが可能であるが、データ消失検出のメカニズムの始動に対する反応（対応）では、必ずしもデータ消失が生じたとはみなさず、それとは極めて対照的に、様々な始動イベントの原因を考慮し得る柔軟な応答が可能である、という点である。

本発明のさらなる特徴と有利な効果（advantages）は、図面を参照した以下の詳細な説明からさらによく理解できるであろう。

以下の説明においては、データの受信確認を利用すると共にタイムアウト機能も備えた任意の通信プロトコルを対象として広く説明を行うこととするが、一連のＴＣＰ／ＩＰプロトコルにより知られている伝送制御プロトコルＴＣＰに関係する例を度々挙げることにする。このプロトコルへの本発明の適用は、一つの好ましい実施形態である。余計な重複説明をすべて回避するため、その適用の導入においての開示は本発明の開示の中に取り入れることにする。

図１は、本発明の好ましい実施形態の部分的な流れ図を示したものである。図から分かるように、ステップＳ１は、応答手順に入ることを示している。図１がこの時点にまで導くフロー制御手順を示していないのは、それが本発明にとっては何等の重要性もないことだからである。例えば、それは、図２との関係で説明した窓単位のフロー制御手順であってもよく、ＴＣＰ等によってよく知られているものであってもよい。本発明にとって重要なことは、データ受信確認及びデータ消失検出機能があり、起こり得る（possible）データ消失ないし発生の可能性があるデータ消失を検出する能力（capability）をプロトコルの送信側ピアが有し、かつ、対応する応答手順をその送信側ピアが実施し得るようにすることだけである。既に述べたように、そのデータ消失検出機能は、例えば、タイムアウト機能や複製受信確認の検出機能等であってもよい。

図１の例では、応答手順に入った後に、ステップＳ２において、選択したフロー制御のために使用される適応パラメータを記憶し、かつ、それから所定の値（predetermined values（予め定めた値））にそれらの選択した適応パラメータをリセットする。例としては、タイムアウト期間及び／又は上述の輻湊窓がかかる適応フロー制御パラメータに当たる。在来のＴＣＰにおいては、通常では、輻湊窓を一つのセグメントの値にリセットし、かつ、同時にＲＴＯを倍にする。フロー制御手順において使用されるすべての適応パラメータを実際に変更する必要はなく、それとは全く別で選択したもの（a selected number）だけを実際に変更する必要があるだけである、という点に注意されたい。

また、本発明が当然窓単位のフロー制御及び関連する適応パラメータに制限されるものではなく、それどころか逆に、本発明があらゆるフロー制御の原理（principle）及び関連する適応パラメータに対して適用できるということは、明らかである。

図１に戻ると、ステップＳ３においては、イベントを始動させたデータ・ユニット（例えば、タイムアウトを発生させたデータ・ユニット）を再送信する。すなわち、タイムアウトの例を使い続ける場合にあっては、そのタイムアウト期間の間に何等の受信確認も受信されなかったデータ・ユニットが再送信される。その後、より後の時点において、再送信したデータ・ユニットに係る受信確認が受信されたかどうかをステップＳ４で判断する。これは、累積的受信確認であってもよく、あるいはまた、単独の受信確認（a single acknowledgment）であってもよい。注記し得る点として、図１中の点線は、他のステップを介在させる（interposed（間に他のステップを入れる））ことにしてもよいことを示しているが、それらは本発明にとって何等重要なことではない。その後、図１の好ましい例によれば、ステップＳ５において、再送信したデータ・ユニットに係る受信確認が実際にはそのデータ・ユニットのもとの送信（the original transmission）に対して受信確認するものであるか、あるいは、再送信に対して受信確認するものであるかを判断する。ここで注意すべき点として、その“もとの送信”が既に再送信となっていてもよく、“再送信”が再送信の再送信等々であるようになっていてもよい。ステップＳ５を実現することが可能な手段（possibilities）は、続くさらなる説明で述べるように様々なものがある。

受信確認メッセージが実際にデータ・ユニットの再送信に対して受信確認しているものとステップＳ５で判断される場合には、手順がステップＳ７へと進む。この場合のステップＳ７においては、データ・ユニットのもとの送信が消失したことを判断ステップＳ５の否定的結論（negative outcome）が指示している（indicates（示し表している））ので、データ・ユニット消失の応答手順を実行する。ＴＣＰの例では、データ・ユニット消失に備えての在来の対策によってステップＳ７がなされることになる。

これに対して、判断ステップＳ５で肯定的（affirmative）な応えがなされる場合には、手順がステップＳ６へと進む。この場合のステップＳ６においては、過度の遅延に応える（answers）応答手順を実行する。すなわち、ステップＳ５は、データ・ユニットのもとの送信が実際には消失したのではなく、過度に遅延しただけであることを指示しているので、対応する対策を取らなければならない。例えば、プロトコルの例としてＴＣＰを採用しているときは、これ（対応する対策）は、輻湊窓をステップＳ２で記憶した値に戻すことと、その一方でタイムアウト期間を遅延に適応させることとによって行うものとしてもよい。すなわち、タイムアウト期間を適応化するための基準としては、もとの送信及びもとの送信の受信確認に係る往復伝送時間ＲＴＴ（round trip time）を利用することができる。これにより、過度の遅延に起因するさらなる余計な再送信及びタイムアウト又は複製受信確認を回避することができる。

好ましくは、輻湊窓は、単純に以前の値にリセットするのではなく、むしろ、応答手順が行われなかったと仮定した場合の値、すなわち、データ消失検出のメカニズムが始動されなかったと仮定した場合の値に設定する方がはるかによい。

上述のことから分かるように、図１の例は、ステップＳ２、Ｓ３、Ｓ４、Ｓ５及びＳ７で構成されている第１のモードを示しており、これに加えてステップＳ２、Ｓ３、Ｓ４、Ｓ５及びＳ６で構成されている第２のモードも示している。

本発明について一層詳細に説明するために、従来のＴＣＰに関して行われるフロー制御手順の例を示した図３を参照する。グラフは、時間の経過とともに伝送されるデータの量をバイト単位で示したものである。図に示されているように、最初の２つのセグメントは、時刻ｔ＝４ｓに送信される。次に、受信確認データユニットと適応パラメータの調整との相互作用にしたがって、セグメントが送られる。

説明のために、ダイヤモンド状の記号はセグメントを表し、正方形の記号は受信確認データユニットを表すことに留意する必要がある。ダイヤモンド状の記号は、セグメントの最初のバイトを、正方形は受信確認されなかった最も下位のバイトをあらわす。所定のセグメントのレベルで示された受信確認データユニットは常に当該セグメントのレベルまでの送信されたセグメントを表す。換言すれば、６４００バイト（ｔ＝１２ｓ）セグメントレベルまでの受信確認は、６４００バイトより下のセグメントの受信確認を意味するが、６４００バイトそのものを含まない。反対に、図に明瞭に示したように、６４００バイト（ｔ＝１０ｓ）のセグメントは、時間切れを生じさせるデータユニット又はパケットである。したがって、６４００バイトレベルで前記データの再送信が行われる。

図３に示した時間切れが長すぎる遅延のために生じたものであり、図に示した第１のパケットが消失したために生じたものではないと仮定するなら、再送信は以下に記載するような不利益を伴なう。

第１に、同じデータが同一の接続又は接続パスを２回通らなくてはならず、さもなければ有益なデータのために使用することができたバンド幅を浪費することになるためにスループット性能を低下させる。この不利益は、時間切れに対して誤ってデータユニットの再送信で答えるすべてのプロトコルで生じるものである。

図３に示すように、ＴＣＰプロトコルが使用されているなら、データユニットの喪失で生じたものではない時間切れに対する送信側のこの応答は特に不都合である。送信側は滞留中のすべてのパケットを再送信して、さらに送信レートを低下させてしまう。このことを具体的に図３に示した。

上述のデータユニットの喪失ではなく生じた時間切れは、擬似時間切れとも称することに注意されたい。

図３に示されているように、従来のＴＣＰでは、送信側は再送信したデータユニットに対するすべての受信確認を、もとの送信の受信確認が遅れて受信されたものであっても、再送信を受信確認するものと誤って解釈する。

図３には示されていないが、送信側のピアから送信される２度目のデータユニットによって、受信側からの二重の受信確認を引き起こし、従来のＴＣＰ送信においては、通信レートはさらに低下し、輻湊による窓は初期の値の半分になる。

ＴＣＰ時間切れ時間が考慮する範囲を超えた過大な遅延は特に、少なくとも一部分が無線リンクで実行される無線ネットワークや、そのためのプロトコル接続において発生する。本発明の発明者は、その種のネットワークでは擬似時間切れが頻繁に発生して、重大な性能の低下をきたすことを発見した。その例を簡単に説明する。

図４は、２つのホストコンピュータがＴＣＰのピアとして動作する状態を示すものである（図の底部と頂部でホストとホストを結ぶ長い矢印で表す）。低層のプロトコルレイヤは、インターネットへの無線アクセスネットワークを含む。右側のインターネットとホストの接続は図示していない。無線リンクのプロトコルの例は、いわゆる無線リンク制御プロトコルＲＬＣである。図４に示したように、搬送レイヤプロトコル（たとえば、ＴＣＰ）と、リンクレイヤプロトコル（例えば、ＲＬＣ）は共に、ＡＲＱ（自動再送信要求）機能を具備している。これは、このプロトコルはいずれも時間切れと再送信機能を具備することを意味する。図４に示した状態では、リンクレイヤでＡＲＱが使用されているために、リンクレイヤと搬送レイヤとの間に競合状態が生じている。リンクレイヤがデータを再送信する間に、搬送再送信タイマが時間切れになって、擬似時間切れになる可能性が有る。リンクレイヤでの再送信は、例えば、ハンドオーバに起因する送信エラーやデータ消失の可能性がある。

無線ネットワークにおける送信の遅延は、通信レイヤプロトコルの送信側と受信側ピアの間の、両端間遅延の一部であることに注意する必要がある。この場合、無線ネットワークの搬送レイヤ接続のために使用可能なバンド幅が、短時間に顕著に低下すれば、搬送レイヤの送信側と受信側の両端の間の遅延が増大して、擬似時間切れを生じさせることになる。バンド幅低下の例は、移動ホストが、前のセルよりも提供できるバンド幅が少ないセルへのハンドオーバを実行する場合が含まれる。

前述のように、本発明を適用する際は、図３に示した問題を回避することができる。より具体的に述べれば、図３に示した問題に対して、図１に示した方法を適用することによって、送信側のピアは、もとのデータユニットに対する受信確認データユニットと、再送信したデータユニットに対する受信確認データユニットを区別することができる。この情報に基づいて、送信側は、擬似時間切れが発生したのか、データユニットが本当に消失したのかを決定することができる。送信側は、これに従って対処を行うことができる。

より具体的には、図３に示した例では、本発明を使用している送信側は、図示した第１のパケットを送信した後に受信した受信確認データユニットを、もとの送信（ｔ＝１０ｓ）に対する受信確認であって、再送信（ｔ＝１５ｓ）したものに対する受信確認ではないことを認識することができる。これに基づいて、送信側は過剰な遅延に対して適切な応答処理を実行して、つまり、第１の再送信データユニット以降についてはデータユニットを再送信するのではなく、送信レートの提言を行うこともせず、もとのデータユニットの送信から当該もとのデータユニットに対する受信確認データユニットの受信までの遅延に基づいて、フロー制御において採用する打ち切り時間を増大させる。この方法で、余計な再送信と打ち切りの発生を回避することができる。

すでに理解されるように、本発明は、データの受信確認と時間打ち切り機能又は二重受信確認検出機能を有するプロトコルを採用した際に、より柔軟な通信システムをもたらすことができる。上述の例では、契機となるイベントを種類によって分類することができる、つまり、少なくとも２つの異なる原因を区別して、それぞれに適切な対処を実行することができる。上述の例において、適応的なパラメータを適用する方法は、一方ではデータユニットの消失と、他方では過大な遅延とに対応しているが、本発明がこれらに限定されるわけではないことは当然である。反対に、適応的なパラメータを適応する態様は、時間切れイベント又は重複受信確認イベントを生じる原因となるものであれば、どのようなものに対しても適用することができる。

図１に示した実施例では、ステップＳ５で、所定のデータユニットの受信確認に対応するデータユニットが、もとの送信を受信確認するものであるか、再送信を受信確認するものであるかを決定する。当該ステップを実現する第１の好ましい実施態様によれば、送信側は送信側と受信側のピアの間の接続に関する往復時間ＲＴＴの記録を保持しており、特に、対象となる時刻までの最も短いＲＴＴ時間の記録を保持している。再送信されたデータユニットに対する受信確認データユニットが、当該最も短いＲＴＴの予め設定した一部よりも短い時間で受信された場合には、送信側は、この受信確認はもとの送信に対するものであって再送信に対するものではないと判断する。この一部の値は固定された値であっても良いし、適応的なパラメータであっても良い。当該比較値を掛けるべき値が測定された最短ＲＴＴ値である必要は無く、送信側は平均ＲＴＴ値を保持していることもできる。この意味において、当該一部の値は、一般的には、接続の途中において（当該セッションにおいて）測定された１つ以上のＲＴＴ値の関数である。

データユニットに、このようにマーキングすることはどのような方法で行っても良い。例えば、データユニットの内の１つのビットを、値が０であればもとの送信であって、値が１であれば再送信であるように、あるいはその逆に割り当てることも理論上は可能である。一般的には、さらに別の情報を搬送するビットストリングを選択することができる。しかし、そのような選択肢を提供するプロトコルについては、タイムスタンプオプションを使用するのが望ましい。当該オプションは、例えば、周知のＴＣＰについては、前出のW. R. Stevensによる書籍を参照されたい。換言すれば、送信されるデータユニットに、データユニットの送信時刻を示す時刻スタンプを含めることが望ましい。受信側は受信確認データユニットにこの時刻スタンプを含めて、送信側ではその受信確認がどの送信データに対するものかを識別することができるようにすることができる。

本発明の好ましい実施例について記載したが、実施例は本発明の範囲を制限するものではなく、本発明の理解を助けることのみを意図したものである。本発明の範囲は、添付の特許請求の範囲によって決定しなければならない。

本発明に基づく制御手順の好ましい実施形態を示した図である。 窓単位のフロー制御の概念を説明するための解説図である。 本発明の有利な効果を説明するためのグラフである。 ２つのホスト・コンピュータ間の接続において過度の遅延が発生し得る状況を例示するための解説図である。

Claims (1)

1. ＴＣＰに基づいて、送信側と受信側の間の通信を制御する方法であって、
   前記送信側は、送るデータの量を、ＴＣＰによって定められる構造を有する、１つ又はそれ以上のセグメントに分割し、
   前記受信側は、当該セグメントが正しく受信されたことを、前記送信側に受信確認セグメントを返すことにより行い、
   前記送信側は、指定された単一のビットを含む各セグメントを送信することにより、もとの送信と再送信による送信を区別するセグメントのマーキングを行い、
   前記受信側は、受信したセグメントに対し、受信確認セグメントに前記単一のビットを含ませることにより、受信セグメントに対する受信確認セグメントにマーキングを行い、
   もとのセグメントに対する受信確認と、再送信されたセグメントに対する受信確認が区別されることを特徴とする方法。

Images