JP2004023794A

JP2004023794A - Ｔｃｐにおける受信側主体のｒｔｔ測定方法

Info

Publication number: JP2004023794A
Application number: JP2003172214A
Authority: JP
Inventors: Fernando Berzosa; フェルナンド　ベルゾーザ; Rolf Hakenberg; ローフ　ハケンベルグ; Thomas Klinner; トーマス　クリナー; Carsten Burmeister; カーステン　ブルマイスター
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2002-06-18
Filing date: 2003-06-17
Publication date: 2004-01-22
Anticipated expiration: 2023-06-17
Also published as: DE60212104D1; JP3789120B2; DE60212104T2; KR100546927B1; EP1376945A1; CN1229945C; KR20040002602A; CN1467953A; US20030231636A1; EP1376945B1; US7330426B2

Abstract

【課題】データパケット受信側におけるラウンドトリップタイム（ＲＴＴ）測定を高速かつ信頼性高く行うための方法を提供することを目的とする。
【解決手段】トランスミッションコントロールプロトコル（ＴＣＰ）を用いネットワークを介して送信側と通信する、データパケット受信側におけるラウンドトリップタイム（ＲＴＴ）測定を行うための方法であり、
現在受信されたデータパケットに対する確認応答を前記送信側に送信するステップと、前記確認応答を送信する第１の時刻を測定するステップと、前記送信側において期待されるデータパケットの送信をトリガーするステップと、期待されるデータパケットの送信が受信される第２の時刻を測定するステップと、前記測定された第１および第２の時刻に基づいてラウンドトリップタイム測定値を計算するステップと、を包含する方法。
【選択図】　　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、パケットデータ伝送に関し、特に、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ：ＩＰ）ネットワークを介したトランスミッションコントロールプロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ：ＴＣＰ）を用いたデータの伝送に関する。ＴＣＰは、その統合的輻輳およびフロー制御メカニズムにより、ネットワークの安定性を提供する。
【０００２】
【従来の技術】
ＴＣＰ送信レートは通常は送信側によって制御されるが、受信側が使用中のリンクおよびビットレートをある程度知っている状況や環境では、送信側のデータ伝送レートを受信側にある程度制御させる意味が生じる。このメカニズムを適用するためには、受信側は、送信側のビットレートを制御または制限するために、ラウンドトリップタイム（ＲＴＴ）値が知る必要がある。結果として、送信側は、自身で利用可能なビットレートを求める必要がない（これは通常はパケットロスと言う犠牲をともない、また受信側の情報よりも不正確である）。ＴＣＰおよびＩＰネットワークに関する情報は、例えば、特許文献１から得ることができる。
【０００３】
【特許文献１】
米国特許第６２９８０４１号明細書
【非特許文献１】
「トランスミッションコントロールプロトコルＤＡＲＰＡインターネットプログラムプロトコル仕様書（ＴＲＡＮＳＭＩＳＳＩＯＮ　ＣＯＮＴＲＯＬＰＲＯＴＯＣＯＬ　ＤＡＲＰＡ　ＩＮＴＥＲＮＥＴ　ＰＲＯＧＲＡＭ　ＰＲＯＴＯＣＯＬ　ＳＰＥＣＩＦＩＣＡＴＩＯＮ）」、南カリファオルニア大学情報科学研究所（Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｃｉｅｎｃｅｓ　Ｉｎｓｔｉｔｕｔｅ　Ｕｎｉｖｅｒｓｉｔｙ　ｏｆ　Ｓｏｕｔｈｅｒｎ　Ｃａｌｉｆｏｒｎｉａ），１９８１年９月
【０００４】
【発明が解決しようとする課題】
ＴＣＰ送信側における送信ビットレートは、輻輳ウィンドウと呼ばれるスライドするウィンドウによって制御される。送信側はデータを送信し、累積的な確認応答を受信する。未処理データとは、送信側が既に送信したが、それに対する応答を受け取っていないデータである。送信側は、輻輳ウィンドウの現在値に等しい量の未処理データを有することが許される。データは通常は送信されてから１ＲＴＴ後に確認応答されるため、許される送信ビットレートＢ＿ｓｅｎｄは、ＲＴＴと輻輳ウィンドウのサイズｃｗｎｄとから、Ｂ＿ｓｅｎｄ＝ｃｗｎｄ／ＲＴＴとして計算され得る。これらの値の一例としては、ＲＴＴ＝１００ミリ秒およびＢ＿ｓｅｎｄ＝６４キロビット／秒である。
【０００５】
サーバにおける輻輳ウィンドウは、集められたネットワーク情報に従って動的に調節される。たとえばパケットロスがある場合、ＴＣＰ送信側はネットワークの輻輳を仮定して、ウィンドウを小さくする。パケットロスが無い場合、ウィンドウは少しずつかつ規則的に増大される。ただし、ＴＣＰがデータパケットの送信の制御のために用いるウィンドウは、輻輳ウィンドウと送信側から通知される別のウィンドウサイズ（広告ウィンドウと呼ばれる）ａｗｎｄとの小さい方である。広告ウィンドウは通常、ＴＣＰのフロー制御特徴、すなわち、高速なＴＣＰ送信側が、受信側が使い尽くせるよりも多くのデータを送信しないことを保証するために使用される。
【０００６】
結論として、統合的フロー制御を用い、ＲＴＴおよび最大送信ビットレートから計算された値で広告ウィンドウを送信することにより、受信側は、ＴＣＰ接続の送信側の送信レートの上限を制限することができる。
【０００７】
１つの接続メンバーのみが送信すべきデータを持っている場合、ＴＣＰ接続における受信側についてのＲＴＴ測定は、接続の最初にしか可能でない（ＴＣＰは３方向ハンドシェークから開始する）。接続のセットアップ時に受信側が行うことができるこの測定は、小さな制御パケット（通常約４０バイト）に基づいているため正確ではない。データパケットはサイズがずっと大きく、例えば１５００バイトであるため、ＲＴＴは通常、小さな制御パケットよりもずっと大きくなる。
【０００８】
これを考慮して、受信側は接続セットアップ時において大まかなＲＴＴ測定を行うことができるが、その後にはさらなるＲＴＴ情報を持っていない。ＩＰネットワークにおいてＲＴＴは通常動的かつ可変であるため、送信側での信頼できる送信ビットレート制御を行うためには、受信側はＲＴＴ情報をより頻繁に集めなくてはならない。
【０００９】
上述のように、ＴＣＰ接続における受信側は、上限を広告ウィンドウの形で通知することにより、送信側の送信ビットレートを制御することができる。しかし、通知すべき広告ウィンドウを計算するためには、受信側はＲＴＴ測定を必要とする。測定値がより良くより正確であればあるほど、ウィンドウの計算もより良くなり、また送信側がそのウィンドウサイズを適用した後のリンク使用状況も良くなる。
それ故に、データパケット受信側におけるラウンドトリップタイム（ＲＴＴ）測定を高速かつ信頼性高く行うための方法を提供することを目的とする。
【００１０】
【課題を解決するための手段および発明の効果】
本発明は、請求項１に記載するように、データパケット受信側におけるラウンドトリップタイム（ＲＴＴ）測定を高速かつ信頼性高く行うための方法を提供する。本方法の好適な実施形態は様々な従属クレームに依拠する。本発明の方法によれば、受信側は、新しいデータパケットの送信をトリガーする確認応答の送信と、トリガーされたデータパケットの受信の時刻との間の時間間隔を決定する。この測定メカニズムが規則的に実行されれば、受信側においてかなり良好なＲＴＴの見積もりが提供される。
【００１１】
【発明の実施の形態】
以下に、添付の図面を参照して本発明をより詳細に説明する。
ネットワークを介して送信側とＴＣＰ接続を有する受信側は、送信側に確認応答を送信し、この確認応答によってトリガーされたデータパケットの受信を待つことによって、ＲＴＴ測定を開始できる。しかし、受信側は、ＲＴＴ測定を開始する前にいくつかの要件が満たされていることを確認しなければならない。以下において、いくつかの要件例を示す。
【００１２】
以下の説明において、１データパケットは典型的な長さが４０バイトのヘッダを含み、ヘッダは、このセグメントの最初のデータバイトを示すシーケンスナンバーフィールドを含むものとする。この値は、データパケットの識別子の役割を果たし得る。ヘッダおよびデータを含むＴＣＰパケットの典型的なサイズは１５００バイトである。一般に、当業者に理解されるように、１つの確認応答は、ａｗｎｄ値と、確認応答の送信側が受信することを期待するデータパケットのシーケンスナンバー（これは確認応答ナンバーとして知られる）とを含んでいる。
【００１３】
以下において、図１は一般的要件を示しており、図２は実施例を示している。理解を容易にするために、対応する要件は、同様の符号の後にＡまたはＢを各々付したものが選ばれている。
【００１４】
開始後の第１の要件Ｒ１として（図１のステップＳ１００）、受信側は、送信側がフロー制御を受けており（広告ウィンドウａｗｎｄによって−−ステップＳ２００Ａを参照のこと）、ＴＣＰスロースタート段階にはもはやないことを、確認しなければならない。ＴＣＰスロースタート段階では、データパケットのバーストが起こるため、ＲＴＴ測定の障害となりうるからである。この要件を確認するための単純かつ保守的な方法は、いくつかのデータパケットを受信するまで待つことである。（２×ａｗｎｄ−１）個のパケットが送信された後（図２の２００Ｂを参照）、送信側のウィンドウがａｗｎｄに達するか、あるいはそれ以前に送信側は既に輻輳回避段階に達している。なお、実際のＴＣＰにおいては変数ａｗｎｄおよびｃｗｎｄはバイト単位で表されるのに対して、上記および以下の説明では、変数ａｗｎｄはセグメントを単位として表される。
【００１５】
例えば、１９個のデータパケットを受信した後にａｗｎｄの値が１０データセグメントである場合を考えると、送信側はもはやスロースタート段階にはないと仮定され得る。
図３において、この要件を例示している。ａｗｎｄが５セグメントであるこの場合において、左から右への直線は送信側から受信側へのデータパケットを示しており、中央の番号はシーケンスナンバーである（これは単なる例であり、実際にはシーケンスナンバーははバイト単位で与えられる）。右側の軸における番号は、ＳＮ＿ａｃｋの値である。
【００１６】
図３は、２×ａｗｎｄ−１＝２×５−１＝９パケットを待つ（ＳＮ＝１０のパケットが到着するまで）と、ちょうど送信側がフロー制御される点に致することを示している。これは、どのＡＣＫパケットも、送信側において１個のデータパケットのみをトリガーすることを意味している。この例においてこれが当てはまる最初のパケットは、第１０パケットである。
【００１７】
第２の要件Ｒ２は、現在の確認応答が送信側においてトリガーするであろうデータパケットのシーケンスナンバーを、受信側が見積もることができることである。すなわち、受信側が、ＳＮ＿ｅｘｐｅｃｔ（ステップＳ３００Ａ）の値を計算できることである。このチェックは、広告ウィンドウａｗｎｄが所定数のパケットについて増大されていなければ成功する（ステップＳ３００Ｂ）。広告ウィンドウの値を増大すると、送信側においてパケットのバーストが起こる可能性という副作用がある。これはまたＲＴＴ測定の障害となり、その値を誤って大きくしてしまう。
【００１８】
図４において、ａｗｎｄ値は５から７へと変化しており、この要件に従えば、次の７パケットについては、ＲＴＴ測定を始めることができない。右側の軸における番号はこの時点では、ａｗｎｄの値をパケット数で表している。この理由は、受信側がＳＮ＿ｅｘｐｅｃｔの値を決定できないからである。図４はまた、送信側によって送信されるパケットのバースト（処理回数が増えるためこの測定の障害となる）を示している。これらの効果は、このＸ＝ａｗｎｄ個のパケットについて必ずしも持続するものではなく、安全な限界である。
【００１９】
第３の要件Ｒ３を表すさらなるステップＳ４００Ａが実行され、ＡＣＫがＴＣＰ送信側において新しいデータパケットをトリガーするか否かをチェックする（ステップＳ４００Ａ）。これは、ａｗｎｄ値が減少したか否かについてのステップが実行されることを意味する（ステップＳ４００Ｂ）。ａｗｎｄ値が減少したならば、次の所定数のデータパケットについて、ＲＴＴ測定はできない。さらに減少した場合には、さらに（ａｗｎｄ＿ｏｌｄ−ａｗｎｄ＿ｎｅｗ）個のパケットを待つことが決定される（ステップＳ４５０Ｂ）。
【００２０】
図５に示す例において、右側の軸における番号はやはり、ａｗｎｄの値を表している。ある時点において、この値は５から３へと変化する。これは、５−３＝２パケットについて、ＲＴＴ測定を開始できないことを意味する。この理由は図５から明らかである。すなわち、ウィンドウサイズが小さくなっているため、送信側が２個の新しいＡＣＫを受信するまでは、新しいＴＣＰパケットがトリガーされないからである。なお、要件を満たさない間は、ＡＣＫによってＲＴＴ測定は開始できない。ただし、入ってくるデータパケットは、以前に開始されたＲＴＴ測定に用いることができる。
【００２１】
ステップＳ５００Ａ、Ｂに示すように、上述の要件Ｒ１〜Ｒ３のすべてを満足したとき、受信側は今回の確認応答を用いたＲＴＴ測定を開始する。ＲＴＴ測定を行うために、図６に示すステップが行われる。
【００２２】
ステップＳ５１０において、現在受信されたデータパケットの確認応答を受信側から送信側へと送信される。さらに、ステップＳ５２０に示すように、確認応答を送信した時刻Ｔ＿ａｃｋが格納される。ステップＳ５３０において、今回の確認応答によってトリガーされるＴＣＰデータパケットの最初のバイトのシーケンスナンバーを示す、期待されるデータパケットのシーケンスナンバーＳＮ＿ｅｘｐｅｃｔが決定される。
【００２３】
期待されるシーケンスナンバーは、次式（１）を用いて計算される。
ＳＮ＿ｅｘｐｅｃｔ＝ＳＮ＿ａｃｋ＋（ａｗｎｄ−１）×ＭＳＳ・・・・（１）
ここでＳＮ＿ａｃｋは、現在の確認応答における確認応答ナンバーであり、ＭＳＳは最大セグメントサイズをバイト単位で示している。
【００２４】
受信側では、ステップＳ５４０において、Ｔ＿ａｃｋの後に受信される全てのデータパケットＳＮ＿ｄａｔａのシーケンスナンバーを、次式（２）に従って比較する。
ＳＮ＿ｄａｔａ≧ＳＮ＿ｅｘｐｅｃｔ・・・・（２）
この条件が真でなければ、受信側は次に受信されるデータパケットを待つ。もし条件が真ならば、次のステップＳ５５０が実行されて実際の時刻Ｔ＿ｎｏｗが格納される。
【００２５】
次のステップＳ５６０において、ＲＴＴが次式（３）により計算される。
ＲＴＴ＝Ｔ＿ｎｏｗ−Ｔ＿ａｃｋ・・・・（３）
一般に、図６のフローチャートに示すＲＴＴ測定を、必要なだけ繰り返すことができ、また、図１に示す要件を満たす限り繰り返すことができる。
【図面の簡単な説明】
【図１】ＲＴＴ測定を開始する前のいくつかの要件例を示すフローチャートである。
【図２】ＲＴＴ測定を開始する前のいくつかの要件を示すための、送信側から受信側へのデータパケットの送信例である。
【図３】ＲＴＴ測定を開始する前のいくつかの要件を示すための、送信側から受信側へのデータパケットの送信例である。
【図４】ＲＴＴ測定を開始する前のいくつかの要件を示すための、送信側から受信側へのデータパケットの送信例である。
【図５】ＲＴＴ測定を開始する前のいくつかの要件を示すための、送信側から受信側へのデータパケットの送信例である。
【図６】本発明によるＲＴＴ測定のフローチャートである。

Claims

トランスミッションコントロールプロトコル（ＴＣＰ）を用いてネットワークを介して送信側と通信する、データパケット受信側におけるラウンドトリップタイム（ＲＴＴ）測定を行うための方法であって、
現在受信されたデータパケットに対する確認応答を前記送信側に送信するステップと、
前記確認応答を送信する第１の時刻を測定するステップと、
前記送信側において期待されるデータパケットの送信をトリガーするステップと、
前記期待されるデータパケットの送信が受信される第２の時刻を測定するステップと、
前記測定された第１および第２の時刻に基づいてＲＴＴ測定値を計算するステップと、
を包含する方法。
前記ＲＴＴ測定は、前記送信側がスロースタート段階にないときにのみ行われることを特徴とする、請求項１に記載の方法。
前記ＲＴＴ測定は、前記受信側から前記送信側に通知されるフロー制御変数が、所定個数の受信データパケットについて一定であったときにのみ行われることを特徴とする、請求項１に記載の方法。
前記受信側は、送信レートの上限を前記送信側に示す、請求項１に記載の方法。
送信レートは、フロー制御コマンドとして機能する広告ウィンドウサイズによって制御される、請求項１に記載の方法。
送信ビットレートは、輻輳ウィンドウを動的に変化させることにより制御される、請求項５に記載の方法。
送信ビットレートは、前記輻輳ウィンドウと、前記受信側によって通知された前記広告ウィンドウとのうちの小さい方に従って制御される、請求項５または６のいずれかに記載の方法。
前記期待されるデータパケットのシーケンスナンバーは、今回の確認応答されたデータパケットＳＮ＿ａｃｋのシーケンスナンバー、前記広告ウィンドウａｗｎｄおよび最大セグメントサイズＭＳＳに基づき、
ＳＮ＿ｅｘｐｅｃｔ＝ＳＮ＿ａｃｋ＋（ａｗｎｄ−１）×ＭＳＳ
に従って計算される、請求項１に記載の方法。
前記広告ウィンドウａｗｎｄが減少したとき、さらに（ａｗｎｄ＿ｏｌｄ−ａｗｎｄ＿ｎｅｗ）個のパケットを受信するまでＲＴＴ測定は行われる、請求項４に記載の方法。