パスワードを忘れた? アカウント作成
6509346 story
テクノロジー

無線ネットワークの速度を「10倍向上させる」という新技術 37

ストーリー by hylom
ネット高速化の鍵 部門より
taraiok 曰く、

MIT、カリフォルニア工科大学、ハーバード大学らの合同研究チームは、基地局の追加や送信電力を増加させることなく無線ネットワークの速度を改善する技術を開発したと発表した。現在、無線ネットワーク通信に使用されているパケットの3%は、干渉や輻輳などが原因で廃棄されているという。さらに電車への乗車中など、高速移動する状況ではこのパケットロスは5%まで増加するとのこと。研究チームが開発した新技術「coded TCP」を使用すればこうしたパケットロスは皆無になるという(technology reviewExtremTech元論文PDFGigazine本家/.)。

MIT内のWi-Fiネットワークを使った実験ではパケットロスがなくなり、通信速度も通常1Mbpsのところ16Mbpsまで増加したとしている。また5%のパケットロスが発生していた電車内での通信では、接続速度は0.5Mbpsから13.5Mbpsにまで向上したとしている。

通常パケットが損失していた場合、受信側はパケットが欠落していたことを送信者に伝える必要があり、代替となる交換パケットが受信されるまで何もできない。「coded TCP」では、これまでのようにパケットを1個ずつ送信するのではなく、パケットのブロック情報がひとまとめに記述された代数方程式を送ることでこれを解決しているという。具体的にはデータの一部が失われた場合、受信側で欠落したデータを代数方程式を解くことで埋め合わせることができるらしい。

各記事では「coded TCP」は、積極的にハードメーカーにライセンス供与されており、近いうちに商品としてそれを見ることができるだろうとしている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2012年10月26日 14時43分 (#2259674)

    > パケットのブロック情報がひとまとめに記述された代数方程式を送ることでこれを解決しているという

    ではなく、複数のパケット(今は、p1, p2, p3の3つとします) を、ひとまとめにして送るのですが、3つのパケットをまとめて送るのに、
    1) p1, p2, p3 を一つづつという構成、
    2) p1, p3 は、一つ、p2 は 2つという構成、
    3) p1は、一つ、p2, p3 は、二つという構成

    で、3パケット送ります。(係数とかは、元論文の図を参照していますが、この構成でうまくいくかのチェックはしていません)
    そのもとで、パケットのいくつかが届かなかったとしても、他のパケットの組み合わせから、残り(p1, p2, p3 のうち受け取れなかったパケットのこと)
    が復元できるよ。
    だから、再送信不要だね
    ということです。

    パケットの個数が3じゃなくても、複数のパケットをうまい多重度で組み合わせて、
    複数のパケットをまとめて送るようにすれば、上のような方法で復元可能ということ

    代数方程式といっても、今回のは線形方程式ですよ(linear combination)。代数方程式というと、1次に限定されませんので。
    # p^2 + p + 1 ってなんじゃと思いますよね。

    #エラそうなことをいっても、私自身元論文をななめ読みしただけなので、違ったらごめん

    • by fcp (32783) on 2012年10月26日 17時45分 (#2259810) ホームページ 日記

      タレコミの中の「代数方程式」は「一次方程式」 (線形方程式) に変えるべきだけど、それ以外の点はタレコミは合ってる。あなたの説明の方がよほどおかしい。「p1, p2, p3 を一つずつ」じゃそれだけでパケット三つになっちゃってるじゃん。 p1, p2, p3 のパケット 3 個分の情報を伝えるのにいったい何個のパケットを送る気だよ。

      そうではなくて、「p1 と p2 と p3 の和」とか「p1 と 2×p2 と p3 の和」のように、パケットデータの一次結合を送るんだよ。しかも、係数はランダムに選ぶ。で、受信側は連立一次方程式を解くことでパケットデータを復元する。こうすると、ランダムパケットロスによって途中のパケットが受け取れなくても、受信側は何個のパケットを受け取れたかだけ送信側に伝えれば良くて、どのパケットが受け取れなかったかを伝える必要がないので効率が上がる。

      親コメント
      • by Anonymous Coward

        あー。これ。Network Coding の論文なのか。
        "coded TCP" なんて変なところで切るからわからなかった。

        上コメにあるように、N個のデータを決定するには最低N個の式があればいいので、
        パケットロスがないときは、冗長データはないものとみなせます。

        #係数がランダムだと方程式が解けないこともあるので、「どの係数の式を受け取ったか」は把握していると思います。

        • by Anonymous Coward

          >#係数がランダムだと方程式が解けないこともあるので、「どの係数の式を受け取ったか」は把握していると思います

          この部分は撤回。把握しなくても解けない確率は非常に低いし、解けなければもう一個式を送ってもらえばさらに解けない確率は下がるってのが NC の特徴だった。

    • by Namany (19002) on 2012年10月26日 14時51分 (#2259682) 日記

      ですよね。元論文は読んでませんが、要はRAID5みたいにパリティ持たせてロスト時に復元できるようにしたよ、と。
      一定以上パケットロスが発生する劣悪な環境において、再送のオーバーヘッドがなくなるので改善しますということではないかと。

      この場合、まともな環境ではパリティ分だけ効率が悪くなるわけで、それをさておき10倍以上とか詐欺くさいタイトルつけて、シャノン先生に謝れ。

      親コメント
      • by ruto (17678) on 2012年10月27日 3時33分 (#2260209) 日記

        この手法のキモは従来のTCPにあった無駄な通信を削減できるようにした点です。
        Selective ACKが無い古典的なTCPでは、パケット1, 2, 3を送って2がロスした場合、受信側は「1までは受信できた」としか返さないため、送信側は2と3を再送します。ここで、3は無事に受信されているのに捨てられてしまいます。
        一方、この手法では2番目のパケットがロスした後に受け取った3つ目のパケットの情報も線形多項式を解くのに使うため、パケットを無駄にしません。

        Selective ACKがある場合は受信側は「1と3は受信できたが2はまだ」という情報を送るので無駄な再送を抑えられます。
        論文ではSelective ACKがある場合との比較はしていません(論文は今回の実験より前のシミュレーション段階のものなので、今回の実験ではどうなのか確認していません)。
        “It may be interesting to compare the performance of the TCP variants with that of TCP/NC. However, we focus on traditional TCP here.”だそうです。

        一方、CRCやリードソロモン誤り訂正符号による冗長化ではなく、冗長化のパラメータは実数で連続に調整可能であるためロスの少ない場合はパラメータを調整して効率の低下を抑えられます。

        親コメント
      • 誤解するのは自由だけど、 coded TCP とやらではパケットロスが発生しなければ送るデータ量は通常の TCP とあまり変わらないよ。 RAID 5 と違って送信側が正しいデータを持っているので、当然ながら、パケットロスが発生した場合だけ「再送信」すれば良いようになっている。 (ただし、「再送信」と言っても、普通の TCP とは違い、完全に同じデータを再び送信するわけではない。)

        親コメント
    • by ameo (13166) on 2012年10月26日 16時28分 (#2259757)

      > パケットの個数が3じゃなくても、複数のパケットをうまい多重度で組み合わせて、
      > 複数のパケットをまとめて送るようにすれば、上のような方法で復元可能ということ

      情報の多重度をパケットの廃棄率より少なく抑えれば効果はあるってことだね。
      ノイズが酷い環境だと役立ちそう。
      ただこの方法だと、通信チャネル不足によるアクセス速度の低下には効かないよね。

      親コメント
      • by Anonymous Coward on 2012年10月26日 17時12分 (#2259782)

        パケットをロストした場合、再送要求と、相手が再送要求に応答してくれるまでの
        待ち時間が必要となるため、3%のパケットロスの環境でも、効果は3%よりずっと大きい
        というものですね。

        再送要求の応答を待つ間も、個々の機器が通信チャネルを占有しているようなら、
        これが解消されるので効果はあるでしょう。もっと細かくチャネルの開放と確保を
        しているなら、その手間が減る分、少しだけ効果があるかも。

        元の論文は読んでいません m(_ _)m

        親コメント
    • by Anonymous Coward

      TCPだけどIPじゃないからwiredでパケットロスは他の訂正符号で復元できてる現状、普及への道のりは険しそうですね

      • by Anonymous Coward

        wirelessの話をしてるのに、なんでwiredで普及しないとかドヤ顔なの?

  • by fcp (32783) on 2012年10月26日 22時38分 (#2260054) ホームページ 日記

    MIT、カリフォルニア工科大学、ハーバード大学らの合同研究チームは、基地局の追加や送信電力を増加させることなく無線ネットワークの速度を改善する技術を開発したと発表した。現在、無線ネットワーク通信に使用されているパケットの3%は、干渉や輻輳などが原因で廃棄されているという。さらに電車への乗車中など、高速移動する状況ではこのパケットロスは5%まで増加するとのこと。研究チームが開発した新技術「coded TCP」を使用すればこうしたパケットロスは皆無になるという(technology review [technologyreview.com]、ExtremTech [extremetech.com]、元論文PDF [mit.edu]、Gigazine [gigazine.net]、本家/. [slashdot.org])。

    ここでリンクされている「論文」は、記事とあまり関係ない。

    ネットワーク符号化 (network coding) という概念を利用して TCP 層の効率を上げようという提案がたぶんいくつかあって、そのうちの一つが TCP with network coding (TCP/NC) という提案 (Shah, Médard, Jakubczak, Mitzenmacher, and Barros, Proceedings of IEEE 2011 [doi.org])。タレコミからリンクされている論文は、去年 5 月の VALUETOOLS 2011 [valuetools.org] という学会で発表された、シミュレーションによる TCP/NC の性能評価の話 (Kim, Médard, and Barros [acm.org])。今回の発表のメインは実際に実験して性能を調べたことで、たぶんまだ論文になっていない。英語が苦にならない人には、 MIT Technology Review の記事に対して今回の研究グループの一人である Muriel Médard さんがコメントを書いている [technologyreview.com]のが参考になる。

    ちなみに MIT Technology Review の記事ではこの技術を「coded TCP」と呼んでおり、 TCP/NC という名前は出てこない。僕は TCP/NC と「coded TCP」が同じものだという前提で書いているけど、本当に同じかどうかは知らない。

  • by ko-zu (30390) on 2012年10月26日 14時42分 (#2259673) ホームページ 日記

    演算力に余裕があれば再送よりもエラー訂正符号で送ったほうが帯域と遅延で有利。ってのは物理層では基本的になったけど、TCPは下層のロスが(現代の無線通信環境よりはずっと)稀という前提で設計されていて再送だよりだったから、そこを改善したい。と。
    無線物理層の訂正に頼るよりも、ハンドオーバ中のロスみたいな場合でもソフトウェアで訂正可能とか訂正符号の強度を最適化出来るとか、その辺りが利点?

    • by Anonymous Coward

      しかしホップのたびに余計な演算が必要になってしまうのでは?
      一番、ロスの大きい無線部分で用いるから効果が大きいのであって……

      でも、世界中の膨大なノードの全てでS/N改善すると……ロングテイル効果がでるんですかね?

    • by Anonymous Coward

      UMTSの無線区間でtarget SIRを下げられるのなら、なんでも歓迎したい。
      UTRAN側での再送も不要にできそうだし。
      全部END-ENDで宜しくやってくれるようになる希望がわいてきた。
      規格制定等々やっている人がうまくやってくれないかな。

    • by Anonymous Coward

      WiFiのFECってそんなにしょぼいの?
      Binaryに落とした後の訂正じゃ、尤度が消えてしまうからたいした符号化利得が得られない気がするんだが。

      • by Anonymous Coward

        パケットごと消えた奴が対象だから良いんでない?
        ヘッダが壊れたようなパケットをどのストリームと結びつけるか試行錯誤したり大半消えたパケットで途方に暮れるより、ロストはロストと割りきってストリーム判別可能なパケットだけで再構築したほうが速いと言えば速い。
        コレの利点はパケットより大きい単位でエラー訂正掛けれること。

        ・・・が、ストリームを同定する為にTCPを置き換える必要があって、無線の時だけ(可能なら無線機近くの通信のみ)このTCPに差し替える・・・ってのはどうやってやるんだろう。
        無線アダプタの中でこのTCPと普通のTCPを変換でもするのかな・・・安物WiFiルータの負荷が怖い事になりそうだ。
        無線アダプタに内包しちゃうなら、全パケットを一つのストリームにぶち込んでラップしたほうが効率上がるしうーん?

        • by Anonymous Coward

          TCPの下にもってけばいいだけでしょ

  • by Lurch (10536) on 2012年10月26日 14時29分 (#2259665)
    赤く塗るだけで......(以下略
    --

    ------------
    惑星ケイロンまであと何マイル?
  • by Anonymous Coward on 2012年10月26日 18時39分 (#2259857)

    NICTの一般公開日、きずなのインターネット中継をする部分を担当された方に、一度エラーと再送要求が発生すると、そのとき地上・衛星間にあるデータを全て捨てることになるので極めてロスが大きい、とお伺いしたのを思い出した。

  • 問:ネットワークの速度が何倍向上したか10進数で答えよ

    a) MIT内のWi-Fiネットワークを使った実験ではパケットロスがなくなり、通信速度も通常1Mbpsのところ16Mbpsまで増加したとしている。

    b) また5%のパケットロスが発生していた電車内での通信では、接続速度は0.5Mbpsから13.5Mbpsにまで向上したとしている。

    • by Anonymous Coward

      > 10進数で答えよ
      ここの10は任意の進数で解釈してかまいませんねっ!
      # 10倍「以上」って言っておけばよかったのにね。

    • by Anonymous Coward

      5%のパケットロスが皆無になると、通信速度が10倍になるってのが、いまひとつピンとこない。

      • by Anonymous Coward

        TCPにはパケット喪失・破損に対する復旧手順は存在するが効率が余り宜しくないから。
        ・パケット喪失時の再送条件が確認応答のタイムアウトなので、拡張実装でタイムアウトを最適化しても再送までの待ち時間短縮には限界がある
        →送信側で1パケット喪失後、1秒でウィンドウサイズを全て消費、2秒後に再送判定だとパケロスの度に1秒無駄になる
        ・パケット破損時に起きる受信側による再送要求が大雑把で、相互にSACKやD-SACKがサポートされないと無駄な再送が起きる
        →送信側で1パケット破損後、1秒で再送要求が返ってきた場合その1秒間に送信した全パケットがゴミになる

typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...