説明

通信端末、輻輳制御方法および輻輳制御プログラム

【課題】確認応答の受信間隔が正確でないネットワーク上においても、用意されたネットワーク帯域を有効利用しつつ、ネットワークの輻輳を回避できるようにする。
【解決手段】計測されると、RTTの最小値(rtt_min)の時間内に受信したAckまたはSAck(Selective Acknowledgement)の情報から、受信側に到着が確認された受信セグメントのバイト数(rcv_bytes)を算出し、受信バイト数設定部16は、ロス検出部15にてパケットロスが検出された場合、受信バイト数計算部14にて算出されたセグメントのバイト数(rcv_bytes)に基づいて、パケットロス発生時の輻輳ウィンドウ(CWND)またはスロースタート閾値(SSTHRESH)を設定する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は通信端末、輻輳制御方法および輻輳制御プログラムに関し、特に、TCP(Transmission Control Protocol)における輻輳制御方法に適用して好適なものである。
【背景技術】
【0002】
現在、インターネットで幅広く用いられているTCPでは、ネットワークの輻輳を回避するために、セグメントを送信する際に輻輳ウィンドウ(CWND)を利用して輻輳制御が行われている。
一般的にTCPの輻輳制御アルゴリズムでは、パケットロスの発生時に、以下のようにして輻輳ウィンドウの設定が行なわれる。
【0003】
1.FF(Fast Retransmit&Fast Recovery:高速再送および高速復帰)時
SSTHRESH=(1−b)×CWND
CWND=SSTHRESHに設定する。
2.RTO(Retransmit Timeout:再送タイムアウト)発生時
SSTHRESH=(1−b)×CWND
CWND=1×MSSに設定する。
【0004】
ただし、MSS(Maximum Segment Size)は送信側が送信することができる最大セグメントサイズである。また、CWND(CONGESTION WINDOW)は、TCPの送信可能サイズを制限するTCPステート変数である。また、SSTHRESH(SLOWSTART THRESHOLD)はスロースタート閾値である。
通常のTCPでは、a=1、b=0.5が利用される。
【0005】
また、例えば、非特許文献1には、パケットロスが検出された際にAck(Acknowledgement:確認応答)の受信間隔からボトルネックリンクに帯域幅を推定しながら、CWNDおよびSSTHRESHの値を計算することで、パケットロスの発生後にネットワークリソースを有効活用する方法が開示されている。
すなわち、パケットロスが検出された際にCWNDおよびSSTHRESHの値を以下のように計算する。
=d/(t−tk−1) (1)
【0006】
ただし、tはk番目のAckを受け取った時刻、dはk番目のAckを受け取るまでに受信側に到着が確認されたセグメントのバイト数である。
そして、(1)式のbの移動平均を(2)式のように算出し、(2)式のbをCWNDおよびSSTHRESHの値としてそのまま使用する。
=19/21・bk−1+2/21・(b−bk−1)/2 (2)
【0007】
【非特許文献1】L.A.Grieco and S.Mascolo:End−to−End bandwidth Estimation for Congestion Control in Packet Networks,Prc.Quality of Service in Multiservice IP Networks(QoS−IP 2003.(Milano),Februry 2003.
【発明の開示】
【発明が解決しようとする課題】
【0008】
しかしながら、従来のTCPの輻輳制御アルゴリズムでは、セグメントロスを契機としてCWNDを減少させ、輻輳制御が行われる。このため、パケットロスの発生前に、CWNDが十分な大きさになっていない場合には、パケットロスの発生後のCWNDおよびSSTHRESHの大きさがネットワーク帯域に対して十分ではないために、用意されたネットワーク帯域を有効利用することができないという問題があった。
【0009】
また、非特許文献1に開示された方法では、Ackの受信間隔からCWNDおよびSSTHRESHの値が決定されることから、Ackの受信間隔が正確でないネットワーク上では、パケットロスの発生後のCWNDおよびSSTHRESHの値をネットワークの最適な値に合わせることができないという問題があった。
そこで、本発明の目的は、確認応答の受信間隔が正確でないネットワーク上においても、用意されたネットワーク帯域を有効利用しつつ、ネットワークの輻輳を回避することが可能な通信端末、輻輳制御方法および輻輳制御プログラムを提供することである。
【課題を解決するための手段】
【0010】
上述した課題を解決するために、請求項1記載の通信端末によれば、受信側から送られる確認応答に基づいて、前記受信側に到着が確認されたセグメントのバイト数を送信側で算出する受信バイト数計算部と、前記受信バイト数計算部にて算出されたセグメントのバイト数に基づいて、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定する受信バイト数設定部とを備えることを特徴とする。
【0011】
また、請求項2記載の通信端末によれば、RTTの最小値を計測する最小時間計測部と、前記最小時間計測部にて計測されたRTTの最小値の期間内に受信側から送られる確認応答に基づいて、前記受信側に到着が確認されたセグメントのバイト数を送信側で算出する受信バイト数計算部と、再送タイムアウトまたは重複確認応答に基づいてパケットロスを検出するロス検出部と、前記受信バイト数計算部にて算出されたセグメントのバイト数に基づいて、前記パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定する受信バイト数設定部とを備えることを特徴とする。
【0012】
また、請求項3記載の通信端末によれば、前記受信バイト数設定部は、高速再送および高速復帰時には、前記受信バイト数計算部にて算出されたセグメントのバイト数および輻輳ウィンドウの1/2の値のいずれか大きい方をスロースタート閾値に設定するとともに、スロースタート閾値を輻輳ウィンドウに設定し、再送タイムアウト時には、前記受信バイト数計算部にて算出されたセグメントのバイト数および輻輳ウィンドウの1/2の値のいずれか大きい方をスロースタート閾値に設定するとともに、送信側が送信することができる最大セグメントサイズを輻輳ウィンドウに設定することを特徴とする。
【0013】
また、請求項4記載の輻輳制御方法によれば、信側から送られる確認応答に基づいて、前記受信側に到着が確認されたセグメントのバイト数を送信側で算出するステップと、前記送信側で算出されたセグメントのバイト数に基づいて、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定することを特徴とする。
また、請求項5記載の輻輳制御プログラムによれば、受信側から送られる確認応答に基づいて、前記受信側に到着が確認されたセグメントのバイト数を送信側で算出するステップと、前記送信側で算出されたセグメントのバイト数に基づいて、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定するステップとをコンピュータに実行させることを特徴とする。
【発明の効果】
【0014】
以上説明したように、本発明によれば、受信側に到着が確認されたセグメントのバイト数に基づいて、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定することが可能となり、パケットロスの発生後の輻輳ウィンドウの値またはスロースタート閾値をネットワークの最適な値に合わせることが可能となる。このため、確認応答の受信間隔が正確でないネットワーク上においても、用意されたネットワーク帯域を有効利用しつつ、ネットワークの輻輳を回避することが可能となる。
【発明を実施するための最良の形態】
【0015】
以下、本発明の実施形態に係る通信端末について図面を参照しながら説明する。
図1は、本発明の一実施形態に係る送信端末の概略構成を示すブロック図である。
図1において、送信端末11には、インターネットなどのネットワークを介して送られたセグメントを受信するセグメント受信部12、RTTの最小値を計測する最小時間計測部13、最小時間計測部13にて計測されたRTTの最小値の期間内に受信側から送られる確認応答に基づいて、前記受信側に到着が確認されたセグメントのバイト数を送信側で算出する受信バイト数計算部14、再送タイムアウトまたは重複確認応答に基づいてパケットロスを検出するロス検出部15、受信バイト数計算部14にて算出されたセグメントのバイト数に基づいて、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定する受信バイト数設定部16およびインターネットなどのネットワークを介してセグメントを送信するセグメント送信部17が設けられている。
【0016】
そして、セグメント受信部12は、ネットワークを介して送られたセグメントを受信すると、そのセグメントを最小時間計測部13、受信バイト数計算部14およびロス検出部15に送る。
そして、最小時間計測部13は、TCPにて行われる方法と同様にしてRTTを計測することができる。すなわち、Timestamp Optionが利用可能な場合、最小時間計測部13は、Ackの受信時に、(現在の時刻)−(Timestamp Echo)をRTTとすることができる。
【0017】
一方、Timestamp Optionが利用できない場合、最小時間計測部13は、Ackの受信時に、(現在の時刻)−(Ackされたセグメントが送信された時刻)をRTTとすることができる。
そして、最小時間計測部13は、セグメントが送信されている間にRTTの計測を継続して行い、RTTの最小値(rtt_min)が計測されるごとにRTTの最小値(rtt_min)を更新しながら、RTTの最小値(rtt_min)を受信セグメントのバイト数(rcv_bytes)の計算期間として用いることができる。
【0018】
また、ルートの切り替えや受信端末の移動などによってRTTが大きく変化する場合を考慮し、以下の場合にはRTTの最小値(rtt_min)を再設定することもできる。
(1)セグメントの送信が1RTT以上の時間行われなかった場合。
この場合には、1RTTとしては、RTTの最小値(rtt_min)の他に、TCPにおいて、RTTから計算されるRTO(Retransmission Timeout)を利用することができる。
(2)CWNDが初期ウィンドウサイズを下回った場合。
【0019】
次に、受信バイト数計算部14は、最小時間計測部13にてRTTの最小値(rtt_min)が計測されると、RTTの最小値(rtt_min)の時間内に受信したAckまたはSAck(Selective Acknowledgement)の情報から、受信側に到着が確認された受信セグメントのバイト数(rcv_bytes)を算出する。
【0020】
図2は、本発明の一実施形態に係る受信セグメントのバイト数の計測方法を示す図である。
図2において、TCP送信側21では、RTTの最小値(rtt_min)の時間内にTCP受信側22から受信したAckの情報から、受信側に到着が確認された受信セグメントのバイト数(rcv_bytes)を算出することができる。
具体的には、受信セグメントのバイト数(rcv_bytes)は、以下のようにして計測することができる。
・SAck Optionがサポートされている場合。
RTTの最小値(rtt_min)の時間内に受け取ったAckによって受信端末に受信が通知された最大のシーケンス番号(rcv_ack)から、計測を開始した際にAckを受信していない先頭セグメントのシーケンス番号(drs_snd_una)を引いた値を利用することができる。
【0021】
また、セグメントの再送中においては、RTTの最小値(rtt_min)の時間内に再送したセグメントの合計バイト数を考慮するために、受け取ったAckのSAck Optionによって通知されたセグメントの合計のバイト数(sack_end)から、計測を開始した際にSAck Optionによって通知されたセグメントの合計のバイト数(sack_start)を引いた値を最初の値に加える。
すなわち、rcv_bytes=rcv_ack−drs_snd_una+(sack_end−sack_start)となる。
【0022】
なお、セグメントロスが発生していない場合、sack_endおよびsack_startの双方とも0になるので、rcv_bytes=rcv_ack−drs_snd_unaとなる。また、RTTの最小値(rtt_min)の時間内にセグメントロスが解消された場合、sack_endは0になり、sack_startだけが有効になる。
・SAck Optionがサポートされていない場合。
この場合には、重複Ack(rcv_ackがAckを受信していない最小のセグメント(snd_una)以下のAck)の数を考慮して受信セグメントのバイト数(rcv_bytes)を算出することができる。
【0023】
すなわち、RTTの最小値(rtt_min)の時間内に最後に受け取ったAckによって受信端末に受信が通知されたシーケンス番号(rcv_ack)から、計測を開始した際にAckを受信していない先頭セグメントのシーケンス番号(drs_snd_una)を引いた値を利用することができる。
また、セグメントの再送中においては、再送したセグメントの合計バイト数を考慮するために、RTTの最小値(rtt_min)の時間内に受信した重複Ackの数×MSS(dack_end)から、計測を開始した際に受信した重複Ackの数×MSS(dack_start)を引いた値を最初の値に加える。
【0024】
すなわち、rcv_bytes=rcv_ack−drs_snd_una+(dack_end−dack_start)となる。
なお、セグメントロスが発生していない場合、dack_endおよびdack_startの双方とも0になる。
ここで、Ackパスについてもキューイングディレイが発生する場合、状況によっては受信セグメントのバイト数(rcv_bytes)を精度よく計測できないことがある。このため、Ackの送信時刻を用いることによってAckパスのキューイングディレイの影響をなくし、受信セグメントのバイト数(rcv_bytes)を精度よく計測することが可能となる。
【0025】
図3は、本発明の一実施形態に係る受信セグメントのバイト数の計測方法のその他の例を示す図である。
図3において、AckにおいてTCP送信側21側と同様のTimestamp Optionが付加されている場合、RTTの最小値(rtt_min)の時間内に送信されたAckの送信時刻を参照することにより、受信セグメントのバイト数(rcv_bytes)を計測することができる。ただし、受信側と送信側で用いられているTimestamp Optionの粒度が異なる場合、送信側でAckの送信時刻を補正する必要がある。
【0026】
図4は、送信側においてAckの送信時刻を補正する例を示す図である。
図4において、tsはセグメントの送信時刻、ts_echoはTimestamp Echoを表す。送信側では、Ackを受信した際に、一定の期間計測を行い、その間に受信したAckのtsとts_echoの増加量を計算し、補正に利用する。図4においては、ts_echoの増加量が60であるに対して、tsの増加量は6なので、rcv_bytesは計測を開始した際のAckの送信時刻にRTTの最小値(rtt_min)の10分の1を加えた時刻までのAckによって算出される。
【0027】
なお、受信セグメントのバイト数(rcv_bytes)が前回算出された受信セグメントのバイト数(rcv_bytes)より増加した場合には、Ackの受信ごとに値を更新するようにしてもよい。また、受信セグメントのバイト数(rcv_bytes)の増減にかかわらず、RTTの最小値(rtt_min)の期間ごとに常に受信セグメントのバイト数(rcv_bytes)の再計算を行うことができる。また、受信セグメントのバイト数(rcv_bytes)に下限を設けることで、受信セグメントのバイト数(rcv_bytes)に極端に小さな値が設定されるのを防止することができる。
【0028】
また、図1のロス検出部15は、再送タイムアウト(RTO)または重複確認応答(Duplicate Ack)に基づいてパケットロスを検出する
次に、図1の受信バイト数設定部16は、ロス検出部15にてパケットロスが検出された場合、受信バイト数計算部14にて算出されたセグメントのバイト数(rcv_bytes)に基づいて、パケットロス発生時の輻輳ウィンドウ(CWND)またはスロースタート閾値(SSTHRESH)を設定することができる。
【0029】
具体的には、受信バイト数設定部16は、パケットロスの発生時に、以下のようにして輻輳ウィンドウ(CWND)またはスロースタート閾値(SSTHRESH)を設定することができる。
1.FF(Fast Retransmit&Fast Recovery:高速再送および高速復帰)時
SSTHRESH=MAX(rcv_bytes,CWND/2)
CWND=SSTHRESHに設定する。
2.RTO(Retransmit Timeout:再送タイムアウト)発生時
SSTHRESH=MAX(rcv_bytes,CWND/2)
CWND=1×MSSに設定する。
【0030】
ただし、受信セグメントのバイト数(rcv_bytes)が、受信セグメントのバイト数(rcv_bytes)の計測時のCWND+α(定数)以下である場合、ネットワークにパケットが滞留していないにもかかわらず、パケットがロストしていることから、このパケットロスはネットワークの輻輳以外の原因で発生したものと判断し、スロースタート閾値(SSTHRESH)を、ロスを検出する前と同じ値に設定することができる。また、輻輳ウィンドウ(CWND)には、一般的なTCPにて行われる方法と同様な値を用いることができる。
【0031】
次に、図1のセグメント送信部17は、受信バイト数設定部16にて設定された輻輳ウィンドウ(CWND)およびスロースタート閾値(SSTHRESH)に従ってセグメントを送信する。
なお、最小時間計測部13、受信バイト数計算部14、ロス検出部15および受信バイト数設定部16は、これらの手段で行われる処理を遂行させる命令が記述されたプログラムをコンピュータに実行させることにより実現することができる。
【0032】
そして、このプログラムをCD−ROMなどの記憶媒体に記憶しておけば、送信端末11のコンピュータに記憶媒体を装着し、そのプログラムをコンピュータにインストールすることにより、最小時間計測部13、受信バイト数計算部14、ロス検出部15および受信バイト数設定部16で行われる処理を実現することができる。また、このプログラムをネットワークを介してダウンロードすることにより、このプログラムを容易に普及させることができる。
【0033】
また、上述した実施形態では、送信側の受信バイト数計算部14にて計算されたセグメントのバイト数に基づいて、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定する方法について説明したが、受信側に到着が確認されたセグメントのバイト数の計算を受信側で行い、受信側で計算されたセグメントのバイト数を送信側に伝えることで、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定するようにしてもよい。
【0034】
また、上述した実施形態では、受信側に到着が確認されたセグメントのバイト数に基づいて、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を送信側で設定する方法について説明したが、受信側に到着が確認されたセグメントのバイト数に基づいて、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を受信側で算出し、受信側で計算されたパケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を送信側に伝えることで、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を送信側で設定するようにしてもよい。
【図面の簡単な説明】
【0035】
【図1】本発明の一実施形態に係る送信端末の概略構成を示すブロック図である。
【図2】本発明の一実施形態に係る受信セグメントのバイト数の計測方法を示す図である。
【図3】本発明の一実施形態に係る受信セグメントのバイト数の計測方法のその他の例を示す図である。
【図4】送信側においてAckの送信時刻を補正する例を示す図である。
【符号の説明】
【0036】
11 送信端末
12 セグメント受信部
13 最小時間計測部
14 受信バイト数計算部
15 ロス検出部
16 受信バイト数設定部
17 セグメント送信部

【特許請求の範囲】
【請求項1】
受信側から送られる確認応答に基づいて、前記受信側に到着が確認されたセグメントのバイト数を送信側で算出する受信バイト数計算部と、
前記受信バイト数計算部にて算出されたセグメントのバイト数に基づいて、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定する受信バイト数設定部とを備えることを特徴とする通信端末。
【請求項2】
RTTの最小値を計測する最小時間計測部と、
前記最小時間計測部にて計測されたRTTの最小値の期間内に受信側から送られる確認応答に基づいて、前記受信側に到着が確認されたセグメントのバイト数を送信側で算出する受信バイト数計算部と、
再送タイムアウトまたは重複確認応答に基づいてパケットロスを検出するロス検出部と、
前記受信バイト数計算部にて算出されたセグメントのバイト数に基づいて、前記パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定する受信バイト数設定部とを備えることを特徴とする通信端末。
【請求項3】
前記受信バイト数設定部は、
高速再送および高速復帰時には、前記受信バイト数計算部にて算出されたセグメントのバイト数および輻輳ウィンドウの1/2の値のいずれか大きい方をスロースタート閾値に設定するとともに、スロースタート閾値を輻輳ウィンドウに設定し、
再送タイムアウト時には、前記受信バイト数計算部にて算出されたセグメントのバイト数および輻輳ウィンドウの1/2の値のいずれか大きい方をスロースタート閾値に設定するとともに、送信側が送信することができる最大セグメントサイズを輻輳ウィンドウに設定することを特徴とする請求項1または2記載の通信端末。
【請求項4】
受信側から送られる確認応答に基づいて、前記受信側に到着が確認されたセグメントのバイト数を送信側で算出するステップと、
前記送信側で算出されたセグメントのバイト数に基づいて、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定することを特徴とする輻輳制御方法。
【請求項5】
受信側から送られる確認応答に基づいて、前記受信側に到着が確認されたセグメントのバイト数を送信側で算出するステップと、
前記送信側で算出されたセグメントのバイト数に基づいて、パケットロス発生時の輻輳ウィンドウまたはスロースタート閾値を設定するステップとをコンピュータに実行させることを特徴とする輻輳制御プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate


【公開番号】特開2008−182410(P2008−182410A)
【公開日】平成20年8月7日(2008.8.7)
【国際特許分類】
【出願番号】特願2007−13611(P2007−13611)
【出願日】平成19年1月24日(2007.1.24)
【出願人】(392026693)株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Fターム(参考)】