JP4589764B2 - スプリアスタイムアウトに対する応答 - Google Patents

スプリアスタイムアウトに対する応答 Download PDF

Info

Publication number
JP4589764B2
JP4589764B2 JP2005072478A JP2005072478A JP4589764B2 JP 4589764 B2 JP4589764 B2 JP 4589764B2 JP 2005072478 A JP2005072478 A JP 2005072478A JP 2005072478 A JP2005072478 A JP 2005072478A JP 4589764 B2 JP4589764 B2 JP 4589764B2
Authority
JP
Japan
Prior art keywords
data
network
transmitted
value
timeout
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
JP2005072478A
Other languages
English (en)
Other versions
JP2005269643A (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.)
Microsoft Corp
Original Assignee
Microsoft Corp
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 Microsoft Corp filed Critical Microsoft Corp
Publication of JP2005269643A publication Critical patent/JP2005269643A/ja
Application granted granted Critical
Publication of JP4589764B2 publication Critical patent/JP4589764B2/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
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/14Arrangements for detecting or preventing errors in the information received by using return channel in which the signals are sent back to the transmitter to be checked ; echo systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/188Time-out mechanisms
    • 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/28Flow control; Congestion control in relation to timing considerations
    • H04L47/283Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • 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
    • 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]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • 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]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures

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)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Description

本発明は、無線ワイドエリアネットワークにおいてスプリアスタイムアウトに応答するための技術を対象とする。
GPRS(汎用パケット無線サービス)などの無線環境では、再送信タイマは、しばしば、スプリアス的に満了して、送信されたデータの実際の損失が存在しない場合でも、1つまたは複数のデータパケットの不要な再送信をトリガすることが知られている。そのような「スプリアスタイムアウト」として知られる(「STO」とも呼ばれる)タイムアウトは、一般に、伝送制御プロトコル(以降、「TCP」)の限界に起因する。
無線ネットワークにおけるスプリアスタイムアウトは、例えば、伝送帯域幅を求めて競合するより高い伝送優先度を有するデータパケットが出現して、スプリアスの再送信タイムアウトをもたらすこと、永続的な信頼できる無線リンクレイヤが、劣悪な無線接続を介してデータパケットを繰り返し再送信して、TCP送信側ホストタイムアウトを生じさせること、またはビジーな逆方向チャネルに起因して、受信側ホストが、受信確認メッセージ(以降、「ACK」)を送信側ホストに適時に送信できないことを含め、様々な原因を有する。
TCPスタックにおいて、MSS(「最大セグメントサイズ」)が、送信側ホストが、単一のパケット内、または単一のセグメント内で受信側ホストに送信することができる最大データ量(バイト単位の)を示す。一般に、効率のため、送信側ホストは、MSSに応じてデータパケットを送信する。TCPウインドウ(以降、「ウインドウ」)とは、送信側ホストが、受信側ホストから、送信されたデータに関する受信確認(「ACK」とも呼ばれる)を受信するまでに送信することができるデータ量を指す。
ACKは、送信されたデータの受信を確認するように受信側ホストから送信側ホストに送信される通信コードである。さらに、ACKは、TCPデータセグメントが受信されるたびに受信側ホストから送信側ホストに送信されることも可能である。また、ACKは、順序の乱れたデータパケットが受信された場合に、受信側ホストから送信側ホストに選択的に送信されることも可能である。受信されたデータパケットは、選択的受信確認(以降、「SACK」)ブロックと呼ばれる拡張TCPヘッダオプションの中で報告される。いずれにしても、TCPは、ACKまたはSACKが、最初に送信されたデータセグメントに応答して生成されたのか、または再送信されたデータセグメントに応答して生成されたのかを区別することができない。
通常、タイムアウトが生じると、TCPスタックは、受信確認が行われていない全ウインドウ分のデータの再送信を既定で行う。しかし、前述したとおり、すべてのタイムアウトがデータ損失によって生じさせられるわけではない。したがって、自動的な再送信は、帯域幅が、既に正常に受信されているデータの再送信に不要に充てられる可能性がある。その結果、ネットワーク接続の完全性が低下する。
TCPデータセグメントのそのような自動的な再送信は、以前に送信されたデータが、受信済みであると確認されるか、または失われたと確認されるまで、データがネットワークに導入されてはならないことを明言する「パケット保存(conservation)原理」に違反する可能性がある。明らかに、スプリアスタイムアウト後のTCPセグメントのあらゆる自動的な再送信は、パケット保存原理と相容れない。
無線ネットワークにおいて生じるスプリアスタイムアウトに応答するための技術を説明する。スプリアスタイムアウトが生じた場合、1つの説明される応答は、データ損失が確認されるまで、または確認されない限り、輻輳状態パラメータの下で送信側ホストからのデータフローを続けることである。詳細には、輻輳状態値が復元され、データ送信が、受信された受信確認に依存して徐々に増加することが可能なフローレート(flow−rate)で続けられる。輻輳値を復元することには、タイムアウトに先立って検出された使用可能な帯域幅を復元すること、受信確認を受信するまでに送信されることが可能なデータの量の限度の既定値を復元することが含まれる。この既定値は、輻輳ウインドウとして知られる。送信データフローが続けられる際、輻輳ウインドウのあらゆる増加は、受信側ホストからの受信確認の受信に依存する。これは、受信確認により、データパケットが送信側ホストから受信側ホストに流れており、ネットワーク上で失われていないことが示されるからである。
添付の図を参照して詳細な説明を述べる。図では、符号の左端の数字が、その符号が最初に現れる図を明らかにする。異なる図における同一の符号の使用により、類似のアイテム、または同一のアイテムが示される。
以下の説明は、無線ネットワークにおいて起こるスプリアスタイムアウトに応答するための技術を対象とする。タイムアウトは、必ずしもデータ損失を示すものではないため、スプリアスタイムアウトの際のデータの自動的な再送信は、ネットワークリソースに関して潜在的に無駄の多い応答である。以下の実施例において実現される保守的な応答は、データ損失が確認されるまで、または確認されない限り、送信側ホストからの確実なデータフローを維持することにより、冗長なデータ送信を回避する。応答は、輻輳状態値を復元すること、および受信された受信確認に基づいて輻輳ウインドウのサイズを増加させることを含む。輻輳ウインドウ(「cwnd」とも呼ばれる)は、送信側ホストが、受信確認を受信するまでにネットワークを介して送信することができるデータの量を制限する状態変数である。
本明細書で説明する例示的な実施形態は、公開プロトコルおよび/または独自のプロトコルを含め、様々なネットワークプロトコルのいずれを利用することもできる。諸実施形態は、例証としてであって、いずれの形でも限定することを意図するものではない。
図1は、ネットワーク102が、クライアントデバイス105、110、115、および120、ならびにサーバデバイス125の間で通信を可能にする例示的なアーキテクチャ100を示す。ネットワーク102は、有線ネットワークおよび/または無線ネットワークを含むことが可能な、様々な従来のネットワークトポロジおよびネットワークタイプのいずれかを表すことを意図している。ネットワーク102は、さらに、公開プロトコルおよび/または独自のプロトコルを含め、様々な従来のネットワークプロトコルのいずれを利用することもできる。ネットワーク102には、例えば、インターネット、および1つまたは複数のローカルエリアネットワーク(LAN)の少なくとも一部が含まれることが可能である。
クライアントデバイス105には、デスクトップパーソナルコンピュータ(PC)、ワークステーション、メインフレームコンピュータ、インターネット機器、およびゲームコンソールを含め、様々な従来のコンピューティングデバイスのいずれが含まれることも可能である。さらに、ネットワーク102に関連するクライアントデバイスには、有線リンクおよび/または無線リンクでネットワーク102と通信することが可能な、パーソナルデジタルアシスタント(PDA)110、ラップトップコンピュータ115、および携帯電話120などが含まれることが可能である。さらに、クライアントデバイス105、110、115、および120の1つまたは複数には、同一のタイプのデバイスが含まれること、または代替として、異なるタイプのデバイスが含まれることが可能である。
サーバデバイス125は、様々なデータおよび/または機能をコンピューティングデバイス105、110、115、および120に提供することができる。データは、公開されていること、または代替として制限されていること、例えば、一部のユーザだけに制限されていること、または適切な料金が支払われた場合にだけ利用可能であることが可能である。サーバデバイス125は、ネットワークサーバ、アプリケーションサーバ、およびWebブレード(blade)の少なくとも1つであり、あるいは以上の任意の組み合わせであることが可能である。サーバデバイス125は、コンテンツのソースである任意のデバイスであり、クライアントデバイス105、110、115、および120には、そのようなコンテンツを受信する任意のデバイスが含まれる。クライアントデバイスまたはサーバデバイスの例示的な実施形態を、図7を参照して以下にさらに詳細に説明する。
クライアントデバイス105、110、115、120、およびサーバデバイス125のいずれのデバイスも、本明細書で説明する例示的な実施形態に従って送信側ホストまたは受信側ホストとして動作することができる。いずれの形でも限定することを意図しない説明の目的で、クライアントデバイス115が、ネットワーク102を介して受信側ホストにデータを送信する送信側ホストである。送信側ホスト115は、プロセッサ117を含み、プロセッサ117が、本明細書で説明する例示的な実施形態に対応するスプリアスタイムアウト応答119を実施する。
図1のネットワーク102に対応するプロトコルには、TCP/IP(Transmission Control Protocol/Internet Protocol)が含まれることが可能であるが、これには限定されず、TCPは、終端間のエラー検出およびエラー訂正を実施する接続ベース(connection−based)のストリーム指向配信サービス(stream−oriented delivery service)である。送信側ホスト115から受信側ホストにデータを送信する際、スプリアスタイムアウトが、無線ワイドエリアネットワークであることが可能なネットワーク102において生じることは稀ではない。送信トランザクションに対するそのようなタイムアウトのあらゆる効果を当業者は理解している。しかし、スプリアスタイムアウトの発生は、必ずしも失われたデータパケットまたは輻輳を示すものではない。
スプリアスタイムアウト応答119は、データの再送信を自動的には起こさない形でスプリアスタイムアウトを扱う。むしろ、スプリアスタイムアウト(STO)が検出された場合、スプリアスタイムアウト応答119は、輻輳状態値を復元し、送信側ホストからの確実なデータフローを維持することにより、STOに応答する。つまり、送信側ホストからのデータフローは、データ損失が確認されるまで、または確認されない限り、データパケットの再送信を全く含まない。
より詳細には、スプリアスタイムアウト応答119は、タイムアウトが検出された時点より前の値にスロースタート(slow−start)閾値(「ssthresh」とも呼ばれる)を復元し、輻輳ウインドウ「cwnd」を徐々に増加させるようにTCPスタックに指示する。スロースタート閾値「ssthresh」は、データ送信を制御するために利用される推定の利用可能な帯域幅に関する状態変数であり、輻輳ウインドウ「cwnd」は、繰り返すが、送信側ホストが、受信確認「ACK」を受信するまでにネットワークを介して送信することができるデータの量を制限する状態変数である。タイムアウトが生じた後、輻輳ウインドウは、MSSに設定され、最初の受信確認されなかったパケットが再送信される。しかし、再送信が不要であることが判明した場合、すなわち、元の送信が受信側ホストによって正常に受信されている場合、送信側ホストは、その他のタイムアウトパケットの再送信を止める。さらに、輻輳ウインドウは、ACKが受信されると、最大セグメントサイズ(MSS)だけ増加させられる(すなわち、cwnd=cwnd+MSS)。というのは、ACKは、タイムアウトデータパケットの送信の成功を示すからである。つまり、ACKは、ネットワークパスを再検証するのに必要な正確なデータを提供するため、ACKを受信することにより、送信することができるデータの量を増加させることができることが示される。
図2は、送信側ホスト115のプロセッサ117をより詳細に示す。プロセッサ117は、例えば、TCPプロトコルを利用して、受信側ホストにデータパケットを送信するデータパケット送信機205を含む。再送信タイマ/タイムアウト検出器210が、送信機205からデータパケットが送信されてからの時間を追跡記録している。このため、再送信タイマ/タイムアウト検出器210は、データパケットが送信されてから所定の時間、例えば、500ミリ秒が経過し、そのデータパケットに対応するACKが、送信側ホスト115において受信されないと、タイムアウトを検出する。タイムアウトがスプリアスタイムアウトであると判定された場合、タイムアウト応答プロセッサ215が、「再パケット化を伴うスプリアスタイムアウト検出」(以降、「STODER」と呼ぶ)応答であるタイムアウト応答プロセス119(図1を参照)を実施する。図4〜6が、タイムアウト応答プロセス119をより詳細に表す。図2に示した処理モジュールは、図示するとおり、個別に、または様々な組み合わせで実装することができる。
図3は、スプリアスタイムアウトに応答するためのタイムアウト応答プロセス119を示す。プロセス119は、このプロセスを実行するように行われる少なくとも1つの動作をそれぞれが表すブロックの組として図示されている。動作は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせによって実施されることが可能である。この場合も、説明の目的で、プロセス119は、タイムアウトが生じると、送信側ホスト115から受信側ホストにデータパケットを送信するという状況で説明する。
305で、送信側ホスト115が、タイムアウト条件を検出する。タイムアウトを検出すると、送信側ホスト115は、タイムアウト検出の時点までに送信側ホスト115から送信されたデータパケットに対応する最大のシーケンス番号を保存する310。保存されたシーケンス番号は、後続するデータパケット送信のための参照点の役割をすることが可能である。次に、最初の受信確認されなかったパケットが、再送信される。受信側ホストから最初の受信確認が受信されると、タイムアウトがスプリアスタイムアウト(STO)であるという判定315が、当技術分野で周知の技術に従って行われる。そのような技術の例には、それに限定するものではないが、2004年1月15日に米国特許庁に出願した同時係属出願第10/758,510号で説明されている技術が含まれ、したがって、本明細書では説明しない。
図4〜6は、STOが検出315されると実施される例示的なプロトコル応答119を示す。詳細には、本明細書で説明するSTODER応答は、データパケットを自動的に再送信すること、または既定で輻輳制御状態処理を行うことによってSTOに応答することはせず、代わりに、パケット保存原理に適合する応答を実施する。
図4は、STODER応答における初期の諸動作を示す。STOの検出315(図3を参照)は、必ずしもデータパケットの損失を前提としないため、送信側ホスト115からの確実なデータフローを維持するように輻輳状態値が復元される405。送信されるべき次のデータパケットに関するパラメータが、STO検出の時点までに送信されている、以前の送信済みデータパケットと実質的に等しくなるように設定される。この時点を「STODER回復点」(以降、「SRP」)と呼ぶことができる。スロースタート閾値「ssthresh」が、タイムアウトが生じる前の値に実質的に等しくなるように復元され、輻輳ウインドウ「cwnd」が、最大セグメントサイズの2倍(すなわち、cwnd=2MSS)に設定される。これは、2つのデータパケットのサイズを超えない輻輳ウインドウの初期値に関する周知のTCP原理に適合する。
データパケットが失われたという確認が存在しない場合、パケット保存原理の遵守により、以前に送信済みのデータが全く再送信されないことが要求される。つまり、この時点で、継続するデータフローは、新たに送信されるデータパケットだけを含むことになる。したがって、410で、送信側ホスト115は、最大で2つの新たなデータパケットを受信側ホストに送信することにより、データフローを維持する。データフローを維持するのにネットワークを介して送信される新たなデータパケットの数は、プロトコルが進化するにつれて変わる可能性があることに留意されたい。
415で、送信側ホスト115は、ネットワーク内で未処理であるバイト数の送信側の推定である「パイプ」値を設定する。この段階で、パイプ値は、以下のとおり、それまでに送信された最大シーケンス番号(すなわち、snd.max)と、まだ受信確認されていない最小シーケンス番号(すなわち、snd.una)の差に、最大セグメントサイズ(MSS)を足した値に等しくなるように設定される。
パイプ=MSS+snd.max−snd.una
MSSの加算は、タイムアウトした最初のデータパケットの再送信を計算に入れるために行われる。
420で、送信側ホスト115は、受信確認(ACK)を受信する。後続の処理は、ACKが、確実なデータフローを進めるか、またはそれが重複(duplicate)ACKであるかによって影響される。ACKは、送信されたデータパケットが受信側ホストにおいて正常に受信済みであることを示す場合、確実なデータフローを進める。重複ACKは、新たなデータを累積的に受信確認するのではなく、受信確認フィールド内でSnd.unaを繰り返すだけのACKである。
図5では、送信側ホスト115においてACKが受信された420(図4を参照)後のSTODER応答の例示的な実施形態を続けている。受信されたACKにより、SRPに及ぶシーケンス番号が受信確認されるかどうかに関して判定505が行われる。ACKに対応するシーケンス番号が、SRPに及んでいる(ACK Seq.No.>SRP)(すなわち、505から「Yes」の分岐)場合、STODER応答は、終了する507。
そうでない場合、ACKにより、SRP未満のデータが受信確認されているかどうか、すなわち、ACKにより、いくらかの新たな、ただし、SRPに及ばないデータが確認されているかどうかの判定510が行われる。そのようなACKは、いくつかのデータパケットが、ネットワークを離れたことを示す。したがって、この条件の肯定的な判定(すなわち、510から「Yes」の分岐)後、未処理のパケットが減少したことを反映するようにパイプ値が調整される(すなわち、ブロック512)。さらに、ACKは、いくらかのデータが受信側ホストにおいて正常に受信されたことを示すので、ACKが受信された時点で、輻輳ウインドウ「cwnd」がスロースタート閾値「ssthresh」未満である(すなわち、cwnd<ssthresh)である場合、輻輳ウインドウ「cwnd」は、最大セグメントサイズ「MSS」を輻輳ウインドウ「cwnd」に加算する(すなわち、cwnd=cwnd+MSS)により、広げられることが可能である。その後、安定した(consistent)データフローを維持するため、パイプ値が輻輳ウインドウ「cwnd」未満(すなわち、pipe<cwnd)である場合、新たなデータパケット、すなわち、まだ送信されていないデータを、送信することが可能である。
そうでない場合、ACKが「重複ACK」であるかどうか、つまり、ACKが、同一のシーケンス番号を有するか、または受信確認されていないデータの最小の番号未満、すなわち、snd.una未満を有するかの判定520が行われる。重複ACKの判定(すなわち、520から「Yes」の分岐)後、ネットワーク内における未処理のデータの量の推定が、パイプ値を最大セグメントサイズ「MSS」未満の元のパイプ値に再設定する522(すなわち、pipe=pipe−MSS)ことにより、調整される。
さらに、重複ACKが、SRPのデータセグメント未満のデータセグメントを選択的に受信確認するSACKブロックを含み、輻輳ウインドウ「cwnd」が、スロースタート閾値「ssthresh」未満(すなわち、cwnd<ssthresh)である場合、輻輳ウインドウ「cwnd」は、最大セグメントサイズ「MSS」を輻輳ウインドウ「cwnd」の現在の値に加算すること(すなわち、cwnd=cwnd+MSS)により、再設定される。その後、安定したデータフローを維持するため、パイプ値が輻輳ウインドウ「cwnd」未満である(すなわち、pipe<cwnd)である場合、新たなデータパケットが送信される。
そうではなく、3つの重複ACKが受信されているという判定530が行われた場合、データパケットはネットワークから失われている(すなわち、530から「Yes」の分岐)ものと、推定に基づいて(presumptively)考えられる。したがって、第3の重複ACKが受信されると、ACKが受信されていない、失われたデータパケットが、送信側ホスト115から再送信525されることが可能である。さらに、損失が検出されているので、スロースタート閾「ssthresh」状態値および輻輳ウインドウ「cwnd」状態値が再設定527される。具体的には、スロースタート閾値は、元の値の1/2に低減され(すなわち、ssthresh=ssthresh/2)、輻輳ウインドウは、第3の重複ACKが受信された時点における輻輳ウインドウとスロースタート閾値の小さい方に設定される(すなわち、cwnd=min(cwnd,ssthresh))。3つの重複ACKに関して否定的な判定530の場合、処理は、505に戻る。
失われたデータの再送信に加えて、STOに対する応答は、SACKベースのスロースタート回復処理に移る。
図6は、SACKベースのスロースタート回復処理を示す。スロースタート閾状態値および輻輳ウインドウ状態値が再設定527された(図5を参照)後の送信側ホスト115におけるACKの受信が、受信されたACKにより、SRPに及ぶシーケンス番号が受信確認されるかどうか、すなわち、ACKが未だに受信確認されていない何らかの未処理のデータに対応するかどうかの判定605を生じさせる。このため、ACKに対応するシーケンス番号がSRPに及んでいる(すなわち、605から「Yes」の分岐)場合、STODER応答は、終了する607。
そうでない場合、ACKにより、SRPで示されるデータに満たないデータが受信確認されているかどうか、すなわち、ACKが「部分的ACK」であるかどうかの判定610が行われる。SACKベースのスロースタート回復段階における第1の部分的ACKの判定615(すなわち、610から「Yes」の分岐)により、SRP未満のすべてのデータパケットが失われたという推定に基づく結論がもたらされる。したがって、以下のとおり、再送信されるべきデータのサイズ(retran_data)に、部分的ACKが判定された時点までに送信されたデータからSRPを引いた値(snd.max−SRP)を足し、SRPを超える選択的に受信確認されたデータパケット(SRPを超えるsacked_pkts)を引いた値に設定することにより、再送信バーストが回避620される。
pipe=retran_data+(snd.max−SRP)−(SRPを超えるsacked_pkts)
さらに、輻輳ウインドウ「cwnd」が、ウインドウと、パイプ値に2MSSという初期ウインドウ値を足した値の間で小さい方の値になるように調整される。すなわち、
cwnd=min(cwnd,pipe+(2MSS))
次に、データが、失われたものと考えられるSRP未満のデータパケットの形態で送信625される。
部分的ACKのその後の受信により、パイプ値が、元のパイプ値から受信確認されたデータのサイズを引いた値に再設定されること(すなわち、pipe=pipe−data_acked)、および輻輳ウインドウ「cwnd」が、「ssthresh」未満である場合、輻輳ウインドウ「cwnd」に最大セグメントサイズ「MSS」を足した値に再設定されること(すなわち、cwnd=cwnd+MSS)を含め、状態値が再設定630されることがもたらされる。安定したデータフローを維持するため、パイプ値が輻輳ウインドウ未満であるものと想定すると(すなわち、pipe<cwnd)、例えば、部分的に受信確認される最も古いデータが、送信側ホスト115から再送信625される。
部分的なACKの否定的な判定610により、ACKが重複ACKであることが示唆される。したがって、パイプ値は、パイプ値からMSSを引いた値に設定635される(すなわち、pipe=pipe−MSS)。第1の部分的ACKより前に重複ACKが受信され、そのACKが、SRP未満のデータを選択的に受信確認するSACKブロックを含み、輻輳ウインドウがスロースタート閾値未満である(すなわち、cwnd<ssthresh)である場合、輻輳ウインドウは、最大セグメントサイズ「MSS」だけ増加される(すなわち、cwnd=cwnd+MSS)。安定したデータフローを維持するため、パイプ値が輻輳ウインドウ未満であるものと想定すると、失われたデータ、または新たなデータが、送信側ホスト115から(再)送信625される。
第2の再送信タイムアウトが生じた場合、前述した応答処理は終了し、周知のスロースタート処理が開始することに留意されたい。
図7は、本明細書で説明する技術を実施するのに使用することができる汎用コンピュータ環境700を示す。コンピュータ環境700は、コンピューティング環境の一実施例に過ぎず、コンピュータ環境およびネットワーク環境の利用法または機能の範囲について何ら限定を示唆するものではない。また、コンピューティング環境700が、例示的なコンピュータ環境700に示したコンポーネントのいずれかの1つ、または組み合わせに関していかなる依存関係も要件も有するものと解釈してはならない。
コンピュータ環境700は、コンピュータ702の形態で汎用コンピューティングデバイスを含む。コンピュータ702のコンポーネントには、1つまたは複数のプロセッサまたは処理装置704、システムメモリ706、ならびにプロセッサ704からシステムメモリ706までを含む様々なシステムコンポーネントを繋ぐシステムバス708が含まれることが可能であるが、これには限定されない。
システムバス708は、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート(accelerated graphics port)、およびプロセッサバスまたはローカルバスを含め、いくつかのタイプのバス構造のいずれかの1つまたは複数を表す。例としては、そのようなアーキテクチャとして、インダストリスタンダードアーキテクチャ(Industry Standard Architecture)(ISA)バス、マイクロチャネルアーキテクチャ(Micro Channel Architecture)(MCA)バス、エンハンストISA(Enhanced ISA)(EISA)バス、ビデオエレクトロニクススタンダーズアソシエーション(Video Electronics Standards Association)(VESA)ローカルバス、メザニン(Mezzanine)バスとしても知られるペリフェラルコンポーネントインターコネクツ(Peripheral Component Interconnects)(PCI)バス、PCIエクスプレス(Express)バス、ユニバーサルシリアルバス(Universal Serial Bus)(USB)、セキュアデジタル(Secure Digital)(SD)バス、またはIEEE1394バス、すなわち、FireWireバスを挙げることができる。
コンピュータ702は、様々なコンピュータ可読媒体を含むことが可能である。そのような媒体は、コンピュータ702がアクセスすることができる任意の利用可能な媒体であることが可能であり、揮発性媒体と不揮発性媒体、リムーバブルな媒体と非リムーバブルの媒体がともに含まれる。
システムメモリ706は、ランダムアクセスメモリ(RAM)710のような揮発性メモリの形態、および/または読み出し専用メモリ(ROM)712またはフラッシュRAMのような不揮発性メモリの形態でコンピュータ可読媒体を含む。起動中などに、コンピュータ702内部の要素間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム(BIOS)714が、ROM712またはフラッシュRAMの中に格納される。RAM710は、通常、処理装置704が即時にアクセスすることができ、かつ/または現在、操作されているデータおよび/またはプログラムモジュールを含む。
コンピュータ702は、他のリムーバブルな/非リムーバブルの、揮発性/不揮発性のコンピュータ記憶媒体も含むことが可能である。例として、図7は、非リムーバブルの不揮発性の磁気媒体(図示せず)に対して読み取りおよび書き込みを行うためのハードディスクドライブ716、リムーバブルな不揮発性の磁気ディスク720(例えば、「フロッピー(登録商標)ディスク」)に対して読み取りおよび書き込みを行うための磁気ディスクドライブ718、およびCD−ROM、DVD−ROM、または他の光媒体などのリムーバブルな不揮発性の光ディスク724に対して読み取りおよび/または書き込みを行うための光ディスクドライブ722を示す。ハードディスクドライブ716、磁気ディスクドライブ718、および光ディスクドライブ722はそれぞれ、1つまたは複数のデータ媒体インタフェース725でシステムバス708に接続される。代替として、ハードディスクドライブ716、磁気ディスクドライブ718、および光ディスクドライブ722は、1つまたは複数のインタフェース(図示せず)でシステムバス708に接続することもできる。
以上のディスクドライブ、およびそれらに関連するコンピュータ可読媒体により、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性の記憶がコンピュータ702に提供される。実施例は、ハードディスク716、リムーバブルな磁気ディスク720、およびリムーバブルな光ディスク724を示しているが、磁気カセットまたは他の磁気記憶装置、フラッシュメモリカード、CD−ROM、デジタルバーサタイルディスク(DVD)または他の光ストレージ、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、電気的に消去可能なプログラマブル読み出し専用メモリ(EEPROM)などの、コンピュータがアクセスすることができるデータを格納することができる他のタイプのコンピュータ可読媒体も、例示的なコンピューティングシステムおよびコンピューティング環境を実施するのに利用できることが理解されよう。
例として、オペレーティングシステム726、1つまたは複数のアプリケーションプログラム728、その他のプログラムモジュール730、およびプログラムデータ732を含め、任意の数のプログラムモジュールが、ハードディスク716、磁気ディスク720、光ディスク724、ROM712、および/またはRAM710に格納されることが可能である。そのようなオペレーティングシステム726、1つまたは複数のアプリケーションプログラム728、他のプログラムモジュール730、およびプログラムデータ732(またはそれらの何らかの組み合わせ)により、分散ファイルシステムをサポートする常駐コンポーネントのすべて、または一部が実装されることが可能である。
ユーザは、キーボード734やポインティングデバイス736(例えば、「マウス」)などの入力デバイスを介して、コマンドおよび情報をコンピュータ702に入力することができる。その他の入力デバイス738(特に図示せず)には、マイク、ジョイスティック、ゲームパッド、サテライトディッシュ、シリアルポート、スキャナ、および/または以上に類するデバイスが含まれることが可能である。以上の入力デバイス、およびその他の入力デバイスは、システムバス708に繋がれた入出力インタフェース740を介して処理装置704に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス(USB)などの他のインタフェースまたはバス構造で接続してもよい。
モニタ742、またはその他のタイプのディスプレイデバイスも、ビデオアダプタ744などのインタフェースを介してシステムバス708に接続されることが可能である。モニタ742に加え、他の出力周辺デバイスには、入出力インタフェース740を介してコンピュータ702に接続することができるスピーカ(図示せず)やプリンタ746などのコンポーネントが含まれることが可能である。
コンピュータ702は、リモートコンピューティングデバイス748などの1つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境において動作することができる。一例として、リモートコンピューティングデバイス748は、PC、ポータブルコンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、または他の一般的なネットワークノードなどであることが可能である。リモートコンピューティングデバイス748は、コンピュータ702に関連して本明細書で説明した要素および特徴の多く、またはすべてを含むことが可能なポータブルコンピュータとして例示している。また、コンピュータ702は、ネットワーク化されていない環境において動作することも可能である。
コンピュータ702とリモートコンピュータ748の間の論理接続をローカルエリアネットワーク(LAN)750および汎用ワイドエリアネットワーク(WAN)752として示す。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的である。
LANネットワーキング環境で実施される場合、コンピュータ702は、ネットワークインタフェースまたはネットワークアダプタ754を介してローカルネットワーク750に接続される。WANネットワーキング環境で実施される場合、コンピュータ702は、通常、ワイドネットワーク752を介して通信を確立するためのモデム756、または他の手段を含む。コンピュータ702の内部にあることも、外部にあることも可能なモデム756は、入出力インタフェース740、または他の適切な機構を介してシステムバス708に接続されることが可能である。例示したネットワーク接続は、実施例に過ぎず、コンピュータ702とコンピュータ748の間で少なくとも1つの通信リンクを確立するための他の手段も使用することができる。
コンピューティング環境700で例示したようなネットワーク化された環境では、コンピュータ702に関連して示したプログラムモジュール、またはその諸部分は、リモートメモリ記憶装置の中に格納されることが可能である。例として、リモートアプリケーションプログラム758は、リモートコンピュータ748のメモリデバイス上に存在する。例示のため、アプリケーションまたはプログラム、ならびにオペレーティングシステムなどの他の実行可能プログラムコンポーネントは、本明細書で別々のブロックとして示しているが、そのようなプログラムおよびコンポーネントは、様々な時点で、コンピューティングデバイス702の異なるストレージコンポーネントの中に存在し、コンピュータの少なくとも1つのデータプロセッサによって実行されることが理解されよう。
様々なモジュールおよび技術は、本明細書で、1つまたは複数のコンピュータまたは他のデバイスによって実行される、プログラムモジュールなどの、コンピュータ実行可能命令の一般的なコンテキストで説明することができる。プログラムモジュールには、一般に、特定のタスクを実行する、または特定の抽象データ型を実装するためのルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。通常、プログラムモジュールの機能は、様々な実施形態において所望に応じて組み合わせることも、分散させることもできる。
以上のモジュールおよび技術の実装は、何らかの形態のコンピュータ可読媒体上に格納すること、または何らかの形態のコンピュータ可読媒体を介して伝送することができる。コンピュータ可読媒体は、コンピュータがアクセスすることができる任意の利用可能な媒体であることが可能である。例として、限定としてではなく、コンピュータ可読媒体は、「コンピュータ記憶媒体」および「通信媒体」を含むことが可能である。
「コンピュータ記憶媒体」には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を格納するために任意の方法または技術で実装された揮発性媒体および不揮発性媒体、リムーバブルな媒体および非リムーバブルの媒体が含まれる。コンピュータ記憶媒体には、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD−ROM、デジタルバーサタイルディスク(DVD)または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、あるいは所望の情報を格納するのに使用することができ、コンピュータがアクセスすることができる他の任意の媒体が含まれるが、以上には限定されない。
「通信媒体」は、通常、搬送波や他のトランスポート機構などの変調されたデータ信号中にコンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを具現化する。通信媒体には、あらゆる情報伝達媒体も含まれる。「変調されたデータ信号」という用語は、信号内に情報を符号化するような形で特性の1つまたは複数が設定または変更されている信号を意味する。限定的ではない単なる例として、通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体、ならびに音響媒体、RF媒体、赤外線媒体、およびその他の無線媒体などの無線媒体が含まれる。また、以上の媒体のいずれかの組み合わせも、コンピュータ可読媒体の範囲内に含まれる。
本明細書全体で、「一実施形態」、「実施形態」、または「例示的な実施形態」について述べており、これは、説明する特定の特徴、構造、または特性が本発明の少なくとも1つの実施形態に含まれることを意味する。このため、そのような言い回しの使用は、1つだけにとどまらない実施形態を指すことが可能である。さらに、説明する特徴、構造、または特性は、1つまたは複数の実施形態において任意の適切な形で組み合わせることができる。
ただし、本発明は、特定の詳細の1つまたは複数を伴わずに、または他の方法、リソース、資材などを使用して実施することも可能なことを、当業者は理解できよう。その他、周知の構造、リソース、または動作は、単に本発明の諸態様を不明瞭にするのを避けるため、詳細に図示したり説明することはしていない。
本発明の例示的な実施形態および応用例を図示し、説明してきたが、本発明は、以上に説明した構成およびリソースそのものには限定されないことを理解されたい。請求する本発明の範囲を逸脱することなく、本明細書で開示する本発明の方法およびシステムの構成、動作、および詳細において、当業者に明らかな様々な改変、変更、および変形を行うことができる。
無線ネットワークを介して通信する、スプリアスタイムアウトに応答するための技術を実施するデバイスを示す図である。 本明細書で説明する例示的な実施形態を実施するための通信環境を示す図である。 スプリアスタイムアウトに応答するためのプロセスを示す流れ図である。 図3に示したスプリアスタイムアウトに応答するためのプロセスの態様の実施例を示す図である。 図3に示したスプリアスタイムアウトに応答するためのプロセスの態様の実施例を示す図である。 図3に示したスプリアスタイムアウトに応答するためのプロセスの態様の実施例を示す図である。 本明細書で説明する技術を実施するのに使用することができる汎用コンピュータネットワーク環境を示す図である。
符号の説明
102 ネットワーク
117 プロセッサ
119 タイムアウト応答プロセス
205 データパケット送信機
210 送信タイマ/タイムアウト検出器
215 タイムアウト応答プロセッサ

Claims (21)

  1. スプリアスタイムアウトに応答するための方法であって、
    輻輳状態値を調整するステップと、
    前記調整された輻輳状態値に従ってネットワーク上のデータフローを維持するステップと、
    以前に送信されたデータを、前記以前に送信されたデータが前記ネットワーク上で失われたと考えられる場合、再送信するステップとを備え
    前記輻輳状態値を調整するステップは、
    スロースタート閾値を復元するステップと、
    輻輳ウインドウの初期値を再設定するステップと、
    送信側ホストによって送信されることが可能な最大セグメントサイズを、現時点までに送信された最大シーケンス番号と、まだ受信確認されていない最小シーケンス番号との差に加算してパイプ値を設定するステップと、を含む
    ことを特徴とする方法。
  2. 前記スロースタート閾値は、前記タイムアウトに先立って検出された使用可能な帯域幅の値であることを特徴とする請求項に記載の方法。
  3. 前記輻輳ウインドウの初期値を再設定するステップは、最大データセグメントサイズの2倍になるように前記輻輳ウインドウを設定するステップを含むことを特徴とする請求項に記載の方法。
  4. 前記調整された輻輳状態値に従ってデータフローを維持するステップは、
    データパケットを送信するステップと、
    受信確認を受信するステップと、
    前記送信側ホストによって送信されることが可能な前記最大データセグメントサイズを加算することによって前記輻輳ウインドウを再設定するステップとを含むことを特徴とする請求項に記載の方法。
  5. 以前に送信されたデータを、前記以前に送信されたデータが前記ネットワーク上で失われたと考えられる場合に再送信するステップは、3つの重複受信確認が送信側ホストによって受信された場合に、以前に送信されたデータを再送信するステップを含むことを特徴とする請求項に記載の方法。
  6. スロースタート回復プロセスを実施するステップをさらに備えることを特徴とする請求項に記載の方法。
  7. 前記スロースタート回復プロセスを実施するステップは、
    前記パイプ値を再調整するステップと、
    受信された受信確認のパターンに従って前記輻輳ウインドウのサイズを再設定するステップとを含む
    ことを特徴とする請求項に記載の方法。
  8. ネットワーク上でスプリアスタイムアウトに応答するための方法であって、
    送信側ホストが、受信確認を受信するまでに前記ネットワークを介して送信することができるデータの限度を設定するステップを含む、輻輳状態値を復元するステップと、
    前記スプリアスタイムアウトに先立つ使用可能な帯域幅の閾値を復元するステップと、
    前記スプリアスタイムアウトに先立つ前記ネットワーク上のデータの推定に基づくパイプ値を調整するステップであって、前記パイプ値は、送信側ホストによって送信されることが可能な最大セグメントサイズを、送信された最大シーケンス番号と、まだ受信確認されていない最小シーケンス番号との差に加算することに基づく、ステップと、
    前記送信側ホストからのデータフローを維持するステップであって、前記データは、前記パイプ値が輻輳状態ウインドウ未満であるときに送信される、ステップと、
    受信確認を受信すると、前記送信側ホストが、受信確認を受信するまでに前記ネットワークを介して送信することができるデータの前記限度を再設定するステップと
    を備えることを特徴とする方法。
  9. 前記送信側ホストが、受信確認を受信するまでに前記ネットワークを介して送信することができるデータの前記限度は、前記送信側ホストが送信することができる前記最大データセグメントサイズの2倍に設定されることを特徴とする請求項に記載の方法。
  10. 前記送信側ホストが、受信確認を受信するまでに前記ネットワークを介して送信することができるデータの前記限度は、受信確認が受信されると、前記送信側ホストが送信することができる前記最大データセグメントサイズを加算することによって再設定されることを特徴とする請求項に記載の方法。
  11. 前記ネットワークを介して以前に送信されたデータが、前記ネットワーク上で失われたことが確認された場合、データを再送信するステップをさらに備えることを特徴とする請求項に記載の方法。
  12. 前記ネットワーク介して以前に送信されたデータは、3つの重複受信確認が受信されると、前記ネットワーク上で失われたことが確認されることを特徴とする請求項11に記載の方法。
  13. 前記データフローを維持するステップは、スロースタート回復プロセスに従ってデータフローを維持することを特徴とする請求項に記載の方法。
  14. ネットワーク上でスプリアスタイムアウトを検出すると、少なくとも1つのプロセッサに、請求項1に記載のステップを実行させる少なくとも1つの命令を有することを特徴とするコンピュータ可読記憶媒体。
  15. スプリアスタイムアウト回復するための装置であって、
    データパケットを送信する送信機と、
    スプリアスタイムアウトを検出する送信タイマと、
    データがネットワーク上で失われたことが確認されるまでデータフローを維持する応答プロセッサとを備え
    前記応答プロセッサは、
    輻輳状態値を調整するステップと、
    前記調整された輻輳状態値に従ってネットワーク上のデータフローを維持するステップと、
    以前に送信されたデータを、前記以前に送信されたデータが前記ネットワーク上で失われたと考えられる場合、再送信するステップと、を実行するものであり、
    前記輻輳状態値を調整するステップは、
    スロースタート閾値を復元するステップと、
    輻輳ウインドウの初期値を再設定するステップと、
    送信側ホストによって送信されることが可能な最大セグメントサイズを、現時点までに送信された最大シーケンス番号と、まだ受信確認されていない最小シーケンス番号との差に加算してパイプ値を設定するステップと、
    前記ネットワーク上のバイト数の送信側の推定であるパイプ値を設定するステップであって、前記パイプ値の設定は、送信側ホストによって送信されることが可能な最大セグメントサイズを、送信された最大シーケンス番号と、まだ受信確認されていない最小シーケンス番号との差に加算することを含む、ステップと、
    前記調整された輻輳状態値に従ってネットワーク上のデータフローを維持するステップと、
    以前に送信されたデータを、前記以前に送信されたデータが前記ネットワーク上で失われたと考えられる場合に、再送信するステップと、を含む
    ことを特徴とする装置。
  16. 輻輳状態値を調整するステップは、
    送信側ホストが、受信確認を受信するまでに送信することができるデータの量に対する限度を、前記送信側ホストが送信することができるデータセグメントのサイズの2倍に設定するステップであることを特徴とする請求項15に記載の装置。
  17. 前記調整された輻輳状態値に従って前記ネットワーク上のデータフローを維持するステップは、
    受信確認を受信すると、送信側ホストが、受信確認を受信するまでに送信することができるデータの量に対する制限を、前記送信側ホストが送信することができるデータセグメントのサイズを加算することによって再設定するステップ、および
    前記ネットワーク上でデータを送信するステップであることを特徴とする請求項15に記載の装置。
  18. 以前に送信されたデータを、前記以前に送信されたデータが前記ネットワーク上で失われたと考えられる場合に再送信するステップは、3つの重複受信確認が受信されると、前記以前に送信されたデータを再送信するステップであることを特徴とする請求項15に記載の装置。
  19. スロースタート回復をさらに処理することを特徴とする請求項15に記載の装置。
  20. スプリアスタイムアウトに応答するための方法であって、
    送信側ホストが送信したデータに関する受信確認を受領するまでのタイムアウトがスプリアスタイムアウトである場合に輻輳状態値を調整するステップと、
    前記調整された輻輳状態値に従ってネットワーク上のデータフローを維持するステップと、
    前記データフローを維持している間に、以前に送信されたデータに対する受信確認を受信するステップと、
    前記受信した受信確認が、前記スプリアスタイムアウトが検出された時点(SRP)の前に送信されたデータに対する受信確認を示しているかに基づいて、以前に送信されたデータのいくつかが前記ネットワーク上で失われたかを判定するステップと、
    前記ネットワーク上で失われたと判定されたデータを再送信するステップと、を備え
    前記輻輳状態値を調整するステップは、
    スロースタート閾値を前記タイムアウトが検出された時点より前の値に復元するステップと、
    輻輳ウインドウの初期値を再設定するステップと、
    送信側ホストによって送信されることが可能な最大セグメントサイズを、現時点までに送信された最大シーケンス番号と、まだ受信確認されていない最小シーケンス番号との差に加算してパイプ値を設定するステップと、を含む
    ことを特徴とする方法。
  21. スプリアスタイムアウトに応答するための方法であって、
    送信側ホストが送信したデータに関する受信確認を受領するまでのタイムアウトがスプリアスタイムアウトである場合に輻輳状態値を調整するステップと、
    前記調整された輻輳状態値に従ってネットワーク上のデータフローを維持するステップと、
    前記データフローを維持している間に、以前に送信されたデータに対する受信確認を受信するステップと、
    前記受信した受信確認が、以前に受信した受信確認と同一のシーケンス番号、または受信確認されていない1以上のデータの最小シーケンス番号よりも小さいシーケンス番号、を有する重複受信確認であるかを判定するステップと、
    3つの前記重複受信確認が送信側ホストによって受信された場合に受信確認が受信されていないデータが前記ネットワーク上で失われたと判定し、当該失われたデータを再送信するステップとを備え、
    前記輻輳状態値を調整するステップは、
    スロースタート閾値を前記タイムアウトが検出された時点より前の値に復元するステップと、
    輻輳ウインドウの初期値を再設定するステップと、
    送信側ホストによって送信されることが可能な最大セグメントサイズを、現時点までに送信された最大シーケンス番号と、まだ受信確認されていない最小シーケンス番号との差に加算してパイプ値を設定するステップと、を含む
    ことを特徴とする方法。
JP2005072478A 2004-03-15 2005-03-15 スプリアスタイムアウトに対する応答 Expired - Fee Related JP4589764B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/800,897 US7397759B2 (en) 2004-03-15 2004-03-15 Response for spurious timeout

Publications (2)

Publication Number Publication Date
JP2005269643A JP2005269643A (ja) 2005-09-29
JP4589764B2 true JP4589764B2 (ja) 2010-12-01

Family

ID=34838876

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005072478A Expired - Fee Related JP4589764B2 (ja) 2004-03-15 2005-03-15 スプリアスタイムアウトに対する応答

Country Status (7)

Country Link
US (1) US7397759B2 (ja)
EP (1) EP1578070B1 (ja)
JP (1) JP4589764B2 (ja)
KR (1) KR101130479B1 (ja)
CN (1) CN1671094B (ja)
AT (1) ATE424674T1 (ja)
DE (1) DE602005013016D1 (ja)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7623464B2 (en) * 2004-07-09 2009-11-24 Cisco Technology, Inc. Rapid protocol failure detection
US7706274B2 (en) * 2004-07-29 2010-04-27 Dell Products L.P. High performance TCP for systems with infrequent ACK
US7903546B2 (en) * 2005-01-14 2011-03-08 Cisco Technology, Inc. Detecting unavailable network connections
JP4445012B2 (ja) * 2005-03-25 2010-04-07 富士通株式会社 パケットの配信帯域制御方法、配信装置及び映像配信システム
US7965771B2 (en) * 2006-02-27 2011-06-21 Cisco Technology, Inc. Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network
US8218654B2 (en) * 2006-03-08 2012-07-10 Cisco Technology, Inc. Method for reducing channel change startup delays for multicast digital video streams
US8031701B2 (en) 2006-09-11 2011-10-04 Cisco Technology, Inc. Retransmission-based stream repair and stream join
US8418016B2 (en) 2006-10-05 2013-04-09 Ntt Docomo, Inc. Communication system, communication device, and communication method
US7937531B2 (en) 2007-02-01 2011-05-03 Cisco Technology, Inc. Regularly occurring write back scheme for cache soft error reduction
US8769591B2 (en) 2007-02-12 2014-07-01 Cisco Technology, Inc. Fast channel change on a bandwidth constrained network
US7940644B2 (en) * 2007-03-14 2011-05-10 Cisco Technology, Inc. Unified transmission scheme for media stream redundancy
US20080253369A1 (en) * 2007-04-16 2008-10-16 Cisco Technology, Inc. Monitoring and correcting upstream packet loss
US8205140B2 (en) * 2007-05-10 2012-06-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for the use of network coding in a wireless communication network
US8787153B2 (en) 2008-02-10 2014-07-22 Cisco Technology, Inc. Forward error correction based data recovery with path diversity
US8495238B1 (en) * 2008-05-28 2013-07-23 Google Inc. Facilitating self-tuning traffic shaping without a central traffic manager
US8019899B2 (en) * 2008-08-28 2011-09-13 Yahoo! Inc. Delivering partially processed results based on system metrics in network content delivery systems
US9294219B2 (en) * 2008-09-30 2016-03-22 Qualcomm Incorporated Techniques for supporting relay operation in wireless communication systems
US9203564B2 (en) * 2008-10-20 2015-12-01 Qualcomm Incorporated Data transmission via a relay station in a wireless communication system
JP5080654B2 (ja) * 2008-12-05 2012-11-21 株式会社エヌ・ティ・ティ・ドコモ 通信装置、通信方法
US8274886B2 (en) * 2009-10-28 2012-09-25 At&T Intellectual Property I, L.P. Inferring TCP initial congestion window
US8625622B2 (en) 2009-12-25 2014-01-07 Cisco Technology, Inc. Increasing transmission rate to a remote device in response to attributing information loss as not being a result of network congestion
WO2012132283A1 (ja) * 2011-03-28 2012-10-04 日本電気株式会社 通信装置およびその通信制御方法
CN102664867B (zh) * 2012-03-15 2014-11-19 南京邮电大学 一种卫星通信系统中的传输协议的增强方法
US9413797B2 (en) * 2013-04-23 2016-08-09 Gurulogic Microsystems Oy Data communication system and method
CN104202257B (zh) * 2014-09-12 2017-07-21 大连大学 一种基于带宽估计的卫星网络拥塞控制方法
EP3560207A1 (en) 2016-12-21 2019-10-30 British Telecommunications Public Limited Company Managing congestion response during content delivery
EP3560152B1 (en) 2016-12-21 2023-04-12 British Telecommunications public limited company Determining the bandwidth of a communication link
GB201621854D0 (en) * 2016-12-21 2017-02-01 British Telecomm Managing congestion response during content delivery
CN110115042B (zh) 2016-12-29 2023-02-21 英国电讯有限公司 在网络中输送视频序列的方法、数据发送器
CN108574644B (zh) * 2017-09-15 2021-05-14 北京金山云网络技术有限公司 一种tcp连接恢复方法、装置、电子设备及存储介质
CN110266446B (zh) * 2019-05-15 2022-05-20 网宿科技股份有限公司 一种基于sack模式调整乱序时长的方法和装置
CN114785462A (zh) * 2022-04-13 2022-07-22 广州国巡机器人科技有限公司 一种防丢包的通信方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7046672B2 (en) * 2000-11-16 2006-05-16 Microsoft Corporation Robust, inferentially synchronized transmission of compressed transport-layer-protocol headers
CN1134135C (zh) * 2000-11-22 2004-01-07 深圳市中兴通讯股份有限公司 一种应用于双网容错系统的通讯方法
US7099273B2 (en) * 2001-04-12 2006-08-29 Bytemobile, Inc. Data transport acceleration and management within a network communication system
FR2830397B1 (fr) 2001-09-28 2004-12-03 Evolium Sas Procede pour ameliorer les performances d'un protocole de transmission utilisant un temporisateur de retransmission
US7609640B2 (en) * 2003-12-19 2009-10-27 Nokia Corporation Methods and applications for avoiding slow-start restart in transmission control protocol network communications
US7310682B2 (en) * 2004-01-08 2007-12-18 Lsi Corporation Systems and methods for improving network performance

Also Published As

Publication number Publication date
US7397759B2 (en) 2008-07-08
DE602005013016D1 (de) 2009-04-16
KR20060043648A (ko) 2006-05-15
EP1578070B1 (en) 2009-03-04
EP1578070A1 (en) 2005-09-21
US20050201279A1 (en) 2005-09-15
KR101130479B1 (ko) 2012-03-27
CN1671094A (zh) 2005-09-21
ATE424674T1 (de) 2009-03-15
CN1671094B (zh) 2010-08-18
JP2005269643A (ja) 2005-09-29

Similar Documents

Publication Publication Date Title
JP4589764B2 (ja) スプリアスタイムアウトに対する応答
US11876714B2 (en) Method and apparatus for network congestion control based on transmission rate gradients
US8094557B2 (en) Adaptive fast retransmit threshold to make TCP robust to non-congestion events
US7296206B2 (en) Communication device, transmission control method, and program product
US7035291B2 (en) TCP transmission acceleration
JP5020076B2 (ja) 低頻度ackのシステムに適した高性能tcp
WO2013012604A1 (en) System and method for reliable virtual bi-directional data stream communications with single socket point-to-multipoint capability
KR100547749B1 (ko) 재전송 타임아웃 수를 줄이기 위한 전송 제어 프로토콜의혼잡제어 방법과 시스템
JP2010093862A (ja) 通信装置及び通信方法
US8607114B2 (en) Communication device and communication method
EP3939191B1 (en) Device and method for delivering acknowledgment in network transport protocols
EP3574600B1 (en) Communication protocol packet retransmission
Hurtig et al. Tcp and stream control transmission protocol (sctp) rto restart
KR100913897B1 (ko) 재전송 타임아웃 수를 줄이기 위한 전송 제어 프로토콜혼잡제어방법
JP2004222271A (ja) 伝送制御方法、通信装置、通信システム及びプログラム
Hurtig et al. Rfc 7765: Tcp and stream control transmission protocol (sctp) rto restart

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080307

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100402

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100701

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: 20100903

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: 20100910

R150 Certificate of patent or registration of utility model

Ref document number: 4589764

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130917

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

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

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