(57)【要約】  TCP送信により現在利用可能なネットワークパス帯域幅の利用率を最大化する方法が開示される。本発明の実施形態では、現在利用可能な帯域幅の大部分（または全帯域幅）を、各特定の接続および、本発明を利用するネットワークパスについて、自動的に検知して利用することができる。さらに、本発明の一部の実施形態では、本技術を実装するソフトウェアに、データ送信側のみで動作させ、標準的な受信器と通信させることができる。本発明の実施形態では、本発明を実装するソフトウェアを、TCP／ＩＰプロトコルドライバと、ネットワークインタフェースドライバとの間に配置してよい。このような仲介ソフトウェアは、実際のネットワーク状態をTCP／ＩＰドライバから隠して、TCP接続SWNDエッジを早期スプーフデータ受領確認およびパケット損失隠蔽によってシフトさせることができる。【選択図】図１
2012515491.tif 000002
【特許請求の範囲】
【請求項１】
混雑を回避しつつコンピュータによりネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信する方法であって、
送信されたセグメントのラウンドトリップ時間（RTT）を計算する段階と、
計算された前記RTTに基づいて送信ウィンドウのサイズを、送信レートに依存せずに修正する段階と
を備える方法。
【請求項２】
前記プロトコルは、送信制御プロトコル（TCP）である請求項１に記載の方法。
【請求項３】
混雑を回避しつつコンピュータによりネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信する方法であって、
一回目にデータを送信するときに第１のモードに従って送信ウィンドウのサイズを制御する段階と、
既に送信したデータが前記ネットワークで失われているかもしれないと判断して前記既に送信したデータを再送信するときに、第２のモードに従って送信ウィンドウのサイズを制御する段階と
を備え、
前記送信ウィンドウの前記サイズを制御する前記第１のモードおよび前記第２のモードは互いに異なる方法。
【請求項４】
前記プロトコルは、送信制御プロトコル（TCP）である請求項３に記載の方法。
【請求項５】
混雑を回避しつつコンピュータによりネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信する方法であって、
送信されたセグメントのラウンドトリップ時間（RTT）を計算する段階と、
計算された前記RTTおよび計算された前記RTTの変化率に基づいて送信ウィンドウのサイズを修正する段階と
を備える方法。
【請求項６】
前記プロトコルは、送信制御プロトコル（TCP）である請求項５に記載の方法。
【請求項７】
前記送信ウィンドウのサイズを修正する段階は、
さらに、一定の期間において計算された前記RTTの変分に基づいて実行される
請求項５に記載の方法。
【請求項８】
混雑を回避しつつコンピュータによりネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信する方法であって、
送信されたセグメントのラウンドトリップ時間（RTT）を計算する段階と、
送信されたセグメントが前記ネットワークにより失われているかもしれないと判断する段階と、
計算された前記RTTと、前記セグメントが失われているかもしれないという判断とに基づいて、前記ネットワークにおいて漸進的に大きくなる混雑レベルを示す少なくとも４つの状態のうち１つで動作することを決定する段階であって、前記少なくとも４つの状態のうちの第１の状態、第２の状態、および第３の状態は、漸進的に大きくなるRTTと、失われたセグメントがないこととに関連付けられており、前記少なくとも４つの状態のうちの第４の状態は、前記セグメントが失われているかもしれないという判断に関連付けられている段階と、
前記第１の状態において動作している間に、送信ウィンドウのサイズを指数関数的に増加させる段階と、
前記第２の状態において動作している間に、送信ウィンドウのサイズを線形に増加させる段階と、
前記第３の状態において動作している間に、送信ウィンドウのサイズを線形に低減させる段階と、
前記第４の状態において動作している間に、送信ウィンドウのサイズを、前記第３の状態において利用されたものとは異なる公式に則って低減させる段階と
を備える方法。
【請求項９】
前記プロトコルは、送信制御プロトコル（TCP）である請求項８に記載の方法。
【請求項１０】
前記第４の状態において動作している間に、前に送信され、失われたと判断されたセグメントを再送信する請求項８に記載の方法。
【請求項１１】
失われたと判断されたセグメントの全ての再送信を、前記第４の状態において動作している間に実行する請求項１０に記載の方法。
【請求項１２】
前記第４の状態に入ると前記送信ウィンドウのサイズを一度低減させ、前記第４の状態が終了するまで前記送信ウィンドウのサイズの低減を再開しない請求項１０に記載の方法。
【請求項１３】
どの状態で動作するかの前記判断は、最後に計算されたRTT（NEW_RTT）と、最近計算されたなかで最小のRTTを示す所定のMIN_RTTとの差分に基づいて行われる請求項８に記載の方法。
【請求項１４】
RTTの現在の成長を計算する段階をさらに備え、
どの状態で動作するかの前記判断は、前記RTTの現在の成長に少なくとも部分的に基づいて行われる請求項１３に記載の方法。
【請求項１５】
前記RTTの現在の成長は、予め定められた受領承認の数における連続するRTTの間の変化の平滑化された移動平均に基づいている請求項１４に記載の方法。
【請求項１６】
前記少なくとも４つの状態は、セグメントが失われてしまったと判断されない間には前記RTTの現在の成長を負であるとして示す第５の状態を含み、
前記方法は、
前記第５の状態において動作している間に、前記送信ウィンドウを一定に保つ段階をさらに備える請求項１４に記載の方法。
【請求項１７】
前記第３の状態において動作している間に、混雑が主に請求項８における方法における動作により生じたものであるか、あるいは、前記ネットワーク上の他のコンピュータまたは実体が送信したデータにより生じたものであるか、を判断して、当該判断に応じて、前記送信ウィンドウを低減させるために２つのそれぞれ異なる公式を利用する段階をさらに備える請求項８に記載の方法。
【請求項１８】
ネットワークを介して、前記ネットワークに接続されているコンピュータによってデータを送信する方法であって、前記コンピュータは、送信制御プロトコル（TCP）スタックソフトウェアを含んで実行し、前記TCPスタックソフトウェアは、前記ネットワークに接続されている他のコンピュータから前記ネットワークを介して入ってくるデータを受信して、前記TCPの有効な認可されている版に従って動作して、
前記方法は、前記TCPスタックソフトウェアを顕著に修正することなく、前記TCPスタックソフトウェアの動作を修正する段階を備え、
前記TCPスタックソフトウェアの動作を修正する段階は、
前記コンピュータによりTCP修正ソフトウェアを実行して、
前記入ってくるデータが前記TCPスタックソフトウェアに到達する前に、前記TCP修正ソフトウェアに前記入ってくるデータにアクセスさせ、
前記入ってくるデータが前記TCPスタックソフトウェアに到達する前に、前記TCP修正ソフトウェアにより前記入ってくるデータを修正させて、前記TCPスタックソフトウェアの動作を変更させ、
入ってきて修正が行われた前記データを前記TCPスタックソフトウェアに送信することにより行われる方法。
【請求項１９】
前記方法は、前記TCPスタックソフトウェアを修正せずに行われる請求項１８に記載の方法。
【請求項２０】
前記入ってくるデータの修正は、前記入ってくるデータが前記コンピュータに到達した後で行われる請求項１８に記載の方法。
【請求項２１】
前記入ってくるデータの修正は、前記入ってくるデータにネットワークセグメントを追加することを含み、
前記ネットワークセグメントは、前記TCPスタックソフトウェアにより、前記ネットワークに接続されている他のコンピュータが受信したセグメントとして扱われる請求項１８に記載の方法。
【請求項２２】
前記入ってくるデータの修正は、前記入ってくるデータに格納されている、既存の入ってくるネットワークセグメントの修正を含む請求項１８に記載の方法。
【請求項２３】
前記TCPスタックソフトウェアの動作の変更によって、前記TCPスタックソフトウェアに、前記TCP修正ソフトウェアと協同して、TCPプロトコルが許可するものより大きな有効送信ウィンドウ（SWND）サイズに基づいて通信させる請求項１８に記載の方法。
【請求項２４】
前記入ってくるデータの修正は、前記入ってくるデータに１以上の早期受領確認を配置することを含む請求項２３に記載の方法。
【請求項２５】
前記早期受領確認は、前記TCP修正ソフトウェアが生成して追加する新たなネットワークセグメントに配置される請求項２４に記載の方法。
【請求項２６】
前記早期受領確認は、前記入ってくるデータの既存のネットワークセグメントに配置され、
前記既存のネットワークセグメントは、前記ネットワークに接続されている遠隔コンピュータから受信され、前記TCP修正ソフトウェアによりアクセスされ、
前記早期受領確認の配置は、前記既存のネットワークセグメントの既存の受領確認を修正することを含む請求項２４に記載の方法。
【請求項２７】
前記TCPスタックソフトウェアにより、前記ネットワークに接続されている遠隔コンピュータにデータを送信する段階と、
前記TCP修正ソフトウェアにより、前記TCPスタックソフトウェアにより送信された前記データを傍受する段階と、
前記TCP修正ソフトウェアにより、前記データを選択的にバッファリング、送信、および再送信する段階と
をさらに備える請求項２３に記載の方法。
【請求項２８】
前記TCP修正ソフトウェアにより、前記データを選択的にバッファリング、送信、および再送信する段階において、
前記TCP修正ソフトウェアと前記TCPスタックソフトウェアとが共に、前記送信制御プロトコルが許可するものより大きな送信ウィンドウ（SWND）サイズに基づいて通信して、
それ以外の場合には、前記データの送信は前記送信制御プロトコルに準拠して行われる請求項２７に記載の方法。
【請求項２９】
前記TCP修正ソフトウェアによる前記入ってくるデータの修正は、前記入ってくるデータの修正を、前記TCPスタックソフトウェアから全てのパケット損失条件を隠蔽するように行う請求項１８に記載の方法。
【請求項３０】
前記TCP修正ソフトウェアによりパケット損失条件を検知する段階と、
前記TCP修正ソフトウェアによって、前記パケット損失条件によって必要となる全ての再送信を実行する段階と
をさらに備える請求項２９に記載の方法。
【請求項３１】
コンピュータ実行可能な命令を備えるコンピュータ可読媒体であって、
前記命令は、プロセッサにより実行されると、前記プロセッサに、
混雑を回避しつつコンピュータによりネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信させ、
前記命令はさらに、前記プロセッサに、
送信されたセグメントのラウンドトリップ時間（RTT）を計算する段階と、
計算された前記RTTに基づいて送信ウィンドウのサイズを、送信レートに依存せずに修正する段階と
を行わせるコンピュータ可読媒体。
【請求項３２】
前記プロトコルは、送信制御プロトコル（TCP）である請求項３１に記載のコンピュータ可読媒体。
【請求項３３】
コンピュータ実行可能な命令を備えるコンピュータ可読媒体であって、
前記命令は、プロセッサにより実行されると、前記プロセッサに、
混雑を回避しつつネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信させ、
前記命令はさらに、前記プロセッサに、
一回目にデータを送信するときに第１のモードに従って送信ウィンドウのサイズを制御する段階と、
既に送信したデータが前記ネットワークで失われているかもしれないと判断して前記既に送信したデータを再送信するときに、第２のモードに従って送信ウィンドウのサイズを制御する段階と
を行わせ、
前記送信ウィンドウの前記サイズを制御する前記第１のモードおよび前記第２のモードは互いに異なるコンピュータ可読媒体。
【請求項３４】
前記プロトコルは、送信制御プロトコル（TCP）である請求項３３に記載のコンピュータ可読媒体。
【請求項３５】
コンピュータ実行可能な命令を備えるコンピュータ可読媒体であって、
前記命令は、プロセッサにより実行されると、前記プロセッサに、
混雑を回避しつつネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信させ、
前記命令はさらに、前記プロセッサに、
送信されたセグメントのラウンドトリップ時間（RTT）を計算する段階と、
計算された前記RTTおよび計算された前記RTTの変化率に基づいて送信ウィンドウのサイズを修正する段階と
を行わせるコンピュータ可読媒体。
【請求項３６】
前記プロトコルは、送信制御プロトコル（TCP）である請求項３５に記載のコンピュータ可読媒体。
【請求項３７】
前記送信ウィンドウのサイズを修正する段階は、
さらに、一定の期間において計算された前記RTTの変分に基づいて実行される
請求項３５に記載のコンピュータ可読媒体。
【請求項３８】
コンピュータ実行可能な命令を備えるコンピュータ可読媒体であって、
前記命令は、プロセッサにより実行されると、前記プロセッサに、
混雑を回避しつつネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信させ、
前記命令はさらに、前記プロセッサに、
送信されたセグメントのラウンドトリップ時間（RTT）を計算する段階と、
送信されたセグメントが前記ネットワークにより失われているかもしれないと判断する段階と、
計算された前記RTTと、前記セグメントが失われているかもしれないという判断とに基づいて、前記ネットワークにおいて漸進的に大きくなる混雑レベルを示す少なくとも４つの状態のうち１つで動作することを決定する段階であって、前記少なくとも４つの状態のうちの第１の状態、第２の状態、および第３の状態は、漸進的に大きくなるRTTと、失われたセグメントがないこととに関連付けられており、前記少なくとも４つの状態のうちの第４の状態は、前記セグメントが失われているかもしれないという判断に関連付けられている段階と、
前記第１の状態において動作している間に、送信ウィンドウのサイズを指数関数的に増加させる段階と、
前記第２の状態において動作している間に、送信ウィンドウのサイズを線形に増加させる段階と、
前記第３の状態において動作している間に、送信ウィンドウのサイズを線形に低減させる段階と、
前記第４の状態において動作している間に、送信ウィンドウのサイズを、前記第３の状態において利用されたものとは異なる公式に則って低減させる段階と
を行わせるコンピュータ可読媒体。
【請求項３９】
前記プロトコルは、送信制御プロトコル（TCP）である請求項３８に記載のコンピュータ可読媒体。
【請求項４０】
前記第４の状態において動作している間に、前に送信され、失われたと判断されたセグメントを再送信する請求項３８に記載のコンピュータ可読媒体。
【請求項４１】
失われたと判断されたセグメントの全ての再送信を、前記第４の状態において動作している間に実行する請求項４０に記載のコンピュータ可読媒体。
【請求項４２】
前記第４の状態に入ると、前記送信ウィンドウのサイズを一度低減させ、前記第４の状態が終了するまで前記送信ウィンドウのサイズの低減を再開しない請求項４０に記載のコンピュータ可読媒体。
【請求項４３】
どの状態で動作するかの前記判断は、最後に計算されたRTT（NEW_RTT）と、最近計算されたなかで最小のRTTを示す所定のMIN_RTTとの差分に基づいて行われる請求項３８に記載のコンピュータ可読媒体。
【請求項４４】
RTTの現在の成長を計算する段階をさらに備え、
どの状態で動作するかの前記判断は、前記RTTの現在の成長に少なくとも部分的に基づいて行われる請求項４３に記載のコンピュータ可読媒体。
【請求項４５】
前記RTTの現在の成長は、予め定められた受領承認の数における連続するRTTの間の変化の平滑化された移動平均に基づいている請求項４４に記載のコンピュータ可読媒体。
【請求項４６】
前記少なくとも４つの状態は、セグメントが失われてしまったと判断されない間には前記RTTの現在の成長を負であるとして示す第５の状態を含み、
前記命令はさらに、前記プロセッサに、
前記第５の状態において動作している間に、前記送信ウィンドウを一定に保つ段階を行わせる請求項４４に記載のコンピュータ可読媒体。
【請求項４７】
前記命令はさらに、前記プロセッサに、
前記第３の状態において動作している間に、混雑が主に前記プロセッサが送信したデータにより生じたものであるか、あるいは、前記ネットワーク上の他のコンピュータまたは実体が送信したデータにより生じたものであるか、を判断して、当該判断に応じて、前記送信ウィンドウを低減させるために２つのそれぞれ異なる公式を利用する段階を行わせる請求項３８に記載のコンピュータ可読媒体。
【請求項４８】
コンピュータ実行可能な命令を備え、TCP修正ソフトウェアを備えるコンピュータ可読媒体であって、
前記コンピュータ実行可能な命令は、ネットワークに接続されているコンピュータの一部であるプロセッサにより実行され、
前記コンピュータは、送信制御プロトコル（TCP）スタックソフトウェアを含んで実行し、前記TCPスタックソフトウェアは、前記コンピュータに、前記ネットワークに接続されている他のコンピュータから前記ネットワークを介して入ってくるデータを受信して、前記TCPの有効な認可されている版に従って動作させ、
前記命令は、
前記TCPスタックソフトウェアを顕著に修正することなく、前記TCPスタックソフトウェアの動作を修正する段階を実行して、
前記TCPスタックソフトウェアの動作を修正する段階は、
前記プロセッサに、
前記入ってくるデータが前記TCPスタックソフトウェアに到達する前に、前記入ってくるデータにアクセスさせ、
前記入ってくるデータが前記TCPスタックソフトウェアに到達する前に、前記入ってくるデータを修正させて、前記TCPスタックソフトウェアの動作を変更させ、
入ってきて修正が行われた前記データを前記TCPスタックソフトウェアに送信することにより行われるコンピュータ可読媒体。
【請求項４９】
前記命令は、前記TCPスタックソフトウェアを修正しない請求項４８に記載のコンピュータ可読媒体。
【請求項５０】
前記入ってくるデータの修正は、前記入ってくるデータが前記コンピュータに到達した後で行われる請求項４８に記載のコンピュータ可読媒体。
【請求項５１】
前記入ってくるデータの修正は、前記入ってくるデータにネットワークセグメントを追加することを含み、
前記ネットワークセグメントは、前記TCPスタックソフトウェアにより、前記ネットワークに接続されている他のコンピュータが受信したセグメントとして扱われる請求項４８に記載のコンピュータ可読媒体。
【請求項５２】
前記入ってくるデータの修正は、前記入ってくるデータに格納されている、既存の入ってくるネットワークセグメントの修正を含む請求項４８に記載のコンピュータ可読媒体。
【請求項５３】
前記TCPスタックソフトウェアの動作の変更によって、前記TCPスタックソフトウェアに、前記TCP修正ソフトウェアと協同して、TCPプロトコルが許可するものより大きな有効送信ウィンドウ（SWND）サイズに基づいて通信させる請求項４８に記載のコンピュータ可読媒体。
【請求項５４】
前記入ってくるデータの修正は、前記入ってくるデータに１以上の早期受領確認を配置することを含む請求項５３に記載のコンピュータ可読媒体。
【請求項５５】
前記早期受領確認は、前記TCP修正ソフトウェアが生成して追加する新たなネットワークセグメントに配置される請求項５４に記載のコンピュータ可読媒体。
【請求項５６】
前記早期受領確認は、前記入ってくるデータの既存のネットワークセグメントに配置され、
前記既存のネットワークセグメントは、前記ネットワークに接続されている遠隔コンピュータから受信され、前記TCP修正ソフトウェアによりアクセスされ、
前記早期受領確認の配置は、前記既存のネットワークセグメントの既存の受領確認を修正することを含む請求項５４に記載のコンピュータ可読媒体。
【請求項５７】
前記TCPスタックソフトウェアはさらに、前記ネットワークに接続されている遠隔コンピュータにデータを送信して、
前記命令はさらに、前記プロセッサに、
前記TCPスタックソフトウェアにより送信された前記データを傍受する段階と、
前記データを選択的にバッファリング、送信、および再送信する段階と
を行わせる請求項５３に記載のコンピュータ可読媒体。
【請求項５８】
前記TCP修正ソフトウェアにより、前記データを選択的にバッファリング、送信、および再送信する段階において、
前記TCP修正ソフトウェアと前記TCPスタックソフトウェアとが共に、前記送信制御プロトコルが許可するものより大きな送信ウィンドウ（SWND）サイズに基づいて通信して、
それ以外の場合には、前記データの送信は前記送信制御プロトコルに準拠して行われる請求項５７に記載のコンピュータ可読媒体。
【請求項５９】
前記入ってくるデータの修正は、前記TCPスタックソフトウェアから全てのパケット損失条件を隠蔽するように行われる請求項４８に記載のコンピュータ可読媒体。
【請求項６０】
前記命令はさらに、前記プロセッサに、
前記TCP修正ソフトウェアによりパケット損失条件を検知する段階と、
前記TCP修正ソフトウェアによって、前記パケット損失条件によって必要となる全ての再送信を実行する段階と
を行わせる請求項５９に記載のコンピュータ可読媒体。
【請求項６１】
ネットワークに接続されたコンピュータシステムであって、前記コンピュータシステムはプロセッサとメモリとを備え、前記メモリは複数の命令を含み、
前記複数の命令は、プロセッサにより実行されると、前記プロセッサに、
混雑を回避しつつコンピュータによりネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信させ、
前記複数の命令はさらに、前記プロセッサに、
送信されたセグメントのラウンドトリップ時間（RTT）を計算する段階と、
計算された前記RTTに基づいて送信ウィンドウのサイズを、送信レートに依存せずに修正する段階と
を行わせるコンピュータシステム。
【請求項６２】
前記プロトコルは、送信制御プロトコル（TCP）である請求項６１に記載のコンピュータシステム。
【請求項６３】
ネットワークに接続されたコンピュータシステムであって、前記コンピュータシステムはプロセッサとメモリとを備え、前記メモリは複数の命令を含み、
前記複数の命令は、プロセッサにより実行されると、前記プロセッサに、
混雑を回避しつつコンピュータによりネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信させ、
前記複数の命令はさらに、前記プロセッサに、
一回目にデータを送信するときに第１のモードに従って送信ウィンドウのサイズを制御する段階と、
既に送信したデータが前記ネットワークで失われているかもしれないと判断して前記既に送信したデータを再送信するときに、第２のモードに従って送信ウィンドウのサイズを制御する段階と
を行わせ、
前記送信ウィンドウの前記サイズを制御する前記第１のモードおよび前記第２のモードは互いに異なるコンピュータシステム。
【請求項６４】
前記プロトコルは、送信制御プロトコル（TCP）である請求項６３に記載のコンピュータシステム。
【請求項６５】
ネットワークに接続されたコンピュータシステムであって、前記コンピュータシステムはプロセッサとメモリとを備え、前記メモリは複数の命令を含み、
前記複数の命令は、プロセッサにより実行されると、前記プロセッサに、
混雑を回避しつつコンピュータによりネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信させ、
前記複数の命令はさらに、前記プロセッサに、
送信されたセグメントのラウンドトリップ時間（RTT）を計算する段階と、
計算された前記RTTおよび計算された前記RTTの変化率に基づいて送信ウィンドウのサイズを修正する段階と
を行わせるコンピュータシステム。
【請求項６６】
前記プロトコルは、送信制御プロトコル（TCP）である請求項６５に記載のコンピュータシステム。
【請求項６７】
前記送信ウィンドウのサイズを修正する段階は、
さらに、一定の期間において計算された前記RTTの変分に基づいて実行される
請求項６５に記載のコンピュータシステム。
【請求項６８】
ネットワークに接続されたコンピュータシステムであって、前記コンピュータシステムはプロセッサとメモリとを備え、前記メモリは複数の命令を含み、
前記複数の命令は、プロセッサにより実行されると、前記プロセッサに、
混雑を回避しつつコンピュータによりネットワークを介してデータを、スライディングウィンドウを利用するプロトコルに従って送信させ、
前記複数の命令はさらに、前記プロセッサに、
送信されたセグメントのラウンドトリップ時間（RTT）を計算する段階と、
送信されたセグメントが前記ネットワークにより失われているかもしれないと判断する段階と、
計算された前記RTTと、前記セグメントが失われているかもしれないという判断とに基づいて、前記ネットワークにおいて漸進的に大きくなる混雑レベルを示す少なくとも４つの状態のうち１つで動作することを決定する段階であって、前記少なくとも４つの状態のうちの第１の状態、第２の状態、および第３の状態は、漸進的に大きくなるRTTと、失われたセグメントがないこととに関連付けられており、前記少なくとも４つの状態のうちの第４の状態は、前記セグメントが失われているかもしれないという判断に関連付けられている段階と、
前記第１の状態において動作している間に、送信ウィンドウのサイズを指数関数的に増加させる段階と、
前記第２の状態において動作している間に、送信ウィンドウのサイズを線形に増加させる段階と、
前記第３の状態において動作している間に、送信ウィンドウのサイズを線形に低減させる段階と、
前記第４の状態において動作している間に、送信ウィンドウのサイズを、前記第３の状態において利用されたものとは異なる公式に則って低減させる段階と
を行わせるコンピュータシステム。
【請求項６９】
前記プロトコルは、送信制御プロトコル（TCP）である請求項６８に記載のコンピュータシステム。
【請求項７０】
前記第４の状態において動作している間に、前に送信され、失われたと判断されたセグメントを再送信する請求項６８に記載のコンピュータシステム。
【請求項７１】
失われたと判断されたセグメントの全ての再送信を、前記第４の状態において動作している間に実行する請求項７０に記載のコンピュータシステム。
【請求項７２】
前記第４の状態に入ると、前記送信ウィンドウのサイズを一度低減させ、前記第４の状態が終了するまで前記送信ウィンドウのサイズの低減を再開しない請求項７０に記載のコンピュータシステム。
【請求項７３】
どの状態で動作するかの前記判断は、最後に計算されたRTT（NEW_RTT）と、最近計算されたなかで最小のRTTを示す所定のMIN_RTTとの差分に基づいて行われる請求項６８に記載のコンピュータシステム。
【請求項７４】
前記複数の命令はさらに、前記プロセッサに、
RTTの現在の成長を計算する段階を行わせ、
どの状態で動作するかの前記判断は、前記RTTの現在の成長に少なくとも部分的に基づいて行われる請求項７３に記載のコンピュータシステム。
【請求項７５】
前記RTTの現在の成長は、予め定められた受領承認の数における連続するRTTの間の変化の平滑化された移動平均に基づいている請求項７４に記載のコンピュータシステム。
【請求項７６】
前記少なくとも４つの状態は、セグメントが失われてしまったと判断されない間には前記RTTの現在の成長を負であるとして示す第５の状態を含み、
前記複数の命令はさらに、前記プロセッサに、
前記第５の状態において動作している間に、前記送信ウィンドウを一定に保つ段階を行わせる請求項７４に記載のコンピュータシステム。
【請求項７７】
前記複数の命令はさらに、前記プロセッサに、
前記第３の状態において動作している間に、混雑が主に前記プロセッサが送信したデータにより生じたものであるか、あるいは、前記ネットワーク上の他のコンピュータまたは実体が送信したデータにより生じたものであるか、を判断して、当該判断に応じて、前記送信ウィンドウを低減させるために２つのそれぞれ異なる公式を利用する段階を行わせる請求項６８に記載のコンピュータシステム。
【請求項７８】
ネットワークに接続されたコンピュータシステムであって、前記コンピュータシステムはプロセッサとメモリとを備え、前記メモリは複数の命令を含み、
前記複数の命令は、送信制御プロトコル（TCP）スタックソフトウェアとTCP修正ソフトウェアとを含み、前記TCPスタックソフトウェアは、前記ネットワークに接続されている他のコンピュータから前記ネットワークを介して入ってくるデータを受信して、前記TCPの有効な認可されている版に従って動作させ、
前記TCP修正ソフトウェアは、前記プロセッサに、前記TCPスタックソフトウェアを顕著に修正することなく、前記TCPスタックソフトウェアの動作を修正する段階を実行させ、
前記TCPスタックソフトウェアの動作を修正する段階は、前記プロセッサに、
前記入ってくるデータが前記TCPスタックソフトウェアに到達する前に、前記入ってくるデータにアクセスさせ、
前記入ってくるデータが前記TCPスタックソフトウェアに到達する前に、前記入ってくるデータを修正させて、前記TCPスタックソフトウェアの動作を変更させ、
入ってきて修正が行われた前記データを前記TCPスタックソフトウェアに送信することにより行われるコンピュータシステム。
【請求項７９】
前記プロセッサは、前記TCP修正ソフトウェアを実行した結果、前記TCPスタックソフトウェアを修正しない請求項７８に記載のコンピュータシステム。
【請求項８０】
前記入ってくるデータの修正は、前記入ってくるデータが前記コンピュータに到達した後で行われる請求項７８に記載のコンピュータシステム。
【請求項８１】
前記入ってくるデータの修正は、前記入ってくるデータにネットワークセグメントを追加することを含み、
前記ネットワークセグメントは、前記TCPスタックソフトウェアにより、前記ネットワークに接続されている他のコンピュータが受信したセグメントとして扱われる請求項７８に記載のコンピュータシステム。
【請求項８２】
前記入ってくるデータの修正は、前記入ってくるデータに格納されている、既存の入ってくるネットワークセグメントの修正を含む請求項７８に記載のコンピュータシステム。
【請求項８３】
前記TCPスタックソフトウェアの動作の変更によって、前記TCPスタックソフトウェアに、前記TCP修正ソフトウェアと協同して、TCPプロトコルが許可するものより大きな有効送信ウィンドウ（SWND）サイズに基づいて通信させる請求項７８に記載のコンピュータシステム。
【請求項８４】
前記入ってくるデータの修正は、前記入ってくるデータに１以上の早期受領確認を配置することを含む請求項８３に記載のコンピュータシステム。
【請求項８５】
前記早期受領確認は、前記TCP修正ソフトウェアが生成して追加する新たなネットワークセグメントに配置される請求項８４に記載のコンピュータシステム。
【請求項８６】
前記早期受領確認は、前記入ってくるデータの既存のネットワークセグメントに配置され、
前記既存のネットワークセグメントは、前記ネットワークに接続されている遠隔コンピュータから受信され、前記TCP修正ソフトウェアによりアクセスされ、
前記早期受領確認の配置は、前記既存のネットワークセグメントの既存の受領確認を修正することを含む請求項８４に記載のコンピュータシステム。
【請求項８７】
前記TCPスタックソフトウェアはさらに、前記ネットワークに接続されている遠隔コンピュータにデータを送信して、
前記TCP修正ソフトウェアはさらに、前記プロセッサに、
前記TCPスタックソフトウェアにより送信された前記データを傍受する段階と、
前記データを選択的にバッファリング、送信、および再送信する段階と
を行わせる請求項８３に記載のコンピュータシステム。
【請求項８８】
前記TCP修正ソフトウェアの実行時に前記プロセッサにより、前記データを選択的にバッファリング、送信、および再送信する段階において、
前記TCP修正ソフトウェアと前記TCPスタックソフトウェアとが共に、前記送信制御プロトコルが許可するものより大きな送信ウィンドウ（SWND）サイズに基づいて通信して、
それ以外の場合には、前記データの送信は前記送信制御プロトコルに準拠して行われる請求項８７に記載のコンピュータシステム。
【請求項８９】
前記TCP修正ソフトウェアの実行中の前記プロセッサによる前記入ってくるデータの修正は、前記入ってくるデータの修正を、前記TCPスタックソフトウェアから全てのパケット損失条件を隠蔽するように行う請求項７８に記載のコンピュータシステム。
【請求項９０】
前記TCP修正ソフトウェアはさらに、前記プロセッサに、
前記TCP修正ソフトウェアによりパケット損失条件を検知する段階と、
前記パケット損失条件によって必要となる全ての再送信を実行する段階と
を行わせる請求項８９に記載のコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、２００９年１月１６日に提出した「送信制御プロトコルを利用した、パケットの損失および高いレイテンシーを有するネットワークにおける帯域幅利用の最大化：MAXIMIZING BANDWIDTH UTILIZATION IN NETWORKS WITH HIGH LATENCIES AND PACKET DROPS USING TRANSMISSION CONTROL PROTOCOL」なる名称の米国仮出願番号６１／１４５，５０５号明細書の優先権を主張しており、その全体を全ての目的でここに参照として組み込む。
【０００２】
本発明は、概してコンピューティングシステムおよびネットワークに係り、より詳しくは、データスループットの劣化に起因するネットワークレイテンシーおよび損失を回避するためのシステムおよび方法に係る。
【背景技術】
【０００３】
TCPは、最も幅広く利用されているネットワークプロトコルの１つである。その最も重要な特徴は、信頼性のある順位付けを行った配信にある。TCPは、データ接続を確実に行うことが要求される数多くのネットワークアプリケーションおよびサービスにより利用されている。
【０００４】
全体として今日のウェブおよびネットワーキングの基礎を成す、幅広いアプリケーションプロトコルのセットにより、TCPはトランスポート層プロトコルとして利用されている。TCPには、ＨＴＴＰ、ＦＴＰ、メールプロトコル、データベース遠隔アクセスプロトコルが含まれる。ＳＳＬに構築されるＶＰＮもTCPを利用する。このようにTCPは一般に幅広く利用されており、既存のコンピュータネットワークの殆どがこれを特徴として有している。TCPの圧倒的な普及率は、全てではないにしても殆ど全ての一般に利用されているオペレーティングシステムにTCP実装が内蔵されていることからも慮ることができる。
【０００５】
しかし、自身が動作するネットワークチャネルの利用可能な帯域幅全体を利用することができない点は、TCPの大きな欠点である。この欠点は、皮肉なことに「信頼性のある順位付けを行った配信」という前述したTCPの主な利点に起因している。つまり、TCPの信頼性を実現するための幾つかのメカニズム（例えば、スライディングウィンドウおよび混雑回避メカニズム）が、TCPの非効率性を助長させているのである。
【０００６】
TCPにおける確実な配信は、データ受領確認メカニズム（各送信データ部分を、受信側で受領確認すること）に基づいている。この目的を達成するべく、TCPパケットで送信された各データ部分に、TCPセグメントヘッダに存在するシーケンス番号を付して供給する。データが受信されると、受信側は、戻りTCPセグメントヘッダの適切な受領確認番号を設定することにより、データの送信側に、受領確認を送る。従って、入っているセグメントの受領確認番号フィールドには、ネットワークを出て、受信側に受け付けられた最大数のデータバイトが示される。データの各個々の部分の受領確認を、他のデータの送信するまで待っていたのでは、時間がかかって仕方がないことは明らかであり、この問題を解決するべく、スライディングウィンドウメカニズムが採用されている。TCP仕様では、受領確認を待つことなく前もって送信可能なデータ量（バイト単位）を示すための「センド・ウィンドウサイズ」というタームが利用される。つまり、一番最近に送信されたデータバイトと、一番最近に受信された受領確認番号との間の差異を、この「センド・ウィンドウサイズ」の値を超えないようにするのである。新たな受領確認が受信されると、このウィンドウをシフトすることで、新たなデータ部分の送信が許可される。
【０００７】
このスライディングウィンドウメカニズムはとても簡易であり、確実な配信と良好なスループットレートとを同時に実現する可能性を有する。しかし、これによって明確なスループットの上限が生じる。つまり、送信レートが、センド・ウィンドウサイズの値をRTT（バイト／秒）の値で除算した値に制限され、ここでRTTは、接続ラウンドトリップ時間（送信されてから、一番最近に受領確認された受領確認までに経過した時間である）のことである。ここで、RTT（ネットワークパスレイテンシー）が高くなると、特定のセンド・ウィンドウサイズについての送信レートが低くなることが容易に理解されるであろう。
【０００８】
上述した限界は、実際には非常に重要であって、TCPが、時間が重要な、または実行が重要な送信のトランスポートとして利用されることは少ない。高い転送レートが必要になるが、確実に送信することがあまり重要ではないＶｏＩＰ等のサービスでは、代わりに、信頼性がないが、高速なＵＤＰトランスポートが利用され、これは同様のプロトコル／サービスも同様である。
【０００９】
TCPの性能問題は、ネットワーク帯域幅が高くなるにつれて悪化する。現在利用されているTCPのセンド・ウィンドウサイズの計算アルゴリズムは、１００−２００ミリ秒のレイテンシーでブロードバンド接続の利用可能な帯域幅のうちせいぜい１０％から３０％の利用率しか達成できない場合が多い。
【００１０】
上述した限定を回避するために数多くの試みが行われてきた。これらは全て、TCPプロトコルを操作しても現行のネットワークレイテンシーを低減させる方法がないことから、センド・ウィンドウサイズを増加させたり、これを高く保ったりすることに基づいている。
【００１１】
公知のTCPに対する修正版Ｔａｈｏｅ, Ｒｅｎｏ，  Ｎｅｗ  ＲｅｎｏおよびＶｅｇａｓは全て、異なるセンド・ウィンドウサイズの計算および送信／再送信制御方法を提案しており、銘々異なるTCPの振る舞いに関するアルゴリズムを、TCPの主要フェーズ（スロースタート：Ｓｌｏｗ  Ｓｔａｒｔ，混雑回避：Ｃｏｎｇｅｓｔｉｏｎ  Ａｖｏｉｄａｎｃｅ，高速再送信および高速復帰：Ｆａｓｔ  Ｒｅｔｒａｎｓｍｉｔ ａｎｄ  Ｆａｓｔ  Ｒｅｃｏｖｅｒｙ）について記述している。
【００１２】
従ってTCPのＴａｈｏｅ版では、スロースタートおよび混雑回避フェーズが実行される。スロースタート中には、混雑ウィンドウサイズは、初期値が最大セグメントサイズに設定されてから、各到着した受領確認の受領確認されたデータサイズにより増加されるので、指数関数的に増加することとなる。混雑ウィンドウ閾値も導入される。混雑ウィンドウサイズが混雑ウィンドウ閾値に達すると、TCPは、混雑回避フェーズに入り、この間に、混雑ウィンドウサイズが線形に増加させられる（受領確認されたデータサイズを、各到着した受領確認に対する混雑ウィンドウサイズで除算したものによって）。閾値は最初は最大ウィンドウサイズに設定されている。パケットの損失時には、閾値を混雑ウィンドウサイズの半分の値に設定して、スロースタートアルゴリズムを導入する（Slow Start Algorithm is involved）。スループットを顕著に低下させてしまうTCPのＴａｈｏｅ版の主要な問題は、損失検出が遅いこと（Ｔａｈｏｅ版では、タイムアウトによってのみ損失を検知する）、および、周期的なスロースタート・フォールバックである。
【００１３】
TCPのＲｅｎｏ版は、TCPのＴａｈｏｅ版の基本コンセプトを継承しており、且つ、早期にパケットの損失を検知する「高速再送信」と称される技術が導入されている。高速再送信技術により、遠隔レシーバが、複数の重複する受領確認を利用することで、パケット損失を即座に示すことができるようになる。即座にパケット再送信を行った後で、TCPのＲｅｎｏ版は、スロースタートに対して返信せず、高速復帰を行う。ウィンドウ閾値および混雑ウィンドウサイズは、最初の混雑ウィンドウサイズの半分の値に設定される。混雑ウィンドウサイズは、重複する受領確認が到着する毎に、ＭＳＳにより増分され、混雑ウィンドウサイズが現在受領確認がとれていないデータサイズを超えている場合には、新たなデータ送信が許可される。高速復帰を行い、受領確認を新たに受け取った後で、TCPのＲｅｎｏ版は混雑回避に戻る。
【００１４】
TCPの新Ｒｅｎｏ版はTCPのＲｅｎｏ版のメカニズムを継承しているが、高速復帰フェーズの修正版を実装している。高速復帰は、パケット損失が検知されたときからネットワークに送信されたパケット全てが受領確認されるまで、終了されない。部分的な受領確認（損失検出のときから送信されたデータ量全体をカバーしない）を、次の損失の証拠として取り扱い、より多くのパケットを即座に再送信する。
【００１５】
TCPのＶｅｇａｓ版は、TCPのＲｅｎｏの修正版である。TCPのＶｅｇａｓ版は、予期された帯域幅の推定値と実際の帯域幅の推定値とに基づくさらなる混雑回避メカニズムを利用して、これらに基づいて混雑ウィンドウサイズを調節する。TCPのＶｅｇａｓ版はさらに、予期せぬ高いレベルのRTTの検知により開始される重複受領確認によりパケット損失が伝えられる前に、早期に再送信する。
【００１６】
本発明は、これら技術のいずれも踏襲しておらず、新たな技術を利用して上述した修正版のいずれもが達成しえなかった最適な帯域幅利用を実現することができる。
【発明の概要】
【００１７】
本発明の実施形態は、TCPプロトコルの修正版、および、これら修正版を既存のＯＳに導入する技術、という２つの側面を含みうる。これら側面は、互いに組み合わせて、または別個に利用することができる。
【００１８】
TCPプロトコル修正版は、既存のTCP実装を修正して、データの送信／再送信中の新たなTCPプロトコルの処理、および、センド・ウィンドウサイズ計算の新たなアルゴリズムを導入して、TCPの性能を向上させる。
【００１９】
導入技術は、既存のコンピュータシステムのホストＯＳの一部として既に提供されている可能性のある既存のTCP実装を取り除いたり、利用不能にしたりすることなく、その代わりに、既存のTCP実装の処理を修正して、そこから部分的なデータ送信制御を再試行（retake）して所望の方法で所望の結果を達成する、TCPの修正版を既存のコンピュータシステムに実装するソフトウェアを利用することが示唆されている。
【００２０】
本発明に導入されるTCP修正版によって、利用可能な帯域幅の利用率が最大化される。本発明の実施形態によるTCP修正版のスキームの利点は、同じ修正版が送信側および受信側のTCP実装で動作可能であること、という要件が不要である点である（一部の実施形態では、修正版は、送信側にあることだけを要件とする）。これが、互換性のある修正版（例えばＳＡＣＫ、ウィンドウスケーリング等）が接続の両端において必要となる従前のTCPを修正しようとする試みから、本発明の実施形態を差別化する特徴である。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施形態を、TCPプロトコルサポートが内蔵されているＯＳを実行するコンピュータシステムに導入する技術と、通信データフローを示す。
【図２】処理サブシステムのアーキテクチャおよび動作を示す。
【図３】パケット関連付けアルゴリズムを示す。
【図４】接続実体生成アルゴリズムを示す。
【図５】出力パケット処理アルゴリズムを示す。
【図６】受信パケット処理アルゴリズムを示す。
【図７】送信アルゴリズムを示す。
【図８】タイムアウトチェックおよびPLCアルゴリズムを利用する再送信を示す。
【図９】本発明の一部の実施形態におけるSWND計算アルゴリズムを示す。
【図１０】本発明の実施形態で処理機能を実装するために利用可能な典型的なコンピューティングシステム１０００を示す。
【発明を実施するための形態】
【００２２】
本発明の実施形態は、概してデータ送信／再送信アルゴリズムに係り、詳しくは、異なるTCPランタイムフェーズにおけるセンド・ウィンドウサイズ計算に係る、TCPプロトコルの修正版を導入する。
【００２３】
様々なTCPの修正版は、それらの混雑回避技術により区別可能である。TCPのＴａｈｏｅ版、Ｒｅｎｏ版、および新たなＲｅｎｏ版は、いわゆる「反応性の」混雑回避技術を利用する。これは、つまり、これら修正版が、混雑が起こった後でないと混雑を検知することができないことを意味している。反応性の混雑回避技術は、センド・ウィンドウサイズが、パケット損失の検知まで増加し続けることを想定している。パケット損失は、混雑の証拠としてみなされ、修正版に応じて必要となるアクションを実行する。このような反応には、センド・ウィンドウサイズおよびセンド・ウィンドウ閾値サイズ調節が含まれ、これにより、再送信または高速再送信が実行され、スロースタートまたは高速復帰フェーズに入る。
【００２４】
この「反応性の」混雑回避技術の欠点は、混雑回避を行わないことである。TCPは、チャネルが混雑するまでセンド・ウィンドウサイズを増加しつづけ、将来とりうる可能な方策としては、混雑を低減させて、一定の期間の間パケット損失を回避する、ということだけである。このように動作することで、TCP実装は、ある混雑から別の混雑を次々に経ることとなり、送信レートを僅かに変化させ、十分に全スループットを低減させることができる。
【００２５】
TCPのＶｅｇａｓ版は、「先を見越した（proactive）」混雑回避と称される、別のメカニズムを利用する。そのコンセプトは、実際に生じる前に混雑を回避する、というものである。TCPのＶｅｇａｓ版は、センド・ウィンドウサイズを調節する際に異なる推定値（estimations）を利用して、再送信に関する決定を行う。これら推定値は、予想された、および、実際のスループット差分値および基準値、且つ、現在のRTT差分値に基づいている。これら計測値によって、実際に殆どの混雑が回避され、送信レートが平滑化され、帯域幅利用率が最適化される。
【００２６】
全てのTCPの修正版は、同様のセンド・ウィンドウサイズ計算アルゴリズムを、各接続フェーズに対して利用している。ここでは、受信ウィンドウサイズと混雑ウィンドウサイズという２つの推定量（estimator）が利用される。センド・ウィンドウサイズは、これらのうち小さいほうに設定される。
【００２７】
スロースタートフェーズにおいては、混雑ウィンドウサイズは初期値が最大セグメントサイズに設定されており、後で指数関数的に増分される。各新たな受領確認が受信されるたびに、混雑ウィンドウは、遠隔側で受領確認されたデータのバイト数の分だけ増分される。このような指数関数的な増加は、混雑ウィンドウサイズがセンド・サイズ閾値に達するまで続けられ、その後、混雑回避フェーズに入る。
【００２８】
混雑回避フェーズは、混雑ウィンドウサイズが線形に増加することを想定している。各新たな受領確認が到着するたびに、混雑ウィンドウサイズを、受領確認されたバイト数を混雑ウィンドウサイズで除算した値分だけ、増分させる。
【００２９】
本発明の実施形態では、他のTCPの修正版と異なり、スロースタートと混雑回避フェーズとを明確に区別する必要がなく、その代わり、新たに「混雑回避しながら送信する」フェーズを利用することができる。混雑回避しながら送信するフェーズにおいては、本実施形態では、センド・ウィンドウサイズを指数関数的あるいは線形に増加させることができ、あるいは、現在のRTT値に従って減少させることができる。本発明の実施形態では、さらに、失われたパケットを再送信するとき、「再送信」フェーズ中について様々に異なるルールを利用することができる。パケット損失は、以下の条件のうちいずれかが生じた場合に生じると考えられる。条件とはつまり、特定のパケットの再送信タイムアウトに期限切れが生じた場合、特定のパケットについて三つ目の重複する受領確認が到着した、あるいは、あるパケットが、それに後続するパケットが受信器により示される選択的な受領確認ギャップにある間にその選択的な受領確認ギャップから外れている場合である。
【００３０】
本発明の実施形態は、以下に関するセンド・ウィンドウサイズ調節に関する決定に基づくことができる。ネットワークパスレイテンシーは、仲介するルータのキューの充実度に応じていてよい。ひとたびキューが空になると、即座にルータが全てのパケットを転送して、ルータキュー内でサービスを待っている状態のパケットに起因するレイテンシーはこれ以上生じない。これによって、ネットワークパスが混雑しておらず、ルータが、現在のレートでの送信を手助けすることが分かる。この場合には、パケットとその受領確認は、可能な限り短い時間でネットワークルートを通過することができる。ルータのキューにパケットが満たされ始めると、ネットワークレイテンシーが増加をし始め、パケットが通過する各ルータに僅かなに増分がみられるようになる。これにより、本発明の一部の実施形態では、ネットワークパスのルータキューの充実度を暗にトラッキングすることができるようになり、ひいては、ネットワークパスが混雑しているかを推定することでセンド・ウィンドウサイズ調節に関する決定を行うことができるようになる。
【００３１】
ネットワークパスが当初は部分的にしか混雑していない場合であっても、センド・ウィンドウサイズ調節の後で計算されたRTT（ひいては、さらなるパケットの入力）および最小RTTの間が異なっていると、これはネットワーク状態変化の証拠となる。そして差異の大きさを利用して、センド・ウィンドウサイズ調節に関する決定を行うことができる。この技法は、「レイテンシーに基づくウィンドウ調節」と称される。この技法はさらに、RTTの変分およびRTT変化速度等のパラメータを考慮に入れており、これにより、センド・ウィンドウ調節の時点および大きさに関する決定を、より精度の高いものとすることができる。
【００３２】
本発明の一部の実施形態では、センド・ウィンドウサイズ調節プロセスを実行する際に以下に説明するパラメータを利用することができる。
（１）RTTとは、ラウンドトリップ時間またはラウンドトリップ遅延時間、あるパケットの送信から、これの受領確認受信までに経過した時間のことである。
（２）MIN_RTTとは、所定の接続処理期間中に気づかれた最小RTTのことである（MIN_RTT寿命については後述する。）
（３）NEW_RTTとは、一番最近に受領確認されたセグメントのRTTである。
（４）S_RTTとは、平滑化されたRTT推定量であり、S_RTT = (S_RTT*(RTT_SW - 1) + NEW_RTT)/RTT_SWとして表され、ここでRTT_SWはRTT平滑化ウィンドウサイズであるので、S_RTTは、一番最近のRTT_SW受領確認について計測されたNEW_RTT値の平均のようなもの（a sort of an average）であり、S_RTTは実際には、元のTCP平滑化されたRTT推定値に類似している。
（５）RTT_AVARは、各受領確認について計測されたRTTの変分の絶対値であり、受領確認のVAR_SWの数について平滑化されたものであり、VAR_SWは、ウィンドウサイズを平滑化した変分である。RTT_AVAR = (RTT_AVAR*(VAR_SW - 1) + NEW_AVAR)/VAR_SWとなり、NEW_AVARは、最近計測された変分の絶対値NEW_AVAR = NEW_RTT - S_RTTである。
（６）RTT_RVAR は、 RTTの相対的な変分であり、RTT_RVAR = RTT_AVAR/S_RTTである。
（７）RTT_AGRWは、各受領確認に対して計測され、受領確認のGRW_SW数について平滑化されたRTTの絶対的な成長であり、GRW_SWは成長平滑化ウィンドウサイズである。RTT_AGRW = (RTT_AGRW*(GRW_SW - 1) + NEW_AGRW)/GRW_SWであり、ここでNEW_AGRWは、最近計測された絶対的な成長であり、NEW AGRW =新たなS_RTT - 前のS_RTTである。
（８）RTT_RGRWは、 RTT の相対成長であり、RTT_RGRW = RTT_AGRW/S_RTTである。
（９）RTOは、再送信タイムアウトであり、RTO = S_RTT*totであり、ここでtotはタイムアウト閾値を表す。
（１０）ACK_DSは、受領承認されたデータサイズであり、一番最近に受信された受領確認番号で受領確認されたバイト数である。
（１１）MAX_RWNDは、受信側がアドバタイズしたもののなかの最大受信ウィンドウサイズである。
（１２）NEW_RWNDは、最近アドバタイズされた遠隔の受信側のウィンドウサイズである。
（１３）SWNDは、送信ウィンドウサイズであり、受領確認なしに送信が許可されているバイト数である。
（１４）AWNDは、実際のウィンドウサイズ、つまり、既に送信済みであるが、まだ受領確認がとれていないバイト数のことである。
（１５）SWND_GRWは、送信ウィンドウサイズ成長であり、各SWNDの増分に対して計測され、平滑化されたものである。この値は、最新のMIN_RTT期間中に平滑化されたSWND成長である。SWND_GRWは、SWNDが同じ値で増分されるたびに増分され、SWNDは、この直後に公式SWND_GRW = SWND_GRW - SWND_GRW*(dt/MIN_RTT)に従って平滑化され、本式中において、dtは、最新の平滑化から経った時間間隔を表す。SWND_GRWは、０を下回ってはならない。
（１６）EIRTは、指数関数的に増加するRTT閾値であり、このNEW_RTT がSWNDについてMIN_RTTを超えてはならない時間の値（MIN_RTTの一部における）は、指数関数的に増加する場合がある。
（１７）EIGTは、指数関数的に増加する成長閾値であり、このRTT_RGRW/RTT_RVAR（あるいはRTT_AGRW/RTT_AVAR）がSWNDについて超えてはならない値は、指数関数的に増加する場合がある。
（１８）EIIDは、指数関数的に増加する増分除算子（increment divider）であり、これによる値によってSWND増分が指数関数的な増加中に除算される。
（１９）LIRTは、線形増加するRTT閾値であり、このNEW_RTTがSWNDについてMIN_RTTを超えてはならない時間の値（MIN_RTTの一部における）は、指数関数的に増加してよい。
（２０）LIGTは、線形増加する成長閾値であり、RTT_RGRW/RTT_RVARがこの値を超えない場合には、SWNDは線形に増加してよい。
（２１）LIIDは、線形増加する増分除算子（increment divider）であり、これによる値によってSWND増分が線形増加中に除算される。
（２２）CARTは、混雑回避RTT閾値であり（この時間の値は、MIN_RTTの一部で計測される）、NEW_RTTがCART分だけMIN_RTTを超える場合、SWNDを低減させて混雑を回避する。
（２３）CAGTは、混雑回避成長閾値であり、RTT_RGRW/RTT_RVARがこの値を超えると、SWNDを低減させて混雑を回避する。
（２４）CAWTは、混雑回避ウィンドウ成長閾値である。SWND_GRWがCAWTを超える場合には、SWNDを線形に低減させ、その他の場合には、SWNDを一定の比率で低減させる。
（２５）OAWTは、オーバフロー回避ウィンドウ閾値である。RWNDがこの値を下回った場合には、RWNDが十分な程度にアドバタイズされるまで送信を休止する。
（２６）CCRTは、特徴変更RTT閾値である。SRTTがこの閾値を超える場合には、ネットワーク状態の大幅な変更が予期され、MIN_RTT等の重要な接続パラメータをリセットおよびリフレッシュする。
（２７）CADDは、混雑回避低減除算子であり、これによる値でSWND減少子が混雑回避低減中に除算される。
（２８）PDDDは、一定の比率での低減除算子であり、混雑回避またはパケット損失時に、これによる値でSWND低減子が、一定の比率の減少中に除算される。
【００３３】
一部の実施形態では、混雑回避しながら送信を行うフェーズは、接続処理の極初期に開始される。センド・ウィンドウサイズの初期値は、m*MSSに設定されており、ここでmはセグメントの最小ウィンドウサイズであり、MSSは、この特定の接続における最大セグメントサイズである。そしてセンド・ウィンドウサイズは、重複するもののない受領確認が入力されるたびに調節される。SWND調節に関する決定は、上述したようなチャネル状態を示すRTTの値およびRTT成長の大きさに応じてなされる。一部の実施形態では、フリーである、占有されている、殆ど混雑している、混雑している、という４つのチャネル状態が存在する。フリーである、占有されている、殆ど混雑しているチャネル状態は、それぞれ、低程度、中程度、および高程度のRTT値（MIN_RTTとの比較で）により示される。混雑している状態は、RTTの値が高いことに加えて、パケットの損失により示される。SWNDは、ネットワークが、フリーである状態であると判断されている間は指数関数的に増加し、RTTがより高くなり、ネットワークが占有されている状態になると、線形増加する。RTTが高いということは、混雑している状態に近づいている証拠を示す可能性が高く、RTTの成長は、通常は、ルータキューが略満たされ、この特定の接続が送信を非常に高いレートでの送信を試みることと、その他の接続によって、同じボトルネックの帯域幅の一部を取得することとの間の差異が実際にないときに生じる。従ってネットワーク状態が「殆ど混雑している」状態であると検知されると、SWNDを低減させて、混雑の可能性を回避する。パケット損失が既に生じており、ネットワーク状態が「混雑している」場合には、「混雑を回避しながら送信する」フェーズでは対処できないが、これに関しては後述する。
【００３４】
RTT成長速度に関するさらなる条件は、SWND調節の時点を判断するために利用される。RTTは通常は即座には増加せず、ネットワークが混雑してくる間に継続して成長する。ネットワークが安定状態にあるときには、RTTは通常はS_RTTの周りを振動するので、RTTの成長は０の周りを振動する。RTTの成長が顕著になってきた、ということは、RTTが継続して増加している可能性が非常に高いことを意味する。これにより、本発明の実施形態では、前もってSWND調節に関する決定を行っておくことができるようになる。RTTの成長が少ない場合には、一部のネットワークの不安定性、および、ネットワークが「殆ど混雑している」状態に近づいていることが考えられる。この場合には、本発明の実施形態では、状態が安定化するまでの一定の期間、SWNDの増加を停止させることができる。RTTの成長が十分速くなった場合には、この特定の接続またはその他の接続が、ネットワークを混雑させ始めた可能性が高く、差分NEW_RTT - MIN_RTTが閾値を超えるまで、SWNDの低減の開始を待つ理由は存在しない。本発明の実施形態では、SWNDの低減を、RTT成長速度に基づいて開始させることができる。この技法によって、本発明の実施形態では、RTTの差分を用いる技法よりも数パケット前に、混雑している状態に近づいていることを検知することができる。これらパケットが、起こりうる混雑している状態においては損失してしまう可能性があるパケットであることを鑑みると、この点は重要であろう。
【００３５】
SWNDの増加も、RTT成長がゼロを下回るように低い場合には停止させる。このような負の成長値は、一部の接続が自身の送信を終了したこと、または混雑の後のチャネルのパージにより生じるネットワークの不安定性を示し、SWNDはこれらの場合には、状況が安定化するまで小さなRTTに対して増加させるべきではない。SWNDを不安定なときに増加させてしまうと、特定のネットワークパスについて実際の可能な最大値を超える可能性がある。しかしながら、負のRTT成長値は、混雑に近づいていることを示しているわけではないので、これについてSWNDは低減させない。
【００３６】
様々なネットワークおよびネットワークパスは、様々なRTT変分の大きさにより特徴付けられるので、RTT成長は、RTT変分により除算することで調節することができ、これにより、RTTの変分（または振動）が高いことを、RTTの成長が維持されていることと間違え易い場合にSWNDの調節に関する決定を誤ってしまう可能性の殆どを回避することができる。
【００３７】
センド・ウィンドウサイズは、NEW_RTT <= MIN_RTT*(1 + EIRT)および| RTT_ RGRW/RTT_RVARI <= EIGTの場合に指数関数的に増加する。この条件は、RTTが十分低く、ネットワークがフリーの状態であり、SWNDが高速に成長してよい場合に生じ、最大帯域幅利用率を高速に達成することができる。指数関数的な増加は、一般的には一定の値ではなくて、NEW_RTTに応じた値であり、MIN_RTT*(1 + EIRT)に近づくほど、増分が小さくなる。指数関数的な増分は、ACK_DS*{*(1 - 1/EIID) + 1/EIID}という公式に従って計算される。つまり、指数関数的な増分は、値ACK_DS (NEW_RTT = MIN_RTTのとき)と、値ACK_DS/EIID (NEW_RTT = MIN_RTT*(1 + EIRT)のとき)との間に存在する。これにより、RTTの差分が閾値に近づいている間は、指数関数的なSWNDの成長を徐々に低減させることができる。
【００３８】
MIN_RTT*(1 + EIRT) < NEW_RTT <= MIN_RTT*(1 + LIRT)およびEIGT < |RTT_RGRW/RTT_RVAR| <= LIGTの場合に、センド・ウィンドウサイズは線形に増加する。これは、これら条件においては、RTTが依然として十分低いが、ネットワークは既にいくらか占有されているので、SWNDをより精度高く増加させる必要がある、と信じられていることに起因している。線形増加はここでも一定の値ではなく、NEW_RTTに依存する。線形増加の公式は(ACK_DS/SWND)*{[(1 + LIRT)/(LIRT - EIRT) - (NEW_RTT - MIN_RTT)/(MIN_RTT* (LIRT - EIRT))] *(1/LIID)}である。つまり、線形増加は、ACK DS/LIID (NEW_RTT = MIN_RTT*(1 + EIRT) + l/∞のとき)と、0 (NEW_RTT = MIN_RTT*(1 + LIRT)のとき)との間に存在する。
【００３９】
NEW_RTT > MIN_RTT*(1 + CART)またはRTT_RGRW/RTT_RVAR) > CAGTのときにセンド・ウィンドウサイズが低減されるが、これは、ネットワークがとても混雑している状態であるので、送信レートを変更するべきであることを示す。SWNDは、SWND_GRW/CADDにより低減される。つまり、SWNDは、実質的に数RTTミリ秒前の値で低減される。これは、この時点が、連続SWND（ひいてはAWND）の増加によってネットワークの状態が悪化した時点であると思われているからである。システムは、現在のRTT経過に等しい時間まで、その計測値がなんらかの結果を生じたかに気づかないので、SWNDは、MIN_RTTごとに、よりも頻繁には低減されない。
【００４０】
NEW_RTT > MIN_RTT*(1 + CART)または|RTT_RGRW/RTT_RVAR| > CAGTであるがSWND_GRW < CAWTである場合には、現在の接続が一定の安定したレートで送信を行っているので、ネットワークは他の接続により混雑している、ということになる。従ってSWNDは、新たに出現する条件に従って調節されるべきである。利用可能な帯域幅は、公知の公式SWND/RTTに従って推定され、RTTが変化したので、SWNDも同じレートで変化しうる。従ってSWND = SWND*(MIN_RTT/NEW_RTT)となる。上述した理由により、SWNDはMIN_RTTごとに１回よりも頻繁に低減するべきではない。
【００４１】
２つの上述したSWND低減に関するコンセプトによって、一時的なネットワークの不安定性、利用可能な帯域幅を一時的に部分的に占有する臨時の少量の送信、または、特定の接続の過度な転送レートによって生じる混雑は回避することができる。しかし、大きな転送により、利用可能な帯域幅その他のネットワーク特徴はかなり長期間にわたり変更され、これはこの接続が、前に利用されていたネットワークではもはや動作できないことを示しており、接続ランタイム変数および推定値を変更する必要がでてくることを示している。全てのランタイムパラメータ計算は、気づかれうる最小のRTTであるMIN_RTT値に基づいており、基本的なネットワークパス特徴の１つである。ネットワーク状態が大幅に変更されてしまった場合には、この特徴はもはや有効とは考えられなくなる。S_RTTがMIN_RTT*(1 + CCRT)値に達した場合には、十分なネットワーク状態の変化が特定され、これはMIN_RTTリセットのトリガとなりうる。この場合には、MIN_RTTがS_RTT*fにリセットされてよく、ここでfは、最小RTT調節係数である。従ってMIN_RTT寿命は、十分なS_RTT増加により特定される感知可能なネットワーク状態変化間の期間として定義することができる。
【００４２】
システムを「混雑を回避しながら送信する」フェーズにする主要な送信条件は、AWND < SWNDであるが、遠隔の受信バッファのオーバフローを回避するためにはもう１つの制約が課される場合がある。元のTCPプロトコルは、SWNDを、CWNDとRWNDのうちの小さいほうに設定する。本発明の実施形態では、通常の場合においてウィンドウスケーリングオプションがイネーブルであっても、SWNDにかなり厳しい制約を課しているので、RWND推定値は直接利用されない。RWNDは、その時点で遠隔受信器が受領準備のできているバイト数を示し、元のTCP実装では、この制約を越える場合にこれ以上のデータは送信されない。しかし、本発明の実施形態は、この制約を無視して、SWNDを過度に成長させて、より高速な送信レートを可能とすることができる。RWNDは本発明の実施形態について利用可能なパラメータを維持していてよいが、これは実施形態の一部において、いくらAWND < SWNDという条件が満たされていても、NEW_RWND < MAX_RWND*OAWTである場合には、さらなるデータが送信されないからである。これによって、遠隔受信側のバッファのオーバフローを確実に回避することができる。アドバタイズされたRWNDが過度に下がり始めたら、遠隔受信側のバッファに、大量の順序付けの誤ったパケットがあることを示しており、この時点で順序を付け直さないと、遠隔受信器は現在の転送レートではパケットを受け付けることができない。転送レートが即座に低減されない場合には、これら条件両方によってバッファがオーバフローして、大量にパケットが失われることになる。この理由から、本発明の実施形態では、十分大きなRWNDが再度アドバタイズされるまで、送信を中断させることができる。
【００４３】
本発明の一部の実施形態では、第２のランタイムフェーズを利用することができ、これを「再送信」フェーズとする。再送信フェーズにおいては、前に失われたものとして検知されたパケットを再送信し、全ての条件が満たされていようといまいと、通常の送信を許可しない。上述したように、パケットが失われたという判断は、特定のセグメントのRTOに期限切れが生じた場合、特定のセグメントについて三つ目の重複する受領確認が到着した、あるいは、あるパケットが、それに後続するパケットが受信器により示される選択的な受領確認ギャップにある間にその選択的な受領確認ギャップから外れている場合に、行われる。
【００４４】
RTO値は、各RTT計測値に対するRTO = S_RTT*a + RTT_AVAR*bという公式に従って計算される。定期的なチェック中の特定のパケット送信時刻からRTO期間が経過したと判断されると、パケットは失われたと判断して、システムは「再送信」モードに入り、パケットを再送信する。RTOの期限切れは、通常、混雑、またはその他の深刻なネットワーク（または遠隔受信器）に生じている問題による大量のパケット損失を示している。これは、偶発的な損失または少しの混雑が生じる損失は、三つ目の重複する受領確認またはSACKによってもっと早期に発見される可能性が高いからである。RTO期限切れになり、システムがひとたび「再送信」モードに入ると、SWNDをSWND = SWND*(MIN_RTT/RTO)に調節して、次のMIN_RTT期間において、「再送信」フェーズが終了されるまでは、SWND低減を許可しないようにして、過度なSWND低減レートを回避する。
【００４５】
パケット損失は、三つ目の重複する受領確認またはSACKオプションによって、特定のパケットが受信されていないが、後続するものは受信されたと報告されることで、特定されてもよい。このようなイベントによっても、エクストリームなTCPを「再送信」フェーズにすることができ、失われたパケットを再送信することができる。しかし、このパケット損失の示唆は、通常、ネットワークがその時点で軽く混雑していること、または損失が偶発的なことであることを特定するので、利用されるSWND低減は少ない。従ってSWNDをSWND = SWND*(MIN_RTT/L_RTT)に調節するが、ここでL_RTTは「パケット損失RTT」を示し、これは、損失パケットを送信した時点からその損失が示された時点までを計測したラウンドトリップ時間である。そして、次のMIN_RTT期間において、「再送信」フェーズが終了されるまでは、SWND低減を許可しない。
【００４６】
損失したパケットの受領確認の直後に、システムは、「再送信」フェーズを終了して、「混雑回避しながら送信する」フェーズに再度入る。しかし、パケット損失が生じてしまうと、遠隔側で、損失されたパケットの後でいくつのパケットが受信されたかに応じて、「再送信」が終了してから、後で大量の受領確認が生じる場合が多い。これは、「損失に応じた」SWND調節をした後であっても、大量の受領確認によって、AWNDは「再送信」フェーズの終了時におけるSWNDよりもずっと低く見えるので、生じやすい状況である。この状況により、かなり大量のデータが過度なレートで殆ど即座に送信されてしまうことになり、これによってもより劇的なネットワークの混雑が生じる。さらなるSWND調節を「再送信」フェーズの終了時に行ってこれを回避することもできる。「再送信」フェーズの終了時にSWND > AWND + MSS*mである場合には、SWNDをAWND + MSS*mに設定するが、ここでMSSは接続における最大セグメントサイズであり、mは、最小ウィンドウサイズ（MSSにおける）である。
【００４７】
本発明の実施形態は、TCP送信および再送信メカニズムのみに関するものであってよい。TCP接続構築／閉鎖／リセット技術のいずれを邪魔することがない。さらに本発明の実施形態は、TCPで利用される上位プロトコルまたは転送データについて知っている必要がない。実施形態は、TCPで転送されるデータを、原オクテットストリームとして処理し、上位のコンテンツ／処理を邪魔する試みを行わず、修正、複写、または第三者への授与をしない。従って本実施形態におけるTCP送信／再送信メカニズムの修正版は、TCPの信頼のある順位付けを行った配信という特徴の邪魔になったり、TCPの互換性を損ねたりする必要がない。
【００４８】
＜TCP実装が内蔵されたＯＳを実行するマシンにおける技術の利用方法の説明＞
一般的に利用されているオペレーティングシステムの殆どにはTCPが実装されている。既に内蔵されているOS TCP実装を置き換えることはかなり複雑でありうる。従って本発明の実施形態では、TCP実装が内蔵されたオペレーティングシステムに対して、既存のTCP実装を完全に置き換えるのではなくて、上述した通常のTCP実装の修正を実行する技法を特徴とする。この技法は柔軟であり、殆どの一般的に利用されているＯＳと互換性を有するように開発がなされている。一部の実施形態の特徴の１つは、既に内蔵されているTCP実装自身を置き換えるのではなく、その振る舞いを修正したり、元の実装から送信／再送信を部分的に再試行したりして、上述したTCPの修正版に則ったTCPの振る舞いを提供することができる、ということにある。
【００４９】
ネットワーキング可能な全ての現行のＯＳは、ＩＳＯのＯＳＩコンセプトの一部の変形例を実装して、これにより、ネットワークプロトコルを、それぞれが対応するＯＳＩ層（または一式の隣接する層）として機能するサブシステムのスタックとして実装する。本発明の実施形態が正常に機能するためには、ネットワークと物理層との間の層においてパケットを傍受／生成する機能が必要となる。既存のＯＳは通常この機能を提供する。本発明の実施形態は、ネットワーキングおよび物理層実装の間のどこかの位置にあるソフトウェアにより実装することができ、ローカルな送信器にとっては遠隔受信器のように見え、遠隔受信器にとっては送信器のように見えるさらなる仲介サブシステムとなることができる。
【００５０】
本発明の実施形態を実装するソフトウェアは、パケット取得および接続処理サブシステムから形成することができる。
【００５１】
パケット取得サブシステムは、パケットの傍受および生成機能を提供する。このサブシステムは、ソフトウェアの外部通信インタフェースであり、パケットをローカルTCP実装の残りおよび遠隔受信器との間で交換することができてよい。
【００５２】
接続処理サブシステムは、上述したTCPフロー制御の修正版を実装するサブシステムである。
【００５３】
パケット取得サブシステムは、外部サブシステムであり、第三者パケット取得ソフトウェアおよび本発明の実施形態専用のソフトウェアで表すことができる。本発明の実施形態は、これらのソフトウェアが、データリンクまたはネットワーク層においてパケットを少なくとも取得（傍受）および送信することができる最低限のＡＰＩを提供している場合に、任意のパケット取得ソフトウェアとともにパケット取得サブシステムとして利用することができるように減衰することができるものであってよい。
【００５４】
接続処理サブシステムは、TCPの修正版それ自身を実装している。そして接続処理サブシステムは、複数のサブシステム（入力サブシステム、フィルタリングサブシステム、処理サブシステム、出力サブシステム）を含む。
【００５５】
入出力サブシステムは、接続処理サブシステムデータインタフェースを形成している。入力サブシステムは、パケット取得サブシステムからパケットを受信して、受信したパケットを処理サブシステムに、フィルタリングサブシステムを介して渡す。出力サブシステムは、処理サブシステムからパケットを受信して、受信したパケットをパケット取得サブシステムに転送する。
【００５６】
フィルタリングサブシステムは、入力側から出力側へパケットをトランスペアレントに転送させて、処理サブシステムが関与しないようにする。パケットは、ユーザが定義した所定の基準に従ってフィルタリングにより除去されて、これにより、残りの接続の振る舞いは変えないままに、TCPの修正版を所望の接続のみに利用することができる。利用可能なパケット取得サブシステムが一部のフィルタリング機能を提供する場合には、これらパケット取得サブシステムは、フィルタリングサブシステムの少なくとも一部を実装するために利用されてよい。パケット取得サブシステムで早期にパケットフィルタリングを行うことにより、不要な時間のかかるサブシステム間のデータ転送が回避されるので、全体の性能を向上することができる。
【００５７】
処理サブシステムは、上述したTCPの修正版を実行する。処理サブシステムは、現在処理中の接続の状態をトラッキングして、データの送信／再送信を実行する。各接続は、ＩＤ、データ、および変数により表すことができるTCP接続の実体に関連付けられていてよい。接続のＩＤは、特定の接続を他の接続から一意に区別する一式のネットワークアドレスであり、さらなる処理のために、取得されたパケットを、特定の接続実体に関連付けるものである。接続データストレージは、既に送信準備のできたパケット、および、既に送信され、受領確認を待っているパケットのそれぞれを含む送信および再送信バッファにより表される。接続実体は、ネットワークの現在の状態およびその接続を反映する大きなランタイム変数のセットであり、例としてはSWND、 AWND、 RTTs、 変分等が挙げられる。
【００５８】
本発明の一部の実施形態がもともと内蔵されているTCPの振る舞いを修正するのに利用する２つの主要な技術は、早期スプーフデータ受領確認（Preemptive Spoof Data Acknowledgement）およびパケット損失隠蔽である。
【００５９】
もともと内蔵されているTCP実装は、SWND/RTTを超えるレートでの送信ができず、元のSWNDは通常、所望の転送レートを達成するほど高速ではない。本発明の実施形態では、現行の元のSWND値を知らない可能性があり、変更することもできない。このために、早期スプーフデータ受領確認（PSDA）技法を利用することができる。PSDAは、早期受領確認の発行（実際の受領確認が到着する前の）、およびこれを元のTCP実装に転送して、元のTCP実装に強制的に、送信ウィンドウエッジをシフトさせて、新たなデータを送信させる。このようにして本発明の実施形態では、SWNDを満たすに足るパケットを取得することができ、しかも送信を所望のレートで行うことができる。PSDAはさらに、元のTCPに早期に受領確認されたパケットをその再送信バッファから削除させることができ、本発明の実施形態では、これを、自身の再送信メカニズムを実行することで行うことができる。PSDAは、空のパケットを早期スプーフ受領確認番号と共に発行すること、または、実際に入ってくるパケット受領確認番号を早期スプーフのものに修正すること、の２つの方法で行われる。早期スプーフ受領確認番号は、現在のソフトウェア接続送信バッファが常に、次の実際のデータ受領確認の後で、差分SWND - AWNDを満たすに足るデータを含むべきである、ということを考慮に入れて計算される。差分は、１回の実際の受領確認について受領確認されるデータの平均サイズとして推定される。早期スプーフ受領確認番号はさらに、以下の限定を満たす必要もある。限定とは、元のTCP実装によりまだ送信されておらず、現在のソフトウェアにバッファリグされているデータはカバーすべきではないこと（つまり、早期スプーフ受領確認番号が、「最近バッファリングされたパケットシーケンス番号」＋「最近バッファリングされたパケットデータサイズ」の値を超えないこと）である。この理由は、元のTCPにこの受領確認番号を渡すことによって生じる振る舞いが定義されていないものになり、接続処理を脅かすからである。
【００６０】
パケット損失隠蔽（PLC）は、元のTCP実装が、実際に失ったパケットについて気づき、それらを再送信することを回避するために利用される。元のTCPパケット再送信は、本発明の実施形態の処理には必須ではないが（重複するパケットは処理において破棄される）、再送信には、さらに時間のかかるデータの転送が必要となり、全体的な性能を低下させる。さらに、既に早期スプーフ受領確認されたデータの損失（このデータは、スプーフの受領確認時に、既に元のTCP再送信バッファから除去されている）は、元のTCPから隠蔽しないと、予期せぬ振る舞いをすることがある。PLCは、PSDAによって実装され、部分的にそれにより無効とされる。ここでは、RTO期限切れが示す損失および三つ目の重複する受領確認が示す損失の２つの種類のPLC隠蔽が区別される。
【００６１】
三つ目の重複する受領確認が受信されると、本発明の実施形態では、「再送信」フェーズに入り、新たなパケットの送信を行わないが、これは、接続実体の送信バッファが空にされておらず、早期スプーフ受領確認番号が増分されないことを意味する。この場合には、早期スプーフ受領確認番号を、重複受領確認が受信されるたびに１増分することで、元のTCPについて重複する受領確認のスプーフを回避する。早期スプーフ受領確認番号が「最近バッファリングされたパケットシーケンス番号」＋「最近バッファリングされたパケットデータサイズ」の値に到達すると、これ以上の増分は行われないので、一番最近にバッファリングされたデータバイト（明らかにこれも元のTCPが一番最近送信したものである）が、到着する重複受領確認全てに対する元のTCPに対してスプーフ受領確認のとれたものである。
【００６２】
RTO期限切れ隠蔽は、PSDAにより部分的に無効とされる。これは、殆どのパケットがRTOの期限切れの前に受領確認されるからである。しかし、早期スプーフ受領確認によりカバーされないパケットのバッファリング時からRTOが期限切れになると、このパケットデータを受領確認する特別な空のスプーフパケットが発行されて元のTCPに転送される。早期スプーフ受領確認番号はその後、最近スプーフ受領確認されたパケットの「シーケンス番号」＋「データサイズ」に調節される。しかし、本発明の実施形態のRTO計算が、元のTCP  RTO計算と相関付けられる必要はない。従って、元のTCP実装は、このソフトウェアが受領確認するスプーフを発行する前に、そのようなパケットに対する内部のRTO期限切れを検知してしまう場合がある。もっともこれは重大な問題とはならない。というのも、RTOが示す損失は動作に重要なものではなく、この場合、損失が示されるパケットは依然としてモットのTCP再送信バッファ内に存在しており、再送信されても、全体の性能をあまり劣化させず、接続動作をクラッシュさせたりはしないからである。
【００６３】
処理サブシステムの動作全体は、以下のアルゴリズムにより記述される。つまり、パケット関連付け、接続実体生成、出力パケット処理、入ってくるパケット処理、送信、タイムアウトチェックおよびPLCを利用する再送信、である。
【００６４】
処理サブシステムの動作は、新たなパケットの受信を待つことから開始される。一部の停止条件がこの待ち時間中に満たされると、処理サブシステムはこの待ち動作を破棄して、動作を終了する。そうでない場合には、パケットが受信されると、処理にまわされる。
【００６５】
処理サブシステムは、自身が受信するパケットが既にフィルタリングまたはパケット取得サブシステムによるフィルタリングを受けていることを前提とする。しかし依然として、受信されたパケットがどの接続に関連付けられているかを判断するためにパケット関連付けメカニズムは必要である。本発明の実施形態は、以下の予後を処理することができる（つまり、ローカルおよび遠隔ホストそれぞれのネットワーク／トランスポートアドレスを表すローカルIP／ポートおよび遠隔IP／ポート）。接続実体のIDは、これら２対のアドレスで表される。受信されたパケットは、パケットアドレスセットがIDに合致する場合に、現在トラッキングされている接続のいずれかに属すると判断する。パケットの接続が判断されると、そのパケットを特定の接続実体コンテクスト内で処理する。パケットの接続が不定のままである場合には、所定の新たな接続生成条件をチェックした後で、出力サブシステムにトランスペアレントに転送する。
【００６６】
本発明の実施形態は、本発明でさらに処理されうる特定の接続の接続構築中に交渉された一部の重要な情報を必要とする場合がある。従って、本発明のソフトウェアが通信をモニタリングしている間に新たな接続が構築された場合のみに、新たな接続実体をさらなる処理用に生成することができる。一部の実施形態では、接続が既に処理中である場合には（この場合には接続は、フィルタリングサブシステムによりフィルタリングされて、元のTCP実装の処理を受けている）、さらなる処理用の新たな接続実体を生成しない。新たな実体生成の主要な条件は、SYNフラグセットを有する、ネットワークからTCPへの（遠隔からローカルホストへの）パケットの受信であってよい。最大ウィンドウサイズ、ウィンドウスケールおよび最大セグメントサイズ等の重要なランタイムパラメータは、この接続を構築するパケットから取得される。上述した接続をセーブする条件が満たされない場合には、新たな接続実体は生成されず、パケットは、処理しないままに出力サブシステムに転送される。
【００６７】
上述したようにパケットは、現存している接続実体のいずれかと関連付けられた後で、そのパケットの方向に従ってそのコンテクスト内で処理を受ける。
【００６８】
出力される（ローカルから遠隔ホストへと）パケットは、「新たなパケットシーケンス番号」＝「最近のパケットシーケンス番号」＋「最近のパケットデータサイズ」という式が満たされる場合に接続送信バッファに追加される。この条件により、順序付けが良好なパケットのみを、送信用に処理サブシステムによりバッファリングさせることができる。一方で、重複する、あるいは順序付けが間違っているパケットは破棄される。新たな出力パケットをバッファリングした後で、送信アルゴリズムを利用する。
【００６９】
入ってくる（遠隔からローカルホストへの）パケットは、重要な接続状態情報を取得するために利用される。これらは格納されず、オプションの僅かな修正を加えられてPSDAおよびPLC要件が満たされた後で、TCPにトランスペアレントに転送される。パケットが受信されると行われる第１の処理は、受領確認されたパケットまたは再送信要求を検知する目的で実行される接続再送信バッファリングチェックである。RTT計算も、受領確認チェック中に実行される。接続再送信バッファからのパケットが、入ってくるパケットで受領確認された場合には（「バッファリングされたパケットシーケンス番号」＋「バッファリングされたパケットデータサイズ」＜＝「受信されるパケット受領確認番号」）、NEW_RTTを、このバッファリングされたパケットを送信してからその受領確認を受信するまでに経過した時間に等しい時間に設定する。バッファリングパケットの三つ目の重複する受領確認が検知されると、L_RTTを、このバッファリングされたパケットを送信してから三つ目の重複する受領確認を受信するまでに経過した時間に等しい時間に設定する。そして、再送信パケットについて受領確認され要求されたものを、再送信バッファから削除して、再送信用にそれぞれマーキングする。RWND、AWND、S_RTT、RTT変分および成長等のランタイム変数をリフレッシュして再計算する。これら変数をリフレッシュした後で、主要なパラメータであるSWNDを再計算する。SWND、AWND、およびRWNDは変更される可能性があり、新たなパケットの送信が今は許可されているので、送信アルゴリズムを利用することができる。
【００７０】
送信アルゴリズムは、送信バッファパケット抽出および送信が成功した後に行われる送信条件チェックを含む。送信アルゴリズムは、最初のパケット選択および送信条件チェックから始まる。最小シーケンス番号を有するパケットを送信バッファから選択して、SWND > AWND +「選択されたパケットデータサイズ」およびNEW_RWND > MAX_RWND* OAWTという送信条件をチェックする。上述した条件が満たされている場合には、このパケットを送信バッファから抽出および送信して、そのコピーを再送信バッファにセーブする。そしてAWNDを送信されたパケットのデータサイズで増分する。これら動作は、送信バッファが空になるまで、または送信条件が満たされなくなるまで、ループ状に繰り返される。
【００７１】
PLCアルゴリズムを利用したタイムアウトチェックおよび再送信は２つのセクションに分けられる。PLC段階において、送信バッファおよび再送信バッファ両方からのパケットをチェックして、各パケットが最初にバッファリングされたとき（つまり、元のTCP実装がそのパケットを送信したとき）からRTO期間が経過したかを判断する。このパケットが見当たらず、PSDAによる受領確認もとれない場合には、特別な損失隠蔽スプーフ受領確認パケットを発行して、元のTCPに転送して、RTO期限切れおよび再送信を気づかせないようにする。損失隠蔽スプーフ受領確認番号は、バッファリングされたときからRTOの期限が切れた一番最近バッファリングされたパケットをカバーしている必要がある。そして早期スプーフ受領確認番号を、損失隠蔽スプーフ受領確認番号に設定する。タイムアウトチェックおよび再送信フェーズは、再送信バッファからのパケットがRTO期限切れしているかをチェックして、再送信するものとしてマーキングすることが行われることを想定している。受信するパケット処理中またはタイムアウトチェック中に再送信とマーキングされた全てのパケットをその後再送信するが、このとき過度な再送信レートを回避するために以下の制約が課される。制約とは、特定のパケットを各MIN_RTTについてだけ１度だけ再送信を許可し、全再送信レートが推定された利用可能帯域幅を超えないようにする、ということである。
【００７２】
図１は、本発明の実施形態を、TCPプロトコルサポートが内蔵されているＯＳを実行するコンピュータシステムに導入する技術と、通信データフローを示す。本発明の実施形態を実装するソフトウェアをデータ送信システムに導入して、その動作を物理層およびトランスポートISO OSIモデル層間で実行する。このソフトウェアは、現在「エクストリームTCP」と称されている。データ送信システムは、通常のパソコンであってよく、あるいは、TCPプロトコル経由でデータを送信する任意のコンピュータであってよい。ソフトウェアは、ネットワークパケットを傍受して、傍受したパケットの修正および新たなパケットの生成によってTCP処理の標準フローを変更する。エクストリームTCPソフトウェア１０６は、ローカルTCP１０２と遠隔TCP１０３との間に構築されたTCP接続を介して遠隔データ受信システムにデータ送信を行うデータ送信システム１００に導入される。エクストリームTCPソフトウェア１０６は、ローカルTCP１０２と遠隔TCP１０３との間の直接接続フローを断ち切り、自身のTCPの修正版を実行する仲介仮想ホストとなる。エクストリームTCPソフトウェアは、接続処理サブシステム１０７とパケット取得サブシステム１０８とからなる。パケット取得サブシステム１０８は、入出力両方向のネットワークパケットを傍受して、それらを接続処理サブシステム１０７に方向付けしなおす。ネットワークパケットの通常のフローは、「ローカルTCP１０２−データフロー１３３−ローカルネットワークインタフェース１０４−データフロー１２７−ネットワーク１０５−データフロー１２８−遠隔TCP１０３」という実体のシーケンスおよびデータフローとして記載され、逆の方向についてはこの逆の順序となる。出力パケットを方向付けなおすフローは、「ローカルTCP１０２−データフロー１２０−パケット取得サブシステム１０８−データフロー１２１−接続処理サブシステム１０７−データフロー１２５−パケット取得サブシステム１０８−データフロー１２６−ローカルネットワークインタフェース１０４−データフロー１２７−ネットワーク１０５−データフロー１２８−遠隔TCP１０３」というようになり、入力パケットフローは、「遠隔TCP１０３−データフロー１２９−ネットワーク１０５−データフロー１３０−ローカルネットワークインタフェース１０４−データフロー１３１−パケット取得サブシステム１０８−データフロー１２１−接続処理サブシステム１０７−データフロー１２５−パケット取得サブシステム１０８−データフロー１３２−ローカルTCP１０２」となる。
【００７３】
接続処理サブシステム１０７は、入力サブシステム１０９、フィルタリングサブシステム１１０、処理サブシステム１１１、および出力サブシステム１１２からなる。入力１０９および出力１１２サブシステムは、接続処理サブシステム１０７およびパケット取得サブシステム１０８の間の通信を行う。フィルタリングサブシステム１１０は、無関係のパケットをフィルタリングにより除去して、それらを出力１１２に転送し、その直後にデータフロー１１３を介してトランスペアレントにパケット取得サブシステム１０８に送信する。フィルタリングシステム１１０は、パケット取得サブシステム１０８によって（これにより適切な特徴が提供される場合に）、その全体または部分が実装される。
【００７４】
処理サブシステム１１１は、本発明の実施形態のプロトコルの修正版の実装を具現化する。図２により共通のアーキテクチャおよび処理が表され、図３から図９が詳細を示す。処理サブシステム１１１、ローカル１０２、および遠隔TCP１０３の間には、幾つかの別個の仮想データ通信フローが存在していてよい。
【００７５】
仮想データフロー１１４は、「ローカルTCP１０２−データフロー１２０−パケット取得サブシステム１０８−データフロー１２１−入力サブシステム１０９−データフロー１２２−フィルタリングサブシステム１１０−データフロー１２３−処理サブシステム１１１」で表される。処理サブシステム１１１は、エクストリームTCPプロトコルの修正版のコンセプトに従って、ローカルTCP１０２から仮想データフロー１１４を介してデータを受信して、そのデータをバッファリングして、仮想データフロー１１６を介して遠隔TCP１０３に送信／再送信する。仮想データフロー１１６は、「処理サブシステム１１１−データフロー１２４−出力サブシステム１１２−データフロー１２５−パケット取得サブシステム１０８−データフロー１２６−ローカルネットワークインタフェース１０４−データフロー１２７−ネットワーク１０５−データフロー１２８−遠隔TCP１０３」で表される。遠隔TCP１０３は、受信したデータの受領確認を、仮想データフロー１１７を介して処理サブシステム１１１に送信し、このフローは、「遠隔TCP１０３−データフロー１２９−ネットワーク１０５−データフロー１３０−ローカルネットワークインタフェース１０４−データフロー１３１−パケット取得サブシステム１０８−データフロー１２１−入力サブシステム１０９−データフロー１２２−フィルタリングサブシステム１１０−データフロー１２３−処理サブシステム１１１」となる。処理サブシステムは、ローカルTCP１０２の振る舞いを、仮想データフロー１１５を介して通信されるPSDAおよびPLCにより修正するが、このフローは、「処理サブシステム１１１−データフロー１２４−出力サブシステム１１２−データフロー１２５−パケット取得サブシステム１０８−データフロー１３２−ローカルTCP１０２」となる。
【００７６】
図２は、処理サブシステムのアーキテクチャおよび動作を示す。実線は、処理サブシステムの主要ループの制御フローを表す。処理サブシステムは、停止条件が満たされる、タイムアウトチェック時間が来る、または新たなパケットがフィルタリング／入力サブシステムからデータフロー２０７を介して受信される、のいずれかを無限に待つ。処理サブシステムは、停止条件が満たされると、即座に停止する。タイムアウトチェック時間が来ると、制御をタイムアウトチェックおよびPLCアルゴリズム２０６を利用する再送信に渡し、それが終了すると処理サブシステムを待ち状態にする。新たなパケットがフィルタリング／入力サブシステムから受信されると、パケット関連付け２０１を行う。最近受信されたパケットの、現在処理されている接続実体のいずれかへの関連付けに成功すると、制御フロー２１０およびデータフロー２１１、または、制御フロー２１２およびデータフロー２１３にそれぞれ介するパケット方向に従って制御およびデータを、出力２０３または入力２０４パケット処理のいずれかに渡す。出力パケット処理アルゴリズム２０３は、受信したパケットをバッファリングして、早期スプーフ受領確認パケットを発行するPSDAを実行して、これを、データフロー２０８を介して出力サブシステムに転送する。入力パケット処理アルゴリズム２０４は、接続状態およびランタイム変数をリフレッシュして、受信したパケットをPSDAおよびPLC用に修正して、これを出力サブシステムにデータフロー２１４を介して転送する。そして制御を送信アルゴリズム２０５に渡し、これにより、前にバッファリングされたパケットを、出力サブシステムにデータフロー２０９を介して転送することで送信する。タイムアウトチェックおよびPLCアルゴリズムチェックを利用する再送信によって、RTO期限切れが示す損失およびPLCの必要性についてチェックが行われ、損失隠蔽スプーフ受領確認パケットを発行して、それらを、データフロー２１５を介して出力サブシステムに転送して、その後、要求されているパケットを、出力システムにデータフロー２１６を介して転送することで再送信する。そして処理サブシステムは待ち状態になる。新たなパケットが現在処理されている接続実態に関連付けられていなかった場合には、これを処理するために接続実体生成アルゴリズム２０２に渡し、このパケット接続を表す新たな実体の生成が可能であるかをチェックする。制御およびデータは、制御フロー２１７およびデータフロー２１８を介して接続実体生成アルゴリズムに転送される。そして接続実体生成は、パケットを、データフロー２２０を介して出力サブシステムに転送して、制御を再送信アルゴリズム２０６にフロー２１９を介して渡す。
【００７７】
図３は、パケット関連付けアルゴリズムを示す。処理サブシステムの主要ループから、制御を（制御フロー３００を介して）受信して、データを（データフロー３０５を介して）受信する。そしてパケットは現在処理されている接続実体に属するかをチェックされる。受信したパケットに合致する接続実体が見つからなかった場合には、制御（制御フロー３０１を介して）およびデータ（データフロー３０３を介すパケット）を、接続実体生成アルゴリズムに渡す。合致する接続実体が見つかった場合には、制御およびデータは、制御フロー３０４およびデータフロー３０６、または、制御フロー３０７およびデータフロー３０８をそれぞれ介して、出力または入力パケット処理アルゴリズムのいずれかに渡す。
【００７８】
図４は、接続実体生成アルゴリズムを示す。これにより、制御（制御フロー４００を介して）およびデータ（データフロー４０２を介すパケット）を、パケット関連付けアルゴリズムから受信する。新たな接続実体生成条件が満たされている場合には、新たな実体を生成して、データフロー４０３を介して接続実体バッファ４０５にセーブする。そしてパケットをデータフロー４０７を介して出力サブシステムに転送して、新たな実体生成条件が満たされていてもいなくても、制御を処理サブシステムの主要ループに制御フロー４０６を介して戻す。
【００７９】
図５は、出力パケット処理アルゴリズムを示す。制御（制御フロー５０４）およびデータ（データフロー５０６を介すパケット）を、パケット関連付けアルゴリズムから受信する。受信したパケットが、良好な順序付けされた連続したデータ送信という条件に合致するかをチェックする。パケットが、重複したものである、あるいは、誤った順序付けがなされている場合には、破棄または破棄を行う。パケットの順序付けが良好である場合には、このパケットを接続実体送信バッファ５０５に（データフロー５０８を介して）セーブする。そして、PSDAの必要性をチェックして、早期スプーフ受領確認パケットを発行して、データフロー５０７を介して出力サブシステムに転送する。完了すると、制御を送信アルゴリズムに渡す（制御フロー５０１）。
【００８０】
図６は、入ってくるパケットの処理アルゴリズムを示す。パケット関連付けアルゴリズムから制御（フロー６０５）およびデータ（データフロー６１１を介すパケット）を受信する。接続実体再送信バッファ６１０からのパケットに対して、受信パケットの受領確認または再送信が要求をされているかをチェックする。パケットが受領確認されると、NEW_RTTをリフレッシュして、受領確認したパケットを再送信バッファ６１０から削除する。再送信要求を検知すると、要求されているパケットをさらなる再送信用にマーキングする。全てのバッファリングされたパケットのチェックが終わると、接続状態およびランタイム変数をリフレッシュする。エクストリームTCPプロトコルの修正の本質であることが明らかであるSWNDの計算をここで採用する（アルゴリズム６０７）。受信したパケットを修正して、PSDAおよびPLCの要件に合致させて、出力サブシステムにデータフロー６１２を介して転送する。制御を送信アルゴリズムに渡す（フロー６０８）。
【００８１】
図７は、送信アルゴリズムを示す。出力パケット処理アルゴリズム（制御フロー６０８を介して）または入ってくるパケットの処理アルゴリズム（制御フロー５０１を介して）から制御を受け取る。パケットは結果として、送信バッファ５０５から選択されて、送信条件をチェックする。特定のパケットが送信を許可されている場合には、送信バッファ５０５から抽出して、送信して（データフロー７０５を介して出力サブシステムに転送することで）、その後このコピーを再送信バッファ６１０にセーブする。ひとたび送信条件が満たされないようになると、または送信バッファ５０５が空となると、制御を再送信アルゴリズムに（制御フロー７０３を介して）渡す。
【００８２】
図８は、タイムアウトチェックおよびPLCアルゴリズムを利用する再送信を示す。制御を、処理サブシステムの主要ループ（フロー８００）または送信アルゴリズム（フロー７０３）または接続生成アルゴリズム（フロー４０６）から受け取る。送信５０５および再送信６１０バッファからの第１のパケットが、損失隠蔽スプーフ受領確認の必要があるかをチェックする。RTOが特定のパケットをバッファリングしたときから期限切れになり、まだパケットがPSDAによりスプーフ受領確認されていない場合には、PLC受領確認を発行して、データフロー８１３を介して出力サブシステムに転送する。再送信バッファ６１０からのパケットについても同時にRTOが示す損失があるかをチェックする。RTOがパケットを送信したときから期限切れになっている場合には、損失が疑われるので、再送信するものとしてマーキングする。そして、アルゴリズムは、前にマーキングしたパケットを再送信して、出力サブシステムにデータフロー８１４を介して渡す。再送信が完了すると、制御を処理サブシステムの主要ループに戻す（制御フロー８０２）。
【００８３】
図９は、本発明の一部の実施形態におけるSWND計算アルゴリズムを示す。
１．パケットが受領確認されている場合
（１．１）  NEW_RTT <= MIN_RTT*(1 + EIRT)および|RTT_RGRW/RTT_RVAR| <= EIGTである場合、SWND = SWND + ACK_DS*{[1-(New_RTT-MIN_RTT/(MIN_RTT*EIRT))(1 - 1/EIID) + 1/EIID} (SWNDは指数関数的に増加する)とする。
（１．２）MIN_RTT*(1 + EIRT) < NEW_RTT <= MIN_RTT*(1 + LIRT)およびEIGT < | RTT_RGRW/RTT_RVARI <= LIGTである場合、SWND = SWND + (ACK_DS/SWND)*{[(1 + LIRT)/(LIRT - EIRT) -(NEW_RTT - MIN_RTT)/(MIN_RTT* (LIRT - EIRT))]*(1/LIID)} (SWNDは線形に増加する)とする。
（１．３）[NEW_RTT > MIN_RTT*(1 + CART) または|RTT_RGRW/RTT_RVAR| > CAGT ] およびSWND_GRW >= CAWTである場合、SWND = SWND - SWND_GRW/CADD (SWNDは線形に減少する)とする。
（１．４）[ NEW_RTT > MIN_RTT*(1 + CART) または|RTT_RGRW/RTT_RVAR| > CAGT ] and SWND_GRW < CAWTである場合、 SWND = SWND*(MIN_RTT/NEW_RTT) (SWNDは一定の比率で減少する)とする。
２．損失が検知された場合
（２．１）RTO期限切れが示す損失が示されると、SWND = SWND*(MIN_RTT/RTO) (SWNDは一定の比率で減少する)となる。
（２．２）SACKの三つ目の重複する受領確認が示す損失が検知されると、SWND = SWND*(MIN_RTT/L_RTT) (SWNDは一定の比率で減少する)となる。
【００８４】
図１０は、本発明の実施形態で処理機能を実装するために利用可能な典型的なコンピューティングシステム１０００を示す。この種類のコンピューティングシステムは、例えばクライアントおよびサーバで利用することができる。当業者であればさらに、本発明を他のコンピュータシステムまたはアーキテクチャを利用して実装することができることを想到するであろう。コンピューティングシステム１０００は、例えば、デスクトップ、ラップトップ、またはノートブックコンピュータ、ハンドヘルドコンピューティングデバイス（ＰＤＡ、携帯電話器、パームトップ等）、メインフレーム、サーバ、クライアント、または、ある用途または環境に適したまたは望ましい任意の他の種類の専用または汎用コンピューティングデバイスを表してよい。コンピューティングシステム１０００は、プロセッサ１００４等の１以上のプロセッサを含むことができる。プロセッサ１００４は、例えばマイクロプロセッサ、マイクロコントローラ、その他の制御ロジック等の汎用または専用処理エンジンを利用して実装することができる。この例では、プロセッサ１００４は、バス１００２またはその他の通信媒体に接続される。
【００８５】
コンピューティングシステム１０００はさらに、プロセッサ１００４が実行する情報および命令を格納するランダムアクセスメモリ（ＲＡＭ）その他の動的メモリ等のメインメモリ１００８を含むことができる。メインメモリ１００８は、一時変数またはその他の仲介情報を、プロセッサ１００４による命令の実行中に格納するために利用することもできる。コンピューティングシステム１０００は、同様に、バス１００２に接続され、プロセッサ１００４用の静的情報および命令を格納する読み取り専用メモリ（ＲＯＭ）その他の静的格納デバイスを含んでもよい。
【００８６】
コンピューティングシステム１０００はさらに、例えば媒体ドライブ１０１２および取り外し可能な格納インタフェース１０２０を含んでよい情報格納システム１０１０を含んでよい。格納ドライブ１０１２は、ハードディスクドライブ、フロッピー（登録商標）ディスクドライブ、磁気テープドライブ、光ディスクドライブ、ＣＤ、またはＤＶＤドライブ（ＲまたはＲＷ）、あるいは、その他の固定または取り外し可能な媒体ドライブ等の固定または取り外し可能な格納媒体をサポートするドライブまたはその他のメカニズムを含んでよい。格納媒体１０１８は、例えばハードディスク、フロッピー（登録商標）ディスク、磁気テープ、光ディスク、ＣＤ、またはＤＶＤ、その他の、媒体ドライブ１０１２が読み書き可能な固定または取り外し可能な媒体を含んでよい。これらの例が示すように、格納媒体１０１８は、特定のコンピュータソフトウェアまたはデータが格納されたコンピュータ可読媒体を含んでよい。
【００８７】
別の実施形態では、情報格納システム１０１０は、コンピューティングシステム１０００にコンピュータプログラムあるいはその他の命令またはデータをロードすることのできる他の同様のコンポーネントを含んでよい。このようなコンポーネントには、例えば、取り外し可能格納ユニット１０２２およびインタフェース１０２０（プログラムカートリッジおよびカートリッジインタフェース等）、取り外し可能メモリ（例えばフラッシュメモリまたはその他の取り外し可能メモリモジュール）およびメモリスロット、その他の、取り外し可能な格納ユニット１０２２からコンピューティングシステム１０００にソフトウェアおよびデータを転送することのできる取り外し可能な格納ユニット１０２２およびインタフェース１０２０が含まれてよい。
【００８８】
コンピューティングシステム１０００はさらに通信インタフェース１０２４を含むことができる。通信インタフェース１０２４は、ソフトウェアおよびデータをコンピューティングシステム１０００と外部デバイスとの間で転送するために利用することができる。通信インタフェース１０２４の例には、モデム、ネットワークインタフェース（例えばイーサネット（登録商標）その他のＮＩＣカード）、通信ポート（例えばＵＳＢポート）、ＰＣＭＣＩＡスロットおよびカード等が含まれてよい。通信インタフェース１０２４を介して転送されるソフトウェアおよびデータは、電子信号、電磁気信号、光信号、その他の通信インタフェース１０２４が受信することのできる任意の形態の信号である。これらの信号は、チャネル１０２８を介して通信インタフェース１０２４に提供される。このチャネル１０２８は、信号を搬送してよく、無線媒体、有線またはケーブル、光ファイバ、またはその他の通信媒体を利用して実装することができる。チャネルの一部の例には、電話回線、携帯電話リンク、ＲＦリンク、ネットワークインタフェース、ローカルエリアネットワークまたはワイドエリアネットワーク、またはその他の通信チャネルが含まれる。
【００８９】
この明細書では、「コンピュータプログラムプロダクト」、「コンピュータ可読媒体」等の用語は、一般的に、例えばメモリ１００８、格納デバイス１０１８、または格納ユニット１０２２等である媒体のことを示すために利用されてよい。これらおよびその他の形態のコンピュータ可読媒体を利用して、プロセッサ１００４が特定の処理を実行するために利用する１以上の命令を格納することができる。このような命令は一般的には、「コンピュータプログラムコード」（コンピュータプログラムの形態に分類される、または他の分類分けをされる場合がある）と称されており、実行されると、コンピュータシステム１０００に、本発明の実施形態の特徴または機能を実行させることができる。コードは直接プロセッサに特定の処理を実行させることができたり、コンパイルされてそうすることができたり、および／または、他のソフトウェア、ハードウェア、および／またはファームウェアエレメント（例えば標準的な機能を実行するためのライブラリ）と組み合わせられてそうすることができたりする。
【００９０】
エレメントがソフトウェアを利用して実装される実施形態では、ソフトウェアは、コンピュータ可読媒体に格納されてよく、コンピュータシステム１０００に、例えば取り外し可能格納ドライブ１０１４、ドライブ１０１２または通信インタフェース１０２４を利用してロードすることができる。制御ロジック（本例では、ソフトウェア命令またはコンピュータプログラムコード）は、プロセッサ１００４により実行されると、プロセッサ１００４に、ここで記載する発明の機能を実行させる。
【００９１】
明瞭性を帰して、上述した記載では、本発明の実施形態を異なる機能ユニットおよびプロセッサを参照して記載してきた。しかし、本発明を逸脱せずに、異なる機能ユニット、プロセッサ、またはドメイン間に任意の適切な機能を分配させることも可能であることは明白である。例えば、別個のプロセッサまたはコントローラにより実行されるとして記載されている機能を、同じプロセッサまたはコントローラにより実行させることもできる。ここで、特定の機能ユニットに関する参照は、記載された機能を提供するのに適した手段の参照としてみなされることのみを意図しており、厳格な意味で論理的または物理的な構造または組織を示すものではない。本発明の一部の実施形態は、TCPプロトコルとの関連で記載された。しかし本発明はそれに限定はされず、スライディングウィンドウのコンセプトを利用する他のプロトコルに適合されてもよい。
【００９２】
本発明は幾つかの実施形態との関連で記載されたが、これら特定の形態に限定されはしない。本発明の範囲は、請求項によってのみ制限される。さらに、ある特徴が特定の実施形態との関連で記載されているとしても、当業者であれば、記載された実施形態の様々な特徴を本発明に従って組み合わせることができることを理解する。
【００９３】
さらに、個々にリストした複数の手段、エレメント、または方法ステップは、例えば単一のユニットまたはプロセッサにより実装されてもよい。さらに、個々の特徴が異なる請求項に含まれていようとも、これらは、組み合わせることで効果を奏する場合もあり、異なる請求項に含まれているからといって、特徴同士の組み合わせが可能ではない、および／または効果を奏さないという意味ではない。さらに、同一カテゴリーの請求項にある特徴が含まれているからといって、このカテゴリーに制限されることを意味しているわけではなく、必要に応じてこの特徴を同様にして他の請求項カテゴリーに適用することもできる。また、本明細書および添付請求項で利用される、単数形および定冠詞の記載は、コンテクスト上そうではないということが明白な場合以外はその部材を複数含んでもよいこととする。
【００９４】
さらに、当業者であれば、本発明の精神および範囲から逸脱せずに様々な変形例および変更例について想到するであろう。本発明は、前述した詳細に制限されず、請求項に従ってのみ定義される。
【００９５】
限られた数の実施形態のみを詳述してきたが、当業者であれば、実質的に本発明の新規な教示および利点を逸脱せずに実施形態に対して行うことのできる数多くの変形例を容易に想到する。従ってこれら全ての変形例を、本発明の範囲に含まれるものとする。
【図１】
2012515491.tif 000003
【図２】
2012515491.tif 000004
【図３】
2012515491.tif 000005
【図４】
2012515491.tif 000006
【図５】
2012515491.tif 000007
【図６】
2012515491.tif 000008
【図７】
2012515491.tif 000009
【図８】
2012515491.tif 000010
【図９】
2012515491.tif 000011
【図１０】
2012515491.tif 000012
【国際調査報告】
2012515491.tif 000013
2012515491.tif 000014
2012515491.tif 000015
2012515491.tif 000016
2012515491.tif 000017