リンク・アグリゲーションでのリンクの割り当て

質問

IEEE802.3ad Link Aggregation という規格を知り、Windows 7 (64Bit) で、下記の構成で、ネットワークの帯域を実験してみました。
1Gbps の NIC を２枚　なので、期待値は、2Gbps です。（PCは、共に、Windows7）

Jumbo Packet 9016Bytes
チーム化は、LACP にて行い、ネットワークのプロパティでは、2GBPS の表示は、出ています。

PC#1
INTEL Pro/1000 PT Desktop １枚
INTEL Gigabit CT Desktop １枚

PC#2
INTEL Gigabit CT Desktop ２枚

(1) PC#1→PC#2 へ、WinSock で、UDP 送信を Non-Blocking で送信
結果：ある瞬間をみるとネットケーブルの一本側にしか UDP Packet が流れません。
数秒後に、LACPのロードバランスの制御で、他方のケーブルへUDP パケットが流れます。
　　　　　Windows のタスクマネージャで見ても、Networkの利用率は、50% 近辺で、実際とあっています。

(２) 上記(1) を実行中に、
PC#1←PC#2 へ、WinSock で、UDP 送信を Non-Blocking で送信
　　 結果：(1) のパケットとは、別のケーブルの方に、パケットが流れます。
　　　　　Windows のタスクマネージャで見ても、Networkの利用率は、70% 近辺で、実際とあっています。

質問：
期待する動作としては、
上記（１）において、Network 利用率 70% 辺りを期待したいのですが、無理でしょうか？
IEEE802.3ad　の規格によれば、物理リンク（ケーブル相当）の決定は、MAC Address と、Port Number　のようです。
一方、私がやりたいのは、一つのUDP Port でもって、２本のケーブルに同時にパケットを送出したい訳です。
受信側のドライバの作りからいって、無理なような気がしているのですが、このあたり、教えていただけると、とっても、うれしいです。
INTEL NIC は、TX/RX 共に、Descriptor でもって、パケットを送受するので、無理っぽい気がしています。
TX/RX の Descriptor は、めいっぱい確保しています。

以上ですが、よろしく、お願いいたします。

回答No.4

onosuke

ちょっと期間が空いてしまいましたが。。。

802.3ad-2000をお探しであれば、このあたりに落ちていたりします。
http://voiplab.niu.edu.tw/IEEE/obsolete/802.3/802.3ad-2000.pdf

>All packets associated with a given “conversation” are transmitted on the
>same link to prevent mis-ordering
>と記載があり、同一リンク(この場合、物理リンクと解釈)で、送信するようです。
strictな802.3adだと、送信側(Frame Distributor)には上記の通りの制約があります。
現実には、いろいろなベンダ拡張が入っており、上記制約に従わないものがあります。
（Linux bondingのbalanced-rrも、802.3ad規格の制約を外れたものです）

>また、ロードバランスについては、
>This standard does not mandate any particular distribution algorithm(s);
>のように、アルゴリズムを特定しているようではないようです。
これはその通りです。

>また、LAG は、Point-Point なので、イーサネットのPHY の都合を除けば、Pause Frame による
>パケットの停滞は、まずないでしょう！？（RX Desc を多分に用意するので）
10Gとかだと怪しいですが、1G程度であれば、最近のマシンなら大丈夫でしょう。

検証がんばってください。

回答No.3

onosuke

>Linux の Bonding ではどうなのかは、まだ、試していません。(送出側として)
LinuxのBondingであれば、
動作モードに、round-robin方式（balanced-rr)を選択することで、
期待の動作となります。

回答No.2

onosuke

>NIC２個を一個のストリームとして見た場合の、
>時系列の判断が、無理ではないか？と理解してます。

時系列（パケット到着順序）の判断はドライバレベルでは不要です。
パケット到着順序が保証されない（順不同となる可能性がある）旨は、
EthernetやIP等のプロトコル規約でも明言されています。

時系列の判断は、上位層のしかるべきプロトコル層で処理すべき内容であり、
物理NICドライバや（チーミング用）仮想NICドライバは関与する必要がありません。

具体例をいくつかあげると。。。
　・IPフラグメント結合のための時系列判断は、TCP/IPスタックが処理すべき。
　・UDPを利用した音声ストリーミングの時系列判断は、アプリケーションレイヤが実装すべき。
といった具合です。

ご質問のように「UDP利用が前提」で、さらに「時系列の補償が必要」であれば、
アプリケーションレイヤで時系列を補償するための仕組みを実装する必要があります。

お礼

明快な回答、ありがとうございます。

WEB でいろいと検索すると、

プレゼン資料
IEEE 802.3 HSSG　IEEE 802.3ad Link Aggregation　(LAG)
17-April-2007 Ottawa
IEEE 802.3 HSSG

では、
All packets associated with a given “conversation” are transmitted on the same link to prevent mis-ordering
と記載があり、同一リンク(この場合、物理リンクと解釈)で、送信するようです。

また、ロードバランスについては、
This standard does not mandate any particular distribution algorithm(s);
のように、アルゴリズムを特定しているようではないようです。

このような表現が、IEEE の文献に多数記述があり、混乱していました。

しかし、このところのこの質問箱での、対話を通じて、下記のようにいけるかな？という理解になってきました。

NIC ドライバの受信系の一般的な構造は、以下のような感じ

割込み処理
割込み遅延処理
プロトコル層へのポスト

チーム用のNIC処理は、上記プロトコル層へのポストの前ですね。

なので、確かに、パケットの順序性は、気にしようにも、できません。

また、LAG は、Point-Point なので、イーサネットのPHY の都合を除けば、Pause Frame による
パケットの停滞は、まずないでしょう！？（RX Desc を多分に用意するので）

従って、ここは、UDP 層の上位にて、パケットの順序性・確実性を補償すべきでしょうね。

今後は、この検証作業をしようと思います。

回答No.1

onosuke

Link Aggregationにおいて、どのケーブルを利用して送信するかは、
信号送信側の制御に依存します。（受信側が来た信号を全て受け取るだけ）

つまり、PCで受信パケットを負荷分散する場合、
通常は接続するL2スイッチ（＝信号送信側）の制御に依存してしまいます。

今回の場合は、対向PCのINTEL NIC送信側ドライバの作りに依存して、
そのような挙動を示す結果が出てしまっており、期待する動作は実現不可能です。

以下、参考URLから、
INTEL NIC送信側ドライバの挙動に関する引用です。
-------------------------------------------------------
リンク・アグリゲーション / ロード・バランシング機能は、
サーバー － クライアントのような
1 : n の関係にある通信の帯域を広げるための機能です。
　（中略）
サーバー間接続のような、
1 : 1 の関係にある通信については、帯域を広げることはできません
--------------------------------------------------------

参考URL：

http://www.intel.com/jp/support/network/sb/cs-009747.htm

お礼

早速のご回答、ありがとうございます。
大変、参考になりました。　さらに、上記に、質問の補足をします。

どうぞ、よろしく、お願い申し上げます。

補足

素早い、ご回答、ありがとうございます。　大変、助かります。

まさに、ご指摘の INTEL のサイトの以下の記述

>アドバンスド・ネットワーキング・サービス (ANS) の仕様により、
> 1 つのセッションを複数の物理アダプターに振り分けません。

ですね。　一つのセッション＝UDP Port １個分ですね。

実を申しますと、送出側は、独自に作ろうと思っていて、その事前調査で、既存品を調べました。
一方で、海外では、このINTEL NIC を２個受信側で使って、240MB/S　程度の速度を実現できているようです。

この事実と、INTEL サイトの記述からは、受信側は、できそうな感じです。

さらに、質問を具体化すると、
UDP １　Port のパケットを２個の物理リンクに、バーストで、同時に流して、受信側で、どうやって
順序の検出ができるのだろう？というのが、私の疑問です。

受信側においては、INTEL NIC の　RX Descriptor が、沢山つながっていて、そこを見て、
NIC が、バスマスター(DMA)で、転送するだけだと、思います。

そうすると、受信側では、今回の例では、２個同様の受信動作になり、PC の DDR 上には、
パケットが、各NIC毎に時系列に並びます。
NIC２個を一個のストリームとして見た場合の、時系列の判断が、無理ではないか？と理解してます。 リンクアグリゲーションのプロトコルの中に、Marker Protocol というのがあるのですが、
それで行うのか？　わかっていません。

Linux の Bonding ではどうなのかは、まだ、試していません。(送出側として)

現状、分かっていることは、UDP Port を２個にすれば、PC－PC間は、1Gbps を超えられる
ということです。
これを、なんとか、UDP １ Port で済ませたいとチャレンジしてる次第です。

以上、どうぞ、よろしく、お願い申し上げます。