JP2001352339A - 通信システム - Google Patents

Abstract

(57)【要約】 【課題】 無効な再送タイマのタイムアウトであれば、
送信トラヒックを元に戻し、誤った送信トラヒックの抑
制を避ける。これにより、効率のよい通信を行う。 【解決手段】 受信局は、重複セグメントの受信によ
り、再送タイマの誤ったタイムアウトを検出し、それを
送信局に通知するためのＡＣＫを作成する。送信局に
は、そのＡＣＫの受信から、再送タイマの誤ったタイム
アウトを検出し、トラヒックを元に戻す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はネットワークを介し
て行われるコンピュータ間通信に利用する。

【０００２】

【従来の技術】ネットワークを介してコンピュータ間通
信を行う場合には、送信局が多大なトラヒツクを送信し
たとき、ネットワークやルータなどの中継装置において
輻輳が発生する場合がある。そのため、送信局が輻輳発
生を検出した場合には、送信トラヒックを一時的に減少
させる輻輳制御機能が具備されている。

【０００３】また、ファイル転送、電子メールなどの信
頼性の高いデータ転送が必要となる通信アプリケーショ
ンのために、受信局がユーザの情報を含むデータ（以下
データパケットと呼ぶ）を誤りなく受信した場合には、
送信局にそれを通知する機能（送達確認機能）とデータ
パケットが伝送路上で発生したビット誤りや輻輳などに
より廃棄された場合に、送信局は廃棄されたパケットを
再送する機能（誤り回復機能）を実行する。

【０００４】このような輻輳制御機能、誤り回復機能、
送達確認機能を実行するための通信手順をプロトコルと
呼び、各種のプロトコルが標準化されている。例えば、
ホストコンピュータ間の代表的なプロトコルとしてＴＣ
Ｐ(Transmission Control Protocol)(例えば、W.R.Steve
ns著、“TCP/IP Illustrated,Volume1:The Protocols”,
Addison-Wesley Publishing Company,1994年参照)が標
準化されている。

【０００５】従来のＴＣＰでは、送信局は、再送タイマ
(retransmission timer:前著、pp.297参照)のタイムアウ
ト、もしくは受信局から同一送達確認パケットの複数回
の受信により、データパケットの送信の失敗を検出した
場合に、輻輳が発生したと仮定して、ウィンドウサイズ
を減少させることにより送信トラヒックを減少させる。

【０００６】従来の通信システムについてさらに詳細に
説明する。図６に示すような送信局１および受信局２
が、通信網３を介して接続されている通信システムを考
える。以下の例では、送信局１で発生したデータを受信
局２に送信する片方向の場合を考えるが、両方向の通信
の場合は、送信局１に受信局２の機能を、受信局２に送
信局１の機能を具備することにより実現可能であるた
め、その実現例は省略する。また、ＴＣＰのようなコネ
クション型プロトコルでは、コネクションの確立および
解放処理が必要となるが、ここではコネクション確立後
のデータ転送フェーズに関するものであるため、コネク
ションの確立および解放処理については記述しない。

【０００７】送信局１と受信局２ではＴＣＰが実行され
ている。また、そのＴＣＰのバージョンとして、ＴＣＰ
ＴａｈｏｅもしくはＴＣＰ Ｒｅｎｏが実装されてい
ると仮定する。これらのバージョンの違いは輻輳制御に
ある（例えば、A.Kumar著“Comparative Performance An
alysis of Versions of TCP on a Local Network with
a Lossy Link”,IEEE/ACM Transactions on Networkin
g,vol.4,No.4,August,pp.485-498,1998年参照)。

【０００８】送信局１と受信局２の間には、ひとつのＴ
ＣＰコネクションが設定されていると仮定する。複数の
コネクションが設定されている場合の処理を考慮するに
は、送信局１および受信局２のコネクションに関する各
テーブルに、各ＴＣＰコネクションを特定する識別子を
設け、送信および受信したパケットを該当するコネクシ
ョンに対応づけて処理すれば容易に拡張できる。したが
って、複数のコネクションを処理する場合については省
略する。

【０００９】図７に、従来の送信局のブロック構成図を
示す。図７で示される送信局１では、大きく、ファイル
転送、電子メール、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂなど
のアプリケーション層の処理部に相当する送信局送信側
上位層処理部１０、ＴＣＰの送信側の処理を行う送信局
送信側ＴＣＰ処理部２０、ＴＣＰの受信側の処理を行う
送信局受信側ＴＣＰ処理部３０、各ＴＣＰコネクション
の状態値を保持する送信側ＴＣＰコネクション管理テー
ブル４０、ＩＰの送信側の処理を行う送信局送信側ＩＰ
処理部５０、ＩＰの受信側の処理を行う送信局受信側Ｉ
Ｐ処理部６０、送信側回線のための処理を行う送信局送
信側回線処理部７０、受信側回線のための処理を行う送
信局受信側回線処理部８０、上り回線９０、下り回線１
００から構成される。

【００１０】送信側ＴＣＰコネクション管理テーブル４
０を図８に示す。送信側ＴＣＰコネクション管理テーブ
ル４０は、次の要素から構成される。

【００１１】次送信順序番号１００１：次に送信すべ
き、データパケット（以下、ＴＣＰ用語でのセグメント
と呼ぶ）の送信順序番号（単位はバイトである）（送信
局では、今までに次送信順序番号−１までのバイト数を
送信したことを意味する）。初期値は１とする。

【００１２】次送達確認順序番号１００２：受信局で次
に受信を期待する順序番号（受信局では、次送達確認順
序番号−１までの送信順序番号のバイト数を確かに受信
したことを意味する）。初期値は１とする。受信局は送
達確認パケット（以下、ＡＣＫと呼ぶ）を使って、送信
局に通知する。

【００１３】最大セグメント長１００３：一度の転送で
送信可能な最大のセグメントのデータフィールドの長
さ。

【００１４】受信局側ウィンドウサイズ１００４：受信
局で受信可能なセグメント数。受信局はＡＣＫを使って
送信局に通知する。

【００１５】輻輳ウィンドウサイズ１００５：送信局で
送達確認なしで送信可能なセグメント数。送信局は、輻
輳ウィンドウサイズを調節して、ネットワークヘの送信
トラヒックを制御する。

【００１６】スロースタート閾値１００６：輻輳ウィン
ドウサイズをスロースタートフェーズから輻輳回避フェ
ーズに変更する輻輳ウィンドウサイズ。スロースタート
フェーズでは、輻輳ウィンドウサイズは指数的に増加す
るが、輻輳回避フェーズでは、徐々に輻輳ウィンドウサ
イズが増加する(W.R.Stevens著、“TCP/IP Illustrated,
Volume1:The Protocols”,Addison-Wesley Publishing
Company,pp.310-316,1994年参照)。

【００１７】送信局送信側上位層処理部１０では、アプ
リケーションの処理を行う上位層送信処理部１１とアプ
リケーションで発生したメッセージを保持するメッセー
ジバッファ１２から構成される。

【００１８】送信側ＴＣＰ処理部２０では、ウィンドウ
サイズを制御するウィンドウフロー制御部２１とセグメ
ントを作成するセグメント作成部２２と、セグメントの
再送に備え、送信したセグメントを保持する再送用セグ
メントバッファ２３と、セグメントを送信後、一定時
間、受信局２から応答がない場合を監視する再送タイマ
管理部２４から構成される。

【００１９】なお、受信局側のウィンドウサイズが更新
しているかを確認するための監視タイマであるウィンド
ウ更新監視(persist)タイマ(W.R.Stevens著、“TCP/IP Iuus
trated,Vo1umel:The Protocols”,Addison-Wes1ey Publ
ishing Company,pp.323-330、1994年参照)が必要となる
が、ここでは関係しないため省略する。

【００２０】ウィンドウフロー制御部２１では、送達確
認なしで送信できるバイト数（ウィンドウサイズ）を制
限する。すなわち、送信局１は、次送達確認順序番号＋
ウィンドウサイズ−１までの値をもつバイト数までの送
信を許可する。ただし、このウィンドウサイズは、受信
局側ウィンドウサイズと輻輳ウィンドウサイズの内、小
さい値が取られる。この輻輳ウィンドウサイズは、後述
するように、正常な受信、重複ＡＣＫの受信、再送タイ
マのタイムアウト時などにより変更される。

【００２１】セグメント作成部２２では、ウィンドウフ
ロー制御部２１で送信許可された場合には、メッセージ
バッファ１２に蓄積されているメッセージから、送信可
能なバイト数分のデータを取り出す。もし、メッセージ
長が最大データ長を超える場合には、最大データ長分だ
けのバイト数のデータをとり出す。取り出されたデータ
をセグメントのデータフィールドとし、データパケット
の順序番号(sequencenumber)フィールドに送信側ＴＣＰ
コネクション管理テーブルの次送信順序番号をセットし
たセグメントを作成し、次送信順序番号をセグメントの
データフィールド長分増加させる。セグメント作成部２
２では、最初の送信のセグメントの場合には、そのセグ
メントを再送用セグメントバッファ２３に保存する。

【００２２】送信局送信側ＩＰ処理部５０では、送信局
送信側ＴＣＰ処理部２０で作成されたセグメントに対
し、ＩＰヘッダを付加してパケット作成し、送信局送信
側回線処理部７０に送信する。送信局送信側回線処理部
７０は、上り回線９０にパケットを送信する。送信局受
信側回線処理部８０では、下り回線１００からのパケッ
トを受信した場合に、そのパケットを送信局受信側ＩＰ
処理部６０に送る。送信局受信側ＩＰ処理部６０では、
受信パケットのＩＰ処理（誤り検出、ＩＰパケット並び
換えなど）を行う。

【００２３】送信局受信側ＴＣＰ処理部３０では、ＡＣ
Ｋを処理するＡＣＫ処理部３１から構成される。ＡＣＫ
処理部３１では、ＡＣＫを受信した場合に、そのパケッ
ト内で指示されている送達確認順序番号(acknowledgeme
nt number)フィールド値（受信局２で次に受信を期待す
るセグメントの送信順序番号）の値を送信側ＴＣＰコネ
クション管理テーブル４０の次送達確認順序番号１００
２にセットし、再送用セグメントバッファ２３内にあ
り、末尾バイト値が次送達確認順序番号−１以下のセグ
メントを削除する。また、ＡＣＫ処理部３１は、パケッ
ト内のウィンドウサイズフィールド値を送信側ＴＣＰコ
ネクション管理テーブル４０の受信局側ウィンドウサイ
ズ１００４にセットする。もし、同一のＡＣＫ(duplica
teACK)を続けて複数回（例えば３回）受信した場合に
は、重複ＡＣＫ受信を送信局送信側ＴＣＰ処理部２０に
通知する。

【００２４】送信局送信側ＴＣＰ処理部２０内のウィン
ドウフロー制御部２１では、再送タイマ管理部２４のタ
イマがタイムアウトした場合または重複ＡＣＫ受信の通
知を受けた場合または正常なＡＣＫ受信の通知を受けた
場合には、輻輳ウィンドウサイズおよびスロースタート
閾値を後述するアルゴリズムにしたがって変更する。

【００２５】セグメント作成部２２では、再送タイマ管
理部２４のタイマがタイムアウトした場合もしくは重複
ＡＣＫ受信の通知を受けた場合に、先頭バイト値が次送
達確認順序番号のセグメントを再送する。また、重複Ａ
ＣＫもしくは正常なＡＣＫを受信した場合には、ウィン
ドウ内で送信可能な新しいデータパケットをセグメント
作成部２２において作成して順次送信する。

【００２６】もし、ＡＣＫ内にＲＦＣ２０１８で規定さ
れているＳＡＣＫオプションが指定され、送信局１がＳ
ＡＣＫオプション処理を実装している場合には、受信局
から抜けのあったセグメントを再送する。具体的な実装
方式は、特願平１１−３４６１９２号（本願出願時に未
公開）を参照されたい。

【００２７】輻輳ウィンドウサイズおよびスロースター
ト閾値変更アルゴリズムを次に説明する。

【００２８】（１）ＴＣＰ Ｔａｈｏｅバージョンの場
合 ・再送タイマのタイムアウト時または重視ＡＣＫ受信時 輻輳ウィンドウサイズを最大セグメント長（すなわち最
小のウィンドウサイズ値）にセットする。スロースター
ト閾値を半分にする。 ・正常なＡＣＫパケット受信時 輻輳ウィンドウサイズがスロースタート閾値より小さい
場合には、最大セグメント長増加させる。輻輳ウィンド
ウサイズがスロースタート閾値以上の場合には、（最大
セグメントの二乗）／（現在の輻輳ウィンドウサイズ
値）分増加させる。

【００２９】（２）ＴＣＰ Ｒｅｎｏバージョンの場合 重複ＡＣＫ受信時のみ、ＴＣＰ Ｔａｈｏｅバージョン
と処理が異なる。重複ＡＣＫ受信時、輻輳ウィンドウサ
イズを半分に設定する。

【００３０】図９に、従来の受信局２のブロック構成図
を示す。受信局２では、上り回線１９０、受信側回線の
ための処理を行う受信局受信側回線受信制御部１１０、
ＩＰの受信側の処理を行う受信局受信側ＩＰ処理部１２
０、ＴＣＰの受信側の処理を行う受信局受信側ＴＣＰ処
理部１３０、各ＴＣＰコネクションの状態値を保持する
受信側ＴＣＰコネクション管理テーブル１４０、ＴＣＰ
より上位の層の処理を行う受信側上位層処理部１５０、
ＴＣＰの送信側の処理を行う受信局送信側ＴＣＰ処理部
１６０、ＩＰの送信側の処理を行う受信局送信側ＩＰ処
理部１７０、送信側回線のための処理を行う受信局送信
側回線処理部１８０、下り回線２００から構成される。

【００３１】受信局受信側ＴＣＰ処理部１３０には、受
信側ＴＣＰコネクション管理テーブル１４０と並び換え
用セグメントバッファを保持する。受信側ＴＣＰコネク
ション管理テーブル１４０には、送信局１と受信局２の
間で設定されたコネクションごとに以下の状態値を保持
する。

【００３２】受信期待順序番号：次に受信すべきセグメ
ントの送信順序番号（受信局２は、受信期待順序番号−
１までのセグメントを正しく受信したことを意味す
る。）最近の実装では、受信したセグメントの送信順序
番号が受信期待順序番号と異なる場合には、以下の処理
を行う。 ・受信したセグメントの送信順序番号が受信期待順序番
号より小さい場合には、そのセグメントを廃棄する。 ・受信したセグメントの送信順序番号が受信期待順序番
号より大きい場合には、そのセグメントを並び換え用セ
グメントバッファ管理部１３３に保持する(W.R.Stevens
著、“TCP/IP Illustrated,Vo1umel:The Protocols”,Ad
dison-Wes1ey Publishing Company,pp.308、図21.7を参
照)。また、受信局送信側ＴＣＰ処理部１６０内のＡＣ
Ｋ作成部１６１では、次送達確認順序番号フィールド値
に、受信期待順序番号を入れ、ＡＣＫを作成する。ま
た、受信局では、ＲＦＣ２０１８で規定されているＳＡ
ＣＫオプションが実装されていると仮定する。このＳＡ
ＣＫオプションを使って、受信していないセグメントを
送信局１に通知する。

【００３３】受信したセグメントの送信順序番号と受信
期待順序番号が等しい場合には、もし、並び換え用セグ
メントバッファ管理部１３３内の情報から並び換え用セ
グメントバッファ１３２にセグメントがある場合には、
セグメントを並び換え、順序が正しく整列され最大の送
信順序番号をもつセグメントを求める。その最大の送信
順序番号をＡＣＫ内の次送達確認順序番号フィールド値
とする。もし、並び換え用セグメントバッファ１３２に
セグメントがない場合には、受信したセグメントの送信
順序番号をＡＣＫ内の次送達確認順伴番号フィールド値
とする。セグメント処理部では、順序正しいセグメント
の集合を受信側上位層処理部１５０に送信する。

【００３４】上記の処理において作成されたＡＣＫは、
受信局送信側ＩＰ処理部１７０でＩＰフィールドが付与
され受信局送信側回線処理部１８０を通して、下り回線
２００に送信され、送信局１に到達する。

【００３５】

【発明が解決しようとする課題】前述の例で示したよう
に、従来の通信システムでは、再送タイマがタイムアウ
トしたときに、輻輳ウィンドウサイズを最大セグメント
長すなわち最小の値に設定する。一般に、再送タイマの
タイムアウト値は、往復応答時間より大きい値に設定す
るが、文献（長谷川ら、「誤再送を考慮したＴＣＰのふ
くそう制御方式／エラー回復方式の改善」、電子情報通
信学会論文誌BVol・J82-B,No.11,pp.2074-2084,1999年11
月)で指摘されているように、ネットワークとしてＡＴ
Ｍ（Asynchronous Transfer Mode)網のＥＲ(Explicit R
ate)が使われている場合や、ネットワークの一時的トラ
ヒック増加やセグメントのルート変更により、一時的に
再送タイマのタイムアウト値が、往復応答時間より小さ
くなり、実際には輻輳が発生していないにもかかわら
ず、再送タイマのタイムアウトにより、ネットワークヘ
の送信トラヒックを必要以上に減少させてしまう。これ
により、スループットを不必要に減少させてしまうこと
がある。したがって、輻輳発生の検出が誤りであったこ
とを検出した場合には、速やかに送信トラヒックを元に
戻す工夫が必要となる。

【００３６】本発明は、このような背景に行われたもの
であって、無効な再送タイマのタイムアウトであれば、
送信トラヒックを元に戻し、誤った送信トラヒックの抑
制を避けることができる通信システムを提供することを
目的とする。本発明は、効率のよい通信を行うことがで
きる通信システムを提供することを目的とする。

【００３７】

【課題を解決するための手段】本発明の通信システムで
は、送信局は、無効な再送タイマのタイムアウトを検出
した場合に、送信トラヒックを元に戻す。具体的には、
受信局は、重複セグメントの受信により、再送タイマの
誤ったタイムアウトを検出し、それを送信局に通知する
ためのＡＣＫを作成する。送信局には、そのＡＣＫの受
信から、再送タイマの誤ったタイムアウトを検出し、ト
ラヒックを元に戻す。

【００３８】すなわち、本発明は、一連のデータパケッ
トにその送信順序を示す順序番号である送信順序番号を
付与して送信する手段と、所定時間経過後にこのデータ
パケットの送達確認ができない場合には送信するデータ
トラヒックを減少させる手段とを含む送信局を備えた通
信システムである。

【００３９】ここで、本発明の特徴とするところは、受
信したデータパケットの送信順序番号が受信されること
を期待すべき順序番号である受信期待順序番号より小さ
い値のデータパケットを受信した場合には重複受信情報
を前記送信局に通知する手段を含む受信局が設けられ、
前記減少させる手段は、データトラヒックを減少させる
以前のデータトラヒック情報を保持する手段と、前記重
複受信情報にしたがって前記データトラヒック情報を保
持する手段により保持されたデータトラヒックに現在の
データトラヒックを復帰させる手段とを備えるところに
ある。

【００４０】これにより、無効な再送タイマのタイムア
ウトであれば、送信トラヒックを元に戻し、誤った送信
トラヒックの抑制を避けることができる。したがって、
効率のよい通信を行うことができる。

【００４１】前記受信局は、送信順序番号が受信期待順
序番号と異なるデータパケットを受信した場合にはこの
データパケットを保持する手段を備え、前記通知する手
段は、保持されているデータパケットと同一の送信順序
番号のデータパケットを受信した場合には前記重複受信
情報を送信局に通知する手段を含むことが望ましい。

【００４２】これにより、受信局で欠落した順序番号の
データパケットだけを送信局に再送要求する通信形態の
場合においても本発明を適用することができる。

【００４３】

【発明の実施の形態】本発明実施例の通信システムの構
成を図１および図２を参照して説明する。図１は本発明
実施例の送信局のブロック構成図である。図２は本発明
実施例の受信局のブロック構成図である。

【００４４】本発明は、図１に示すように、一連のデー
タパケットにその送信順序を示す順序番号である送信順
序番号を付与して送信するセグメント作成部２２と、所
定時間経過後にこのデータパケットの送達確認ができな
い場合には送信するデータトラヒックを減少させるウィ
ンドウフロー制御部２１および再送タイマ管理部２４と
を含む送信局１を備えた通信システムである。

【００４５】ここで、本発明の特徴とするところは、図
２に示すように、受信したデータパケットの送信順序番
号が受信されることを期待すべき順序番号である受信期
待順序番号より小さい値のデータパケットを受信した場
合には重複受信情報を前記送信局に通知する重複セグメ
ント受信フラグ作成部２００４を含む受信局２が設けら
れ、ウィンドウフロー制御部２１は、データトラヒック
を減少させる以前のデータトラヒック情報を保持する輻
輳検出時送信トラヒックテーブル２００１を備え、前記
重複受信情報にしたがって輻輳検出時送信トラヒックテ
ーブル２００１により保持されたデータトラヒックに現
在のデータトラヒックを復帰させるところにある。

【００４６】受信局２は、送信順序番号が受信期待順序
番号と異なるデータパケットを受信した場合にはこのデ
ータパケットを保持する並び換え用セグメントバッファ
１３２を備え、重複セグメント受信フラグ作成部２００
４は、保持されているデータパケットと同一の順序番号
のデータパケットを受信した場合には前記重複受信情報
を送信局１に通知する。以下では、本発明実施例をさら
に詳細に説明する。

【００４７】図１に示す送信局１では、ウィンドウフロ
ー制御部２１内に新たに輻輳検出時送信トラヒックテー
ブル２００１と、ＡＣＫ処理部３１内に送信側重複セグ
メント検出部２００２を追加している。また、図２に示
す受信局２では、セグメント処置部１３１内に、受信側
重複セグメント検出部２００３と、ＡＣＫ処理部内に、
送信側重複セグメント検出部２００２を追加している。

【００４８】図３に第一実施例での受信側重視セグメン
ト検出部２００３での処理フローを示す。まず、受信し
たセグメントの送信順序番号と受信期待順序番号を比較
する（ステップ３００１）。受信したセグメントの送信
順序番号が受信期待順序番号より小さい場合は、重複セ
グメント受信フラグをＴＲＵＥにする（ステップ３００
２）。それ以外は、重複セグメント受信フラグをＦＡＬ
ＳＥとする（ステップ３００３）。

【００４９】図４に第二実施例での受信側重複セグメン
ト検出部２００３での処理フローを示す。まず、受信し
たセグメントの送信順序番号と受信期待順序番号を比較
する（ステップ４００１）。もし、前者の値が、後者の
値より小さいとき、並び換え用セグメントバッファ１３
２にセグメントがあるか調べる（ステップ４００２）。
もし、セグメントがある場合は、並び換え用セグメント
バッファ内に受信したセグメントと同じセグメントがあ
るか調べる（ステップ４００３）。受信したセグメント
の送信順序番号が受信期待順序番号より小さいか、もし
くは、受信したセグメントが並び換え用セグメントバッ
ファ内にある場合は、重複セグメント受信フラグをＴＲ
ＵＥにする（ステップ４００４）。それ以外は、重複セ
グメント受信フラグをＦＡＬＳＥとする（ステップ４０
０５）。重複セグメント受信フラグの値を送信局１に通
知するために、ＴＣＰ Ｏｐｔｉｏｎフィールドを使用
する方法が考えられる(W.R.Stevens著、“TCP/IP Illust
rated,Vo1umel:The Protocols”,Addison-Wes1ey Publi
shing Company,pp.253-254を参照)。例えば、Ｋｉｎｄ値
１９を使用する案がある(RFC1700、Assigned Numbersで
は値19は未使用である)。

【００５０】ＡＣＫ作成部１６１内の重複セグメント受
信フラグ作成部２００４では、ＡＣＫを作成する際に、
上記ＴＣＰ Ｏｐｔｉｏｎフィールドに重複セグメント
受信フラグの値を入れる。

【００５１】ウィンドウフロー制御部２１では、再送タ
イマのタイムアウト時（従来の装置では、網内で輻輳が
発生したと仮定している）、送信トラヒックを減少させ
る前の現時点の送信トラヒックの情報（図８における輻
輳ウィンドウサイズ１００５、スロースタート閾値１０
０６）の値を輻輳検出時送信トラヒックテーブル２００
１内に保存しておく。

【００５２】図５に、前述した受信局２に関する第一お
よび第二実施例に共通した送信局１での処理フローを示
す。送信側重複セグメント検出部２００２では、受信し
たＡＣＫのＯｐｔｉｏｎフィールド内の重複セグメント
受信フラグの値を調べる（ステップ５００１）。もし、
重複セグメント受信フラグの値がＴＲＵＥの場合には、
ウィンドウフロー制御部２１に、受信局２で重複したセ
グメントを受信した旨を通知し、送信局は輻輳発生の検
出が誤りであったと仮定し、ウィンドウフロー制御部２
１は送信トラヒックの値を輻輳検出時送信トラヒックテ
ーブル２００１に保存されている情報（輻輳ウィンドウ
サイズ１００５、スロースタート閾値１００６）の値に
戻し、セグメントを送信する（ステップ５００２）。

【００５３】もし、重複セグメント受信フラグの値がＦ
ＡＬＳＥの場合には、現時点の送信トラヒックの値を使
ってセグメントを送信する（ステップ５００３）。この
場合には、送信側重複セグメント検出部２００２は、ウ
ィンドウフロー制御部２１に通知する必要はない。

【００５４】

【発明の効果】以上述べたように本発明によれば、無効
な再送タイマのタイムアウトであれば、送信トラヒック
を元に戻し、誤った送信トラヒックの抑制を避けること
ができる。これにより、効率のよい通信を行うことがで
きる。

【図面の簡単な説明】

【図１】本発明実施例の送信局のブロック構成図。

【図２】本発明実施例の受信局のブロック構成図。

【図３】第一実施例での受信側重視セグメント検出部で
の処理フローを示す図。

【図４】第二実施例での受信側重複セグメント検出部で
の処理フローを示す図。

【図５】本発明実施例の送信局での処理フローを示す
図。

【図６】通信システムの全体構成図。

【図７】従来の送信局のブロック構成図。

【図８】送信側ＴＣＰコネクション管理テーブルの構成
を示す図。

【図９】従来の受信局のブロック構成図。

【符号の説明】

１ 送信局 ２ 受信局 ３ 通信網 １０ 送信局送信側上位層処理部 １１ 上位層送信処理部 １２ メッセージバッファ ２０ 送信局送信側ＴＣＰ処理部 ２１ ウィンドウフロー制御部 ２２ セグメント作成部 ２３ 再送用セグメントバッファ ２４ 再送タイマ管理部 ３０ 送信局受信側ＴＣＰ処理部 ３１ ＡＣＫ処理部 ４０ 送信側ＴＣＰコネクション管理テーブル ５０ 送信局送信側ＩＰ処理部 ６０ 送信局受信側ＩＰ処理部 ７０ 送信局送信側回線処理部 ８０ 送信局受信側回線処理部 ９０、１９０ 上り回線 １００、２００ 下り回線 １１０ 受信局受信側回線受信制御部 １２０ 受信局受信側ＩＰ処理部 １３０ 受信局受信側ＴＣＰ処理部 １３１ セグメント処理部 １３２ 並び換え用セグメントバッファ １３３ 並び換え用セグメントバッファ管理部 １４０ 受信側ＴＣＰコネクション管理テーブル １５０ 受信側上位層処理部 １６０ 受信局送信側ＴＣＰ処理部 １６１ ＡＣＫ作成部 １７０ 受信局送信側ＩＰ処理部 １８０ 受信局送信側回線処理部 ２００１ 輻輳検出時送信トラヒックテーブル ２００２ 送信側重複セグメント検出部 ２００３ 受信側重複セグメント検出部 ２００４ 重複セグメント受信フラグ作成部

Claims (2)

【特許請求の範囲】
1. 【請求項１】 一連のデータパケットにその送信順序を
   示す順序番号である送信順序番号を付与して送信する手
   段と、 所定時間経過後にこのデータパケットの送達確認ができ
   ない場合には送信するデータトラヒックを減少させる手
   段とを含む送信局を備えた通信システムにおいて、 受信したデータパケットの送信順序番号が受信されるこ
   とを期待すべき順序番号である受信期待順序番号より小
   さい値のデータパケットを受信した場合には重複受信情
   報を前記送信局に通知する手段を含む受信局が設けら
   れ、 前記減少させる手段は、データトラヒックを減少させる
   以前のデータトラヒック情報を保持する手段と、前記重
   複受信情報にしたがって前記データトラヒック情報を保
   持する手段により保持されたデータトラヒックに現在の
   データトラヒックを復帰させる手段とを備えたことを特
   徴とする通信システム。
2. 【請求項２】 前記受信局は、送信順序番号が受信期待
   順序番号と異なるデータパケットを受信した場合にはこ
   のデータパケットを保持する手段を備え、 前記通知する手段は、保持されているデータパケットと
   同一の送信順序番号のデータパケットを受信した場合に
   は前記重複受信情報を送信局に通知する手段を含む請求
   項１記載の通信システム。