JP2015019232A

JP2015019232A - 通信装置、通信装置の制御方法およびプログラム

Info

Publication number: JP2015019232A
Application number: JP2013144856A
Authority: JP
Inventors: 智和八巻; Tomokazu Yamaki
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2013-07-10
Filing date: 2013-07-10
Publication date: 2015-01-29

Abstract

【課題】プロトコル処理など通信装置内のボトルネックに起因するデータ損失、スループット低下を軽減する。【解決手段】通信装置であって、受信処理がなされたパケットに対してプロトコル処理を行う処理部と、プロトコル処理後の受信データを格納するソケットバッファの使用状況が特定値または特定割合を超えるTCPコネクションを特定する特定部と、受信処理が不可能である場合に、特定部により特定されたTCPコネクションの広告ウィンドウサイズが所定範囲内になるように制御する制御部とを備える。【選択図】図3

Description

本発明は、ネットワークを構成可能な通信装置、通信装置の制御方法及びプログラムに関し、特に、TCPのフロー制御に関する。

通信装置が通信を行うために、TCP (Transmission Control Protocol) やUDP (User Datagram Protocol) といった通信プロトコルが規定されている。TCPはUDPに比べ、信頼性を向上するため、シーケンス番号による順序保障やウィンドウサイズ広告によるフロー制御といった機能を有する。TCPの仕様はRFC793に開示されている。しかしながら、プロトコル処理後の受信データを格納するソケットバッファの使用状況等から広告するウィンドウサイズを決定して行うTCPフロー制御だけでは解決できないデータ損失、スループット低下が発生し得る問題があった。この問題を解決するために特許文献1には、移動局と無線基地局が無線リンクでセッションを行うケースにおいて、無線区間の状態測定を行い、その測定結果に基づき、TCPの広告するウィンドウサイズを設定する技術が開示されている。

特開2009-218912号公報

しかしながら、特許文献1に記載した通信装置では、無線リンクといった回線状況に起因する非効率的な通信に対応することはできるが、プロトコル処理など通信装置内のボトルネックに起因するデータ損失、スループット低下には対応することができない。

図1のデータフロー図により、通信装置内のボトルネックに起因するデータ損失、スループット低下を説明する。通信装置の受信処理において、パケット受信処理は、MAC/PHY部へのポーリング、MAC/PHY部からの割り込み等により、受信すべきデータがMAC/PHY部に存在するか判断する。受信すべきデータがある場合、パケット受信処理はTCP、UDP、ICMP (Internet Control Message Protocol) など全ての受信パケットをMAC/PHY部からプロトコルバッファへ格納する。IP、UDP、TCP等のプロトコル処理は、プロトコルバッファに格納されている受信パケットを参照して行われ、TCPの場合プロトコル処理が完了すると、コネクション毎に確保されているソケットバッファへ受信データを格納する。App受信処理はAppの受信要求により、該当コネクションの受信データをソケットバッファからAppが使用するAppバッファへ格納する。ここで、Gigabit Ethernet等MAC/PHY部の通信処理が高速であり、大量の受信パケットを扱うプロトコル処理がボトルネックとなる場合、プロトコルバッファが枯渇し、MAC/PHY部から受信パケットを受信できず、データ損失、スループット低下が発生する。またTCPはソケットバッファの使用状況等から広告するウィンドウサイズを決定してフロー制御を行うが、プロトコル処理がボトルネックのため、ソケットバッファの使用状況は少なく、実際に受信可能なサイズより大きなウィンドウサイズを対向装置に広告する。そのため、TCPのフロー制御が発揮できない。

上記の課題に鑑み、本発明は、プロトコル処理など通信装置内のボトルネックに起因するデータ損失、スループット低下を軽減することを目的とする。

上記の目的を達成する本発明に係る通信装置は、
受信処理がなされたパケットに対してプロトコル処理を行う処理手段と、
前記プロトコル処理後の受信データを格納するソケットバッファの使用状況が特定値または特定割合を超えるTCPコネクションを特定する特定手段と、
前記受信処理が不可能である場合に、前記特定手段により特定された前記TCPコネクションの広告ウィンドウサイズが所定範囲内になるように制御する制御手段と
を備えることを特徴とする。

本発明によれば、プロトコル処理など通信装置内のボトルネックに起因するデータ損失、スループット低下を軽減することができる。

通信装置のデータフロー図。本発明の実施形態に係る通信装置200の構成例を示すブロック図。本発明の実施形態に係るウィンドウ制御変更のシーケンス図。本発明の実施形態に係る信システム部220の受信、ウィンドウ制御変更の処理手順を示すフローチャート。本発明の実施形態に係る記憶部240が保持する制御対象のTCPコネクションを特定するために用いるコネクション判断テーブルを示す図。本発明の実施形態に係るプロトコルスタック部230の処理手順を示すフローチャート。

以下、本発明の実施の形態について添付の図面を参照して詳細に説明する。なお、以下では、有線LAN (Local Area Network) を用いた例を説明するが、その通信形態は本実施形態に限るものではなく、その技術思想の範囲内で種々の変更が可能である。また実施形態ではメインシステム部とTOE (TCP/IP offload engine) などの通信システム部から構成される通信装置を用いるが、通信システム部を分離せず、1つのシステム部で構成された通信装置にも適用が可能である。

[装置の構成]
図2のブロック図により実施形態の通信装置200の構成の一例を示す。通信装置200は、各種アプリケーションを実行し、必要に応じて他の装置と通信を行うことが可能である。通信装置200は、メインシステム部210と、通信システム部220と、MAC/PHY部230と、記憶部240とを備えており、システムバス250を介して互いに接続されている。

＜メインシステム部210＞
メインシステム部210は、主に、アプリケーションの処理、通信システム部220の制御を行う。メインシステム部210は、制御部211と、App部212と、入出力部213と、通信システムドライバ部214とを備えている。制御部211は、CPUを有し、RAMをワークメモリとしてROMなどに格納されたプログラムを実行し、メインシステム部210の構成を実現したり制御したりする。App部212は、制御部211の処理によって実現される各種アプリケーションであり、ユーザへ各種機能を提供し、必要に応じて、通信システムドライバ部214、通信システム部220、MAC/PHY部230を介して対向通信装置と通信を行う。入出力部213は、ユーザから各種入力を受け付け、LCDやLEDによる表示、スピーカなどによる音声出力によって各種情報を出力する。通信システムドライバ部214は、通信システム部220の各種制御を行いApp部212に通信機能を提供する。

＜通信システム部220＞
通信システム部220は、主にプロトコル処理といった通信処理を行う。通信システム部220は、制御部221と、TCP制御部222と、プロトコルスタック部223と、受信不可検知部224とを備えている。制御部221は、CPUを有し、RAMをワークメモリとしてROMなどに格納されたプログラムを実行し、通信システム部220の各構成を実現したり制御したりする。TCP制御部222は、受信不可検知部224が受信処理不可能と判断した時に、TCP制御情報244を参照して、制御対象のコネクションおよびウィンドウ制御方法を決定し、プロトコルスタック部223のTCPのウィンドウ制御を切り替える。プロトコルスタック部223は、ネットワーク通信プロトコルスタックでTCP/IPなどのプロトコル処理を行う。また、プロトコルスタック部223は、TCP制御部222の指示に基づき、TCPのウィンドウ制御を変更することが可能である。受信不可検知部224は、プロトコルバッファ243の空き状況から、MAC/PHY部230からプロトコルバッファ243へのパケット受信処理が行えるか判断する。

＜MAC/PHY部230＞
MAC/PHY部230は、MAC (Media Access Control) 層、PHY (Physical) 層の処理を実現するMAC/PHYデバイスである。

＜記憶部240＞
記憶部240は、制御部211や制御部221が実行するプログラムなど各種情報を記憶するROMやワークメモリとして使用されるRAMなどを有する。また、プロトコルスタック部223が使用する通信パラメータなどの各種情報を記憶する。Appバッファ241はApp部212が送受信を行う時に使用するバッファである。ソケットバッファ242はプロトコルスタック部223のIPおよびTCP処理が完了した受信データを格納する等に用いるバッファである。プロトコルバッファ243はMAC/PHY部230からTCP、UDP、ICMPなどの全受信パケットを格納するバッファである。TCP制御情報244は、プロトコルスタック部223のTCPが管理するTCB (Transmission Control Block) であり、コネクション単位でソケットバッファの使用状況などTCPに関わる各種情報が格納される。なお、記憶部240に配置される情報は、メインシステム部210や通信システム部220内に内部メモリを配置して管理しても良い。

[通信装置のシーケンス]
図3を参照して、対向通信装置から受信パケットを受取るが、パケット受信処理ができないことを検知し、各TCPコネクションのソケットバッファの使用状況を解析後、TCPのウィンドウ制御を変更する通信装置200のシーケンス例を示す。

MAC/PHY部230は、対向通信装置から受信パケットを受信する(S301)。プロトコルスタック部223は、MAC/PHY部230からの割り込み通知、またはMAC/PHY部230へのポーリングにより受信パケットが存在することを検知する(S302)。受信パケットの存在を検知したプロトコルスタック部223は、受信不可検知部224へパケット受信処理が行えるか確認を行い、受信不可を検知する(S303)。パケット受信処理は、MAC/PHY部230からプロトコルバッファ243へ受信パケットを格納する処理である。受信不可検知部224は、プロトコルバッファ243の空きが特定サイズまたは特定バッファ数より少ない時、パケット受信処理が行えない、すなわち受信不可と判断する。プロトコルスタック部223は、TCP制御部222にコネクション解析を指示する(S304)。TCP制御部222は、プロトコルスタック部223によって行われたIPおよびTCPのプロトコル処理後の受信データを格納するソケットバッファ242の使用状況が特定値または特定割合を超えるTCPコネクションを特定する。TCP制御部222は、特定したTCPコネクションに関するウィンドウ制御指示をプロトコルスタック部223に対して行う(S305)。ウィンドウ制御指示を受けたプロトコルスタック部223のTCPは、指示された内容に基づきウィンドウ制御を実施する。

[装置の動作フロー]
図4のフローチャートを参照して、通信システム部220の受信処理およびウィンドウ制御切換え処理の手順について説明する。なお、図4に示す処理は、プロトコルスタック部223がMAC/PHY部230に受信パケットが存在することを検知する度に実行される。

MAC/PHY部230に受信パケットが存在することを検知したプロトコルスタック部223は、パケット受信処理が可能か受信不可検知部224に問合せを行う(S401)。受信不可検知部224は、プロトコルバッファ243の空きが特定サイズまたは特定バッファ数より多い時、受信可能と判断し（S401でYes）、プロトコルスタック部223は受信パケットをMAC/PHY部230からプロトコルバッファ243へ格納するパケット受信処理を行う(S402)。

プロトコルスタック部223は、プロトコルバッファ243の受信パケットに対してプロトコル処理を実施する(S403)。プロトコルバッファ243には、全ての受信パケットが格納されるため、各種プロトコル処理が行われるが、該当受信パケットがTCPの場合、プロトコル処理が完了すると、プロトコルバッファ243からコネクション毎に確保されているソケットバッファ242へ受信データを格納する(S404)。ソケットバッファ242からAppバッファ241へ受信データを格納するApp受信処理は、メインシステム部210のApp部212が、通信システムドライバ部214を介して受信要求を通信システム部220に対して行った際に、実施される。

S402からS404は受信可能時の処理であったが、プロトコルバッファ243の空きが特定サイズまたは特定バッファ数より少ない時、受信不可検知部224は受信不可能と判断し（S401でNo）、プロトコルスタック部223は、TCP制御部222にコネクション解析を指示する。指示を受けたTCP制御部222は、TCP制御情報244を参照することで、ソケットバッファ242の使用状況を把握し、記憶部240に保持するコネクション判断テーブル（図5）の特定値または特定割合に基づき、制御対象のTCPコネクションを特定する(S405)。

図5(a)の例ではTCPの総コネクション数に関係なく、各ソケットバッファの使用状況が、各ソケットバッファのサイズに対して、80%を超えたものが制御対象のTCPコネクションとして特定される。図5(b) の例ではTCPの総コネクション数に応じて、各ソケットバッファの使用状況が、各ソケットバッファのサイズに対して、判定ウィンドウ割合を超えた場合、制御対象のTCPコネクションと特定する。例えば、TCPの総コネクション数が15本の場合、15個の各ソケットバッファの使用状況が各ソケットバッファのサイズに対して、判定ウィンドウ割合70%を超えた場合、制御対象のTCPコネクションと特定する。

図5(c) の例では受信パケットのTCP/IPヘッダフィールドが条件値と一致し、かつヘッダフィールド条件に一致したTCPコネクションのソケットバッファの使用状況が、判定ウィンドウサイズを超えた場合、制御対象のTCPコネクションと特定する。例えば、送信ポートが100で、その他のヘッダフィールドが任意のTCPパケットを受信した場合、対応するTCPコネクションのソケットバッファの使用状況が32KBを超えた場合、制御対象のTCPコネクションと特定する。

TCP制御情報222は、S405で特定したTCPコネクションのウィンドウ制御方法を切り替えるため、TCP制御情報244のウィンドウ制御切換フラグの値を変更する(S406)。ウィンドウ制御切換フラグは、どのTCPコネクションに対して指示するかを特定できるように、例えば、コネクション単位でフラグを設ける。なお、ウィンドウ制御切換フラグはTCP制御情報244ではない記憶部240に配置しても良い。切換え後のウィンドウ制御方法は、ソケットバッファ242からAppバッファ241へ受信データを格納し、ソケットバッファ242の空き容量が拡大しても、該当コネクションの広告ウィンドウサイズを拡大しない（所定範囲内に収める）ものである。これにより対向装置からのパケット送信を抑制する。

なお、TCPウィンドウ制御に関わるものであれば、例えば、該当コネクション毎に特定サイズより大きなウィンドウサイズを広告しないなど、別の制御方法を適用しても良い。また図4を用いて受信、ウィンドウ制御変更の動作を説明してきたが、受信処理やACKなどの送信処理を高速化するため、S401でNoの場合、S405およびS406を毎回実施せず、前回から変化があった時のみ実施するようにしても良い。

次に図6のフローチャートを参照して、プロトコルスタック部223のTCPがプロトコル動作を行う時の処理の手順について説明する。なお、図6に示す処理は、送信また受信時にプロトコルスタック部223のTCPがプロトコル動作を行う度に実行される。

プロトコルスタック部223のTCPは、通信システムドライバ部214からの送信要求、またはプロトコルスタック部223のIPからの受信要求などTCP処理を行う場合、TCP制御情報244のウィンドウ制御切換フラグ値を参照し、TCP制御部222からの指示があるか確認を行う(S501)。ウィンドウ制御切換フラグは、値0は指示なし、値1は該当コネクションの広告ウィンドウサイズを拡大しない、値2はコネクション毎のウィンドウ上限サイズを変更して動作する等のように定義する。TCP制御部222の指示がある場合(S502でYes)、プロトコルスタック部223のTCPは、TCP制御情報244のウィンドウ制御切換フラグが1の場合は該当コネクションの広告ウィンドウサイズを拡大しないようにTCP処理を行い、TCP制御情報244のウィンドウ制御切換フラグが2の場合は該当コネクション毎に特定サイズより大きなウィンドウサイズを広告しないようにTCP処理を行う(S503)。TCP制御部222の指示がない場合(S502でNo)、プロトコルスタック部223のTCPは特別なウィンドウ制御を行わないTCP処理を行う(S504)。

なお、本実施形態ではメインシステム部210とTOE (TCP/IP offload engine) などの通信システム部220とを備える通信装置200を用いたが、通信システム部を分離せず、1つのシステム部で構成された通信装置にも適用が可能である。

また、プロトコルスタック部223のTCPのウィンドウ制御を変更後、特別なウィンドウ制御を行わないTCP処理に再度変更するように構成しても良い。例えば、タイマの時間計測により一定時間後に、TCP制御部222がウィンドウ制御切換フラグの値を0に設定してもよい。または、プロトコルバッファ243の使用状況が規定値または規定割合より下がった場合、受信不可検知部224がそれを検知し、TCP制御部222がウィンドウ制御切換フラグの値を0に設定してもよい。これにより、TCP制御部222が指示したウィンドウ制御変更により通信装置内の輻輳がなくなった後、広告ウィンドウサイズの制限をなくし、広告ウィンドウサイズを拡大させることで、ウィンドウ制御変更後のスループットを向上させることができる。

以上説明したように、通信装置200における受信時のボトルネックがプロトコル処理などソケットバッファ242に受信データを格納する前に存在する場合、受信不可検知部224がMAC/PHY部230からパケット受信できないことを検知し、TCP制御部222が各TCPコネクションの状況を把握してソケットバッファ242の使用状況が特定値または特定割合を超えるTCPコネクションを特定し、プロトコルスタック部223は、TCP制御部222のウィンドウ制御に関する指示に基づき、プロトコル処理を行うことで、今までのTCPフロー制御では解決できないデータ損失、スループット低下を軽減することが可能となる。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims

通信装置であって、
受信処理がなされたパケットに対してプロトコル処理を行う処理手段と、
前記プロトコル処理後の受信データを格納するソケットバッファの使用状況が特定値または特定割合を超えるTCPコネクションを特定する特定手段と、
前記受信処理が不可能である場合に、前記特定手段により特定された前記TCPコネクションの広告ウィンドウサイズが所定範囲内になるように制御する制御手段と
を備えることを特徴とする通信装置。
MAC/PHY部で受信した前記パケットをプロトコルバッファに格納する前記受信処理が可能か否かを検知する検知手段をさらに備え、
前記制御手段は、前記検知手段により前記受信処理が不可能であると検知された場合に、前記広告ウィンドウサイズが所定範囲内になるように制御することを特徴とする請求項1に記載の通信装置。
前記検知手段は、前記プロトコルバッファの空き状況に基づいて、前記受信処理が可能か否かを検知することを特徴とする請求項2に記載の通信装置。
前記処理手段は、前記プロトコルバッファに格納された前記パケットに対してプロトコル処理を行うことを特徴とする請求項3に記載の通信装置。
前記特定手段は、各TCP制御情報に基づいて各TCPコネクションの使用状況を把握することを特徴とする請求項1乃至4の何れか1項に記載の通信装置。
前記特定手段は、TCPコネクションの数に応じた特定値または特定割合によって、当該特定値または特定割合を超えるTCPコネクションを特定することを特徴とする請求項1乃至4の何れか1項に記載の通信装置。
前記特定手段は、TCPコネクションごとに異なる特定値または特定割合によって、当該特定値または特定割合を超えるTCPコネクションを特定することを特徴とする請求項1乃至4の何れか1項に記載の通信装置。
通信装置の制御方法であって、
処理手段が、受信処理がなされたパケットに対してプロトコル処理を行う工程と、
特定手段が、前記プロトコル処理後の受信データを格納するソケットバッファの使用状況が特定値または特定割合を超えるTCPコネクションを特定する工程と、
制御手段が、前記受信処理が不可能である場合に、前記特定された前記TCPコネクションの広告ウィンドウサイズが所定範囲内になるように制御する工程と
を有することを特徴とする通信装置の制御方法。
請求項8に記載の通信装置の制御方法の各工程をコンピュータに実行させるためのプログラム。