JP3617649B2 - 最適化された受信側始動型送信レート増大方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、パケットデータ伝送に関し、特に、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：ＩＰ）ネットワークを介したトランスミッションコントロールプロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ：ＴＣＰ）を用いたデータの伝送に関する。ＴＣＰは、その統合的輻輳およびフロー制御メカニズムにより、ネットワークの安定性を提供する。
【０００２】
【従来の技術】
ＴＣＰ送信レートは通常は送信側によって制御されるが、受信側が使用中のリンクおよびビットレートをある程度知っている状況や環境では、これらのため、送信側のデータ伝送レートを受信側にある程度制御させる意味が生じる。このメカニズムを適用するためには、受信側は、送信側のビットレートを制御または制限するために、ラウンドトリップタイム（ＲＴＴ）値を知る必要がある。結果として、送信側は、自身で利用可能なビットレートを求める必要がない（これは通常はパケットロスと言う犠牲をともない、また受信側の情報よりも不正確である）。ＴＣＰおよびＩＰネットワークに関する情報は、例えば、特許文献１から得ることができる。
【０００３】
【特許文献１】
米国特許第６２９８０４１号明細書
【非特許文献１】
「トランスミッションコントロールプロトコルＤＡＲＰＡインターネットプログラムプロトコル仕様書（ＴＲＡＮＳＭＩＳＳＩＯＮ ＣＯＮＴＲＯＬＰＲＯＴＯＣＯＬ ＤＡＲＰＡ ＩＮＴＥＲＮＥＴ ＰＲＯＧＲＡＭ ＰＲＯＴＯＣＯＬ ＳＰＥＣＩＦＩＣＡＴＩＯＮ）」、南カリファオルニア大学情報科学研究所（Ｉｎｆｏｒｍａｔｉｏｎ Ｓｃｉｅｎｃｅｓ Ｉｎｓｔｉｔｕｔｅ Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｓｏｕｔｈｅｒｎ Ｃａｌｉｆｏｒｎｉａ）、１９８１年９月
【０００４】
【発明が解決しようとする課題】
ＴＣＰ送信側における送信ビットレートは、輻輳ウィンドウと呼ばれるスライドするウィンドウによって制御される。送信側はデータを送信し、累積的な確認応答を受け取る。未処理データとは、送信側が既に送信したが、それに対する応答を受け取っていないデータである。送信側は、輻輳ウィンドウの現在値に等しい量の未処理データを有することが許される。データは通常は送信されてから１ＲＴＴ後に確認応答されるため、許される送信ビットレートＢ＿ｓｅｎｄは、ＲＴＴと輻輳ウィンドウのサイズｃｗｎｄとから、Ｂ＿ｓｅｎｄ＝ｃｗｎｄ／ＲＴＴとして計算され得る。これらの値の一例としては、ＲＴＴ＝１００ミリ秒およびＢ＿ｓｅｎｄ＝６４キロビット／秒である。
【０００５】
サーバにおける輻輳ウィンドウは、集められたネットワーク情報に従って動的に調節される。たとえばパケットロスがある場合、ＴＣＰ送信側はネットワークの輻輳を仮定して、ウィンドウを小さくする。パケットロスが無い場合、ウィンドウは少しずつかつ規則的に増大される。ただし、ＴＣＰがデータパケットの送信の制御のために用いるウィンドウは、輻輳ウィンドウと送信側から通知される別のウィンドウサイズ（広告ウィンドウと呼ばれる）ａｗｎｄとの小さい方である。広告ウィンドウは通常、ＴＣＰのフロー制御特徴、すなわち、高速なＴＣＰ送信側が、受信側が使い尽くせるよりも多くのデータを送信しないことを保証するために使用される。
【０００６】
結論として、統合的フロー制御を用い、ＲＴＴおよび最大送信ビットレートから計算された値で広告ウィンドウを送信することにより、受信側は、ＴＣＰ接続の送信側の送信レートの上限を制限することができる。すなわち、受信側は、送信ビットレートの最大値をサーバに指示することができる。この最大ビットレートを増加するとき、レートをあまり早く増加させないように送信側の挙動を予見しなければならない。レートをあまり早く増加させると、ＴＣＰ送信側で伝送されるデータパケットのバーストが始まり、経路上でのバッファオーバーフローにつながるからである。
【０００７】
一方、受信側が広告ウィンドウをあまりに遅く増大させると、送信側は送信レートを同様に遅く増加させるため、リンク容量を十分に利用し切らないことになってしまう。
従って、ＴＣＰ送信側における送信レートが最適に増加されるような、広告ウィンドウの最適化された増加方法が必要である。
【０００８】
【課題を解決するための手段および発明の効果】
本発明は、請求項１に記載するように、ビットレートをなるべく早く最適値に増加することを可能にすると同時に、利用可能なリンクリソースを最大限に利用する、最適化された受信側始動型送信レート増大する方法を提供する。本方法の好適な実施形態は様様な従属クレームに依拠する。本発明の方法は、最大で確認応答毎につき１セグメントサイズだけ広告ウィンドウを増大する。この結果、伝送経路におけるバッファオーバーフローにつながり得るパケットのバーストのきっかけとなることなく、送信ビットレートを新しい値に調節することができる。従って受信側は、送信側のビットレートを、スムーズにかつ非常に高速に増大することができる。実際、送信側は広告ウィンドウによって許されるよりも多くのデータは送信せず、１度に１個よりも多くのパケットを生成しない。
【０００９】
好適な実施形態において、確認応答は規則的な間隔で送信され、これにより送信側のビットレートの増大をさらにスムーズにし、伝送されるパケットを均一に分布させる。
【００１０】
さらに好適な実施形態において、確認応答は、送信側への送信前にはキューに格納されている。この結果、入ってくるデータパケットは直接には確認応答されず、キュー内に十分な確認応答が存在する限り、規則的な間隔で送信される。
【００１１】
さらに有利な実施形態において、次の規則的な時間間隔においてキュー内に所定の数未満の確認応答しか存在しない場合、セグメントの一部だけに対する確認応答が送信側に送信される。これは、十分な確認応答が存在しないとき、追加的な確認応答（１セグメント全体には確認応答しない）が生成されると言う利点を有する。ただし、送信側は、確認応答を用いて、広告ウィンドウを調節し、これに対応して送信ビットレートを増加することができる。
【００１２】
好ましくは、本方法は、１つの確認応答の送信を完了すべき最大期間を決定するステップを包含する。これにより、ＴＣＰ送信側における再送信タイムアウトにつながり得る、確認応答の送信の過大な遅れを回避する。
【００１３】
本方法のさらに好適な実施形態によれば、セグメントの残りに対する確認応答は、最も遅くとも、１つの確認応答の完了のための最大期間が過ぎたときに送信される。
【００１４】
【発明の実施の形態】
以下に、添付の図面を参照して本発明をより詳細に説明する。
本発明を説明するため、以下において送信側と受信側との間のＴＣＰ接続を仮定する。ここでは次式（１）に基づき、送信側のビットレートＢ＿ｏｌｄは、広告ウィンドウａｗｎｄによって制限される。
Ｂ＿ｏｌｄ ＝ ａｗｎｄ／ＲＴＴ・・・・（１）
【００１５】
受信側は、この接続で利用可能なリンク容量はＢ＿ｏｌｄからＢ＿ｎｅｗに増加するという情報を得る。例えば、移動体通信ネットワーク中の無線リソースコントロールが新しい無線携帯者をセットアップしたか、あるいは今までリンクを共有していた別のデータフローが終了した場合にこのような事が起こりうる。受信側においては、新しい広告ウィンドウは、次式（２）に従って計算される。
ａｗｎｄ＿ｎｅｗ ＝ Ｂ＿ｎｅｗ × ＲＴＴ・・・・（２）
【００１６】
図１を参照すると、第１のステップＳ１００は、次式（３）または（４）に従って新しい確認応答スペースＡＣＫ＿ｓｐａｃｅは計算される。
ＡＣＫ＿ｓｐａｃｅ ＝ ＭＳＳ／Ｂ＿ｎｅｗ・・・・（３）
ここで、ＭＳＳは接続のセットアップ時にネゴシエートされた最大セグメントサイズである。
ＡＣＫ＿ｓｐａｃｅ ＝ ＲＴＴ／ａｗｎｄ＿ｎｅｗ・・・・（４）
ここで、ａｗｎｄ＿ｎｅｗはセグメントの数として与えられる。
【００１７】
入って来る全てのデータパケットが直接確認応答されるのではなく、確認応答はＡＣＫキューに格納される。
【００１８】
ステップＳ１００においてタイマをセットすると、ステップＳ２００に示すように、受信側は次のＡＣＫ＿ｓｐａｃｅ時間が終わるまで待つ。送信側が新しいビットレートによる伝送をなるべく早く開始することが望まれるので、最初の確認応答についてはステップＳ１００のタイマはより小さな値あるいはゼロに設定され得る（前の確認応答が送信された時刻による）ことに留意されたい。続く確認応答は、パケットのバーストを避けるために、ＡＣＫ＿ｓｐａｃｅ変数に従ってスペースを空けられる。
【００１９】
このとき、１つの確認応答が送られなければならず、フローチャートは続いてステップＳ３００により、ＡＣＫキュー内に１つより多くの確認応答が存在するか否かを確認する。もしキュー内に確認応答が無ければ、アルゴリズムは、新しい確認応答が生成されるまで、ここで停止しなければならない。
【００２０】
もしＡＣＫキュー内に２以上の確認応答が存在する場合、ステップＳ４００に示すように、１つの確認応答が送信され、ａｗｎｄ値が更新され、ＡＣＫ＿ｓｐａｃｅタイマが新しく起動される。この条件下において、
サーバの送信ビットレートをスムーズに増加させるためのフロー制御コマンドとして用いられるのに十分な確認応答が、キュー内に存在することになる。
【００２１】
一方、確認応答が１つだけがキュー内に存在する場合、手続きは図１におけるステップＳ５００に示すステップに進む。パラメータｏｒｉｇｉｎａｌ＿ａｃｋ＿ｎｏは、入って来る完全なデータパケットを確認応答するためのセグメントの確認応答ナンバーを表す。すなわち、元の確認応答パケットの確認応答ナンバーフィールドである。パラメータｌａｓｔ＿ａｃｋ＿ｎｏは、最後に送信されたセグメントのａｃｋ＿ｎｏを格納している。ステップＳ５００のステップにおいて、広告ウィンドウａｗｎｄおよび最終広告ａｗｎｄ＿ｌａｓｔは、それぞれ１セグメントずつ増大する。さらに、確認応答ナンバーａｃｋ＿ｎｏおよび最終確認応答ナンバーｌａｓｔ＿ａｃｋ＿ｎｏはそれぞれ、１バイト増加する。さらに、１つの確認応答ＡＣＫの送信を完了すべき最大の期間を定義するタイマである、ｓｐｌｉｔ＿ａｃｋタイマを定義する必要がある。このタイマは完全なＡＣＫの送信の過大な遅れ（これは送信側における再送信タイムアウトにつながる）を避けるように、適宜設定する必要がある。
【００２２】
その後、１つの確認応答が生成される。生成とは、元の確認応答のヘッダフィールドのうちの一部を、今計算されたものに変更することを意味する。変数である広告ウィンドウａｗｎｄおよび確認応答ナンバーａｃｋ＿ｎｏが、ＴＣＰヘッダ中に適切に設定されなければならない。残りの変数は、アルゴリズム内の計算のためにローカルのみとして保存される。これらの変更の結果として、ヘッダチェックサムもまた計算されて設定されなければならない。
【００２３】
最後のステップにおいて、確認応答が送信される。この確認応答は１セグメント全体についてではなく、その一部だけについてであり、本例においては１バイトである。したがってこの確認応答は、送信側にさらなるデータパケットの送信を許さない。しかし、（各確認応答と同じく）広告ウィンドウ（この場合１だけ増大されている）を含んでおり、これが新しいデータパケットの送信をトリガーする。しかし、データパケットは確認応答自体によってはトリガーされるのではなく、広告ウィンドウの増大によってトリガーされることを強調しておく。最後に、ステップＳ５００の中の最後のステップは、確認応答が送信されるとともにＡＣＫ−ｓｐａｃｅタイマを開始あるいはスタートさせることである。
【００２４】
フローチャート中の次のステップＳ６００において、ＡＣＫ＿ｓｐａｃｅタイマおよびｓｐｌｉｔ＿ＡＣＫタイマの一方が切れたかどうかを決定する。ｓｐｌｉｔ＿ＡＣＫタイマが切れた場合は、１セグメント全体についての確認応答を完了するための最大期間が過ぎたため、フローはステップＳ７００へと続く。従って、元々の確認応答ナンバーを有する確認応答が送信され、パラメータｌａｓｔ＿ａｃｋ＿ｎｏおよび広告ウィンドウ値が更新される。１つのＴＣＰセグメント全体が確認応答されたのであるから、この確認応答は今度は、新しいデータパケットの送信をトリガーする。
【００２５】
一方、ステップＳ６００においてＡＣＫ＿ｓｐａｃｅタイマが切れたと判断された場合は、ステップＳ８００において、確認応答キュー中に別の確認応答が利用可能であるか否かをチェックする。もし利用可能であれば、手順はステップＳ７００へと続く。そうでなければ、ステップＳ９００に達する。ステップＳ９００において、ステップＳ５００と同じステップが実行されるが、ただしｓｐｌｉｔ＿ＡＣＫ＿タイマをスタートする必要がない。従って、ステップＳ９００において、セグメントの次のバイトについてさらなる確認応答が、対応するａｃｋ＿ｎｏおよびａｗｎｄ値でもって送信される。フローは上述のようにステップＳ６００へと続く。
【００２６】
最後に、広告ウィンドウの値が変更されるたびに、ａｗｎｄの新しい目標値に達したか否かについて比較されることに留意されたい。もし到達していれば、広告ウィンドウがその最終目標値に達したとしてアルゴリズムは終了する。
【００２７】
上述のアルゴリズムを用いることにより、受信側は、確認応答を受け取った後に、送信側がすぐに新しいデータレートに従って送信側を開始することを確実にする。増大した広告ウィンドウ値が送信側で受け取られるからである。さらに、送信側は、広告ウィンドウによって許されるよりも多くのデータは送信せず、パケットバーストを発生させない。
【００２８】
従って、本アルゴリズムは、経路途中でのバッファオーバーフローのリスクなしに、受信側が送信側のビットレートを非常にスムーズかつ高速に増大することを可能にする。同時に、利用可能なリンク容量が効率的に利用される。
【図面の簡単な説明】
【図１】サーバにおいて新しい送信ビットレートを開始するためのステップを説明するフローチャートである。

Claims (5)

1. トランスミッションコントロールプロトコル（ＴＣＰ）を用いてネットワークを介して送信側から受信側に送信されたデータパケットの、受信側始動型送信レートを増大する方法であって、
   許可される送信ビットレートを示す広告ウィンドウを含み、受信したデータパケットに対する確認応答であって、許可される送信ビットレートを示す広告ウィンドウを含んだ確認応答を規則的な時間間隔で前記受信側から前記送信側へと送信するステップと、
   前記送信側への送信前に、前記確認応答をキューに格納するステップと、
   次の規則的な時間間隔において前記キュー内に所定数未満の確認応答しか存在しない場合、セグメントの一部に対する確認応答を前記送信側に送信するステップと、
   前記広告ウィンドウを、最大で確認応答毎につき１セグメントサイズ増大するステップと、
   を包含する方法。
2. １つのデータセグメントに対する１つの確認応答の送信を完了すべき最大期間を決定するステップをさらに包含する、請求項１に記載の方法。
3. 前記セグメントの残りに対する確認応答を、最も遅くとも、１つの確認応答の完了のための前記最大期間が過ぎたときに送信するステップをさらに包含する、請求項２に記載の方法。
4. 前記セグメントの一部に対する前記確認応答は、１つのセグメントによって広告ウインドウを増大するのに対し、当該セグメントの残り又は全部に対する前記確認応答は、広告ウインドウを増大せず、両方の確認応答は、次の１データパケットのトリガーを許可する、請求項３に記載の方法。
5. 前記時間間隔で送信される確認応答は、最大セグメントサイズ及び新たな送信ビットレートに基づいて決定される、請求項１〜４のいずれかに記載の方法。

Images