JP4632874B2 - 通信端末 - Google Patents
通信端末 Download PDFInfo
- Publication number
- JP4632874B2 JP4632874B2 JP2005183043A JP2005183043A JP4632874B2 JP 4632874 B2 JP4632874 B2 JP 4632874B2 JP 2005183043 A JP2005183043 A JP 2005183043A JP 2005183043 A JP2005183043 A JP 2005183043A JP 4632874 B2 JP4632874 B2 JP 4632874B2
- Authority
- JP
- Japan
- Prior art keywords
- congestion
- control parameter
- value
- congestion control
- ideal
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/11—Identifying congestion
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2416—Real-time traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
- H04L47/263—Rate modification at the source after receiving feedback
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
- H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Description
本発明は、通信システム、及び通信端末に関し、特に、送受信端末間の経路および通信状況に応じて送信レートの制御を可能とする通信システム及び通信端末に関する。
現在さまざまな種類のアプリケーションがネットワーク上で用いられており、それらのアプリケーション毎にネットワークに対して要求する品質が異なる。例えば、即時性が要求されるアプリケーションは、他のアプリケーションに比べて低い遅延時間、高い帯域、あるいは低いパケット廃棄確率が求められる。一方、即時性の要求されないアプリケーションは、即時性が要求されるアプリケーションに比べて、長い遅延時間、低い帯域、あついは高い廃棄が許容される。これら異なる特性のアプリケーションが混在する場合、ネットワークがこれらのアプリケーションを等しく扱うよりも、即時性を要求されるアプリケーションを優先して扱う方が望ましい。
ネットワーク内でアプリケーション毎の優先制御を実現する第１の技術としては、ネットワークによる優先制御が知られている。例えば、ディファレンシエイテッド・サービス(Differentiated Services)（非特許文献１参照）では、パケット毎に優先度を示す情報を付加することにより、即時性を要求するアプリケーションのパケットをネットワーク内で優先して伝送することが可能である。
ネットワーク内でアプリケーション毎の優先制御を実現する第２の技術としては、端末のトランスポート層制御による優先制御が知られている。すなわち、動作の異なる複数のトランスポート層制御方式をアプリケーションによって使い分けることにより、すなわち、即時性を要求するアプリケーションは貪欲に帯域を得ようとするトランスポート層制御を導入し、一方即時性を要求しないアプリケーションはネットワークが混雑していないときのみ帯域を得ようとするトランスポート層制御を導入することで、上記優先制御の実現が可能である。
現在トランスポート層の代表的なプロトコルとしてはTCP (Transmission Control Protocol)が挙げられる。一般的に、TCPではウインドサイズというパラメータを調節することにより送信レートを制御する。ウインドサイズは、送受信端末間の往復遅延時間(RTT; Round Trip Time)内に送信されるパケット量を表している。従ってTCPの送信レートは、ウインドサイズをRTTで割った値で求められる。RTTはパケットを送信してからそのパケットに対する確認応答として受信側から返信されるACKパケットを受信するまでの時間として計測され、一般的には、伝送路遅延、中継ノードでのキューイング遅延、及び受信端末での処理遅延が含まれる。
TCPには多くのバージョンがあり、その中で最も広く普及しているバージョンはTCP-Reno（非特許文献２参照）である。従って、TCP-Renoと異なる動作を行うトランスポート層制御方式を導入することにより、トランスポート層制御による優先制御の実現が可能である。
これらのトランスポート層制御としては、TCP-Renoを用いるTCPコネクションに対してスループットの低優先を実現するTCP-Nice（非特許文献３参照）やTCP-LP（非特許文献４参照）等が提案されている。これらの方式では、通常のTCPコネクションよりも輻輳の程度が軽い状態で輻輳とみなし送信レートを制御する。具体的には、パケットロスではなく、観測しているRTTが、ある値(閾値)を越えるまではウインドサイズを増加させ、観測しているRTTがある値を越えるとウインドサイズを半分、あるいは最小値まで減少させる。
S. Blake et al., "An Architecture for differentiated services", IETF RFC 2475, 1998）
W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms," RFC2001, Jan 1997）
A. Venkataramani, R. Kokku, and M. Dahlin. "TCP-Nice: A mechanism for background transfers", In OSDI02,2002
A. Kuzmanovic and E. Knightly, "TCP-LP: A Distributed Algorithm for Low Priority Data Transfer", in Proc. of IEEE INFOCOM 2003
従来の優先制御を実現する第１の技術の問題点は、導入コストが高い点である。ネットワーク内のノードに優先制御方式を実装しなければならないため、すでにネットワーク内に導入されているノードを優先制御方式対応のものに置き換える必要がある。
従来の優先制御を実現する第２の技術の、第１の問題点は、従来技術であるTCP-LP及びTCP-Niceでは、軽度の輻輳でも大幅にウインドサイズを減少させるため、帯域の有効活用ができない点である。
従来の優先制御を実現する第２の技術の、第２の問題点は、従来技術であるTCP-LP及びTCP-Niceでは、優先トラヒックが存在しない場合でも、軽度の輻輳でも大幅にウインドサイズを減少させるため、帯域の有効活用ができない点である。
従来の優先制御を実現する第２の技術の、第３の問題点は、従来技術であるTCP-LP及びTCP-Niceでは、輻輳以外の要因でパケット廃棄が発生する場合に帯域の有効活用ができない点である。
従来の優先制御を実現する第２の技術の、第４の問題点は、従来技術であるTCP-LP及びTCP-Niceでは、伝播遅延時間の長いTCPフローのスループットが低い点である。
本発明の第１の目的は、ネットワーク内のノードを置き換えることなく、低コストで優先制御方式を導入することである。
本発明の第２の目的は、即時性を要求するアプリケーションが存在する場合、これらのアプリケーションの品質を落とすことなく、残された帯域を効率よく利用できるトランスポート層制御方式を達成することである。
本発明の第３の目的は、即時性を要求するアプリケーションが存在しない場合、全てのリンク帯域を効率よく利用できるトランスポート層制御方式を達成することである。
本発明の第４の目的は、輻輳以外の要因でパケット廃棄が発生する場合でも、残された帯域を効率よく利用できるトランスポート層制御方式を達成することである。
本発明の第５の目的は、伝播遅延時間が長いTCPフローでも適切な帯域を使用できるトランスポート層制御方式を達成することである。
本発明による通信端末及び本発明による中継装置は、次のとおりである。
（１） ネットワークを介しデータの送信を行う通信端末において、
輻輳（congestion）を検出する輻輳検出手段と、理想的な輻輳制御パラメータと輻輳制御パラメータの現在値とをもとに前記輻輳の兆候を検出する兆候検出手段とを有し、前記輻輳検出手段が前記輻輳を検出するか、もしくは前記兆候検出手段が前記兆候を検出した際に、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する機能を有することを特徴とする通信端末。
輻輳（congestion）を検出する輻輳検出手段と、理想的な輻輳制御パラメータと輻輳制御パラメータの現在値とをもとに前記輻輳の兆候を検出する兆候検出手段とを有し、前記輻輳検出手段が前記輻輳を検出するか、もしくは前記兆候検出手段が前記兆候を検出した際に、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する機能を有することを特徴とする通信端末。
（２） ネットワークを介しデータの送信を行う通信端末において、
輻輳を検出する輻輳検出手段と、前記データとしてパケットを送信してからそのパケットに対する確認応答として受信端末側から返信される受信確認パケットを受信するまでのラウンド・トリップ・タイム(RTT)の現在の値を最大の値及び最小の値に比較することによって前記輻輳の兆候を検出する兆候検出手段とを有し、前記輻輳検出手段が前記輻輳を検出するか、もしくは前記兆候検出手段が前記兆候を検出した際に、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する機能を有することを特徴とする通信端末。
輻輳を検出する輻輳検出手段と、前記データとしてパケットを送信してからそのパケットに対する確認応答として受信端末側から返信される受信確認パケットを受信するまでのラウンド・トリップ・タイム(RTT)の現在の値を最大の値及び最小の値に比較することによって前記輻輳の兆候を検出する兆候検出手段とを有し、前記輻輳検出手段が前記輻輳を検出するか、もしくは前記兆候検出手段が前記兆候を検出した際に、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する機能を有することを特徴とする通信端末。
（３） ネットワークを介しデータの送信を行う通信端末において、
ネットワーク内のトラヒックに占める優先トラヒックの割合を推定する手段を有し、
前記割合によって送信レートもしくは輻輳制御パラメータを制御することを特徴とする通信端末。
ネットワーク内のトラヒックに占める優先トラヒックの割合を推定する手段を有し、
前記割合によって送信レートもしくは輻輳制御パラメータを制御することを特徴とする通信端末。
（４） ネットワークを介し受信端末へのデータの送信を行う中継装置において、
輻輳を検出する輻輳検出手段と、理想的な輻輳制御パラメータと輻輳制御パラメータの現在値とをもとに前記輻輳の兆候を検出する兆候検出手段とを有し、前記輻輳検出手段が前記輻輳を検出するか、もしくは前記兆候検出手段が前記兆候を検出した際に、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する機能を有することを特徴とする中継装置。
輻輳を検出する輻輳検出手段と、理想的な輻輳制御パラメータと輻輳制御パラメータの現在値とをもとに前記輻輳の兆候を検出する兆候検出手段とを有し、前記輻輳検出手段が前記輻輳を検出するか、もしくは前記兆候検出手段が前記兆候を検出した際に、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する機能を有することを特徴とする中継装置。
（５） ネットワークを介し受信端末へのデータの送信を行う中継装置において、
輻輳を検出する輻輳検出手段と、前記データとしてパケットを送信してからそのパケットに対する確認応答として受信端末側から返信される受信確認パケットを受信するまでのラウンド・トリップ・タイム(RTT)の現在の値を最大の値及び最小の値に比較することによって前記輻輳の兆候を検出する兆候検出手段とを有し、前記輻輳検出手段が前記輻輳を検出するか、もしくは前記兆候検出手段が前記兆候を検出した際に、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する機能を有することを特徴とする中継装置。
輻輳を検出する輻輳検出手段と、前記データとしてパケットを送信してからそのパケットに対する確認応答として受信端末側から返信される受信確認パケットを受信するまでのラウンド・トリップ・タイム(RTT)の現在の値を最大の値及び最小の値に比較することによって前記輻輳の兆候を検出する兆候検出手段とを有し、前記輻輳検出手段が前記輻輳を検出するか、もしくは前記兆候検出手段が前記兆候を検出した際に、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する機能を有することを特徴とする中継装置。
（６） ネットワークを介し受信端末へのデータの送信を行う中継装置において、
ネットワーク内のトラヒックに占める優先トラヒックの割合を推定する手段を有し、
前記割合によって送信レートもしくは輻輳制御パラメータの現在値を制御することを特徴とする中継装置。
ネットワーク内のトラヒックに占める優先トラヒックの割合を推定する手段を有し、
前記割合によって送信レートもしくは輻輳制御パラメータの現在値を制御することを特徴とする中継装置。
本発明によれば、以下に述べるような効果が達成される。
第１に、低優先での通信を必要としているTCP送信端末のみの変更で優先制御方式が導入可能である。そのため、ネットワーク内のノードを置き換えることなく、低コストで優先制御方式を導入可能である。
第２に、輻輳検出時のウインドサイズ変更幅を最適化することにより、即時性を要求するアプリケーションが存在する場合でもこれらのアプリケーションの品質を落とすことなく、残された帯域を効率よく利用することが可能である。
第３に、即時性を要求するアプリケーションによるトラヒックの割合を推定しこれに基づいて輻輳の検出を行うため、前記アプリケーションが存在しない場合には全てのリンク帯域を効率よく利用することが可能である。
第４に、パケット廃棄検出時のウインドサイズ変更幅を最適化することにより、残された帯域を効率よく利用することができる。
第５に、輻輳判定をネットワーク内にキューイングされていると推定されるパケット数で行うため、伝播遅延時間によるTCPフロー間の不公平性を改善することが可能である。
次に本発明の実施例について図面を参照して説明する。
＜第１の実施例＞
まず、本発明の第１の実施例について説明する。
まず、本発明の第１の実施例について説明する。
（構成の説明）
図１は第１の実施例による端末（通信端末）1のデータ送信制御部1-1の構成を示すブロック図である。データ送信制御部1-1は、パケット送信部1-2、パケット受信部1-3、輻輳ウインド決定部1-4、使用可能帯域設定部1-5、RTT計測部1-6、初期輻輳判定部1-7、初期輻輳閾値設定部1-8、優先トラヒック割合推定部1-9、輻輳判定部1-10、で構成される。
図１は第１の実施例による端末（通信端末）1のデータ送信制御部1-1の構成を示すブロック図である。データ送信制御部1-1は、パケット送信部1-2、パケット受信部1-3、輻輳ウインド決定部1-4、使用可能帯域設定部1-5、RTT計測部1-6、初期輻輳判定部1-7、初期輻輳閾値設定部1-8、優先トラヒック割合推定部1-9、輻輳判定部1-10、で構成される。
まず、本データ送信制御部における、低優先制御に関するブロック 1-A 以外のブロックに関して説明する。
通信端末1がデータパケットを受信端末（後に図示）に送信し、受信端末がデータパケットを受信し、受信確認パケット（ACKパケット）を通信端末1に送り返したものとする。
パケット受信部1-3は、受信端末から送り返されてくる受信確認パケット（ACKパケット）を受信する。
RTT計測部1-6は、パケット受信部1-3がACKパケットを受信した際、該ACKパケットに対応するデータパケットの送信時刻と、該ACKパケットの到着時刻を比較し、往復転送遅延時間 （RTT） を測定する。
使用可能帯域設定部1-5は、RTT計測部1-6で計測したRTT、及び輻輳ウインド決定部1-4から通知される現在の輻輳ウインドの値を元に、一つのセッションが使用可能な帯域を推定する。
輻輳判定部1-10は、パケット受信部1-3からの通知されるACK情報を元にパケット廃棄があったか否かを判定し、パケット廃棄があったと判定した際には輻輳が発生したと判定する。このように、輻輳判定部1-10は、輻輳を検出する輻輳検出手段として作用する。
輻輳ウインド決定部1-4は、該セッションに関わる輻輳ウインドの値を決定する。通常、輻輳が検知されない間は1RTTに相当する時間あたり1パケットに相当する量だけ輻輳ウインドを増加する。一方、輻輳判定部1-10あるいは初期輻輳判定部1-7から輻輳が通知された際は、使用可能帯域設定部1-5より通知される使用可能帯域に従って輻輳ウインド及びスロースタート閾値を再設定する。
パケット送信部1-2は、輻輳ウインド決定部1-4において決定された輻輳ウインドの値に従って、本端末1からのパケット出力を制御する。
次に、本データ送信制御部における、初期輻輳に関わるブロック1-A の説明を行う。
優先トラヒック割合推定部1-9は、RTT計測部1-6において計測されたRTTに関連する各種統計情報を元に、本送信端末が使用する経路上における優先トラヒックの割合を推定する。本推定は、輻輳判定部1-10もしくは初期輻輳判定部1-7において輻輳を検知する毎に更新される。優先トラヒック割合推定部1-9では、隣接する2回の輻輳検知の間での、キューイング遅延(RTTから最小RTTを引いたもの)の最小値と平均値をもって、優先トラヒック割合を推定する。
初期輳閾値設定部1-8は、優先トラヒック割合推定部1-9において推定された優先トラヒック割合を元に、初期輻輳閾値を設定する。
初期輻輳判定部1-7は、使用可能帯域設定部1-5から通知される使用可能帯域とRTT計測部1-6から通知されるRTTとを用いて計算される理想的な輻輳ウインドの値（理想的な輻輳制御パラメータ）と、輻輳ウインド決定部1-4から通知される現在の輻輳ウインドの値（輻輳制御パラメータの現在値）とを比較し、その差が初期輻輳閾値設定部1-8から通知される初期輻輳閾値以上であれば、初期輻輳（輻輳の兆候）であると判定する。このように、初期輻輳判定部1-7は、理想的な輻輳制御パラメータと輻輳制御パラメータの現在値とをもとに輻輳の兆候を検出する兆候検出手段として作用する。
本通信端末1は、前記輻輳検出手段（1-10）が輻輳を検出するか、もしくは前記兆候検出手段（1-7）が兆候を検出した際に、輻輳ウインド決定部1-4において、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは、パケット送信部1-2において、送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する機能を有する。
（動作の説明）
図２は、本実施例の動作を説明するフローチャートである。ここでは、図１及び図２を参照して、本実施例の動作について説明する。
図２は、本実施例の動作を説明するフローチャートである。ここでは、図１及び図２を参照して、本実施例の動作について説明する。
図２において、コネクションが開設されると、まず輻輳ウインドの初期値に従ってパケット送信部1-2がパケットを出力する。送信パケットに対する確認応答としてＡＣＫパケットが受信側から返信されると、パケット受信部1-3で受信を行う。
ＡＣＫパケットの受信を行うと、ＲＴＴ計測部1-6で、パケットを送信した時刻と、前述の送信パケットに対するＡＣＫパケットを受信した時刻を利用してＲＴＴを計測する。RTT計測部1-6ではまた、過去計測したRTTのうち最も小さいものを最小RTTとして記憶しておく。このとき、優先トラヒック割合推定部1-9では、隣接する２回の輻輳検知の間でのキューイング遅延の最小値と平均値を計測するため、前回の輻輳検知から現時点までの間での最小遅延の値と平均遅延の値を仮に計算しておく。
次に初期輻輳閾値設定部1-8において、優先トラヒック割合推定部1-9で推定した優先トラヒック割合を元に初期輻輳閾値を設定する。初期輻輳判定部1-7では、現在の輻輳ウインドの値と、使用可能帯域と最小RTTの積から計算される理想的な輻輳ウインドの値との差分を計算し、この差分が初期輻輳閾値以上になれば初期輻輳と判断する。一方、輻輳判定部1-10は同じ番号のACKが３回以上続けて到着すると網内でパケット廃棄が発生したと判断し、これを輻輳と判断する。
そして、輻輳ウインド決定部1-4では、初期輳判定部1-7あるいは輻輳判定部1-10において輻輳と判定されなければ、1RTTに相当する時間あたり1パケットに相当する量だけ増加する割合で、輻輳ウインドを増加させる。もし輻輳が検出されれば、以下で述べるように優先トラヒック割合の推定値を更新し、その後使用帯域と最小RTTの積から計算される理想的な輻輳ウインドの値へとスロースタート閾値を更新し、更新されたスロースタート閾値よりも現在の輻輳ウインドが大きければ輻輳ウインドをスロースタート閾値と同じ値に設定し、最後に輻輳の原因がパケットロスによるものであればパケットの再送処理に関連する処理を行う。
以上の、ACKパケット受信に関わる処理が全て終了すると、再びパケット送信部1-2におけるパケット出力処理へと戻る。もし、送信するデータが無く、コネクションの終了が指示されれば、コネクションの切断処理を行い全ての処理を終了する。
次に、優先トラヒック割合推定部1-9における優先トラヒック割合の推定に関して説明する。優先トラヒック割合推定部1-9では、輻輳判定部1-10もしくは初期輻輳判定部1-7において輻輳を検知する毎に優先トラヒック割合の推定値を更新する。その際、まず、前回の輻輳判定から今回の輻輳判定との間の、キューイング遅延の最小値と平均値を、これらの値の仮の値から求める。これらの値は、これらの値の時間平均を取ることで滑らかな値としてもよい。これらの値を更新したあとは、次回の値を求めるため、これらの値の仮の値を初期化しておく。最後に、以上で求めたキューイング遅延の最小値をその平均値で割ることで優先トラヒック割合を求める。なお、これらの遅延の値が非常に小さい場合は優先トラヒック割合の値の誤差が大きくなるため、優先トラヒック割合を求める際には平均遅延の値にある小さな固定値あるいはRTTから求められる小さな値を加えても良い。
（本実施例の効果）
以上のような送信レートの制御を行うことにより、優先トラヒックが存在する場合は、キューイング遅延の平均値及び最小値が共に大きくなり優先トラヒック割合は1へと近づき、その結果として初期輻輳閾値が非常に小さくなる。そのため、本方式を用いる低優先のトラヒックのスループットは抑えられ、優先トラヒックの品質への影響は最小限となる。
以上のような送信レートの制御を行うことにより、優先トラヒックが存在する場合は、キューイング遅延の平均値及び最小値が共に大きくなり優先トラヒック割合は1へと近づき、その結果として初期輻輳閾値が非常に小さくなる。そのため、本方式を用いる低優先のトラヒックのスループットは抑えられ、優先トラヒックの品質への影響は最小限となる。
一方、優先トラヒックが存在しない場合には、キューイング遅延の最小値が小さくなるため、優先トラヒック割合が小さくなり、その結果として初期輻輳閾値が大きくなりある定数で定められた初期値に近くなる。そのため、本方式を用いる低優先トラヒックが十分なスループットを得られるようになる。
また、優先トラヒックが存在するが、それでもなお空き帯域が存在する場合には、優先トラヒック割合が0と1の中間の値を取り、初期輻輳閾値は空き帯域量に比例した適切な値となる。そのため、本方式を用いる低優先トラヒックは、優先トラヒックに影響を与えることなく、優先トラヒックが余している帯域を効率よく使用することができる。
＜第２の実施例＞
次に、本発明の第２の実施例について説明する。
次に、本発明の第２の実施例について説明する。
（構成の説明）
第２の実施例の構成は、第１の実施例の構成と同一であり、優先トラヒック割合推定部の動作が若干異なるだけであるため、ここでブロック図を省略する。
第２の実施例の構成は、第１の実施例の構成と同一であり、優先トラヒック割合推定部の動作が若干異なるだけであるため、ここでブロック図を省略する。
本実施例では、優先トラヒック割合推定部は、隣接する２回の輻輳検知の間での、キューイング遅延(RTTから最小RTTを引いたもの)の最小値と最大値をもって、優先トラヒック割合を推定する。すなわち、第１の実施例と比較した場合、キューイング遅延の平均値ではなく最大値を用いる点のみが異なる。
（動作の説明）
図３は、本実施例の動作を説明するフローチャートである。ここでは、図３を参照して、第１の実施例の動作と本実施例の動作の相違点について説明する。
図３は、本実施例の動作を説明するフローチャートである。ここでは、図３を参照して、第１の実施例の動作と本実施例の動作の相違点について説明する。
まず、第１に、ACKパケットを受信しRTTを測定した際、第１の実施例では仮の値としてキューイング遅延の平均値を計算しているが、本実施例においては仮の値としてキューイング遅延の最大値を計算している。
第２に、輻輳が検出され優先トラヒック割合を更新する際、第１の実施例では最小遅延を平均遅延で割ることで優先トラヒック割合を求めているが、本実施例においては、最小遅延を最大遅延で割ることで優先トラヒック割合を求めている。
以上が、第１の実施例と本実施例の相違点であり、上記で述べた点以外ではこれらの実施例の間に相違点はない。
（本実施例の効果）
本実施例は、第１の実施例と比較して、優先トラヒック割合の推定アルゴリズムが若干異なるのみであり、ほぼ同様の効果が得られると期待できる。
本実施例は、第１の実施例と比較して、優先トラヒック割合の推定アルゴリズムが若干異なるのみであり、ほぼ同様の効果が得られると期待できる。
＜第３の実施例＞
次に、本発明の第３の実施例について説明する。
次に、本発明の第３の実施例について説明する。
（構成の説明）
図４は、第３の実施例による通信端末3のデータ送信制御部3-1の構成を示すブロック図である。データ送信制御部3-1は、パケット送信部3-2、パケット受信部3-3、輻輳ウインド決定部3-4、使用可能帯域設定部3-5、RTT計測部3-6、初期輻輳判定部3-7、初期輻輳閾値設定部3-8、RTT比較部3-9、輻輳判定部3-10、で構成される。
図４は、第３の実施例による通信端末3のデータ送信制御部3-1の構成を示すブロック図である。データ送信制御部3-1は、パケット送信部3-2、パケット受信部3-3、輻輳ウインド決定部3-4、使用可能帯域設定部3-5、RTT計測部3-6、初期輻輳判定部3-7、初期輻輳閾値設定部3-8、RTT比較部3-9、輻輳判定部3-10、で構成される。
本データ送信制御部における、低優先制御に関するブロック以外のブロックの構成は第１の実施例と同様であるため、ここでは説明を省略する。
次に、本データ送信制御部における、初期輻輳検出に関わるブロックの説明を行う。
RTT比較部3-9は、RTT計測部3-6において計測されたRTTと、その最大値及び最小値との相対値を求める。本推定は、輻輳判定部1-10もしくは初期輻輳判定部1-7において輻輳を検知する毎に更新されるのではなく、RTTを計測する毎に更新される。RTT比較部3-9では、現在のRTTと、現在までに計測された最小及び最大のRTTとを比較し、その結果を初期輻輳閾値設定部3-6に通知する。
初期輳閾値設定部3-6は、現在のRTTと、その最大値及び最小値との相対値から、初期輻輳閾値を設定する。すなわち、現在のRTTが最大値に近ければ初期輻輳閾値を小さく設定し、さもなければ初期輻輳閾値を大きく設定する。
初期輻輳判定部3-7は、使用可能帯域設定部1-5から通知される使用可能帯域とRTT計測部3-6から通知されるRTTとを用いて計算される理想的な輻輳ウインドの値と、輻輳ウインド決定部3-4から通知される現在の輻輳ウインドの値とを比較し、その差が初期輻輳閾値設定部3-6から通知される初期輻輳閾値以上であれば、初期輻輳であると判定する。
（動作の説明）
図５は、本実施例の動作を説明するフローチャートである。ここでは、図４及び図５を参照して、本実施例の動作について説明する。
図５は、本実施例の動作を説明するフローチャートである。ここでは、図４及び図５を参照して、本実施例の動作について説明する。
図５において、コネクションが開設されると、まず輻輳ウインドの初期値に従ってパケット送信部3-2がパケットを出力する。送信パケットに対する確認応答としてＡＣＫパケットが受信側から返信されると、パケット受信部3-3で受信を行う。
ＡＣＫパケットの受信を行うと、ＲＴＴ計測部3-6で、パケットを送信した時刻と、前述の送信パケットに対するＡＣＫパケットを受信した時刻を利用してＲＴＴを計測する。RTT計測部3-6ではまた、過去計測したRTTのうち最も小さいものを最小RTTとして記憶しておく。このとき、RTT比較部では、RTTの最大値を計測しており、もし今回計測したRTTが保存されている最大RTTよりも大きければ、最大RTTを今回計測したRTTへと更新する。
次に、RTT比較部3-9では、現在のRTTと、その最大値及び最小値との相対値を求める。そして、初期輻輳閾値設定部3-6では前記相対値に定数を乗じ、これを初期輻輳閾値とする。この時、現在のRTTが最大RTTと同じであれば初期輻輳閾値は0となり、逆に現在のRTTが最小RTTと同じであれば初期輻輳閾値は初期値である定数と同じ値になる。
初期輻輳判定部3-7では、現在の輻輳ウインドの値と、使用可能帯域と最小RTTの積から計算される理想的な輻輳ウインドの値との差分を計算し、この差分が初期輻輳閾値以上になれば初期輻輳と判断する。一方、輻輳判定部3-10は同じ番号のACKが３回以上続けて到着すると網内でパケット廃棄が発生したと判断し、これを輻輳と判断する。
そして、輻輳ウインド決定部3-4では、初期輻輳判定部3-7あるいは輻輳判定部3-10において輻輳と判定されなければ、1RTTに相当する時間あたり1パケットに相当する量だけ増加する割合で、輻輳ウインドを増加させる。もし輻輳が検出されれば、以下で述べるように優先トラヒック割合の推定値を更新し、その後使用帯域と最小RTTの積から計算される理想的な輻輳ウインドの値へとスロースタート閾値を更新し、更新されたスロースタート閾値よりも現在の輻輳ウインドが大きければ輻輳ウインドをスロースタート閾値と同じ値に設定し、最後に輻輳の原因がパケット廃棄によるものであればパケットの再送処理に関連する処理を行う。
本実施例においては、輻輳の原因がパケット廃棄によるものであれば、輻輳を検出した時点のRTTを最大RTTとして設定する。なお、もし現在のRTTの値が予め定めた最小値よりも小さい場合は、この最小値を最大RTTとして用いる。また、最大RTTを更新する際、過去の値を参照して平均をとることにより、最大RTTの変化を滑らかにしても良い。
以上の、ACKパケット受信に関わる処理が全て終了すると、再びパケット送信部3-2におけるパケット出力処理へと戻る。もし、送信するデータが無く、コネクションの終了が指示されれば、コネクションの切断処理を行い全ての処理を終了する。
（本実施例の効果）
本実施例は、第１の実施例と比較して、優先トラヒック割合ではなく、計測したRTTを元に初期輻輳判定の閾値を設定している。計測したRTTは優先トラヒック割合に比べて、忠実に網の輻輳を反映するが、一方低優先トラヒックしか存在しない場合でも初期輻輳を検出してしまう。そのため、本実施例の効果は、第１の実施例と比較して、低優先トラヒックが網に与える影響が小さい反面、低優先トラヒックによる帯域の利用効率に劣ると推定できる。
本実施例は、第１の実施例と比較して、優先トラヒック割合ではなく、計測したRTTを元に初期輻輳判定の閾値を設定している。計測したRTTは優先トラヒック割合に比べて、忠実に網の輻輳を反映するが、一方低優先トラヒックしか存在しない場合でも初期輻輳を検出してしまう。そのため、本実施例の効果は、第１の実施例と比較して、低優先トラヒックが網に与える影響が小さい反面、低優先トラヒックによる帯域の利用効率に劣ると推定できる。
＜第４の実施例＞
次に、本発明の第４の実施例について説明する。
次に、本発明の第４の実施例について説明する。
（構成の説明）
図６は、第４の本実施例による通信端末4のデータ送信制御部4-1の構成を示すブロック図である。データ送信制御部4-1は、パケット送信部4-2、パケット受信部4-3、輻輳ウインド決定部4-4、使用可能帯域設定部4-5、RTT計測部4-6、初期輻輳判定部4-7、初期輻輳閾値設定部4-8、優先トラヒック割合推定部4-9、輻輳判定部4-10、RTT比較部4-11、で構成される。すなわち、本実施例の構成は、第１の実施例の構成にRTT比較部4-11を加えた構成であり、第１の実施例と第３の実施例の構成を足したものである。
図６は、第４の本実施例による通信端末4のデータ送信制御部4-1の構成を示すブロック図である。データ送信制御部4-1は、パケット送信部4-2、パケット受信部4-3、輻輳ウインド決定部4-4、使用可能帯域設定部4-5、RTT計測部4-6、初期輻輳判定部4-7、初期輻輳閾値設定部4-8、優先トラヒック割合推定部4-9、輻輳判定部4-10、RTT比較部4-11、で構成される。すなわち、本実施例の構成は、第１の実施例の構成にRTT比較部4-11を加えた構成であり、第１の実施例と第３の実施例の構成を足したものである。
（動作の説明）
図７は、本実施例の動作を説明するフローチャートである。本実施例は、第１の実施例と第３の実施例の構成を足したものであり、本実施例の動作も第１の実施例の動作及び第３の実施例の動作に準じる。
図７は、本実施例の動作を説明するフローチャートである。本実施例は、第１の実施例と第３の実施例の構成を足したものであり、本実施例の動作も第１の実施例の動作及び第３の実施例の動作に準じる。
すなわち、本実施例では、第１の実施例と同様の動作にて優先トラヒック割合の推定を行い、また同時に第３の実施例と同様の動作にて現在のRTTとその最大値及び最小値との相対値を求め、これらの積によって初期輻輳閾値設定部4-8において初期輻輳閾値を定める。
（本実施例の効果）
本実施例は、第１の実施例と第３の実施例を合成したものであり、その効果は第１の実施例の効果と第３の実施例の効果との中間であると推定できる。
本実施例は、第１の実施例と第３の実施例を合成したものであり、その効果は第１の実施例の効果と第３の実施例の効果との中間であると推定できる。
＜第５の実施例＞
次に、本発明の第５の実施例について説明する。
次に、本発明の第５の実施例について説明する。
（構成の説明）
図８は、第５の本実施例による通信端末5のデータ送信制御部5-1の構成を示すブロック図である。データ送信制御部5-1は、パケット送信部5-2、パケット受信部5-3、輻輳ウインド決定部5-4、使用可能帯域設定部5-5、RTT計測部5-6、初期輻輳判定部5-7、初期輻輳閾値設定部5-8、ECN付パケット割合測定部5-9、輻輳判定部5-10、で構成される。
図８は、第５の本実施例による通信端末5のデータ送信制御部5-1の構成を示すブロック図である。データ送信制御部5-1は、パケット送信部5-2、パケット受信部5-3、輻輳ウインド決定部5-4、使用可能帯域設定部5-5、RTT計測部5-6、初期輻輳判定部5-7、初期輻輳閾値設定部5-8、ECN付パケット割合測定部5-9、輻輳判定部5-10、で構成される。
本データ送信制御部の構成は、第１の実施例から優先トラヒック割合推定部を取り除き、代わりにECN付パケット割合推定部を追加した構成である。
ECN付パケット割合測定部5-9は、パケット受信部5-3で受信したパケットのヘッダを検査し、該パケットのヘッダ部にECN（明示的輻輳通知）が含まれているか否かを検査する。そして全受信パケットに占めるECN付パケットの割合を求め、これを初期輻輳閾値設定部5-6に通知する。
（動作の説明）
図９は、本実施例の動作を説明するフローチャートである。ここでは、図８及び図９を参照して、本実施例の動作について説明する。
図９は、本実施例の動作を説明するフローチャートである。ここでは、図８及び図９を参照して、本実施例の動作について説明する。
図８において、コネクションが開設されると、まず輻輳ウインドの初期値に従ってパケット送信部5-2がパケットを出力する。送信パケットに対する確認応答としてＡＣＫパケットが受信側から返信されると、パケット受信部5-3で受信を行う。
ＡＣＫパケットの受信を行うと、ＲＴＴ計測部5-6で、パケットを送信した時刻と、前述の送信パケットに対するＡＣＫパケットを受信した時刻を利用してＲＴＴを計測する。RTT計測部5-6ではまた、過去計測したRTTのうち最も小さいものを最小RTTとして記憶しておく。このとき、RTT比較部では、RTTの最大値を計測しており、もし今回計測したRTTが保存されている最大RTTよりも大きければ、最大RTTを今回計測したRTTへと更新する。
次に、ECN付パケット割合測定部5-9において、全受信パケットに占めるECN付パケットの割合を求める。そして、初期輻輳閾値設定部5-6では前記割合に応じて初期輻輳閾値を設定する。ここでは、全てのパケットにECN表示がなければ定数1を初期輻輳閾値として設定し、ECN表示のあるパケットの割合が増えるに従って初期輻輳閾値は小さくなり、ECN表示のあるパケットの割合が一定数以上になれば初期輻輳閾値は0に固定される。
以降の動作は第１の実施例と同様であるため、ここでは説明を省略する。
（本実施例の効果）
本実施例は、ECN付パケットの割合は網の輻輳度を反映したものであるため、本実施例の効果は第３の実施例の効果に準ずるものであると推定できる。ただし、ECNは各パケットにつき輻輳しているかいないかの2値判定であるため、RTTを用いて輻輳を検出する場合に比べて、精度に劣ると考えられる。しかしながら、無線網など伝播遅延時間が頻繁に変化し、RTTを輻輳の指標として用いることのできない網においては、本方式が有利である。
本実施例は、ECN付パケットの割合は網の輻輳度を反映したものであるため、本実施例の効果は第３の実施例の効果に準ずるものであると推定できる。ただし、ECNは各パケットにつき輻輳しているかいないかの2値判定であるため、RTTを用いて輻輳を検出する場合に比べて、精度に劣ると考えられる。しかしながら、無線網など伝播遅延時間が頻繁に変化し、RTTを輻輳の指標として用いることのできない網においては、本方式が有利である。
＜第６の実施例＞
次に、本発明の第６の実施例について説明する。
次に、本発明の第６の実施例について説明する。
（構成の説明）
図１０は本実施例による通信端末6のデータ送信制御部6-1の構成を示すブロック図である。データ送信制御部6-1は、パケット送信部6-2、パケット受信部6-3、輻輳ウインド決定部6-4、使用可能帯域設定部6-5、RTT計測部6-6、初期輻輳判定部6-7、初期輻輳閾値設定部6-8、優先トラヒック割合推定部6-9、輻輳判定部6-10、で構成される。
図１０は本実施例による通信端末6のデータ送信制御部6-1の構成を示すブロック図である。データ送信制御部6-1は、パケット送信部6-2、パケット受信部6-3、輻輳ウインド決定部6-4、使用可能帯域設定部6-5、RTT計測部6-6、初期輻輳判定部6-7、初期輻輳閾値設定部6-8、優先トラヒック割合推定部6-9、輻輳判定部6-10、で構成される。
本データ送信制御部の構成は、第１の実施例に対して初期輻輳判定部6-7及び初期輳閾値設定部6-8の動作が異なる構成である。
初期輻輳閾値設定部6-9では、RTT計測部6-6から受け取ったRTT情報を元に最小RTT及び最大RTTを管理している。そして、優先トラヒック割合推定部6-9から受け取った優先トラヒック割合を元に、最小RTTと最大RTTの間に閾値を設定し、これを初期輻輳判定部6-7に通知する。
初期輻輳判定部6-7では、RTT計測部6-6から受け取った現在のRTTと、初期輻輳閾値設定部6-8から受け取った閾値とを比較し、その結果を輻輳ウインド決定部6-4及び優先トラヒック割合推定部6-9へと通知する。
（動作の説明）
図１１は、本実施例の動作を説明するフローチャートである。ここでは、図１０及び図１１を参照して、本実施例の動作について説明する。
図１１は、本実施例の動作を説明するフローチャートである。ここでは、図１０及び図１１を参照して、本実施例の動作について説明する。
図１０において、コネクションが開設されると、まず輻輳ウインドの初期値に従ってパケット送信部6-2がパケットを出力する。送信パケットに対する確認応答としてＡＣＫパケットが受信側から返信されると、パケット受信部6-3で受信を行う。
ＡＣＫパケットの受信を行うと、ＲＴＴ計測部6-6で、パケットを送信した時刻と、前述の送信パケットに対するＡＣＫパケットを受信した時刻を利用してＲＴＴを計測する。RTT計測部6-6ではまた、過去計測したRTTのうち最も小さいものを最小RTTとして記憶しておく。このとき、優先トラヒック割合推定部6-9では、隣接する２回の輻輳検知の間でのキューイング遅延の最小値と平均値を計測するため、前回の輻輳検知から現時点までの間での最小遅延の値と平均遅延の値を仮に計算しておく。
次に、初期輻輳閾値設定部6-8において、優先トラヒック割合推定部6-9で推定した優先トラヒック割合を元に初期輻輳閾値を設定する。ここでは、まず、もし現在記憶している最大RTTよりも現在のRTTが大きければ、最大RTTを現在のRTTへと更新する。そして、(RTT-最小RTT)/(最大RTT-最小RTT)、すなわち網内での最大のキューイング遅延に対する現在のキューイング遅延の割合に対して、非優先トラヒックの割合(すわわち、1-優先トラヒック割合)を乗じ、さらに定数を乗じて、これを初期輻輳閾値として設定する。初期輻輳判定部6-7では、現在のキューイング遅延(すなわち、RTT-最小RTT)と、前記で求めた初期輻輳閾値を比較し、前者の方が大きければ初期輻輳と判断する。一方、輻輳判定部6-10は同じ番号のACKが３回以上続けて到着すると網内でパケット廃棄が発生したと判断し、これを輻輳と判断する。
そして、輻輳ウインド決定部6-4では、初期輳判定部6-7あるいは輻輳判定部6-10において輻輳と判定されなければ、1RTTに相当する時間あたり1パケットに相当する量だけ増加する割合で、輻輳ウインドを増加させる。もし輻輳が検出されれば、優先トラヒック割合の推定値を更新し、その後使用帯域と最小RTTの積から計算される理想的な輻輳ウインドの値へとスロースタート閾値を更新し、更新されたスロースタート閾値よりも現在の輻輳ウインドが大きければ輻輳ウインドをスロースタート閾値と同じ値に設定し、最後に輻輳の原因がパケット廃棄によるものであればパケットの再送処理に関連する処理を行う。
本実施例においては、輻輳の原因がパケット廃棄によるものであれば、輻輳を検出した時点のRTTを最大RTTとして設定する。なお、もし現在のRTTの値が予め定めた最小値よりも小さい場合は、この最小値を最大RTTとして用いる。また、最大RTTを更新する際、過去の値を参照して平均をとることにより、最大RTTの変化を滑らかにしても良い。
以上の、ACKパケット受信に関わる処理が全て終了すると、再びパケット送信部6-2におけるパケット出力処理へと戻る。もし、送信するデータが無く、コネクションの終了が指示されれば、コネクションの切断処理を行い全ての処理を終了する。
優先トラヒック割合推定部6-9における優先トラヒック割合の推定動作は第１の実施例と同様であるため、ここではその説明は省略する。
（本実施例の効果）
第１から第５の実施例においては、理想的な輻輳ウインドと現在の輻輳ウインドの比較を行うことによって初期輻輳を判定しているが、本実施例においては測定したRTTを用いて輻輳の判定を行っている。前者では網の負荷が高い場合でも自らのトラヒックが少ない場合(輻輳ウインドが小さい場合)には初期輻輳を判定しないが、後者では自らのトラヒックに関係なく網の状態のみで初期輻輳を判定している。そのため、本実施例では、前記実施例に比べて、低優先セッション間の公平性は劣るが、高負荷時に網に与える影響が小さい特性を持つと推定できる。
第１から第５の実施例においては、理想的な輻輳ウインドと現在の輻輳ウインドの比較を行うことによって初期輻輳を判定しているが、本実施例においては測定したRTTを用いて輻輳の判定を行っている。前者では網の負荷が高い場合でも自らのトラヒックが少ない場合(輻輳ウインドが小さい場合)には初期輻輳を判定しないが、後者では自らのトラヒックに関係なく網の状態のみで初期輻輳を判定している。そのため、本実施例では、前記実施例に比べて、低優先セッション間の公平性は劣るが、高負荷時に網に与える影響が小さい特性を持つと推定できる。
＜第７の実施例＞
次に、本発明の第７の実施例について説明する。
次に、本発明の第７の実施例について説明する。
（構成の説明）
第７の実施例の構成は、第１の実施例の構成と同一であり、使用可能帯域測定部の動作が若干異なるだけであるため、ここでブロック図を省略する。
第７の実施例の構成は、第１の実施例の構成と同一であり、使用可能帯域測定部の動作が若干異なるだけであるため、ここでブロック図を省略する。
本実施例では、使用可能帯域設定部は、優先トラヒック割合推定部で求められる最小遅延を反映して使用可能帯域を設定する点が異なる。
（動作の説明）
図１２は、本実施例の動作を説明するフローチャートである。ここでは、図１２を参照して、本実施例の動作について説明する。
図１２は、本実施例の動作を説明するフローチャートである。ここでは、図１２を参照して、本実施例の動作について説明する。
本実施例の動作は、第１の実施例の動作と比べて、RTT計測後の使用可能帯域の推定動作が異なるのみであり、ここでは使用可能帯域の推定動作についてのみ説明する。本実施例では、定常的に網内にキューイングされているパケットを取り除くため、使用可能帯域を他の実施例に比べて低く設定する。すなわち、定常的に網内にキューイングされているパケット量は優先トラヒック割合推定部から得られる最小遅延に比例しているとし、最小遅延が最小になるよう使用可能帯域を設定する。
ここで、“輻輳ウインド/RTT”は当該セッションの使用帯域であり、これに最小遅延を乗じたものが網内でキューイングされているパケットのうち該セッションに属するものであると推定できる。これらのパケットを取り除くように使用可能帯域を設定するためには、輻輳ウインドの値を理想的な値からこれらのパケット分、すなわち”(輻輳ウインド/RTT) x 最小遅延“を差し引きする必要があり、従って使用可能帯域としては、”(輻輳ウインド/RTT) x 最小遅延 / 最小RTT“を差し引きする必要がある。結果として、使用可能帯域は図１２に示される式を用いて求めることができる。
（本実施例の効果）
本実施例は、第１の実施例と比較して、使用可能帯域が小さく設定される特長を持つ。そのため、本実施例の効果は、第１の実施例と比較して、低優先トラヒックが網に与える影響が小さい反面、低優先トラヒックによる帯域の利用効率に劣ると推定できる。
本実施例は、第１の実施例と比較して、使用可能帯域が小さく設定される特長を持つ。そのため、本実施例の効果は、第１の実施例と比較して、低優先トラヒックが網に与える影響が小さい反面、低優先トラヒックによる帯域の利用効率に劣ると推定できる。
＜第８の実施例＞
次に、本発明の第８の実施例について説明する。
次に、本発明の第８の実施例について説明する。
（構成の説明）
図１３は、第８の実施例による通信端末8のデータ送信制御部8-1の構成を示すブロック図である。データ送信制御部8-1は、パケット送信部8-2、パケット受信部8-3、輻輳ウインド決定部8-4、使用可能帯域設定部8-5、RTT計測部8-6、初期輻輳判定部8-7、初期輻輳閾値設定部8-8、優先トラヒック割合推定部8-9、輻輳判定部8-10、RTT比較部8-11で構成される。
図１３は、第８の実施例による通信端末8のデータ送信制御部8-1の構成を示すブロック図である。データ送信制御部8-1は、パケット送信部8-2、パケット受信部8-3、輻輳ウインド決定部8-4、使用可能帯域設定部8-5、RTT計測部8-6、初期輻輳判定部8-7、初期輻輳閾値設定部8-8、優先トラヒック割合推定部8-9、輻輳判定部8-10、RTT比較部8-11で構成される。
RTT比較部8-11では、最小RTTと最大RTTの間に設定される閾値と現在のRTTを比べることにより、輻輳判定部8-10及び初期輻輳判定部8-7に加えて、第３の輻輳判断を行う。
輻輳ウインド決定部は、輻輳判定部8-10及び初期輻輳判定部8-7に加え、RTT比較部8-11からの輻輳情報も加味して輻輳ウインドの更新を行う。
他の構成要素に関しては第１の実施例と同様であるため、ここでは説明を省略する。
（動作の説明）
図１４は、本実施例の動作を説明するフローチャートである。ここでは、図１３及び図１４を参照して、本実施例の動作について説明する。
図１４は、本実施例の動作を説明するフローチャートである。ここでは、図１３及び図１４を参照して、本実施例の動作について説明する。
本実施例の動作は、第１の実施例の動作と比べて、以下の動作を加えたものである。
まず、本実施例ではRTTに基づく輻輳判断が加わる。ACKパケット受信時及び輻輳ウインド更新時には、第３の実施例におけるRTT比較部3-9と同様の動作によって、最大RTTを更新する。そして、ACKパケット受信時にはさらに、最大RTTと最小RTTの間に閾値を設定し、この閾値よりも現在のRTTが大きければ輻輳と判断する。
次に、本実施例では輻輳時の動作が以下のように変更される。本実施例においても、初期輻輳を判定した場合、もしくはパケット廃棄による輻輳を判定した場合には、使用可能帯域を用いて輻輳ウインドの更新を行う。一方、前記のようにRTTによって輻輳を検出した場合には、使用可能帯域を使用せず、輻輳ウインドを一律に減少させる。
本実施例では、RTTによる輻輳判断単独で輻輳ウインドの更新を行うが、本実施例の別の構成として、RTTによる輻輳判断と他の輻輳判断が同時に行われたときのみ輻輳ウインドの一律減少を行う構成も考えられる。
（本実施例の効果）
本実施例は、第１の実施例と比較して、RTTに基づく輻輳判断と輻輳ウインドの更新動作が加わる。RTTに基づく輻輳判断では、優先トラヒックの割合に関わり無く、網の輻輳度すなわちRTTに基づいて輻輳を判断する。そのため、本実施例の効果は、第１の実施例と比較して、低優先トラヒックが網に与える影響が小さい反面、低優先トラヒックによる帯域の利用効率に劣ると推定できる。
本実施例は、第１の実施例と比較して、RTTに基づく輻輳判断と輻輳ウインドの更新動作が加わる。RTTに基づく輻輳判断では、優先トラヒックの割合に関わり無く、網の輻輳度すなわちRTTに基づいて輻輳を判断する。そのため、本実施例の効果は、第１の実施例と比較して、低優先トラヒックが網に与える影響が小さい反面、低優先トラヒックによる帯域の利用効率に劣ると推定できる。
＜第９の実施例＞
次に、本発明の第９の実施例について説明する。
次に、本発明の第９の実施例について説明する。
（構成の説明）
図１５は、第９の実施例による通信端末9のデータ送信制御部9-1の構成を示すブロック図である。データ送信制御部9-1は、パケット送信部9-2、パケット受信部9-3、輻輳ウインド決定部9-4、使用可能帯域設定部9-5、RTT計測部9-6、初期輻輳判定部9-7、初期輻輳閾値設定部9-8、優先トラヒック割合推定部9-9、輻輳判定部9-10で構成される。
図１５は、第９の実施例による通信端末9のデータ送信制御部9-1の構成を示すブロック図である。データ送信制御部9-1は、パケット送信部9-2、パケット受信部9-3、輻輳ウインド決定部9-4、使用可能帯域設定部9-5、RTT計測部9-6、初期輻輳判定部9-7、初期輻輳閾値設定部9-8、優先トラヒック割合推定部9-9、輻輳判定部9-10で構成される。
本実施例では、初期輻輳判定部9-7は2段階の初期輻輳の判定を行い、輻輳ウインド決定部9-4に対して2段階の初期輻輳を通知する。
輻輳ウインド決定部9-4では、初期輻輳判定部9-7から2段階の初期輻輳の判定を受け取る。重度の初期輻輳の場合には、第１の実施例と同様の輻輳ウインドの更新動作を行う。一方、軽度の輻輳の場合には、輻輳ウインドの更新動作は行わず、単に輻輳ウインドの増加が抑制されるのみである。
他の構成要素に関しては第１の実施例と同様であるため、ここでは説明を省略する。
（動作の説明）
図１６は、本実施例の動作を説明するフローチャートである。ここでは、図１５及び図１６を参照して、本実施例の動作について説明する。
図１６は、本実施例の動作を説明するフローチャートである。ここでは、図１５及び図１６を参照して、本実施例の動作について説明する。
本実施例の動作は、第１の実施例の動作と比べて、以下の動作を加えたものである。
第１の実施例では、ACKパケット到着時、初期輻輳及びパケット廃棄による輻輳のいずれも判定されない場合には、輻輳ウインドの増加処理を行う。本実施例においては、この際、初期輻輳検出部において、軽度の初期輻輳のあるなし判定する。具体的には、使用可能帯域から計算された理想的な輻輳ウインドサイズと現在の輻輳ウインドサイズとの差が、初期輻輳閾値とある定数の積以上であれば軽度の初期輻輳であると判定する。ここである定数とは0より大きく1より小さい定数である。そして、軽度の初期輻輳であると判定された場合には、輻輳ウインドの増加処理を行わない。
（本実施例の効果）
本実施例は、第１の実施例と比較して、軽度の初期輻輳が検出された場合には輻輳ウインドの増加を停止する処理が加えられている。そのため、本実施例の効果は、第１の実施例と比較して、低優先トラヒックが網に与える影響が小さい反面、低優先トラヒックによる帯域の利用効率に劣ると推定できる。
本実施例は、第１の実施例と比較して、軽度の初期輻輳が検出された場合には輻輳ウインドの増加を停止する処理が加えられている。そのため、本実施例の効果は、第１の実施例と比較して、低優先トラヒックが網に与える影響が小さい反面、低優先トラヒックによる帯域の利用効率に劣ると推定できる。
＜第１０の実施例＞
次に、本発明の第１０の実施例について説明する。
次に、本発明の第１０の実施例について説明する。
（構成の説明）
図１７は、第１０の実施例による通信端末10のデータ送信制御部10-1の構成を示すブロック図である。データ送信制御部10-1は、パケット送信部10-2、パケット受信部10-3、輻輳ウインド決定部10-4、使用可能帯域設定部10-5、RTT推定部10-6、初期輻輳判定部10-7、初期輻輳閾値設定部10-8、優先トラヒック割合推定部10-9、輻輳判定部10-10、使用帯域測定部10-11で構成される。
図１７は、第１０の実施例による通信端末10のデータ送信制御部10-1の構成を示すブロック図である。データ送信制御部10-1は、パケット送信部10-2、パケット受信部10-3、輻輳ウインド決定部10-4、使用可能帯域設定部10-5、RTT推定部10-6、初期輻輳判定部10-7、初期輻輳閾値設定部10-8、優先トラヒック割合推定部10-9、輻輳判定部10-10、使用帯域測定部10-11で構成される。
本実施例では、RTT計測部を持つ代わりに、使用帯域測定部10-11及びRTT推定部10-6を持つ。
使用帯域測定部10-11では、パケット受信部10-3から受け取ったACKから計算される応答確認バイト数及び過去計測した応答確認バイト数、そしてそれらの受信時刻を元に現在送信に使用している帯域を計測する。
RTT推定部10-6では、使用帯域測定部10-11で測定された送信帯域を元に現在のRTTの値を推定する。
他の構成要素に関しては第１の実施例と同様であるため、ここでは説明を省略する。
（動作の説明）
図１８は、本実施例の動作を説明するフローチャートである。ここでは、図１７及び図１８を参照して、本実施例の動作について説明する。
図１８は、本実施例の動作を説明するフローチャートである。ここでは、図１７及び図１８を参照して、本実施例の動作について説明する。
本実施例の動作は、第１の実施例の動作と比べて、以下の動作が異なる。
第１の実施例においては、ＡＣＫパケットの受信を行うと、ＲＴＴ計測部で、パケットを送信した時刻と、前述の送信パケットに対するＡＣＫパケットを受信した時刻を利用してＲＴＴを計測する。一方、本実施例においては、ACKパケットの受信を行うと、パケット受信部10-3から受け取ったACKから計算される応答確認バイト数及び過去計測した応答確認バイト数、そしてそれらの受信時刻を元に現在送信に使用している帯域を計測する。例えば、単位時間内に受信した応答確認バイト数を単位時間で割ったものを使用帯域として計測することができる。そして、使用可能帯域を元に現在のRTTを推定する。例えば、現在の輻輳ウインドの値を使用帯域で割ったものをRTTの推定値として利用することができる。
上記以外の動作は第１の実施例と同様であり、第１の実施例では計測したRTTを用いるが、本実施例では上記で推定したRTTを用いる点のみが異なる。
本実施例で用いたRTTの推定方式は、第１の実施例だけではなく、他の実施例においても適用可能である。
（本実施例の効果）
本実施例は本質的に第１の実施例と同様であり、第１の実施例と同様の効果が得られると考えられる。ただし、本実施例ではRTTを測定ではなく推定しているため、無線網のようにRTTが輻輳を反映していない網でも適用が可能である。
本実施例は本質的に第１の実施例と同様であり、第１の実施例と同様の効果が得られると考えられる。ただし、本実施例ではRTTを測定ではなく推定しているため、無線網のようにRTTが輻輳を反映していない網でも適用が可能である。
＜第１１の実施例＞
次に、本発明の第１１の実施例について説明する。
次に、本発明の第１１の実施例について説明する。
（構成の説明）
図１９は、第１１の実施例による中継装置11を用いた通信システムの構成を示すブロック図である。本通信システムは、送信端末12、受信端末13、及びこれらの端末間の通信を中継する中継装置11、で構成される。本実施例においては、送信端末12から受信端末13へと直接TCP通信を用いて送信データを送信するのではなく、送信端末12から中継装置11へのTCP通信と中継装置11から受信端末13へのTCP通信との2つのTCP通信を用い、中継装置11でこれらのTCP通信間の中継処理を経て通信を行なう。
図１９は、第１１の実施例による中継装置11を用いた通信システムの構成を示すブロック図である。本通信システムは、送信端末12、受信端末13、及びこれらの端末間の通信を中継する中継装置11、で構成される。本実施例においては、送信端末12から受信端末13へと直接TCP通信を用いて送信データを送信するのではなく、送信端末12から中継装置11へのTCP通信と中継装置11から受信端末13へのTCP通信との2つのTCP通信を用い、中継装置11でこれらのTCP通信間の中継処理を経て通信を行なう。
送信端末12はデータ送信制御部12-1を有し、受信端末13はデータ受信制御部13-1を有し、中継装置11は、データ送信制御部11-1及びデータ受信制御部11-12を有する。
本実施例においては、送信端末12内のデータ送信制御部12-1は本発明による構成ではなく、従来のTCP送信制御部と同様の構成である。一方、中継装置11内のデータ送信制御部11-1は本発明による構成であり、第１の実施例（図１の端末1）と同様の構成である。
中継装置11内のデータ受信制御部11-12及び受信端末13のデータ受信制御部13-1は、共に、従来のTCPデータ受信制御部と同様の構成である。
（動作の説明）
以下では、送信端末12から受信端末13へ向けたデータ転送の動作について説明する。
以下では、送信端末12から受信端末13へ向けたデータ転送の動作について説明する。
送信端末12内のデータ送信制御部12-1から送信されたTCPのデータパケット（図中太線で表示）は、受信端末13のデータ受信制御部13-1ではなく、中継装置11内のデータ受信制御部11-12が受信する。そして、これに応答して、中継装置11内のデータ受信制御部11-12から送信端末12内のデータ送信制御部12-1へと、データ受信の確認応答としてACKパケットを送信する（図中細線で表示）。データ送信制御部12-1及びデータ受信制御部11-12は、それぞれ、従来のTCP送信制御部及び従来のTCP受信制御部と同様の動作を行ない、これらの間のデータ通信は従来のTCP方式で通信が行なわれる。
中継装置11が受信したデータパケットは、データ受信制御部11-12においてもとの送信データへと再構成される。そしてこの再構成されたデータは、データ送信制御部11-1へと送られ、ここから再びTCP通信を用いて受信端末13へと送られる。
中継装置11内のデータ送信制御部11-1は、再構成された送信データからTCPパケットを作成して送信し、これを受信端末13のデータ受信制御部13-1が受信する。そして、これに応答して、受信端末13内のデータ受信制御部から中継装置11内のデータ送信制御部11-1へと、データ受信の確認応答としてACKパケットを送信する。データ送信制御部11-1は、従来のTCPと同様動作ではなく、本発明による第１の実施例（図１の端末1）と同様の動作を行なうため、これらの間のデータ通信は従来のTCP方式ではなく、低優先なTCP方式で通信が行なわれる。
（本実施例の効果）
本実施例では、送信端末12と中継装置11との間は従来のTCP方式で通信を行ない、中継装置11と受信端末13との間は低優先なTCP方式で通信を行なう。送信端末12と中継装置11との間の回線は輻輳しておらず、中継装置11と受信端末13との間の回線が輻輳している場合、本実施例では輻輳している回線で低優先TCP方式を用いて通信するため、競合する優先トラヒックの品質への影響は最小限となる。
本実施例では、送信端末12と中継装置11との間は従来のTCP方式で通信を行ない、中継装置11と受信端末13との間は低優先なTCP方式で通信を行なう。送信端末12と中継装置11との間の回線は輻輳しておらず、中継装置11と受信端末13との間の回線が輻輳している場合、本実施例では輻輳している回線で低優先TCP方式を用いて通信するため、競合する優先トラヒックの品質への影響は最小限となる。
本実施例では、送信端末12及び受信端末13は従来のTCP方式のままであり、変更は不要である。従って、特に送信端末の数が多い場合、送信端末の変更に大きな工数をかけることなく、１台の中継装置を挿入するだけで優先トラヒックの品質への影響を最小限とするという目的を達成することが可能である。
図１９において、中継装置11内のデータ送信制御部11-1が、第１の実施例による端末と同様の動作をするものである場合を説明したが、本発明はそれに限定されない。例えば、図１９において、中継装置11内のデータ送信制御部11-1は、上述した第２〜第１０の実施例のいずれかによる端末と同様の動作をするものであっても良い。
1 端末（通信端末）
1-1 データ送信制御部
1-2 パケット送信部
1-3 パケット受信部
1-4 輻輳ウインド決定部
1-5 使用可能帯域設定部
1-6 RTT計測部
1-7 初期輻輳判定部
1-8 初期輻輳閾値設定部
1-9 優先トラヒック割合推定部
1-10 輻輳判定部
3 端末（通信端末）
3-1 データ送信制御部
3-2 パケット送信部
3-3 パケット受信部
3-4 輻輳ウインド決定部
3-5 使用可能帯域設定部
3-6 RTT計測部
3-7 初期輻輳判定部
3-8 初期輻輳閾値設定部
3-9 RTT比較部
3-10 輻輳判定部
4 端末（通信端末）
4-1 データ送信制御部
4-2 パケット送信部
4-3 パケット受信部
4-4 輻輳ウインド決定部
4-5 使用可能帯域設定部
4-6 RTT計測部
4-7 初期輻輳判定部
4-8 初期輻輳閾値設定部
4-9 優先トラヒック割合推定部
4-10 輻輳判定部
4-11 RTT比較部
5 端末（通信端末）
5-1 データ送信制御部
5-2 パケット送信部
5-3 パケット受信部
5-4 輻輳ウインド決定部
5-5 使用可能帯域設定部
5-6 RTT計測部
5-7 初期輻輳判定部
5-8 初期輻輳閾値設定部
5-9 ECN付パケット割合測定部
5-10 輻輳判定部
6 端末（通信端末）
6-1 データ送信制御部
6-2 パケット送信部
6-3 パケット受信部
6-4 輻輳ウインド決定部
6-5 使用可能帯域設定部
6-6 RTT計測部
6-7 初期輻輳判定部
6-8 初期輻輳閾値設定部
6-9 優先トラヒック割合推定部
6-10 輻輳判定部
8 端末（通信端末）
8-1 データ送信制御部
8-2 パケット送信部
8-3 パケット受信部
8-4 輻輳ウインド決定部
8-5 使用可能帯域設定部
8-6 RTT計測部
8-7 初期輻輳判定部
8-8 初期輻輳閾値設定部
8-9 優先トラヒック割合推定部
8-10 輻輳判定部
8-11 RTT比較部
9 端末（通信端末）
9-1 データ送信制御部
9-2 パケット送信部
9-3 パケット受信部
9-4 輻輳ウインド決定部
9-5 使用可能帯域設定部
9-6 RTT計測部
9-7 初期輻輳判定部
9-8 初期輻輳閾値設定部
9-9 優先トラヒック割合推定部
9-10 輻輳判定部
10 端末（通信端末）
10-1 データ送信制御部
10-2 パケット送信部
10-3 パケット受信部
10-4 輻輳ウインド決定部
10-5 使用可能帯域設定部
10-6 RTT計測部
10-7 初期輻輳判定部
10-8 初期輻輳閾値設定部
10-9 優先トラヒック割合推定部
10-10 輻輳判定部
10-11 使用帯域測定部
11 中継装置
11-1 データ送信制御部
11-12 データ受信制御部
12 送信端末
12-1 データ送信制御部
13 受信端末
13-1 データ受信制御部
1-1 データ送信制御部
1-2 パケット送信部
1-3 パケット受信部
1-4 輻輳ウインド決定部
1-5 使用可能帯域設定部
1-6 RTT計測部
1-7 初期輻輳判定部
1-8 初期輻輳閾値設定部
1-9 優先トラヒック割合推定部
1-10 輻輳判定部
3 端末（通信端末）
3-1 データ送信制御部
3-2 パケット送信部
3-3 パケット受信部
3-4 輻輳ウインド決定部
3-5 使用可能帯域設定部
3-6 RTT計測部
3-7 初期輻輳判定部
3-8 初期輻輳閾値設定部
3-9 RTT比較部
3-10 輻輳判定部
4 端末（通信端末）
4-1 データ送信制御部
4-2 パケット送信部
4-3 パケット受信部
4-4 輻輳ウインド決定部
4-5 使用可能帯域設定部
4-6 RTT計測部
4-7 初期輻輳判定部
4-8 初期輻輳閾値設定部
4-9 優先トラヒック割合推定部
4-10 輻輳判定部
4-11 RTT比較部
5 端末（通信端末）
5-1 データ送信制御部
5-2 パケット送信部
5-3 パケット受信部
5-4 輻輳ウインド決定部
5-5 使用可能帯域設定部
5-6 RTT計測部
5-7 初期輻輳判定部
5-8 初期輻輳閾値設定部
5-9 ECN付パケット割合測定部
5-10 輻輳判定部
6 端末（通信端末）
6-1 データ送信制御部
6-2 パケット送信部
6-3 パケット受信部
6-4 輻輳ウインド決定部
6-5 使用可能帯域設定部
6-6 RTT計測部
6-7 初期輻輳判定部
6-8 初期輻輳閾値設定部
6-9 優先トラヒック割合推定部
6-10 輻輳判定部
8 端末（通信端末）
8-1 データ送信制御部
8-2 パケット送信部
8-3 パケット受信部
8-4 輻輳ウインド決定部
8-5 使用可能帯域設定部
8-6 RTT計測部
8-7 初期輻輳判定部
8-8 初期輻輳閾値設定部
8-9 優先トラヒック割合推定部
8-10 輻輳判定部
8-11 RTT比較部
9 端末（通信端末）
9-1 データ送信制御部
9-2 パケット送信部
9-3 パケット受信部
9-4 輻輳ウインド決定部
9-5 使用可能帯域設定部
9-6 RTT計測部
9-7 初期輻輳判定部
9-8 初期輻輳閾値設定部
9-9 優先トラヒック割合推定部
9-10 輻輳判定部
10 端末（通信端末）
10-1 データ送信制御部
10-2 パケット送信部
10-3 パケット受信部
10-4 輻輳ウインド決定部
10-5 使用可能帯域設定部
10-6 RTT計測部
10-7 初期輻輳判定部
10-8 初期輻輳閾値設定部
10-9 優先トラヒック割合推定部
10-10 輻輳判定部
10-11 使用帯域測定部
11 中継装置
11-1 データ送信制御部
11-12 データ受信制御部
12 送信端末
12-1 データ送信制御部
13 受信端末
13-1 データ受信制御部
Claims (20)
- ネットワークを介しデータの送信を行う通信端末において、
輻輳を検出する輻輳検出手段と、理想的な輻輳制御パラメータと輻輳制御パラメータの現在値とをもとに前記輻輳の兆候を検出する兆候検出手段とを有し、前記輻輳検出手段が前記輻輳を検出するか、もしくは前記兆候検出手段が前記兆候を検出した際に、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する機能を有する通信端末であって、
輻輳制御パラメータの上限値を設定する手段を更に有し、輻輳制御パラメータの上限値は、理想的な輻輳制御パラメータと閾値との和、もしくは理想的な輻輳制御パラメータと閾値との積であり、
前記兆候検出手段は、前記上限値よりも前記輻輳制御パラメータの現在値が大きければ、前記兆候を検出することを特徴とする通信端末。 - 請求項１に記載の通信端末であって、
前記閾値を、あるいは前記上限値を、現在のネットワークの状態を元に、動的に設定することを特徴とする通信端末。 - 請求項１に記載の通信端末であって、
前記輻輳検出手段は、パケット廃棄を検出することで輻輳を検出するものであり、
前記通信端末は、現在送信を行っている帯域、受信確認パケットから計算される現在受信端末がデータを受信できている帯域、及びボトルネック回線の推定帯域の内の少なくとも一つをもとに計算される送信可能帯域を元に、前記理想的な輻輳制御パラメータを決定することを特徴とする通信端末。 - 請求項３に記載の通信端末であって、
前記通信端末は、前記送信可能帯域に、ラウンド・トリップ・タイムの最小の値としての往復伝播遅延時間の推定値を乗ずることにより、前記理想的な輻輳制御パラメータを決定することを特徴とする通信端末。 - 請求項３に記載の通信端末であって、
前記通信端末は、前記送信可能帯域に、ラウンド・トリップ・タイムの最小の値としての往復伝播遅延時間の推定値を乗じ、乗算結果を得、この乗算結果に対してネットワークの輻輳度あるいは推定した優先トラヒックの割合に応じた減算を行うことで、前記理想的な輻輳制御パラメータを決定することを特徴とする通信端末。 - 請求項５に記載の通信端末であって、
前記通信端末は、前記送信可能帯域に、ラウンド・トリップ・タイムの最小の値としての往復伝播遅延時間の推定値を乗じ、乗算結果を得、ある時間間隔で測定したラウンド・トリップ・タイムの最小の値から前記往復伝播遅延時間を減算したものに前記送信可能帯域を乗じたものを、前記乗算結果から減算することで、前記理想的な輻輳制御パラメータを決定することを特徴とする通信端末。 - 請求項６に記載の通信端末であって、
前記時間間隔を、輻輳制御パラメータの現在値を減少させてから次に輻輳制御パラメータの現在値を減少されるまでの時間とすることを特徴とする通信端末。 - 請求項４に記載の通信端末であって、
前記通信端末は、前記送信可能帯域に、ラウンド・トリップ・タイムの最小の値としての往復伝播遅延時間の推定値を乗じ、乗算結果を得、さらにこの乗算結果に、推定した優先トラヒックの割合を乗じることで、前記理想的な輻輳制御パラメータを決定することを特徴とする通信端末。 - 請求項１に記載の通信端末であって、
前記兆候検出手段は、輻輳の兆候を検出する閾値として、第１の閾値及び該第１の閾値よりも小さい第２の閾値を有し、前記第１の閾値をもって輻輳の兆候を検出した場合には、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する動作を行い、前記第２の閾値をもって輻輳の兆候を検出した場合には、前記動作を行わず、また輻輳制御パラメータの増加処理も行わないことを特徴とする通信端末。 - ネットワークを介し受信端末へのデータの送信を行う中継装置において、
輻輳を検出する輻輳検出手段と、理想的な輻輳制御パラメータと輻輳制御パラメータの現在値とをもとに前記輻輳の兆候を検出する兆候検出手段とを有し、前記輻輳検出手段が前記輻輳を検出するか、もしくは前記兆候検出手段が前記兆候を検出した際に、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する機能を有する中継装置であって、
輻輳制御パラメータの上限値を設定する手段を更に有し、輻輳制御パラメータの上限値は、理想的な輻輳制御パラメータと閾値との和、もしくは理想的な輻輳制御パラメータと閾値との積であり、
前記兆候検出手段は、前記上限値よりも前記輻輳制御パラメータの現在値が大きければ、前記兆候を検出することを特徴とする中継装置。 - 請求項１０に記載の中継装置であって、
前記閾値を、あるいは前記上限値を、現在のネットワークの状態を元に、動的に設定することを特徴とする中継装置。 - 請求項１０に記載の中継装置であって、
前記輻輳検出手段は、パケット廃棄を検出することで輻輳を検出するものであり、
前記中継装置は、現在送信を行っている帯域、受信確認パケットから計算される現在受信端末がデータを受信できている帯域、及びボトルネック回線の推定帯域の内の少なくとも一つをもとに計算される送信可能帯域を元に、前記理想的な輻輳制御パラメータを決定することを特徴とする中継装置。 - 請求項１２に記載の中継装置であって、
前記中継装置は、前記送信可能帯域に、ラウンド・トリップ・タイムの最小の値としての往復伝播遅延時間の推定値を乗ずることにより、前記理想的な輻輳制御パラメータを決定することを特徴とする中継装置。 - 請求項１２に記載の中継装置であって、
前記中継装置は、前記送信可能帯域に、ラウンド・トリップ・タイムの最小の値としての往復伝播遅延時間の推定値を乗じ、乗算結果を得、この乗算結果に対してネットワークの輻輳度あるいは推定した優先トラヒックの割合に応じた減算を行うことで、前記理想的な輻輳制御パラメータを決定することを特徴とする中継装置。 - 請求項１４に記載の中継装置であって、
前記中継装置は、前記送信可能帯域に、ラウンド・トリップ・タイムの最小の値としての往復伝播遅延時間の推定値を乗じ、乗算結果を得、ある時間間隔で測定したラウンド・トリップ・タイムの最小の値から前記往復伝播遅延時間を減算したものに前記送信可能帯域を乗じたものを、前記乗算結果から減算することで、前記理想的な輻輳制御パラメータを決定することを特徴とする中継装置。 - 請求項１５に記載の中継装置であって、
前記時間間隔を、輻輳制御パラメータの現在値を減少させてから次に輻輳制御パラメータの現在値を減少されるまでの時間とすることを特徴とする中継装置。 - 請求項１３に記載の中継装置であって、
前記中継装置は、前記送信可能帯域に、ラウンド・トリップ・タイムの最小の値としての往復伝播遅延時間の推定値を乗じ、乗算結果を得、さらにこの乗算結果に、推定した優先トラヒックの割合を乗じることで、前記理想的な輻輳制御パラメータを決定することを特徴とする中継装置。 - 請求項１０に記載の中継装置であって、
前記兆候検出手段は、輻輳の兆候を検出する閾値として、第１の閾値及び該第１の閾値よりも小さい第２の閾値を有し、前記第１の閾値をもって輻輳の兆候を検出した場合には、輻輳制御パラメータの現在値を理想的な輻輳制御パラメータへと変更するか、もしくは送信レートを、理想的な輻輳制御パラメータから計算された理想的な送信レートに変更する動作を行い、前記第２の閾値をもって輻輳の兆候を検出した場合には、前記動作を行わず、また輻輳制御パラメータの増加処理も行わないことを特徴とする中継装置。 - 請求項１０に記載の中継装置であって、
輻輳制御に、TCP（Transmission Control Protocol）を用い、輻輳制御パラメータとして輻輳ウインドサイズを用いることを特徴とする中継装置。 - 請求項１に記載の通信端末であって、
輻輳制御に、TCP（Transmission Control Protocol）を用い、輻輳制御パラメータとして輻輳ウインドサイズを用いることを特徴とする通信端末。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/875,688 US8125910B2 (en) | 2004-06-25 | 2004-06-25 | Communication system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2006014329A JP2006014329A (ja) | 2006-01-12 |
| JP4632874B2 true JP4632874B2 (ja) | 2011-02-16 |
Family
ID=35505568
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005183043A Expired - Fee Related JP4632874B2 (ja) | 2004-06-25 | 2005-06-23 | 通信端末 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US8125910B2 (ja) |
| JP (1) | JP4632874B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7325883B1 (ja) | 2022-01-31 | 2023-08-15 | 株式会社346 | 缶蓋切除器具 |
Families Citing this family (103)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7454500B1 (en) | 2000-09-26 | 2008-11-18 | Foundry Networks, Inc. | Global server load balancing |
| US7657629B1 (en) | 2000-09-26 | 2010-02-02 | Foundry Networks, Inc. | Global server load balancing |
| US9130954B2 (en) | 2000-09-26 | 2015-09-08 | Brocade Communications Systems, Inc. | Distributed health check for global server load balancing |
| US7086061B1 (en) | 2002-08-01 | 2006-08-01 | Foundry Networks, Inc. | Statistical tracking of global server load balancing for selecting the best network address from ordered list of network addresses based on a set of performance metrics |
| US7676576B1 (en) | 2002-08-01 | 2010-03-09 | Foundry Networks, Inc. | Method and system to clear counters used for statistical tracking for global server load balancing |
| US7574508B1 (en) | 2002-08-07 | 2009-08-11 | Foundry Networks, Inc. | Canonical name (CNAME) handling for global server load balancing |
| US7974195B2 (en) * | 2003-06-12 | 2011-07-05 | California Institute Of Technology | Method and apparatus for network congestion control |
| US9584360B2 (en) | 2003-09-29 | 2017-02-28 | Foundry Networks, Llc | Global server load balancing support for private VIP addresses |
| US7496651B1 (en) | 2004-05-06 | 2009-02-24 | Foundry Networks, Inc. | Configurable geographic prefixes for global server load balancing |
| US7584301B1 (en) | 2004-05-06 | 2009-09-01 | Foundry Networks, Inc. | Host-level policies for global server load balancing |
| JP2008511205A (ja) * | 2004-08-17 | 2008-04-10 | カリフォルニア・インスティチュート・オブ・テクノロジー | キュー制御と１方向遅延測定を用いた、ネットワークの輻輳を制御する方法および装置 |
| US7423977B1 (en) | 2004-08-23 | 2008-09-09 | Foundry Networks Inc. | Smoothing algorithm for round trip time (RTT) measurements |
| US7239886B2 (en) * | 2004-08-27 | 2007-07-03 | Motorola, Inc. | Adaptive power control method for cellular systems |
| US20060072522A1 (en) * | 2004-09-29 | 2006-04-06 | Praphul Chandra | Call parameter selection and self-enforced admission control for optimizing voice over internet protocol performance in wireless networks |
| JP4257307B2 (ja) * | 2005-03-14 | 2009-04-22 | 富士通株式会社 | 通信制御システムおよび通信制御方法 |
| EP1886443A4 (en) * | 2005-05-06 | 2011-03-09 | California Inst Of Techn | ARCHITECTURE OF RECOVERY OF EFFECTIVE LOSS FOR TCP CUT OFF LOSS |
| US8902739B2 (en) * | 2005-05-26 | 2014-12-02 | Alcatel Lucent | Backhaul congestion control for wireless communication networks |
| US20060277303A1 (en) * | 2005-06-06 | 2006-12-07 | Nikhil Hegde | Method to improve response time when clients use network services |
| US7869395B2 (en) | 2005-09-30 | 2011-01-11 | Research In Motion Limited | Methods and apparatus for dynamically adjusting a data packet window size for data packet transmission in a wireless communication network |
| US20070091922A1 (en) * | 2005-10-21 | 2007-04-26 | Steven Elliot | Method and apparatus for adaptive bandwidth control with a bandwidth guarantee |
| US7558271B2 (en) * | 2005-10-21 | 2009-07-07 | International Business Machines Corporation | Method and apparatus for adaptive bandwidth control with defined priorities for different networks |
| US7760633B2 (en) * | 2005-11-30 | 2010-07-20 | Cisco Technology, Inc. | Transmission control protocol (TCP) congestion control using transmission delay components |
| US7929571B2 (en) * | 2006-01-12 | 2011-04-19 | Cisco Technology, Inc. | System and method for implementing a preemptive retransmit for error recovery in a communications environment |
| US8000238B2 (en) * | 2006-08-04 | 2011-08-16 | Cisco Technology, Inc. | System and method for detecting and regulating congestion in a communications environment |
| US7944823B1 (en) * | 2006-09-01 | 2011-05-17 | Cisco Technology, Inc. | System and method for addressing dynamic congestion abatement for GSM suppression/compression |
| JP4698555B2 (ja) * | 2006-11-17 | 2011-06-08 | 富士通株式会社 | 検出方法、検出装置及びコンピュータプログラム |
| JP4778453B2 (ja) * | 2007-01-24 | 2011-09-21 | 株式会社エヌ・ティ・ティ・ドコモ | 通信端末、輻輳制御方法および輻輳制御プログラム |
| US7733785B2 (en) | 2007-01-31 | 2010-06-08 | International Business Machines Corporation | Method and system for dynamically adjusting packet size to decrease delays of streaming data transmissions on noisy transmission lines |
| JP4407700B2 (ja) * | 2007-02-02 | 2010-02-03 | 日本電気株式会社 | 通信端末、通信システム、輻輳制御方法、及び輻輳制御用プログラム |
| US7760642B2 (en) * | 2007-03-12 | 2010-07-20 | Citrix Systems, Inc. | Systems and methods for providing quality of service precedence in TCP congestion control |
| US7706266B2 (en) | 2007-03-12 | 2010-04-27 | Citrix Systems, Inc. | Systems and methods of providing proxy-based quality of service |
| US7796510B2 (en) | 2007-03-12 | 2010-09-14 | Citrix Systems, Inc. | Systems and methods for providing virtual fair queueing of network traffic |
| JP2008236307A (ja) * | 2007-03-20 | 2008-10-02 | Fujitsu Ltd | ネットワーク監視装置およびネットワーク監視方法 |
| US20080299963A1 (en) * | 2007-06-04 | 2008-12-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and Apparatus for Vocoder Rate Control by a Mobile Terminal |
| US8615008B2 (en) | 2007-07-11 | 2013-12-24 | Foundry Networks Llc | Duplicating network traffic through transparent VLAN flooding |
| US7792059B2 (en) * | 2007-09-04 | 2010-09-07 | Motorola, Inc. | Method and system for transitioning between a distributed ad hoc network architecture and a cluster ad hoc network architecture |
| US8248928B1 (en) | 2007-10-09 | 2012-08-21 | Foundry Networks, Llc | Monitoring server load balancing |
| FR2922391B1 (fr) * | 2007-10-15 | 2009-12-04 | Canon Kk | Procede et dispositif de transmission de donnees |
| US7990869B2 (en) * | 2007-11-30 | 2011-08-02 | International Business Machines Corporation | Method for monitoring data congestion in a computer network with multiple nodes and method for controlling data transmission in the computer network |
| JP4930388B2 (ja) * | 2008-01-17 | 2012-05-16 | ヤマハ株式会社 | 通信装置およびプログラム |
| JP4597209B2 (ja) * | 2008-04-14 | 2010-12-15 | 三菱電機株式会社 | 通信解析装置 |
| KR101400990B1 (ko) * | 2008-04-03 | 2014-05-29 | 연세대학교 산학협력단 | 멀티 홉 통신 시스템에서의 중계기 및 상기 중계기의 동작방법 |
| JP5191826B2 (ja) * | 2008-07-04 | 2013-05-08 | パナソニック株式会社 | ストリーム通信装置、ストリーム通信方法及びストリーム通信システム |
| US8374091B2 (en) * | 2009-03-26 | 2013-02-12 | Empire Technology Development Llc | TCP extension and variants for handling heterogeneous applications |
| CN102045764B (zh) * | 2009-10-20 | 2014-02-19 | 华为技术有限公司 | 高速上行分组接入自适应重传方法及装置 |
| KR101628377B1 (ko) * | 2010-01-12 | 2016-06-08 | 삼성전자주식회사 | 통신 시스템에서 혼잡 제어를 수행하는 장치 및 방법 |
| JP5136586B2 (ja) * | 2010-03-31 | 2013-02-06 | ブラザー工業株式会社 | 通信装置、通信方法、および通信プログラム |
| US8307111B1 (en) * | 2010-04-13 | 2012-11-06 | Qlogic, Corporation | Systems and methods for bandwidth scavenging among a plurality of applications in a network |
| WO2011136705A1 (en) * | 2010-04-26 | 2011-11-03 | Telefonaktiebolaget L M Ericsson (Publ) | Method for setting and adjusting a parameter dependent on a round trip time |
| US8427958B2 (en) | 2010-04-30 | 2013-04-23 | Brocade Communications Systems, Inc. | Dynamic latency-based rerouting |
| US8340126B2 (en) * | 2010-06-07 | 2012-12-25 | Lockheed Martin Corporation | Method and apparatus for congestion control |
| US9154394B2 (en) | 2010-09-28 | 2015-10-06 | Brocade Communications Systems, Inc. | Dynamic latency-based rerouting |
| US8549148B2 (en) | 2010-10-15 | 2013-10-01 | Brocade Communications Systems, Inc. | Domain name system security extensions (DNSSEC) for global server load balancing |
| MX2013009341A (es) * | 2011-02-14 | 2013-10-01 | Thomson Licensing | Conectividad wi-fi para correccion de anormalidades mediante medicion del tiempo de carrera completa de paquetes enviados con diferentes velocidades de modulacion. |
| US8982688B2 (en) | 2011-03-09 | 2015-03-17 | Cray Inc | Congestion abatement in a network interconnect |
| US8953442B2 (en) | 2011-03-09 | 2015-02-10 | Cray Inc. | Congestion detection in a network interconnect |
| US8885467B2 (en) | 2011-03-09 | 2014-11-11 | Cray Inc. | Congestion causation in a network interconnect |
| JP5772112B2 (ja) * | 2011-03-18 | 2015-09-02 | 富士通株式会社 | 伝送装置、及び情報取得制御方法 |
| US8953443B2 (en) * | 2011-06-01 | 2015-02-10 | At&T Intellectual Property I, L.P. | Method and apparatus for providing congestion management for a wireless communication network |
| US9391911B1 (en) * | 2011-07-15 | 2016-07-12 | Google Inc. | Congestion window modification |
| US8665729B2 (en) * | 2011-07-29 | 2014-03-04 | Mediatek Inc. | Method for performing radio link control with round trip time awareness, and associated apparatus |
| US9693259B2 (en) * | 2011-09-08 | 2017-06-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Method in a base station, a base station, computer programs and computer readable means |
| EP2916521B1 (en) * | 2012-11-05 | 2018-02-21 | Nec Corporation | Communication device, transmission data output control method, and program for same |
| JP6064593B2 (ja) * | 2012-12-27 | 2017-01-25 | 富士通株式会社 | プログラム、情報処理装置、及び通信方法 |
| JP5998923B2 (ja) * | 2012-12-28 | 2016-09-28 | 富士通株式会社 | プログラム、情報処理装置、及び通信方法 |
| US9277452B1 (en) * | 2013-03-07 | 2016-03-01 | Dragonwave, Inc. | Adaptive modulation and priority-based flow control in wireless communications |
| EP2988545A1 (en) * | 2013-04-19 | 2016-02-24 | NEC Corporation | Data transmission device, data transmission method, and program therefor |
| CN105393231A (zh) * | 2013-07-22 | 2016-03-09 | 富士通株式会社 | 信息处理装置、方法、以及程序 |
| US9565138B2 (en) | 2013-12-20 | 2017-02-07 | Brocade Communications Systems, Inc. | Rule-based network traffic interception and distribution scheme |
| US10171325B2 (en) * | 2013-12-26 | 2019-01-01 | Nec Corporation | Minimum delay value calculating device, information transmitting device, minimum delay value calculating method, and program storage medium |
| US9419900B2 (en) * | 2013-12-31 | 2016-08-16 | International Business Machines Corporation | Multi-bit indicator set according to feedback based on an equilibrium length of a queue |
| US9648542B2 (en) | 2014-01-28 | 2017-05-09 | Brocade Communications Systems, Inc. | Session-based packet routing for facilitating analytics |
| JP6237397B2 (ja) * | 2014-03-27 | 2017-11-29 | 富士通株式会社 | 制御装置、および、通信方法 |
| ES2845078T3 (es) | 2014-04-23 | 2021-07-23 | Bequant S L | Método y aparato para el control de congestión de red basado en los gradientes de la tasa de transmisión |
| CN105099938B (zh) * | 2014-05-13 | 2018-10-12 | 华为技术有限公司 | 网络中拥塞窗口的确定方法和装置 |
| CN105432054B (zh) | 2014-06-25 | 2019-04-05 | 华为技术有限公司 | 确定传输缓存量的方法和设备 |
| JP6263102B2 (ja) * | 2014-08-01 | 2018-01-17 | Kddi株式会社 | バックホール側の混雑度に応じたウィンドウサイズを設定可能な無線端末、通信システム、プログラム及び方法 |
| US9614766B2 (en) * | 2014-12-16 | 2017-04-04 | Cisco Technology, Inc. | System and method to analyze congestion in low latency network |
| US10911353B2 (en) | 2015-06-17 | 2021-02-02 | Extreme Networks, Inc. | Architecture for a network visibility system |
| US10771475B2 (en) | 2015-03-23 | 2020-09-08 | Extreme Networks, Inc. | Techniques for exchanging control and configuration information in a network visibility system |
| US10129088B2 (en) | 2015-06-17 | 2018-11-13 | Extreme Networks, Inc. | Configuration of rules in a network visibility system |
| US9866478B2 (en) | 2015-03-23 | 2018-01-09 | Extreme Networks, Inc. | Techniques for user-defined tagging of traffic in a network visibility system |
| EP3101852A1 (en) * | 2015-06-04 | 2016-12-07 | Alcatel Lucent | An early congestion detection device and the related method for deadline-aware flows |
| US10057126B2 (en) | 2015-06-17 | 2018-08-21 | Extreme Networks, Inc. | Configuration of a network visibility system |
| US10530688B2 (en) | 2015-06-17 | 2020-01-07 | Extreme Networks, Inc. | Configuration of load-sharing components of a network visibility router in a network visibility system |
| SE540352C2 (en) * | 2016-01-29 | 2018-07-24 | Icomera Ab | Wireless communication system and method for trains and other vehicles using trackside base stations |
| US10243813B2 (en) | 2016-02-12 | 2019-03-26 | Extreme Networks, Inc. | Software-based packet broker |
| US10999200B2 (en) | 2016-03-24 | 2021-05-04 | Extreme Networks, Inc. | Offline, intelligent load balancing of SCTP traffic |
| CN105827537B (zh) * | 2016-06-01 | 2018-12-07 | 四川大学 | 一种基于quic协议的拥塞改进方法 |
| US10567259B2 (en) | 2016-10-19 | 2020-02-18 | Extreme Networks, Inc. | Smart filter generator |
| WO2018080726A1 (en) | 2016-10-28 | 2018-05-03 | Level 3 Communications, Llc | Systems and methods for adjusting a congestion window value of a content delivery network |
| US11038806B2 (en) * | 2017-04-11 | 2021-06-15 | Telefonaktiebolaget Lm Ericsson (Publ) | First communication node, method performed thereby, computer program and computer-readable storage medium for handling packets in a communications network |
| CN109309934B (zh) * | 2017-07-27 | 2021-01-15 | 华为技术有限公司 | 一种拥塞控制方法及相关设备 |
| CN111656740A (zh) * | 2018-01-26 | 2020-09-11 | 欧庞戈网络有限公司 | 用于识别数据分组网络中的候选流的***和方法 |
| WO2020030736A1 (en) * | 2018-08-08 | 2020-02-13 | British Telecommunications Public Limited Company | Improved congestion response |
| CN112054965B (zh) * | 2019-06-05 | 2024-06-14 | 阿里巴巴集团控股有限公司 | 一种拥塞控制方法、设备及计算机可读介质 |
| US10999206B2 (en) | 2019-06-27 | 2021-05-04 | Google Llc | Congestion control for low latency datacenter networks |
| CN113055306B (zh) * | 2019-12-26 | 2022-10-28 | 北京华为数字技术有限公司 | 报文转发方法以及相关设备 |
| WO2021148328A1 (en) * | 2020-01-20 | 2021-07-29 | Sony Group Corporation | Network entity and user equipment for transmission rate control |
| US11184260B2 (en) * | 2020-02-17 | 2021-11-23 | Wipro Limited | Method and system for determining network congestion level and synchronizing clock using precision time protocol |
| CN112118191B (zh) * | 2020-09-18 | 2023-07-28 | 首都师范大学 | 多路径传输拥塞控制方法、装置、控制设备及存储介质 |
| US11616730B1 (en) * | 2021-10-01 | 2023-03-28 | Compira Labs Ltd. | System and method for adapting transmission rate computation by a content transmitter |
| US11855867B2 (en) * | 2021-12-28 | 2023-12-26 | Palo Alto Networks, Inc. | Enhanced identification of sources of delays in packet delivery along a path |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001195326A (ja) * | 2000-01-13 | 2001-07-19 | Nec Eng Ltd | ファイル転送方式 |
| WO2004010657A1 (en) * | 2002-07-19 | 2004-01-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for calculating a transmission window size |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002152308A (ja) * | 2000-11-09 | 2002-05-24 | Nec Corp | データ通信システム、その通信方法及びその通信プログラムを記録した記録媒体 |
| US7027389B2 (en) * | 2000-12-11 | 2006-04-11 | Cisco Technology, Inc. | Fast failure detection using RTT time considerations on a non-retransmit medium |
| US7099273B2 (en) * | 2001-04-12 | 2006-08-29 | Bytemobile, Inc. | Data transport acceleration and management within a network communication system |
-
2004
- 2004-06-25 US US10/875,688 patent/US8125910B2/en not_active Expired - Fee Related
-
2005
- 2005-06-23 JP JP2005183043A patent/JP4632874B2/ja not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001195326A (ja) * | 2000-01-13 | 2001-07-19 | Nec Eng Ltd | ファイル転送方式 |
| WO2004010657A1 (en) * | 2002-07-19 | 2004-01-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for calculating a transmission window size |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7325883B1 (ja) | 2022-01-31 | 2023-08-15 | 株式会社346 | 缶蓋切除器具 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20050286416A1 (en) | 2005-12-29 |
| US8125910B2 (en) | 2012-02-28 |
| JP2006014329A (ja) | 2006-01-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4632874B2 (ja) | 通信端末 | |
| Parsa et al. | Improving TCP congestion control over internets with heterogeneous transmission media | |
| Dukkipati et al. | Processor sharing flows in the internet | |
| US7643427B2 (en) | Multipath routing architecture for large data transfers | |
| JP4082669B2 (ja) | キューバッファ制御方法 | |
| US7869365B2 (en) | System and program storage device for controlling data packet flows by manipulating data packets according to an actual manipulation rate | |
| EP1417808B1 (en) | Method and system for congestion control in a communications network | |
| JP4738594B2 (ja) | データフロー制御方法および装置 | |
| US6839321B1 (en) | Domain based congestion management | |
| US8509080B2 (en) | Network traffic accelerator | |
| US20020089930A1 (en) | Method for improving TCP performance over wireless links | |
| KR20060100512A (ko) | 전송제어 프로토콜 기반의 네트워크에서 평균 대역폭 추정방법 및 시스템 | |
| WO2001045331A1 (en) | Congestion control method for a packet-switched network | |
| Tai et al. | Making large scale deployment of RCP practical for real networks | |
| Liu et al. | Improving explicit congestion notification with the mark-front strategy | |
| US20040037223A1 (en) | Edge-to-edge traffic control for the internet | |
| US8446835B2 (en) | Method and termination node for bundling multiple messages into a packet | |
| Ayar et al. | A transparent reordering robust TCP proxy to allow per-packet load balancing in core networks | |
| Santhi et al. | Active Queue Management Algorithm for TCP Networks Congestion Control | |
| Zhou et al. | TFRC Veno: An enhancement of TCP friendly rate control over wired/wireless networks | |
| Elloumi et al. | A simulation-based study of TCP dynamics over HFC networks | |
| Shihada et al. | Threshold-based TCP Vegas over optical burst switched networks | |
| Köhler et al. | Analytic Performance Evaluation of the RED Algorithm for QoS in TCP/IP Networks | |
| Magalhaes et al. | Improving Performance of Rate-Based Transport Protocols in Wireless Environments | |
| Santhi et al. | NEWQUE: A New Approach to Active Queue Management for TCP with ECN |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080519 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100402 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100721 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20101021 |
|
| 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: 20101104 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20101116 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131126 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |