JP5651805B2 - 通信装置 - Google Patents

通信装置 Download PDF

Info

Publication number
JP5651805B2
JP5651805B2 JP2014500864A JP2014500864A JP5651805B2 JP 5651805 B2 JP5651805 B2 JP 5651805B2 JP 2014500864 A JP2014500864 A JP 2014500864A JP 2014500864 A JP2014500864 A JP 2014500864A JP 5651805 B2 JP5651805 B2 JP 5651805B2
Authority
JP
Japan
Prior art keywords
band
transmission
communication
bandwidth
tcp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2014500864A
Other languages
English (en)
Other versions
JPWO2013125096A1 (ja
Inventor
隆史 磯部
隆史 磯部
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2014500864A priority Critical patent/JP5651805B2/ja
Application granted granted Critical
Publication of JP5651805B2 publication Critical patent/JP5651805B2/ja
Publication of JPWO2013125096A1 publication Critical patent/JPWO2013125096A1/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0896Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/127Avoiding congestion; Recovering from congestion by using congestion prediction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/25Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Description

本発明は、通信装置、帯域制御方法、及び通信システムに係り、特に、計算機間の通信帯域を制御する通信装置に関する。
クラウド等に用いられる拠点間の通信網として、IP−VPN(Internet Protocol− Virtual Private Network)技術等を用いたWAN(Wide Area Network)を用いることが、一般的になっている。
或る拠点に存在する端末などの計算機が、別の拠点に存在する端末と通信する場合は、自拠点LANとWANを接続する回線と、WANと別拠点LANを接続する回線とを経由して通信が行われる。これらの回線は、契約帯域によって、使用可能な帯域幅が制限されている。
端末間の通信では、TCPを用いるのが一般的である。TCP通信では、送信端末が送信したデータに対して、受信端末が受信済みデータの位置を送信端末にフィードバック通知する。送信端末は、フィードバック通知される受信済みデータの位置が増加しなくなると、廃棄検出と判定する。
さらに、送信端末は、輻輳ウィンドウサイズ(受信したことを受信端末から通知されなくても送信可能なデータサイズ)と呼ばれるパラメータを管理しており、RTT(Round Trip Time)や廃棄検出の有無に応じて、輻輳ウィンドウサイズを変化させる。
廃棄検出時やRTT増加時にネットワークが混雑していると判定して、ウィンドウサイズを減少させることで、送信帯域を間接的に減少させて、ネットワークの混雑を回避する。また、廃棄が無い時やRTT減少時にネットワークが空いていると判定して、ウィンドウサイズを増加させることで、送信帯域を間接的に増加させて、ネットワークの回線帯域を有効利用する。
RTTが大きいほど、廃棄率が大きいほど、ウィンドウサイズが増加しにくくなり、帯域が小さくなる。
以上のように、WANにおけるTCPを用いた通信では、送信帯域がRTTと廃棄率に大きく左右される。
ウィンドウサイズを増加させる方法として、最初は非線形に増加させていき、ある閾値を上回った後は、線形に増加させていく技術もある(特許文献1)。
一方、特許文献2は、WANにおけるTCPを用いた通信システムにおいて、受信側端末に接続した装置が、送信側端末に接続した装置に対して廃棄箇所を全てフィードバック通知する手段と、送信側端末に接続した装置がフィードバック通知された廃棄箇所を再送する手段と、送信側端末に接続した装置が再送帯域・廃棄帯域に基づいて送信帯域を制御する手段を備える。
WO2007/092901号 WO2011/033894号
TCPを用いた通信では、送信帯域がRTTと廃棄率に大きく左右されるため、WANのようなRTTが大きく、ホップ数が大きく廃棄発生箇所が多い環境で、契約帯域を大幅に下回る通信帯域しか得られない場合がある。
また、特許文献2では、RTTや廃棄率が大きいWANのような回線でも、大きな通信帯域を確保することができる。
ところが、通常のTCPを用いた通信と、特許文献2のような帯域制御を行う通信が、同一の通信回線を共有する場合、特許文献2による通信のように、回線帯域を占有してしまい、通常のTCPを用いた通信が通信帯域を確保できないケースがあった。
本発明は、以上の点に鑑み、通常のTCPを用いた他の通信が、通信帯域を確保できるようにしつつ、送信帯域を制御する通信装置を提供することを目的とする。
上記課題を少なくとも一を解決するために、本願発明の一態様では、ネットワークに接続される第一の通信装置であって、第一の通信装置から第二の通信装置に送信されるパケットに関する帯域をインターバル毎に管理し、管理される現在のインターバルの帯域及び過去のインターバルにおける帯域に基づいて、現在のインターバルよりも後のインターバルにおけるパケットを送出するための制御帯域を増加させる場合、所定の期間は、第一の増加率で制御帯域を増加させ、所定の期間経過後は、第一の増加率よりも高い、第二の増加率で前記制御帯域を増加させ、その制御帯域に従って、パケットをネットワークに送出する送信部と、を有する。
本発明によると、同一の通信回線を複数の通信で共有する場合でも、一の通信における帯域制御による回線での回線帯域を占有することを防ぎ、複数の通信が通信帯域を確保することができ、公平な帯域の利用となる。
本実施の形態における通信装置を含むネットワークシステムの構成図。 本実施の形態における通信装置200のブロック図。 バッファのポインタの説明図。 パケットのフォーマット図。 状態テーブル212のフォーマット図。 プロキシ部206のブロック図。 TCP部209のブロック図。 TCP部203のブロック図。 帯域テーブル213のフォーマット図。 通常TCPと独自TCPを比較する説明図。 廃棄率の変化率を用いた輻輳制御の説明図。 シェーパ毎の帯域テーブル213が保持する値の意味を説明する概念図。 再送率の変化率と、コネクション数とアクセス帯域を用いて制御帯域を更新するフローチャート図A。 再送率の変化率と、コネクション数とアクセス帯域を用いて制御帯域を更新するフローチャート図B。 制御帯域を更新する上位のフローチャート図。 RTT毎に制御帯域を定期更新する部分のフローチャート図。 制御帯域を不定期更新する部分のフローチャート図。 制御帯域を増加させる部分のフローチャート図A。 制御帯域を増加させる部分のフローチャート図B。 制御帯域を増加させる部分のフローチャート図C。 制御帯域の変化の4種類のフェーズを説明する概念図。 対向装置の独自TCPへの対応の有無に応じてモードを切り替える概念図。 対向装置の独自TCPへの対応の有無に応じてモードを切り替えるフローチャート図。 対向装置の独自TCPへの対応の有無に応じてモードを切り替えるフローチャート図。 対向装置の有無に応じて廃棄率/再送率と再送帯域の計算方法を変更するフローチャート図。 独自TCPと通常TCPの再送方法の差異 モード/最低帯域指定テーブルのフォーマット図。
本発明を実施するための代表的な形態は、下記の通りである。実施例1には基本的な一形態を、記載する。
まず、図1を用いて、本発明が解決しようとする課題について説明する。
図1は、通信装置を含むネットワークシステムの構成図を示す。
通信装置(中継装置ともいう。以下、単に装置と記す)101、102及びルータ186は、複数の拠点内のLAN110、120、130とWAN140を接続する通信回線上に設置される。また、複数の計算機111、112、113、は、LAN110を介して通信装置101に接続される。複数の計算機121、122、123は、LAN120を介して、通信装置102に接続される。
また、通信装置101、102とWAN140は、アクセス回線191、192で接続されている。
通信装置101は、例えば、特許文献2で開示されるような独自TCPによる送信帯域制御を実行するモードを選択し、選択されたモードに従って帯域制御を行う送信帯域制御部150を有する。通信装置102は、通信装置101とのWAN140を介して通信を高速化するために必要なACK送信部155を備える。図1に示す通信装置101、及び通信装置102では、計算機間でのデータ通信を行うための2種類のコネクションを確立される例を示す。第一のコネクションは、送信帯域制御部150による帯域制御を行う、計算機111及び121間のコネクション160(独自TCP)である。第2のコネクションは、送信帯域制御部を介さない、計算機113及び123間の通常TCPのコネクション163である。なお、送信帯域制御部150及びACK送信部155双方が通信装置101や102に備えられていてもよい。
ルータ185は、LAN(図示せず)を介して計算機134に接続される。ルータ185は、WAN140を介してルータ186や、通信装置102に接続される。ルータ186は、LAN130を介して複数の計算機131、132、133と接続される。図1に示す計算機131からのコネクション165は、通常TCPのコネクションで、WANを介してルータ185は、計算機134と計算機131とのTCPプロトコルに従ったデータ通信を行う。
図1のように独自TCPによるコネクション160、通常TCPによるコネクション163及び165の通信では、回線192を共有する場合が生じる。独自TCPによるコネクションで、通信装置101が、送信帯域を急激に増加させる制御をすると、回線帯域を占有してしまい、通常のTCPコネクションを用いた通信が十分な通信帯域を確保できないケースがある。また、通信装置101においても、独自TCPのコネクション160と通常TCPのコネクション163は、回線192だけではなく、回線191も共有する。コネクション160と163間でも同様に、通常のTCPであるコネクション163を用いた通信が十分な通信帯域を確保できない。そのため、以下、通信装置101や102で、他のコネクションの帯域が確保できるよう、独自TCPによるコネクションにおける送信帯域の制御に関する例を詳細に説明する。
なお、計算機、通信装置及びネットワークの数は図示以外にも適宜の数を備えても良い。計算機は、サーバーや情報処理装置、端末、携帯型情報処理端末、スマートフォン等を含む。計算機間の通信は、クライアントサーバ間のデータ転送や、情報処理装置間のファイル転送等を含む。また、計算機間の通信は、Transmission Control Protocol(トランスミッション コントロール プロトコル、TCP)は、OSI参照モデルのトランスポート層にあたる伝送制御プロトコルに基づく通信を例として以下説明する。また、WAN140は、LANに比べると長い拠点間を結ぶネットワークや、拠点間での通信の遅延が大きいネットワークを含む。
図2には、本実施の形態の通信装置200のブロック図を示す。図1の通信装置101、102に相当する。
通信装置200は、例えば、外部のWAN/LANネットワークとのパケットの送受信を行うWAN側及びLAN側のネットワークインターフェース(201/211)と、高速化非対象のTCPパケットやTCP以外のUDPパケットやARPパケット等を素通しさせるためのフィルタ(202/210)と、TCP通信のための制御を行うWAN側及びLAN側のTCP処理部203/209と、WAN側のTCP209の管理するN個の送信バッファ207およびN個の受信バッファ208と、LAN側のTCP203の管理するN個の送信バッファ205およびN個の受信バッファ204と、送受信バッファ間でデータの乗せ換えを行うプロキシ206と、を備える。通信装置200は、メモリ(図示せず)を備え、メモリには、N個のエントリを備えた状態テーブル(状態記憶領域)212と、N個のエントリを備えた帯域テーブル213と、各TCP通信の通信モードや最低帯域を指定するモード/最低帯域指定テーブル740とを保持する。なお、上述のN個は、それぞれ異なる数でもよい。
フィルタ202/210は、外部から入力されるパケットが、独自TCP対象パケット化否かを、判別し、高速化非対象のTCPパケットやTCP以外のUDPパケット(IPプロトコル番号)やARPパケット等を素通しさせる。TCPパケットの場合、TCPパケットが、IPアドレスとポート番号の組み合わせあるいはいずれか一方を用いて非対象パケットかどうかが判別される。図1のコネクション163でのパケットがその例である。一方、入力パケットが、TCP以外のUDPパケットに該当するかは、IPプロトコル番号で判別される。入力パケットが、ARPパケットであるかは、イーサータイプがIPv4,v6いずれにも該当せず、イーサタイプがARPであるかどうかで判別される。フィルタで該当したパケットは、独自TCPの処理はされず、LAN側からの入力パケットは、WANに転送され、WAN側からの入力パケットは、LANに転送される。
TCP処理部203、209、プロキシ206については、後に詳述しここでは概略を述べる。
LAN側のTCP処理部203は、送信履歴更新部725と、パケット再送部724と、受信履歴更新部726と、振分部728と、集約部732とを備える。受信履歴更新部726は、受信したパケットデータを、LAN側受信バッファ204に蓄積する。更に、受信履歴更新部726は、蓄積したデータに応じて、状態テーブル212のバッファ管理ポインタ(508〜510、515〜517、521〜527)の情報を更新する。更に、受信履歴更新部726は、受信したデータの位置を記載したACKパケットを集約部732経由で返信する。送信履歴更新部725は、LAN側送信バッファ205から読み出した送信データをパケットにして送信すると共に、読み出したデータに応じて、状態テーブル212のバッファ管理ポインタ(508〜510、515〜517、521〜527)の情報を更新する。詳細は、図7Bにて説明する。
WAN側のTCP処理部209は、送信帯域制御部715と、送信履歴更新部705と、パケット再送部704と、受信履歴更新部706と、振分部708と、集約部712とを備える。受信履歴更新部706は、受信したパケットデータを、WAN側受信バッファ208に蓄積する。更に、受信履歴更新部706は、蓄積したデータに応じて、状態テーブル212のバッファ管理ポインタ(508〜510、515〜517、521〜527)の情報を更新する。更に、受信履歴更新部706は、受信したデータの位置を記載したACKパケットを集約部712経由で、WAN140を介して、他の通信装置200に送信する。詳細は、図7Aにて説明する。
送信帯域制御部715は、送信帯域と再送帯域とACK受信数(WAN140を介して受信されるACKの数)の情報を帯域テーブル213に蓄積する。送信履歴更新部705は、WAN側送信バッファ207から読み出した送信データをパケットにして送信すると共に、読み出した送信データサイズに応じて、状態テーブル212のバッファ管理ポインタ(508〜510、515〜517、521〜527)の情報を更新する。
プロキシ206は、データ読出し部(601、606)と、データ加工部(602、605)と、データ書込部(603、604)を備える。データ読出部(601、606)は、受信バッファ(204、208)から読み出したデータサイズに応じて、状態テーブル212のバッファ管理ポインタ(508〜510、515〜517、521〜527)の情報を更新する。データ書込部(603、604)は、送信バッファ(207、205)に書き込んだデータサイズに応じて、状態テーブル212のバッファ管理ポインタ(508〜510、515〜517、521〜527)の情報を更新する。詳細は図6にて説明する。
図3には、送受信バッファ管理用のポインタの説明図を表す。本図では、データを左から右に書き込んでいき、左から右に読み出していくものとする。
受信バッファは、受信したデータの末尾を示すポインタright_recv303と、整列済みデータと未整列データの境界を示すポインタleft_recv302と、プロキシ206がすでに読出し済のデータとまだ読出していないデータの境界を示すleft_rbuf301と、を管理する。
受信したデータの末尾を示すポインタright_recv303は、ロスの発生が無く、前から順番にデータを受信すると、受信したデータサイズ分増えて、右へ移動する。受信できずに歯抜けになっているデータ箇所(ロスセグメント)が存在する状態で、再送パケットを受信して、ロスセグメントが消滅すると、整列済みデータと未整列データの境界を示すポインタleft_recv302は、最も小さなロスセグメントの左端まで移動する。プロキシ206は、読出済データと未読出データの境界を示すleft_rbuf301から右へ向かって順番にデータを読み出し、読み出したデータサイズ分、left_rbuf301を右へ移動させる。読み出せるデータサイズの最大値は、left_recv302とleft_rbuf301の差である。
送信バッファは、プロキシ206が書込済みで送信可能な状態となっているデータの末尾を表すポインタright_sbuf306と、すでに送信済みのデータの末尾を示すポインタright_send305と、受信側から確認応答を受信済みのデータの末尾を示すポインタleft_send304と、を管理する。
プロキシ206が書込済みで送信可能な状態となっているデータの末尾を表すポインタright_sbuf306は、プロキシ206がデータを書き込む毎に、書き込んだデータサイズ分増加し、右へ移動する。送信済みデータの末尾を示すポインタright_send305を始点として右に向かって新たなデータが送信され、right_send305は、送信されたデータサイズ分増加し、右へ移動する。受信側から、left_send304よりも大きな受信シーケンス番号を持つ確認応答パケットを受信すると、left_send304は、確認応答(ACK)パケットに記載された受信シーケンス番号へと増加し、右へ移動する。
図4には、通信装置が送受信するパケットのフォーマット図を表す。パケットは、MACヘッダ400、IPヘッダ410、TCPヘッダ420、TCPオプションヘッダ430、ペイロード450を含む。MACヘッダ400は、宛先MACアドレスを表すDMAC401と、送信元MACアドレスを表すSMAC402と、MACフレームタイプを表すType403を含む。IPヘッダ410は、MACヘッダを除くパケット長を表すIP length411と、プロトコル番号を表すprotocol412と、送信元IPアドレスを表すSIP413と、宛先IPアドレスを現すDIP414とを含む。TCPヘッダ420は、送信元ポート番号を表すsrc.port421と、宛先ポート番号を表すdst.port422と、送信シーケンス番号を表すSEQ423と、受信シーケンス番号を表すACK424と、TCPフラグ番号を表すflag425と、TCPのヘッダ長を表すtcp hlen426とを含む。TCPオプションヘッダ430は、オプション種別を表すoption kind431と、オプション長を表すoption length432と、どこからどこまで部分的に受信できたかデータ箇所の位置を送信計算機に通知するために用いられるleft_edge_1〜4(433、435、437、439)、right_edge_1〜4(434、436、438、440)を含む。left_edge_1〜4(433、435、437、439)、right_edge_1〜4(434、436、438、440)は、部分的に受信できなかったデータ箇所の位置を通知するために用いられるケースもある。更に、TCPオプションヘッダ430は、TCP通信を開始するときに、装置間の情報交換などに使用するケースもある。
例えば、MSSオプションは、TCP通信を開始するときに、自装置の受信可能なMSSのサイズを対向装置に通知するために用いられる。SACKオプションは、図1の通信装置101及び102の間で、TCP通信を開始するときに、自装置がSACKオプションに対応可能であることを対向装置に通知するために用いられるだけでなく、通信中に廃棄が検出されたときに部分的に受信出来た箇所を対向装置に通知するためにも用いられる。タイムスタンプオプションは、通信中の自装置の受信時刻を対向装置に通知するために用いられる。このように、TCPオプションは、通信開始時および通信中に、自装置の対応可能な機能や情報を対向装置に伝えるために用いられる。
図5には、状態テーブル212のフォーマット図を示す。
通信装置200の状態テーブル212は、例えばTCPコネクション毎の状態を記録するためのn個のエントリ520を有する。
各エントリ520は、例えば、エントリが使用中であるか否かを記載するVLD501と、LANまたはWAN側のコネクションが確立中であるか否かを記載するconnect_state502と、LAN側の計算機のIPアドレスを表すLIP503と、WAN側の計算機のIPアドレスを表すWIP504と、LAN側の計算機のTCPポート番号を表すLport505と、WAN側の計算機のTCPポート番号を表すWport506と、LAN側のTCP通信の状態を表すlan_state507と、LAN側の受信バッファ管理用のポインタを表すlan_left_rbuf508、lan_left_recv509、lan_right_recv510と、LAN側のウィンドウスケールオプションの値を表すlan_ws511と、LAN側の平均RTTを表すlan_rtt512と、LAN側の輻輳ウィンドウサイズを表すcwnd513と、LAN側の受信バッファから読み出され加工中のデータサイズを表すlan_wan529と、LAN側の送信バッファ管理用のポインタを表すlan_left_send521、lan_right_send522、lan_right_sbuf523と、WAN側のTCP通信の状態を表すwan_state514と、WAN側の受信バッファ管理用のポインタを表すwan_left_rbuf515、wan_left_recv516、wan_right_recv517と、WAN側のウィンドウスケールオプションの値を表すwan_ws518と、WAN側の平均/初期RTTを表すwan_rtt519と、WAN側の最大セグメントサイズMSSを表すwan_mss536と、WAN側の受信バッファから読み出され加工中のデータサイズを表すwan_lan530と、WAN側の送信バッファ管理用のポインタを表すwan_left_send524、wan_right_send525、wan_right_sbuf526と、RTT前のACK受信済み箇所を表すold_wan_left_send527と、通常のTCPに対してフレンドリなモードで通信するか否かを決定するためのfriendly_mode532と、対向装置が独自TCPによる通信に対応していないときに独自TCPによる通信を行うか否かを決定するためのone−way_mode533と、最小帯域を表すmin_token534と、輻輳が検出されない状態になった直近の制御帯域を表すt_token535と、直近の定期更新時の制御帯域を表すc_token537と、帯域が増加し始めた時刻を表すinc_time538とを有する。
図6には、プロキシ206のブロック図を示す。
プロキシ206は、LAN側の受信バッファrbuf204からデータを読出すデータ読出し部601と、読み出したデータに対して圧縮・解凍・暗号化・復号・削除・複製・追記などの加工を行うデータ加工部602と、加工済みデータをWAN側の送信バッファsbuf207へ書き込むデータ書き込み部603と、WAN側の受信バッファrbuf208からデータを読み出すデータ読出し部606と、読み出したデータに対して圧縮・解凍・暗号化・復号・削除・複製・追記などの加工を行うデータ加工部605と、加工済みデータをLAN側の送信バッファsbuf205へ書き込むデータ書き込み部604とを有する。データ加工部602とデータ加工部605との間で、データのやり取りをしてもよい。データの加工は上述の例以外でもよい。
データ読出し部601は、lan_left_rbuf508からlan_left_recv509までの間に蓄積されている整列済みデータから読み出した先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する。先頭データとしては、TLS(Transport Layer Security)/SSL(Secure Socket Layer)ヘッダ、SMB(Server Message Block)ヘッダ、等などを使用してもよい。TLS/SSLヘッダに記載された値からは、復号後のチェックサムやヘッダを除いた平文データサイズを推定することができる。SMBヘッダからは、プリフェッチ等を行った後のコマンドデータサイズを推定することができる。推定した加工後のデータサイズが、wan_right_sbuf526とwan_left_send524の差、すなわち未送信データとACK確認待ちデータの合計値が、WAN側の送信バッファサイズwan_sbuf_sizeを超えない場合は、データを読み出して、データ加工部602へ転送する。更に、推定した読み出すべきデータサイズと、データ加工後のデータサイズのうち、大きい方を状態テーブル212のlan_wan528へ記載する。
データ読出し部606は、wan_left_rbuf515からwan_left_recv516までの間に蓄積されている整列済みデータから読み出した先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する。先頭データとしては、TLS(Transport Layer Security)/SSL(Secure Socket Layer)ヘッダ、SMB(Server Message Block)ヘッダ、等などを使用してもよい。推定した加工後のデータサイズが、lan_right_sbuf523とlan_left_send521の差、すなわち未送信データとACK確認待ちデータの合計値が、LAN側の送信バッファサイズlan_sbuf_sizeを超えない場合は、データを読み出して、データ加工部605へ転送する。更に、推定した読み出すべきデータサイズと、データ加工後のデータサイズのうち、大きい方を状態テーブル212のwan_lan529へ記載する。
図7Aには、図2の通信装置200のWAN側のTCP処理部209のブロック図を示す。
TCP通信を実現するTCP処理部209は、受信処理を行うRX部(受信部)702と、送信処理を行うTX部(送信部)701を有する。
RX部702は、受信パケットを、SYN,FINなどのフラグが付いたTCP制御パケットとデータ付パケットとACKパケットに分離するパケット振分部708と、TCP制御パケットに記載されているフラグ番号に基づいて状態テーブル212内のTCP状態(lan_state507、wan_state514)を変更すると共に、TCP制御パケットに記載されているオプション番号の有無や、モード/最低帯域指定テーブル740の指定するモードと最低帯域に基づいて、状態テーブル212内の通信モード(friendly_mode532、one−way_mode533)や最低帯域min_token534を変更するTCP制御部707と、受信したデータパケットの送信シーケンス番号SEQ423と受信シーケンス番号ACK424とに基づいて、状態テーブル212内のバッファ管理ポインタを変更してACKパケットを返信する受信履歴更新部706を有する。
TCP制御部707が、TCP制御パケットに記載されているオプション番号の有無に基づいて、通信開始時に、通信モード(friendly_mode532、one−way_mode533)を変更する方法は、図18を用いて後述する。
TCP制御部707が、モード/最低帯域指定テーブル740の指定するモードと最低帯域に基づいて、通信開始時に、通信モード(friendly_mode532)や最低帯域min_token534を変更する方法は、図20を用いて後述する。
TX部701は、状態テーブル212内のTCP状態lan_state507、wan_state514を用いてTCP制御パケットを送信するTCP制御部703と、受信したACKパケットに基づいて状態テーブル212内のバッファ管理ポインタを変更し、受信したACKパケット記載の部分的確認応答left_edge_1〜4(433、435、436、439)、right_edge_1〜4(434、436、438、440)を用いて送信バッファsbuf207からデータを読み出してパケットを再送すると共に、再送ビット長とACK受信数を送信帯域制御部715に通知するパケット再送部704と、送信バッファsbuf207から読み出したデータを載せたパケットを送信して、状態テーブル212内のバッファ管理ポインタを変更すると共に、送信ビット長を送信帯域制御部715に通知する送信履歴更新部705と、再送パケットとデータパケットを受け取り、バッファ1〜n(709−1〜n)に振り分ける振分部708と、現在時刻を生成して送信帯域制御部715に通知するタイマ713と、インターバル時間(予め定めた固定値、または計測した平均RTTなど)を保存して送信帯域制御部715に通知するインターバル格納部714と、帯域テーブル213を制御して、各TCPコネクションのトークンサイズをトークン更新部717に通知する送信帯域制御部715と、TCPコネクション毎にトークンバケツを管理して、送信可能なコネクションをマルチプレクサ712に通知するトークン更新部717と、ACKパケット、TCP制御パケット、再送パケット、データパケットをFIFOで集約して、出力するマルチプレクサ712およびバッファ709〜711とを有する。モード/最低帯域指定テーブル740の記載内容は、外部のユーザ端末741から変更可能である。
本実施例において、TX部701の各ブロックのうち、各TCP通信の制御帯域(最大送信帯域)に従いデータを送信するブロック(例えば、トークン更新部717、マルチプレクサ712、バッファ709等)をまとめて送信制御部と称することもある。
図7Bには、図2におけるLAN側のTCP処理部203のブロック図を示す。
TCP通信を実現するTCP処理部203は、受信処理を行うRX部(受信部)722と、送信処理を行うTX部(送信部)721を有する。
RX部722は、受信パケットをTCP制御パケットとデータ付パケットとACKパケットに分離するパケット振分部728と、受信したTCP制御パケットに基づいて状態テーブル212内のTCP状態lan_state507、wan_state514を変更するTCP制御部727と、受信したデータパケットの送信シーケンス番号SEQ423と受信シーケンス番号ACK424とに基づいて、状態テーブル212内のバッファ管理ポインタを変更してACKパケットを返信する受信履歴更新部726とを有する。
TX部721は、状態テーブル212内のTCP状態lan_state507、wan_state514を用いてTCP制御パケットを送信するTCP制御部723と、受信したACKパケットに基づいて状態テーブル212内のバッファ管理ポインタを変更し、受信したACKパケット記載の部分的確認応答left_edge_1〜4(433、435、436、439)、right_edge_1〜4(434、436、438、440)を用いて送信バッファsbuf205からデータを読み出してパケットを再送するパケット再送部724と、送信バッファsbuf205から読み出したデータを載せたパケットを送信して、状態テーブル212内のバッファ管理ポインタを変更する送信履歴更新部725と、ACKパケット、TCP制御パケット、再送パケット、データパケットをFIFOで集約して、出力するマルチプレクサ732およびバッファ729〜731とを有する。
WAN側TCP処理部209の送信帯域制御部715、帯域テーブル213内に基準時刻という内部変数を管理している。基準時刻と、タイマ713の現在時刻との差が、インターバル格納部714のインターバル時間よりも大きくなると、基準時刻にインターバル時間を加算して新たな基準時刻とする。加算前の基準時刻は、旧基準時刻となる。すなわち、現在使用している基準時刻の一つ前に使用していた基準時刻は旧基準時刻となる。インターバル時間には、計測した平均RTTや初期RTT(wan_rtt519)を用いることもあれば、固定値を用いることもある。
図2を用いて、LAN側からデータ付きパケットを受信した際の、通信装置200におけるパケットの流れを説明する。
LAN側から到着したデータ付きパケットは、LAN側TCP処理部203に入り、受信履歴更新部726に到着する。受信履歴更新部726は、データ付きパケットに対するACKパケットを集約部732経由でLAN側に返信し、パケットに記載されたデータをLAN側受信バッファrbuf204へと蓄積する。更に、受信履歴更新部726は、蓄積データサイズに基づいて状態テーブル212のポインタを更新する。データ読出し部601は、LAN側受信バッファrbuf204に蓄積された整列済みデータを読出し、データ加工部602へ転送する。更に、読み出したデータサイズに基づいて状態テーブル212のポインタを更新する。
データ加工部602は、データを加工して、データ書き込み部603へ転送する。更に、加工中のデータサイズに基づいて状態テーブル212の加工中データサイズを更新する。データ書き込み部603は、加工済みデータをWAN側送信バッファsbuf207へと書き込む。更に、書き込んだデータサイズに基づいて状態テーブル212のポインタを更新する。WAN側送信バッファsbuf207に書き込まれたデータは、送信履歴更新部705から読み出される。送信帯域制御部715は、読み出されたデータを、WAN側へデータ付きパケットとして送信する制御を行う。
受信履歴更新部726についてさらに説明すると、LAN側の受信バッファの最大値から、lan_right_recv510とlan_left_rbuf508との差分を、引くことで、受信バッファの残存量を計算する。ペイロード450のサイズが、受信バッファの残存量以下のときは、ペイロード450に記載されたデータ全てを受信バッファに格納する。ペイロード450のサイズが、受信バッファの残存量よりも大きい場合は、ペイロード450の先頭から受信バッファの残存量に相当するサイズのデータだけを受信バッファに格納する。格納データサイズが0よりも大きいときは、データ付きパケットのTCPヘッダ420に記載されたSEQ423の値と、格納データサイズに基づいて、受信バッファ管理用ポインタの更新を行う。例えば、パケットヘッダ記載のSEQ423に格納データサイズを加算した値が、lan_right_recv510よりも大きい場合は、lan_right_recv510を、SEQ423に格納データサイズを加算した値に変更する。更に、受信データの最後尾がlan_right_recv510となるように、受信データをLAN側の受信バッファに記載する。その後、受信バッファ管理ポインタの1つlan_left_recv509をTCPヘッダ420のACK424に記載したACKパケットを、LAN側へ返信する。
また、送信履歴更新部705についてさらに説明すると、wan_right_send525から右方向に、最大wan_right_sbuf526までのデータを、WAN側送信バッファsbuf207から読み出す。wan_right_send525は、読み出したデータサイズ分、増加して、右に移動する。更に、読み出したデータをペイロード450に記載し、wan_right_send525をSEQ423に記載したTCPヘッダ420を追加したデータ付きパケットを、WAN側へ送信する。
(WAN側に出て行くデータの送信帯域の制御に使用する変数)
送信帯域制御部715は、帯域テーブル213が管理する変数を用いて、各TCP通信のWAN側に出て行くデータの送信帯域を制御する。
図8には、送信帯域制御部715が管理する帯域テーブル213のフォーマットを表す。
帯域テーブル213は、コネクション毎に、基準時刻と、基準時刻後の送信ビット積算値・再送ビット積算値・ACK受信数・制御帯域と、基準時刻前の送信帯域・再送帯域・受信帯域・制御帯域と、旧基準時刻前の送信帯域・制御帯域と、を記録する。
基準時刻後の制御帯域は、現在時刻における制御帯域を表す(本実施例では、tokenまたはトークンと表す)。基準時刻後の送信帯域は、現在時刻における送信帯域を表し(本実施例では、sndと表す)、基準時刻後の送信ビット積算値を、現在時刻と基準時刻の差分で除算することで求められる。基準時刻後の再送帯域は、現在時刻における再送帯域を表し(本実施例では、rtsと表す)、基準時刻後の再送ビット積算値を、現在時刻と基準時刻の差分で除算することで求められる。基準時刻後の受信帯域は、現在時刻における受信帯域を表し(本実施例では、rcvと表す)、基準時刻後のACK受信数にWAN側のMSSと8を積算した値を、現在時刻と基準時刻の差分で除算することで求められる。基準時刻前の制御帯域・送信帯域・受信帯域・再送帯域は、旧基準時刻から基準時刻までの制御帯域・送信帯域・受信帯域・再送帯域の平均値を表す(本実施例では、old_token、old_snd、old_rcv、old_rtsと表す)。旧基準時刻前の制御帯域・送信帯域は、旧基準時刻の直前までの制御帯域・送信帯域を表す(本実施例では、old_old_token、old_old_snd、と表す)。基準時刻前の再送率/廃棄率old_rts_ratioは、old_rts/old_old_snd、または、1−old_rcv/old_old_sndで求められる。また、基準時刻後の現在の再送率/廃棄率rts_ratioは、rts/old_snd、または、1−rcv/old_sndで求められる。インターバル時間として、固定値を用いることもあれば、状態テーブル212記載のwan_rtt519を用いる場合もある。
図11には、旧基準時刻・基準時刻・現在時刻と、その前後の制御帯域・送信帯域・受信帯域・再送帯域・再送率/廃棄率の関係を表す。
基準時刻と旧基準時刻との差は、インターバル時間である。旧基準時刻前におけるインターバル時間の制御帯域・送信帯域の平均値は、old_old_token、old_old_sndと表す(1103)。旧基準時刻から基準時刻までの間の制御帯域・送信帯域・受信帯域・再送帯域・再送率/廃棄率の平均値は、old_token、old_snd、old_rcv、old_rts、old_rts_ratioと表す(1102)。基準時刻から現在時刻までの制御帯域・送信帯域・受信帯域・再送帯域・再送率/廃棄率の平均値は、token、snd、rcv、rts、rts_ratioと表す(1101)。
送信帯域制御部715は、帯域テーブル213に記載された上述の値を用いて、廃棄率/再送率(rts_ratio530とold_rts_ratio531)を計算する。現在時刻の廃棄率/再送率rts_ratio530は、rts/old_tokenまたはrts/old_sndまたは1−rcv/old_tokenまたは1−rcv/old_sndで計算される。過去の廃棄率/再送率old_rts_ratio531は、old_rts/old_old_tokenまたはold_rts/old_old_sndまたはまたは1−old_rcv/old_old_tokenまたは1−old_rcv/old_old_sndで計算される。更に、廃棄率/再送率の変化(old_rts_ratio531とrts_ratio530の比率)に基づいて、制御帯域(tokenまたはトークン)を決定し、トークン更新部717へ伝える。更に、状態テーブル212を更新する。制御帯域(tokenまたはトークン)の更新方法の詳細は、図12〜図16に後述する。
トークン更新部717は、送信帯域制御部715から伝えられた制御帯域(tokenまたはトークン)の値に基づいて、TCPコネクション毎にトークンバケツを管理して、送信可能なコネクションをマルチプレクサ712に通知する。
(制御帯域tokenの更新処理)
図9と図10と図17の説明図と、図12〜図16のフローチャートを用いて、送信帯域制御部715が制御帯域(tokenまたはトークン)を更新する方法の詳細を説明する。
図9には、通常のTCP通信と独自TCPによる通信との差異、および、独自TCPの送信帯域の制御方法の説明図を示す。
通常のTCP通信では、廃棄が1回でも生じると、輻輳を検出したと判定して、送信帯域を一定の割合で減少させる(906)。ネットワークでは、ボトルネックの帯域が100%使われていなくても、待ち行列理論に基づく確率的な廃棄が一定の割合で発生する。そのため、送信帯域がボトルネック帯域に到達してトップスピードになる前に減少してしまい、ボトルネックの帯域を100%使い切ることができなかった。
独自TCPでは、直近の再送帯域をRTT前の送信帯域で除算することで廃棄率を求め、廃棄率の変化率が予め定めた閾値kを超過したときに、輻輳が発生したと判断して、RTT前の送信帯域と直近の再送帯域に基づいて、送信帯域を減少させる(902)。送信帯域がボトルネック帯域へ到達したことを、廃棄率の変化率の増加により判断する。これにより、確率的な廃棄の影響を受けずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させ続けることが可能となる。
独自TCPでは、送信帯域を減少させた後(902)、ACK受信済み箇所の位置が変わるまで、ACK受信数に応じて送信帯域を一定にする(903)。ACK受信済み箇所の位置が更新され始めると、一定時間Tの間は緩やかに、例えば線形的に、送信帯域を増加させる(904)。緩やかに、例えば線形的に、送信帯域を増加させ続けて一定時間Tが経過すると、急激な増加方法(例えば、指数的などの非線形的な増加方法)に変更する(905)。期間Tは、RTTとトークン(token:制御帯域)によって定めても良いし、これらの積に比例させてもよい。これにより、送信帯域を線形的に増加させる期間が、RTTと送信帯域の過去の履歴によって決定する通信装置が実現される。つまり、送信帯域制御部715は、第一の制御モードと第二の制御モードを備え、第一の制御モードで帯域制御が所定の期間経過後、第2の制御モードでの帯域制御に切り替える制御を行う。第2の制御モードでの送信帯域の増加率は、第一の制御モードでの増加率よりも高くてもよい。なお、一定の期間Tは、通信装置200に接続される管理端末等により変更可能な所定の期間である。
上述の送信帯域の制御方法により、ネットワークの輻輳が検出されず、尚且つ、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、前記TCP通信の送信帯域を線形的に増加させ、その後、送信帯域を非線形的に増加させる通信装置が実現される。更に、廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出する通信装置と、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、廃棄率または再送率とそれらの変化率を推定する通信装置と、輻輳を検出したときに、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、送信帯域を減少させる通信装置が実現される。
ネットワークの輻輳が検出されず、尚且つ、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、送信帯域を通常のTCP通信よりも緩やかに(例えば線形的に)増加させることで、通常のTCP通信と競合したときでも、通常のTCP通信の帯域を圧迫することを防ぎ、通常のTCP通信が帯域を確保しやすくなる。また、一定時間が経過した後に、急激に(例えば指数的に)送信帯域を増加させることで、通常のTCP通信との競合が無い時に、送信帯域がボトルネック帯域へ到達してトップスピードになる時間を短くすることが出来る。更に、廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出することで、確率論的な廃棄に影響されずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させ続けることが可能となる。
図10には、独自TCPによる通信を行っている装置の送信側の送信帯域1001、廃棄率1002、廃棄率の変化率1003の時間遷移を示したグラフを示す。
独自TCPによる通信の送信帯域の増減には、大きく4つのフェーズが存在する。フェーズ1は送信帯域を増加させるステップ、フェーズ2は送信帯域を減少させるステップ、フェーズ3は送信帯域を過去の送信帯域へ戻すステップ、フェーズ4は送信帯域を一定にするステップ、となる。
まず、フェーズ1で送信帯域が増加していき(1004)、ある時にボトルネック帯域を超過する(1013)。送信帯域がボトルネック帯域を超過すると、パケット廃棄が発生するが、廃棄箇所が受信側から送信側に通知されるまでにRTT以上かかる。そのため、送信帯域がボトルネック帯域を超過したことが、廃棄率の増加となって現れるのは、RTT以上後となる(1014)。廃棄率は、直近の再送帯域をRTT前の送信帯域で除算することで求められる。送信帯域がボトルネック帯域よりも小さい間は、確率的な廃棄しかおきないため、廃棄率は一定となる(1010)。送信帯域がボトルネック帯域を超過してからRTT以上経過すると、確率的な廃棄に加えて、使い過ぎによる廃棄(1011)が加わるようになるため、廃棄率が増加しはじめる(1012)。廃棄率が増加しはじめると、廃棄率の変化率は1から急激に増加し、閾値kを超過する(1009)。
独自TCPによる通信では、上記のように、廃棄率の変化率が急激に増加し、閾値kを超過したときに、ネットワークに輻輳が発生したと判断する。
ネットワークに輻輳が発生したと判断すると、RTT前の送信帯域から、現在の再送帯域を引いた値を、新たな送信帯域とする(1018)。RTT前の送信帯域を用いて新たな送信帯域を計算する理由は、送信帯域がボトルネック帯域を超過した時間がRTT以上前だからである。廃棄率の増加はしばらく継続するため(1012)、その間は送信帯域が減少し続ける。この送信帯域を減少させるステップがフェーズ2となる(1005)。
送信帯域が減少していきボトルネック帯域よりも小さくなると、廃棄率が減少しはじめる(1019)。廃棄率の変化率が1よりも小さくなり、閾値kを下回ると(1020)、ネットワークに輻輳が発生しなくなったと判断される。
ネットワークに輻輳が発生しなくなったと判断された後も、廃棄パケットの再送処理は継続している。受信確認済みのデータ箇所がRTT前と比較して増加していない場合は、廃棄パケットの再送処理は継続していると判断して、ACK受信数に応じて、送信帯域を一定とする。この送信帯域を一定とするステップがフェーズ4となる(1006)。
受信確認済みのデータ箇所がRTT前と比較して増加している場合は、廃棄パケットの再送処理が一通り完了したと判断して、再び送信帯域を増加させる(フェーズ1)。
最初は、送信帯域制御部715は、送信帯域をゆっくりと、例えば、第一の制御モードで、線形的に増加させていく(1007)。一定の期間T、輻輳が検出されないと、その後、送信帯域制御部715は、第二の制御モードで送信帯域を急激に(例えば、非線形的に)増加させていく(1008)。非線形的に増加させるときは、RTT毎にα倍するなど、指数的に増加させてもよい(1016)。最初の送信帯域をゆっくりと(例えば、線形的に)増加させていく期間Tは、RTTとトークン(token:制御帯域)によって定めても良いし、これらの積に比例させてもよい(1021)。また、最初の送信帯域をゆっくりと(例えば、線形的に)増加させていく間は、送信帯域をRTT毎にMSS/RTTに比例する速度で線形的に増加させてもよいし、送信帯域をRTT毎にMSS/RTTに比例する速度で線形的に増加させる場合の比例係数αを1よりも小さい値にしてもよい(1017)。これにより、送信帯域を線形的に増加させる期間が、RTTと送信帯域の過去の履歴によって定まる通信装置が実現される。
上述の送信帯域の制御方法により、ネットワークの輻輳が検出されず、尚且つ、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、前記TCP通信の送信帯域を線形的に増加させ、その後、送信帯域を非線形的に増加させる通信装置が実現される。更に、廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出する通信装置と、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、廃棄率または再送率とそれらの変化率を推定する通信装置と、輻輳を検出したときに、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、送信帯域を減少させる通信装置が実現される。
ネットワークの輻輳が検出されず、尚且つ、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、送信帯域を通常のTCP通信よりも緩やかに(例えば線形的に)増加させることで、通常のTCP通信と競合したときでも、通常のTCP通信の帯域を圧迫することを防ぎ、通常のTCP通信が帯域を確保しやすくなる。また、一定時間が経過した後に、急激に(例えば指数的に)送信帯域を増加させることで、通常のTCP通信との競合が無い時に、送信帯域がボトルネック帯域へ到達してトップスピードになる時間を短くすることが出来る。更に、廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出することで、確率的な廃棄に影響されずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させ続けることが可能となり、回線帯域を使い切ることが出来るようになる。
図12〜図16には、送信帯域制御部715が制御帯域(tokenまたはトークン)を更新する方法の詳細を説明するためのフローチャートを示す。
図12〜図15には、独自TCPにおける帯域制御の詳細を、図16には、独自TCPによる通信が回線帯域を占有せずに、通常のTCPによる通信を保護するための帯域増加方法の詳細を示す。
図12Aには、送信帯域制御部715が制御帯域(tokenまたはトークン)を更新する際の概念的なフローチャートを表す。独自TCPでは、送信帯域制御部715が、本フローチャートに従い処理を実行することで、再送率に基づく帯域制御を実現し、RTTと廃棄率に依存せず、回線帯域を使い切ることができる。図12Aの各ステップは、送信帯域制御部715により実行される。
送信帯域制御部715において、制御帯域の更新処理がスタートすると(ステップ1201)、送信帯域制御部715は、パケット再送率(=rts/old_tokenまたはrts/old_sndまたは1−rcv/old_tokenまたは1−rcv/old_sndで計算される値)の増加率が、予め定められた閾値を超過したか否かを判定する(ステップ1202)。パケット再送率の増加率が、予め定められた閾値を超過した場合は、現在の再送帯域(rts)と、過去の(基準時刻より前の)制御帯域(old_token)または過去の(基準時刻より前の)送信帯域(old_snd)を用いて、制御帯域(token)を更新する(ステップ1203)。例えば、過去の(基準時刻より前の)制御帯域を、現在の再送帯域に応じた量減らし、現時刻の制御帯域とする。一方、ステップ1202において、パケット再送率の増加率が、予め定められた閾値を超過しなかった場合は、送信帯域制御部715は、制御帯域を増加させる(ステップ1204)。ステップ1203やステップ1204のあとに、送信帯域制御部715は、各コネクションの最小帯域(min_token534)に基づき、制御帯域(token)を更新する(ステップ1206)。制御帯域(token)を変更することで、トークンバケツに蓄積されるトークンの量が変わり、それによりパケットの送信レートを変更することが可能となる。
図12Bには、送信帯域制御部715が帯域テーブル213記載の値を用いて、制御帯域(token)を変更するフローチャート図を表す。図12Aをより詳細にした例を示す。図12Bの各ステップは、送信帯域制御部715により実行される。独自TCPでは、送信帯域制御部715が、本フローチャートに従い処理を実行することで、再送率に基づく帯域制御を実現し、RTTと廃棄率に依存せず、回線帯域を使い切ることができる。
制御帯域(token)の更新処理がスタートすると(ステップ1207)、送信帯域制御部715が、タイマ713の出力する現在時刻と、帯域テーブル213記載の基準時刻との差が、インターバル格納部714の出力するインターバル時間以上であるか否かを判定する(ステップ1208)。インターバル時間として、計測したRTTの平均値や初期値等を記録した状態テーブル212のwan_rtt519等を使用してもよい。ステップ1208において真と判断された場合は、基準時刻後の現在の制御帯域tokenの値をtmpに退避させておく(ステップ1209)。更に、例えば、帯域テーブル213に記憶された再送ビット積算値(基準時刻後)/(現在時刻−基準時刻)/送信帯域(基準時刻前)で求められる再送率(基準時刻後)rts_ratioが、再送帯域(基準時刻前)/送信帯域(旧基準時刻前)で求められる旧再送率(基準時刻前)old_rts_ratioのK倍(K:予め定められた1以上の係数)よりも大きいか否かを判定する(ステップ1210)。ステップ1210は、上述のステップ1202に相当する。Kの値は、固定としてもよいし、tokenの値に応じて変化してもよい。ステップ1210において、大きいと判定した場合は、ネットワークに輻輳が発生していると判断して、制御帯域(基準時刻後)tokenの値を、制御帯域(基準時刻前)old_tokenの値よりも小さくなるように、例えば、再送帯域rtsを用いて減少させる。例えば、制御帯域(基準時刻後)token=制御帯域(基準時刻前)old_token−再送帯域(基準時刻後)rtsなどとする(ステップ1212)。ステップ1212は、上述のステップ1203に相当する。ステップ1210で偽と判定された場合は、制御帯域(基準時刻後)tokenを増加させる(ステップ1211)。制御帯域(基準時刻後)tokenの増加方法は、線形に増加させてもよいし、指数的に増加させてもよいし、線形増加と指数増加を組み合わせても良いし、最初線形増加させてその後で指数増加してもよいし、増加率を制御帯域(基準時刻後)tokenに応じて変化させてもよい。ステップ1211は、上述の1204に相当する。
ステップ1212またはステップ1211が完了すると、例えば送信帯域(旧基準時刻前)old_old_snd=送信帯域(基準時刻前)old_snd、送信帯域(基準時刻前)old_snd=送信帯域(基準時刻後)snd、再送帯域(基準時刻前)old_rts=再送帯域(基準時刻後)rts、基準時刻=基準時刻+インターバル、送信ビット積算値(基準時刻後)=0、再送ビット積算値(基準時刻後)=0、制御帯域(旧基準時刻前)old_old_token=制御帯域(基準時刻前)old_token、制御帯域(基準時刻前)old_token=tmp、定期更新時の制御帯域c_token=新たな制御帯域token、などと更新し、各値を帯域テーブル213や状態テーブル212に記録する(ステップ1213)。その後ステップ1217に移る。
一方、ステップ1208で、偽と判定された場合は、ステップ1210と同様に、再送ビット積算値(基準時刻後)/(現在時刻−基準時刻)/送信帯域(基準時刻前)で求められる再送率(基準時刻後)rts_ratioが、再送帯域(基準時刻前)/送信帯域(旧基準時刻前)で求められる旧再送率(基準時刻前)old_rts_ratioのK倍(K:予め定められた1以上の係数)よりも大きいか否かを判定する(ステップ1214)。Kの値は、固定としてもよいし、tokenの値に応じて変化してもよい。ステップ1214は、上述のステップ1202に相当する。ステップ1214において大きいと判定した場合は、ネットワークに輻輳が発生していると判断して、ステップ1212と同様に、制御帯域(基準時刻後)tokenの値を、制御帯域(基準時刻前)old_tokenの値よりも小さくなるように、例えば再送帯域rtsを用いて減少させる。例えば、制御帯域(基準時刻後)token=制御帯域(基準時刻前)old_token−再送帯域(基準時刻後)rtsなどとする(ステップ1215)。ステップ1214において小さいあるいは同等と判定した場合は、何もしない。これらのステップにより、インターバル時間が経過しなくても、再送率の増加からネットワークの輻輳を即座に検出し、制御帯域を更新できる。これらのステップの後、ステップ1217に移る。
ステップ1217では、制御帯域(基準時刻後)tokenが、各TCP通信の最小帯域min_tokenよりも小さい場合は、制御帯域(基準時刻後)tokenを各TCP通信の最小帯域min_token534に変更する(ステップ1217)。すなわち図12Bのステップ1217で示す2つの式で定まるtokenのうちいずれか小さいほうをとる。なお、ステップ1217におけるtokenやmin_token534などのデータは、状態テーブル212や帯域テーブル213を参照して読み出すことができる。制御帯域(token)を変更することで、トークンバケツに蓄積されるトークンの量が変わり、それによりパケットの送信レートを変更することが可能となる。
上述のように、独自TCPでは、図12を用いて説明したフローチャートのように、廃棄率または再送率に基づく帯域制御を行うことで、確率論的な廃棄の影響を受けずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させることが出来るようになる。これにより、独自TCPは、RTTと廃棄率に依存せずに、回線帯域を使い切ることが出来る。
図13、図14、図15には、送信帯域制御部715が帯域テーブル213記載の値を用いて、制御帯域(token)を変更するフローチャート図を表す。図12Bの一部をより詳細にした例を示す。図13がメインのフローチャート、図14と図15は、図13の処理の一部を詳細化したフローチャートである。図13、図14、図15の各ステップは、送信帯域制御部715により実行される。独自TCPでは、送信帯域制御部715が、本フローチャートに従い処理を実行することで、再送率に基づく帯域制御を実現し、RTTと廃棄率に依存せず、回線帯域を使い切ることができる。
図13には、送信帯域制御部715が帯域テーブル213記載の値を用いて、制御帯域(token)を変更するメインのフローチャート図を表す。
送信帯域制御部715は、初めに廃棄率の計算を行う(1301)。廃棄率は、前述の図11を用いた説明のように、rts/old_tokenまたはrts/old_sndまたは1−rcv/old_tokenまたは1−rcv/old_sndで計算される。廃棄率として、再送率を用いることもある。次に、tokenの値に応じて、閾値kの調整を行う(1302)。tokenの値が大きいときは、閾値kを小さくすることで、廃棄率が少し増加しただけでも、廃棄率の変化率が閾値kを超えやすくなり、ネットワークの輻輳を検出しやすくする。次に、前回の定期更新からRTTが経過したか否かを判定する(ステップ1303)。これは、現在時刻と基準時刻との差がインターバル以上であるか否かを判定するステップ1208に相当する処理である。RTT経過した場合は、RTT毎に行う定期更新処理を行う(1304)。RTT経過してない場合は、不定期の更新処理を行う(1305)。定期更新1304と不定期更新1305の詳細は、それぞれ図14と図15を用いて後述する。定期更新1304と不定期更新1305の後、アクティブコネクション数とアクセス帯域に基づいて、制御帯域(token)を更新する処理を行う(1306)。この処理により、コネクション間の公平性が確保される。更に、各TCPコネクション通信の最小帯域min_token534に基づいて、制御帯域(token)を更新する(ステップ1307)。
図14には、送信帯域制御部715が行う、制御帯域(token)の定期更新処理1304の詳細なフローチャート図を示す。
送信帯域制御部715が行う定期更新処理1304では、初めに廃棄率(rts_ratio)の増加率が閾値kを超過したか否かを判定する(ステップ1401)。廃棄率(rts_ratio)の増加率が閾値kを超過している場合は、送信帯域制御部715は、0〜RTT前の再送帯域rtsと、RTT〜2RTT前の送信帯域old_sndまたは制御帯域old_tokenに基づき新たな制御帯域を決定する(ステップ1402)。例えば、新たな制御帯域token=制御帯域(基準時刻前:RTT〜2RTT前)old_token−再送帯域(基準時刻後:0〜RTT前)rtsなどとする(ステップ1402)。本願では、ステップ1402のことをフェーズ2と呼ぶ。次に、現在のACK受信済み箇所wan_left_send524と、RTT前のACK受信済み箇所を表すold_wan_left_send527の値を比較し(ステップ1403)、変化していればRTT毎の定期更新1304を終了する。変化していない場合は、ステップ1405に進む。
ステップ1401において、廃棄率(rts_ratio)の増加率が閾値kを超過していない場合は、送信帯域制御部715は、現在のACK受信済み箇所wan_left_send524と、RTT前のACK受信済み箇所を表すold_wan_left_send527の値を比較する(ステップ1404)。変化していない場合は、ステップ1405に進む。ステップ1405では、送信帯域制御部715は、WAN側の送信バッファ207を参照し、、未送信データがあるか否かを判断する(ステップ1405)。未送信データが送信バッファ207にある場合は、送信帯域制御部715は、0〜RTT前のACK受信数に基づいて、制御帯域を調整する(ステップ1406)。例えば、新たな制御帯域=受信帯域(基準時刻後:0〜RTT前)rcvなどとする(ステップ1406)。ステップ1406が終わると、送信帯域制御部715は、RTT毎の定期更新1304を終了する。また、ステップ1404において、現在のACK受信済み箇所wan_left_send524が、RTT前のACK受信済み箇所を表すold_wan_left_send527の値よりも大きくなっている場合は、制御帯域(token)を増加させる(ステップ1407)。本願では、ステップ1407の処理のことをフェーズ1と呼ぶ。ステップ1407が終わると、RTT毎の定期更新1304を終了する。なお、制御帯域(token)を増加させるステップ1407の詳細は、図16を用いて後述する。
図15には、送信帯域制御部715が行う、制御帯域(token)の不定期更新処理1305の詳細なフローチャート図を示す。
図13のステップ1303で、現在時刻が、前回のステップ1304のRTT毎の制御帯域更新処理からRTT経過していない場合、送信帯域制御部715が行う不定期更新処理1305では、初めに廃棄率(rts_ratio)の増加率が閾値kを超過したか否かを判定する(ステップ1501)。廃棄率(rts_ratio)の増加率が閾値kを超過している場合は、0〜RTT前の再送帯域rtsと、RTT〜2RTT前の送信帯域old_sndまたは制御帯域old_tokenに基づき新たな制御帯域を決定する(ステップ1502)。例えば、新たな制御帯域token=制御帯域(基準時刻前:RTT〜2RTT前)old_token−再送帯域(基準時刻後:0〜RTT前)rtsなどとする(ステップ1502)。本願では、ステップ1502のことを、ステップ1402と同様に、フェーズ2と呼ぶ。ステップ1502が終わると、不定期更新処理1305を終了する。一方、ステップ1501において、廃棄率(rts_ratio)の増加率が閾値kを超過していない場合は、直近の定期更新時の制御帯域(c_token)を使用して、制御帯域(token)を更新する(ステップ1503)。例えば、token=c_tokenなどとする。(ステップ1503)。本願では、ステップ1503のことを、フェーズ3と呼ぶ。
図13〜図15を用いて上述したように、送信帯域制御部715が行う制御帯域(token)の更新処理は、大きく分けて、帯域を増加させるフェーズ1(ステップ1407)と、帯域を減少させるフェーズ2(ステップ1402、ステップ1502)と、帯域を元の値に戻すフェーズ3(ステップ1503)と、帯域をACK受信数に応じて一定にするフェーズ4(ステップ1406)の4種類の処理から構成される。
図17には、送信帯域制御部715が行う制御帯域(token)の更新処理により、制御帯域(token)が時系列順にどのように変化していくかをグラフにより示す。
まず初めに、帯域増加のフェーズ1(ステップ1407)があり、次に、帯域を減少させるフェーズ2(ステップ1402、ステップ1502)があり、最後に、帯域をACK受信数に応じて一定にするフェーズ4(ステップ1406)がある。帯域を元の値に戻すフェーズ3(ステップ1503)は、RTT毎の定期更新までの間にある、制御帯域(token)が一定になっているときのフェーズである。
送信帯域制御部715は、フェーズ2とフェーズ4の時、状態テーブル212の帯域増加開始時刻inc_time538を現在時刻で更新する。更に、フェーズ4の時、状態テーブル212のt_token535を現在の制御帯域(token)で更新する。t_token535は、独自TCPが検出したボトルネック帯域に相当する。
図16Aには、ステップ1407における帯域増加処理のフローチャート図を示す。
送信帯域制御部715が行う帯域増加処理1407では、初めに、状態テーブル212に記載されているfriendly_mode532の値をチェックして、通常のTCPに対してフレンドリなモード、つまり第一の制御モードでの通信が有効か否かを判断する。加えて、現在時刻と、帯域増加開始時刻inc_time538との差が、時間Tを超過したか否かを判断する(ステップ1601)。フレンドリモードfriendly_mode532が有効で、尚且つ、現在時刻と帯域増加開始時刻inc_time538との差が、時間Tを超過していない場合は、送信帯域制御部715は、第一の制御モードでゆっくりと帯域を増加させる(ステップ1603)。例えば、新たな制御帯域(token)=元の制御帯域(token)+係数α×最大セグメントサイズMSS×8/RTTなどとする(ステップ1603)。係数αは、例えば1未満にする。フレンドリモードfriendly_mode532が無効、または、現在時刻と帯域増加開始時刻inc_time538との差が、時間Tを超過した場合は、送信帯域制御部715は、第一の制御モードよりも送信帯域の増加率が高い第2の制御モードで、帯域を急激に増加させる(ステップ1602)。例えば、新たな制御帯域(token)=係数α×元の制御帯域(token)などとする(ステップ1602)。
上述したように、廃棄率の増加率が閾値kを超過しなくなるなど、ネットワークの輻輳が検出されなくなり(ステップ1401)、尚且つ、受信確認済みのデータ箇所が更新中(ステップ1404)の状態が継続するようになってから、一定の期間Tは、送信帯域をゆっくりと、例えば線形的に増加させ(ステップ1603)、その後、送信帯域を急激に、例えば非線形的に増加させる(ステップ1602)ことで、独自TCPを用いた通信が回線帯域を占有することを防ぎ、通常のTCPを用いた通信が通信帯域を確保できるようになる。
図16Bには、ステップ1407における帯域増加処理の別のフローチャート図を示す。図16Aに分岐処理を一つ加えた例を示す。
図16Aを用いて説明したステップ1601とステップ1602の間に、新たに分岐処理(ステップ1604)が加わり、ステップ1602とは別の処理(ステップ1605)を実施するフローが加わる。それ以外は、図16Aと同様である。
ステップ1601において、フレンドリモードfriendly_mode532が有効で、尚且つ、現在時刻と帯域増加開始時刻inc_time538との差が、時間Tを超過していない場合、次に、計測RTTが、初期RTTの一定倍(例えば2倍)を超過しているか否かを判定する(ステップ1604)。初期RTTの一定倍を超過していない場合は、ステップ1602の処理を実施する。初期RTTの一定倍を超過している場合は、送信帯域制御部715は、第3の制御モードである通常TCPと同等のスピードで帯域を増加させる(ステップ1605)。例えば、新たな制御帯域(token)=元の制御帯域(token)+最大セグメントサイズMSS×8/RTTなどとする(ステップ1605)。これにより、平均RTTと初期RTTの比率に基づいて、増加速度を決定し、決定された増加速度を第一の制御モードと、第2の制御モードとの中間の第3の制御モードとして送信帯域制御を行う通信装置が実現される。
上述したように、計測RTTが、初期RTTの一定倍(例えば2倍)を超過しているときに、帯域増加速度を通常TCPと同等にする処理を加える。ネットワークの輻輳が検出できていなくても、RTTが増加し始めた早い段階から、帯域増加速度を低下させることで、回線帯域の使いすぎを防止でき、帯域の公平利用が図ることができる。
図16Cには、ステップ1407における帯域増加処理の別のフローチャート図を示す。図16Bに分岐処理を一つ加えた例を示す。
図16Bを用いて説明したステップ1604とステップ1602の間に、新たに分岐処理(ステップ1615)が加わり、ステップ1602とは別の処理(ステップ1616)を実施するフローが加わる。それ以外は、図16Bと同様である。
ステップ1604において、計測RTTが、初期RTTの一定倍(例えば2倍)を超過していない場合、次に、現在の制御帯域(token)が、輻輳が検出されない状態になった直近の制御帯域t_token535を超過しているか否かを判定する(ステップ1615)。超過していない場合は、ステップ1602(第2の制御モード)の処理を実施する。超過している場合は、ステップ1602(第2の制御モード)よりは緩やか制御モードだが第3の制御モードより急である第4の制御モードにより、帯域を急に増加させる(ステップ1616)。例えば、新たな制御帯域(token)=係数β×元の制御帯域(token)などとする(ステップ1616)。これにより、輻輳が検出されない状態になった直近の送信帯域に基づいて、増加速度を決定する通信装置が実現される。
上述したように、現在の制御帯域(token)が、輻輳が検出されない状態になった直近の制御帯域t_token535を超過したときに、帯域の増加速度を緩やかにする処理を加える。ネットワークの輻輳が検出できていなくても、ネットワークの輻輳が発生する可能性が高い段階から、帯域増加速度を低下させることで、回線帯域の使いすぎを防止できる。 なお、通信装置101の送信帯域制御部150や、図1の通信装置101に対応する通信装置200の送信帯域制御部715では、第一ないし第4の制御モードを搭載し、図16A−Cの処理のいずれか一を実行してもよい。また、第一ないし第4の制御モードのうち少なくとも2種類の制御モードが、搭載、あるいは実行可能な状態で設定された通信装置であってもよい。ただし、第一の制御モードを実行可能な状態に設定されていない場合、増加率の小さい制御モードを実行する期間が所定の期間経過した後(例えば、現在時刻と帯域増加開始時刻との差>T)、送信帯域制御部715(図1の150)は、他の制御モードに図16の条件で変更してもよい。また、各制御モードは、通信装置200の不揮発性記憶媒体にプログラムとしてそれぞれ格納されていてもよい。図16A−Cで説明した4種類の制御モードのうち、2以上の制御モードの設定を、管理端末等から通信装置が実行可能な状態に設定されてもよい。2以上の制御モードを用いて、所定の条件に応じて増加率を増減する送信帯域制御を行い、他の通信との帯域の公平利用がはかれる。また、図16A−Cの1601の、「フレンドリモード有効」かどうかの判断は省略してもよい。
以上送信帯域制御部715が行う送信帯域の増加するための制御モードについて説明した。
(通信モードを変更する処理)
以下、独自TCP対応の通信装置が、データ通信を開始する場合、対向装置が独自TCP対応か否かで、通信モードを変更する例を説明するが、特に断りのない限り、図1の通信装置100や図2の通信装置のほか上述の実施例の構成と同様である。
図18のシーケンス図と、図19〜図20のフローチャート図と、図23のテーブルフォーマット図を用いて、TCP制御部707/703が状態テーブル212に記載する通信モード(フレンドリモードfriendly_mode532またはワンウェイモードone−way_mode533)を決定する方法の詳細を説明する。
初めに、図23を用いて、モード/最低帯域指定テーブル740のフォーマットについて説明する。
モード/最低帯域指定テーブル740は、送信IP/サブネットと宛先IP/サブネットと送信ポートと宛先ポートの組合せ毎に、フレンドリモードの有効または無効と、最小帯域を指定したエントリを複数個備える。
図7Aに示すユーザ端末741は、送信IP/サブネットと宛先IP/サブネットと送信ポートと宛先ポートの組合せ毎に、フレンドリモードの有効または無効と、最小帯域を指定する。送信IP/サブネットと宛先IP/サブネットと送信ポートと宛先ポートのうち、任意の値をとる項目については、Anyなどと指定する。任意の組合せに対するデフォルト動作を指定したい場合は、送信IP/サブネットと宛先IP/サブネットと送信ポートと宛先ポートの全てをAnyなどと指定した上で、フレンドリモードの有効または無効と、最小帯域を指定すればよい。特定のネットワーク宛の通信について、フレンドリモードの有効または無効と、最小帯域を指定したい場合は、他の送信IP/サブネットと送信ポートと宛先ポートはAnyなどとしたうえで、宛先IP/サブネットと、フレンドリモードの有効または無効と、最小帯域を指定する。特定のネットワーク元の特定の送信ポート番号の通信について、フレンドリモードの有効または無効と、最小帯域を指定したい場合は、宛先IP/サブネットと宛先ポートをAnyなどとした上で、送信IP/サブネットと送信ポートと、フレンドリモードの有効または無効と、最小帯域を指定する。
TCP制御部707/703は、SYNパケットまたはSYNACKパケットを受信してコネクションを確立する時に、モード/最低帯域指定テーブル740から一致するエントリを上から検索して、一致するエントリが有る場合に、エントリ指定の最小帯域を、状態テーブル212のmin_token535に記載する。更に、送信帯域制御部715が、状態テーブル212のmin_token535に基づいて、min_token535を下回らないように制御帯域(token)を制御する。これにより、各TCP通信の最低帯域を、外部から予め定めることが出来るようになる。
図18Aには、通信を自発的に開始する通信装置(独自TCP対応)が、対向装置が独自TCP対応の時に、通信モードを決定するシーケンス図を示す。
通信装置1801(独自TCP対応)は、対向の通信装置(独自TCP対応)1802に対して、独自のオプション番号を持つSYNパケット1803を送信する。対向の通信装置(独自TCP対応)1802は、独自のオプション番号を持つSYNパケット1803を受け取ると、独自のオプション番号を持つSYNACKパケット1804を返信する。通信装置1801(独自TCP対応)は、対向の通信装置(独自TCP対応)1802から、独自のオプション番号を持つSYNACKパケット1804を受け取ると、SYNACKパケット1804のIPヘッダ410とTCPヘッダ420に記載の送信IPアドレス413と宛先IPアドレス414と送信ポート番号421と受信ポート番号422を用いて、モード/最低帯域指定テーブル740から一致するエントリを上から検索する。一致するフレンドリモード有効のエントリがある場合は、状態テーブル212のフレンドリモード532を有効にする(1805)。
図18Bには、通信を自発的に開始する通信装置(独自TCP対応)が、対向装置が独自TCP非対応の時に、通信モードを決定するシーケンス図を示す。
通信装置1801(独自TCP対応)は、対向の装置(独自TCP非対応)1806に対して、独自のオプション番号を持つSYNパケット1803を送信する。対向の装置(独自TCP非対応)1806は、独自のオプション番号を持つSYNパケット1803を受け取ると、独自のオプション番号を持たないSYNACKパケット1807を返信する。通信装置1801(独自TCP対応)は、対向の装置(独自TCP非対応)1806から、独自のオプション番号を持たないSYNACKパケット1807を受け取ると、状態テーブル212のone−way_mode533とフレンドリモード532を有効にする(1808)。
図18Cには、通信を受動的に開始する通信装置(独自TCP対応)が、対向装置が独自TCP対応の時に、通信モードを決定するシーケンス図を示す。
通信装置1801(独自TCP対応)は、対向の通信装置(独自TCP対応)1802から、独自のオプション番号を持つSYNパケット1809を受信すると、独自のオプション番号を持つSYNACKパケット1810を返信する。更に、SYNパケット1809のIPヘッダ410とTCPヘッダ420に記載の送信IPアドレス413と宛先IPアドレス414と送信ポート番号421と受信ポート番号422を用いて、モード/最低帯域指定テーブル740から一致するエントリを上から検索する。一致するフレンドリモード有効のエントリがある場合は、状態テーブル212のフレンドリモード532を有効にする(1811)。
図18Dには、通信を受動的に開始する通信装置(独自TCP対応)が、対向装置が独自TCP非対応の時に、通信モードを決定するシーケンス図を示す。
通信装置1801(独自TCP対応)は、対向の装置(独自TCP非対応)1806から、独自のオプション番号を持たないSYNパケット1812を受信すると、独自のオプション番号を持たないSYNACKパケット1813を返信する。更に、状態テーブル212のone−way_mode533とフレンドリモード532を有効にする(1814)。
以上が、対向装置が、独自TCP対応か非対応かで、通信モードを決定するためのシーケンス図を説明した。なお、独自TCP非対応である対向装置は、例えば、図1のルータ186等の通信装置、計算機131や123である。
図19には、図18A−Dに対応する、通信を自発的に開始する通信装置が、通信モードを決定するフローチャート図を示す。
通信装置1801(独自TCP対応)が、自発的に通信を開始すると(ステップ1901)、TCP制御部703は、初めに特定のオプション番号を持つSYNパケットを送信する(ステップ1902)。対向装置からSYNACKパケットを受信すると(ステップ1903)、次に、TCP制御部703/707は、SYNACKパケットが特定のオプション番号を持つか否かを判定する(ステップ1904)。特定のオプション番号が有る場合は、SYNACKパケットのIPヘッダ410とTCPヘッダ420に記載の送信IPアドレス413と宛先IPアドレス414と送信ポート番号421と受信ポート番号422を用いて、モード/最低帯域指定テーブル740から一致するエントリを上から検索して、一致するフレンドリモード有効のエントリがあるか否かを判定する(ステップ1906)。一致するフレンドリモード有効のエントリが無い場合は、TCP制御部703/707は、そのまま通信を確立する(ステップ1908)。一致するフレンドリモード有効のエントリが有る場合は、状態テーブル212のフレンドリモード532を有効にする(ステップ1907)。また、ステップ1904において、特定のオプション番号が無い場合は、状態テーブル212のone−way_mode533を有効にする(ステップ1905)。その後、強制的にフレンドリモードを有効にしてもよいし(ステップ1907)、ステップ1906を実施して、モード/最低帯域指定テーブル740の検索結果に基づいて、状態テーブル212のフレンドリモード532の有効/無効を決めても良い。なお、状態テーブル212のフレンドリモード532やone−way_mode533は、デフォルトでは無効である。これにより、送信帯域の増加方法を適用するTCP通信を、外部から予め定める通信装置が実現される。
図20には、通信を受動的に開始する装置が、通信モードを決定するフローチャート図を示す。
通信装置1801(独自TCP対応)が、受動的に通信を開始すると(ステップ2001)、初めにSYNパケットを受信して(ステップ2002)、通信を開始する(ステップ2003)。次に、SYNパケットが特定のオプション番号を持つか否かを判定する(ステップ2004)。特定のオプション番号が有る場合は、SYNパケットのIPヘッダ410とTCPヘッダ420に記載の送信IPアドレス413と宛先IPアドレス414と送信ポート番号421と受信ポート番号422を用いて、モード/最低帯域指定テーブル740から一致するエントリを上から検索して、一致するフレンドリモード有効のエントリがあるか否かを判定する(ステップ2006)。一致するフレンドリモード有効のエントリが有る場合は、状態テーブル212のフレンドリモード532を有効にする(ステップ2007)。また、ステップ2004において、特定のオプション番号が無い場合は、状態テーブル212のone−way_mode533を有効にする(ステップ2005)。その後、強制的にフレンドリモードを有効にしてもよいし(ステップ2007)、ステップ2006を実施して、モード/最低帯域指定テーブル740の検索結果に基づいて、状態テーブル212のフレンドリモード532の有効/無効を決めても良い。なお、状態テーブル212のフレンドリモード532やone−way_mode533は、デフォルトでは無効である。通信モードが定まると、次に、one−way_mode533が有効か否かを判定する(ステップ2008)。one−way_mode533が有効な場合は、特定のオプション番号を持つSYNACKパケットを対向装置へ送信する(ステップ2009)。one−way_mode533が無効な場合は、特定のオプション番号を持たないSYNACKパケットを対向装置へ送信する(ステップ2010)。SYNACKパケットを送信すると、通信確立する(ステップ2011)。これにより、送信帯域の増加方法を適用するTCP通信を、外部から予め定める通信装置が実現される。
上述の図23のテーブルフォーマットと、図18に示すシーケンスと、図19〜図20に示すフローチャートを用いて、通信モードを決定することで、フレンドリモードにする通信を、外部から予めコネクション毎にユーザが指定することができる。更に、TCP通信の開始時に対向装置から特定の値を持つオプション情報が送付されないときに、フレンドリモードを強制的に適用することが可能となる。
(通信モードに応じて廃棄率の計算の仕方を変える)
以下、実施例2において、図21のフローチャート図と、図22のシーケンス図を用いて、送信帯域制御部715が、通信モードに応じて廃棄率の計算処理の詳細を説明する。
図22には、独自TCPと通常TCPのパケット廃棄が起きたときの再送方法の差異を説明するためのシーケンス図を示す。左側に通常TCPの再送制御方式を、右側に独自TCPの再送制御方式を示す。
通常TCPでは、ACKパケットのTCPオプションヘッダ430内のleft_edge_1〜4(433、435、437、439)、right_edge_1〜4(434、436、438、440)には、どこからどこまで部分的に受信済であるかを最大4箇所記載して、部分的確認応答(Selective ACK(SACK))用に用いる。一方、独自TCPでは、TCPオプションヘッダ430内のleft_edge_1〜4(433、435、437、439)、right_edge_1〜4(434、436、438、440)には、どこからどこまで部分的に再送してほしいかを最大4箇所記載して、部分的未確認応答(Negative ACK(NACK))用に用いる。
通常TCPでは、送信計算機2201から受信計算機2202へ送った12個のデータパケットA〜L(2205)のうち、B、D、F、H、Jが途中で廃棄されたとすると、TCPオプションヘッダ430に書き込める受信済み箇所が最大4箇所までである制約から、I以降に送ったパケットに対する確認応答をこの時点では送信計算機2201に送ることができない(2209)。送信計算機は、A〜Iまでの部分的確認応答を記載した確認応答パケット(2209)を用いて、パケットA〜Iのうち廃棄されたパケットB、D、F、Hを再送する(2206)。受信計算機2202は、再送パケット(2206)を受信してから、パケットI以降の部分的確認応答を記載した確認応答を返信する(2212)。送信計算機2201は、パケットI以降の部分的確認応答を記載した確認応答(2212)を受信してから、パケットI以降に廃棄されたパケットJを再送することができる(2207)。一方、独自TCPでは、送信計算機2203から受信計算機2204へ送った12個のデータパケットA〜L(2208)のうち、B、D、F、H、Jが途中で廃棄されたとしても、A〜Jまでの再送してほしい箇所をTCPオプションヘッダ430内のleft_edge_1(433)とright_edge_1(434)へ逐一書き込んでから、部分的未確認応答用(NACK)のACKパケットを返信する(2211)。各再送要求箇所は、1つのNACKパケットにだけ書き込まれる。送信計算機2203は、部分的未確認応答用(NACK)のACKパケット(2211)を受信すると、TCPオプションヘッダ430に記載された再送要求箇所B、D、F、H、Jを再送する(2210)。ロスが大量に発生したときでも、一度で再送が完了するため、通信時間が短縮し、帯域が向上する。つまり、送信計算機と受信計算機の間に2台の通信中継装置(プロキシ装置)を設置し、受信計算機側のプロキシ装置が送信計算機側のプロキシ装置に対して廃棄箇所を全て逐一フィードバック通知する。例えば、送信計算機側のプロキシ装置は、受信計算機側のプロキシ装置からフィードバック通知された廃棄箇所を再送すると共に、基準時刻以降の再送帯域や廃棄帯域と、基準時刻以前の送信帯域とに基づいて、特定の宛先に対するデータ送信帯域とデータ再送帯域の総和を増減させる。それにより、廃棄率に依存しない通信を実現することができる。
上述のように、通常TCPでは、SACKを用いるため、対向装置が通常TCPである場合は、SACKを用いる必要がある。更に、廃棄箇所が最大4個までしか通知されないため、再送帯域を用いて廃棄率を計算してしまうと、廃棄箇所が多いときに、誤差が大きくなってしまう。そのため、対向装置が通常TCPである場合は、廃棄率の計算方法を変え、送信帯域を制御する必要がある。
図21には、通信モードに応じて廃棄率の計算方法を変えるフローチャート図を示す。
まず、状態テーブル212のone−way_mode533が有効か否かを判定する(ステップ2101)。one−way_mode533が無効な場合は、対向装置が独自TCPに対応しているということなので、直近の再送数とRTT前の送信数、または、直近の再送帯域rtsとRTT前の制御帯域old_tokenを用いて、再送率を計算し、廃棄率として利用する(ステップ2105)。一方、one−way_mode533が有効な場合は、重複ACKを受信中か否かを判定する(ステップ2102)。重複ACKを受信していない場合は、廃棄率0とする(ステップ2103)。重複ACKを受信している場合は、直近のACK受信数とRTT前の送信数、または、直近の受信帯域rcvとRTT前の制御帯域old_tokenを用いて、廃棄率を計算する(ステップ2104)。これにより、対向装置から特定の値を持つオプション情報が送付されないときに限り、送信帯域とACK受信数の履歴を用いて廃棄率を推定し、推定結果に基づいて帯域制御を行う送信帯域制御部を備える通信装置200が実現される。
上述のように、本実施例での通信装置は、TCP通信の開始時に対向装置から特定の値を持つオプション情報が送付されないときに、即ち、対向装置が独自TCPに対応していないときに、送信帯域とACK受信数の履歴を用いて廃棄率を推定することで、NACKを用いなくても廃棄率を推定する。これにより、独自TCPが帯域制御に用いる廃棄率の誤差を少なくすることができ、上述のボトルネック帯域の推定が容易となる。
なお、実施例2の独自TCP対応の通信装置は、実施例1の構成を前提とした通信装置であってもよい。また、図16の第一ないし第4の制御モードのうち、少なくとも一が搭載されてある、通信装置であってもよい。
上述の実施例のように、本願明細書で開示される他の態様は、下記のとおりである。
TCP通信の送信帯域を制御する通信装置が、前記TCP通信において輻輳が検出されず、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、前記TCP通信の送信帯域を線形的に増加させる手段と、前記の一定の期間が過ぎた後、送信帯域を非線形的に増加させる手段と、前記TCP通信において、廃棄率や再送率の変化率を用いて輻輳を検出する手段と、送信帯域と再送帯域の過去の履歴を用いて再送率とその変化率を推定する手段と、送信帯域とACK受信数の過去の履歴を用いて廃棄率とその変化率を推定する手段と、輻輳を検出したときに、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、送信帯域を減少させる手段と、を備える。
上述の態様により、通常のTCPを用いた通信と、独自TCPを用いた通信が、同一の通信回線を共有する場合でも、独自TCPを用いた通信が、回線帯域を占有することを防ぎ、通常のTCPを用いた通信が通信帯域を確保することが可能となる。
また、本発明の別の態様によると、
LAN側とWAN側の複数のTCP通信を中継する通信装置が、各TCP通信の送信帯域を制御する帯域制御部と、各TCP通信の受信確認済みのデータ箇所の履歴を記録する状態テーブルと、各TCP通信における送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴を記録する帯域テーブルと、を有し、前記帯域制御部が、状態テーブルに記載の送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴と、状態テーブルに記載の受信確認済みのデータ箇所の履歴と基づいて、TCP通信の輻輳の有無と、受信確認済みのデータ箇所が更新中か否かを判定し、輻輳が検出されず、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、TCP通信の送信帯域を線形的に増加させ、前記の一定の期間が過ぎた後、TCP通信の送信帯域を非線形的に増加させる通信装置が提供される。
101、102 通信装置
110、120、130 ネットワーク
111、121、131 計算機
190、191、192 回線
200 通信装置
715 送信帯域制御部

Claims (15)

  1. ネットワークに接続される第一の通信装置であって、
    前記第一の通信装置から前記ネットワークを介して第二の通信装置に送信されるパケットに関する帯域をインターバル毎に管理し、
    管理される現在のインターバルの帯域及び過去のインターバルにおける帯域に基づいて、前記現在のインターバルよりも後のインターバルにおけるパケットを送出するための制御帯域を増加させる場合、
    所定の期間は、第一の増加率で制御帯域を増加させ、前記所定の期間経過後は、第一の増加率よりも高い、第二の増加率で前記制御帯域を増加させる送信帯域制御部と、
    前記制御帯域に従って、パケットを前記ネットワークに送出する送信部と、を有する、ことを特徴とする第一の通信装置。
  2. 請求項1記載の通信装置であって
    前記送信されるパケットの廃棄状況が所定の条件に満たない場合、
    前記送信帯域制御部は、前記制御帯域を前記所定の期間経過するまでは、線形的に増加させ、前記所定の期間経過後は、非線形的に増加させる、ことを特徴とする、通信装置。
  3. 請求項2記載の通信装置であって、
    前記所定の条件は、廃棄率が所定の閾値に達する場合であり、
    前記所定の条件を満たさない場合は輻輳未検出と判定し、前記輻輳未検出の場合、前記送信帯域制御部は、前記送信されるパケットのうち未受信の箇所を示す情報と、前記送信されるパケットの受領確認応答とを含む通知の受領に応じて、制御帯域を増加させる、ことを特徴とする、通信装置。
  4. 請求項1ないし記載の通信装置であって、
    各インターバル間の送信帯域及び再送帯域それぞれの比較結果に基づいて輻輳か否かを検出する、ことを特徴とする通信装置。
  5. 請求項1ないし4に記載の通信装置であって、
    前記送信帯域制御部は、送信帯域と再送帯域と受領確認応答の受信数の過去の履歴を用いて廃棄率または再送率とそれらの変化率を推定して、
    輻輳を検出したときに、送信帯域と再送帯域と前記受信数の過去の履歴を用いて、送信帯域を減少させる、ことを特徴とする通信装置。
  6. 請求項1ないし5記載の通信装置であって、
    前記通信装置は、TCP通信により前記パケットを送信し、
    前記所定の期間が、前記TCP通信におけるRTTと送信帯域の過去の履歴によって定まることを特徴とする通信装置。
  7. 請求項1ないし6記載の通信装置であって、
    前記送信帯域制御部は、現時点よりも過去のインターバルにおいて、輻輳未検出で送信帯域の最大値を超えたか否かで、増加速度を決定することを特徴とする通信装置。
  8. 請求項1ないし7記載の通信装置であって、
    前記送信帯域制御部は、前記所定の期間経過後は、前記制御帯域を指数的に増加させることを特徴とする通信装置。
  9. 請求項1ないし8記載の通信装置であって、
    前記通信装置は、計算機間のTCP通信により前記パケットを送信し、
    前記TCP通信における平均RTTと初期RTTの比率に基づいて、増加速度を決定することを特徴とする通信装置。
  10. 請求項1ないし9記載の通信装置であって、
    TCP通信に基づく計算機間のデータ転送を中継し、前記データ転送を行うTCP通信のうち、所定のTCP通信に対して前記送信帯域制御部による送信帯域制御を適用し、他のTCP通信については、送信帯域制御を適用しない、ことを特徴とする通信装置。
  11. 請求項10記載の通信装置であって、
    通信装置が中継するUDPパケット及びARPパケットは、前記送信帯域制御部での送信帯域制御を適用しない、ことを特徴とする通信装置。
  12. 請求項1記載の通信装置であって、
    前記送信部は、前記パケットを送信するための通信を確立する確立要求パケットを送信し、
    確立要求パケットに対する受信される応答パケットに基づいて、前記パケットに対して、
    前記送信帯域制御部による帯域制御を適用するか、否かを決定する、ことを特徴とする通信装置。
  13. 請求項12に記載の通信装置であって、
    前記確立要求パケットは、TCP通信の開始時に送信され、
    前記応答パケットに対向装置から特定の値を持つオプション情報が含まれない場合、前記送信帯域制御部による帯域制御を適用することを特徴とする通信装置。
  14. 請求項13に記載の通信装置であって、
    前記TCP通信の開始時に対向装置から特定の値を持つオプション情報が送付されないときに限り、送信帯域とACK受信数の履歴を用いて廃棄率を推定することを特徴とする通信装置。
  15. 複数の計算機に接続される第一のネットワークと広域網である第2のネットワークとに接続される複数のTCP通信を中継する通信装置が、
    各TCP通信の送信帯域を制御する帯域制御部と、
    各TCP通信の受信確認済みのデータ箇所の履歴を記録する状態テーブルと、
    各TCP通信における送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴を記録する帯域テーブルと、
    を有し、
    前記帯域制御部が、帯域テーブルに記載の送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴と、状態テーブルに記載の受信確認済みのデータ箇所の履歴と基づいて、TCP通信の輻輳の有無と、受信確認済みのデータ箇所が更新中か否かを判定し、輻輳が検出されず、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、TCP通信の送信帯域を線形的に増加させ、前記の一定の期間が過ぎた後、TCP通信の送信帯域を非線形的に増加させる、ことを特徴とする通信装置
JP2014500864A 2012-02-24 2012-10-26 通信装置 Expired - Fee Related JP5651805B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014500864A JP5651805B2 (ja) 2012-02-24 2012-10-26 通信装置

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2012038157 2012-02-24
JP2012038157 2012-02-24
JP2014500864A JP5651805B2 (ja) 2012-02-24 2012-10-26 通信装置
PCT/JP2012/077755 WO2013125096A1 (ja) 2012-02-24 2012-10-26 通信装置

Publications (2)

Publication Number Publication Date
JP5651805B2 true JP5651805B2 (ja) 2015-01-14
JPWO2013125096A1 JPWO2013125096A1 (ja) 2015-07-30

Family

ID=49005297

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014500864A Expired - Fee Related JP5651805B2 (ja) 2012-02-24 2012-10-26 通信装置

Country Status (5)

Country Link
US (1) US9231829B2 (ja)
EP (1) EP2819353A4 (ja)
JP (1) JP5651805B2 (ja)
CN (1) CN103858404B (ja)
WO (1) WO2013125096A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015037080A1 (ja) * 2013-09-11 2015-03-19 株式会社日立製作所 通信装置および方法、通信処理プログラム
KR20150072512A (ko) * 2013-12-19 2015-06-30 한국전자통신연구원 단방향 지연을 제어하는 프레임 전송 방법 및 장치
CN104754003B (zh) * 2013-12-30 2019-01-08 腾讯科技(深圳)有限公司 传输数据的方法及系统
JP6248638B2 (ja) * 2014-01-06 2017-12-20 富士通株式会社 通信端末、プログラム、及び通信方法
JP6234236B2 (ja) * 2014-01-15 2017-11-22 株式会社日立製作所 通信装置
JP2015195511A (ja) * 2014-03-31 2015-11-05 富士通株式会社 パケット解析プログラム、パケット解析装置およびパケット解析方法
KR20170018057A (ko) 2014-06-25 2017-02-15 후아웨이 테크놀러지 컴퍼니 리미티드 데이터 전송 방법 및 디바이스
US10080231B2 (en) * 2015-06-16 2018-09-18 Avaya Inc. Channel bandwidth optimization for dynamic network conditions
WO2017077613A1 (ja) * 2015-11-05 2017-05-11 三菱電機株式会社 通信装置及び通信方法
US9813299B2 (en) * 2016-02-24 2017-11-07 Ciena Corporation Systems and methods for bandwidth management in software defined networking controlled multi-layer networks
US10587526B2 (en) * 2016-05-30 2020-03-10 Walmart Apollo, Llc Federated scheme for coordinating throttled network data transfer in a multi-host scenario
CN109905327B (zh) * 2017-12-11 2021-05-07 网宿科技股份有限公司 一种无线网络数据传输方法、发送端及接收端
JPWO2019244966A1 (ja) * 2018-06-22 2021-06-24 日本電気株式会社 通信装置、通信方法及びプログラム
CN109039932B (zh) * 2018-08-03 2022-07-15 网宿科技股份有限公司 服务器及其过载控制方法
US11599644B2 (en) 2019-05-17 2023-03-07 Walmart Apollo, Llc Blocking insecure code with locking
CN111935025B (zh) * 2020-07-08 2023-10-17 腾讯科技(深圳)有限公司 一种tcp传输性能的控制方法、装置、设备和介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009027303A (ja) * 2007-07-18 2009-02-05 Univ Of Electro-Communications 通信装置および通信方法
JP2009077036A (ja) * 2007-09-19 2009-04-09 Nec Corp 通信装置および通信方法
JP2009526494A (ja) * 2006-02-07 2009-07-16 アサンキア ネットワークス, インコーポレイテッド トランスポートプロトコルの性能を改善するシステムおよび方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4827652B2 (ja) * 2006-08-10 2011-11-30 富士通株式会社 中継装置、中継方法および中継プログラム
CN100553230C (zh) * 2007-05-21 2009-10-21 中南大学 一种用于高速网络中的协同工作式拥塞控制方法
CN101557607A (zh) * 2009-05-15 2009-10-14 东南大学 无线传感器网络中汇聚节点的传输控制方法
EP2479941B1 (en) 2009-09-16 2019-07-03 Hitachi, Ltd. Communication apparatus and communication system for enhancing speed of communications between terminals
CN101860895B (zh) * 2010-06-11 2012-12-19 上海海维工业控制有限公司 一种改进的aimd拥塞控制方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009526494A (ja) * 2006-02-07 2009-07-16 アサンキア ネットワークス, インコーポレイテッド トランスポートプロトコルの性能を改善するシステムおよび方法
JP2009027303A (ja) * 2007-07-18 2009-02-05 Univ Of Electro-Communications 通信装置および通信方法
JP2009077036A (ja) * 2007-09-19 2009-04-09 Nec Corp 通信装置および通信方法

Also Published As

Publication number Publication date
US9231829B2 (en) 2016-01-05
CN103858404B (zh) 2016-11-09
WO2013125096A1 (ja) 2013-08-29
CN103858404A (zh) 2014-06-11
US20140355442A1 (en) 2014-12-04
EP2819353A1 (en) 2014-12-31
EP2819353A4 (en) 2015-05-20
JPWO2013125096A1 (ja) 2015-07-30

Similar Documents

Publication Publication Date Title
JP5651805B2 (ja) 通信装置
JP5816718B2 (ja) 通信装置、通信システム、およびデータ通信の中継方法
JP5258938B2 (ja) 通信装置
JP5005003B2 (ja) トンネルのトランスポートチャネル上のデータストリームの送信を管理する方法、対応するトンネル終点及びコンピュータ読み取り可能な記憶媒体
US8843654B2 (en) Data packet transfer over wide area network in fast and reliable manner
JP4702151B2 (ja) ネットワーク中継装置およびネットワーク通信システム
JPWO2008023656A1 (ja) 通信装置
JP5264966B2 (ja) 通信装置
US20090316719A1 (en) Method for managing mechanisms to enhance transmission of data streams in a tunnel, corresponding computer program product, storage medium and tunnel end-point
JP4998687B2 (ja) 通信システム、トンネリング装置、通信方法、およびプログラム
CN104683259A (zh) Tcp拥塞控制方法及装置
JP5832335B2 (ja) 通信装置および通信システム
WO2015107806A1 (ja) 通信装置
JP4506430B2 (ja) アプリケーションモニタ装置
WO2015022809A1 (ja) 通信装置及び送信帯域制御方法
US20140369189A1 (en) Method of controlling packet transmission in network system and network system transmitting packet using pseudo-tcp agent
JP4853862B2 (ja) 通信装置
JP2014135575A (ja) 通信装置、及び、送信帯域の制御方法
KR101396785B1 (ko) 네트워크 장치에서 tcp 기능을 수행하는 방법

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20141021

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20141117

LAPS Cancellation because of no payment of annual fees