無線ネットワークの速度を「10倍向上させる」という新技術 37
ストーリー by hylom
ネット高速化の鍵 部門より
ネット高速化の鍵 部門より
taraiok 曰く、
MIT、カリフォルニア工科大学、ハーバード大学らの合同研究チームは、基地局の追加や送信電力を増加させることなく無線ネットワークの速度を改善する技術を開発したと発表した。現在、無線ネットワーク通信に使用されているパケットの3％は、干渉や輻輳などが原因で廃棄されているという。さらに電車への乗車中など、高速移動する状況ではこのパケットロスは5％まで増加するとのこと。研究チームが開発した新技術「coded TCP」を使用すればこうしたパケットロスは皆無になるという（technology review、ExtremTech、元論文PDF、Gigazine、本家/.）。
MIT内のWi-Fiネットワークを使った実験ではパケットロスがなくなり、通信速度も通常1Mbpsのところ16Mbpsまで増加したとしている。また5％のパケットロスが発生していた電車内での通信では、接続速度は0.5Mbpsから13.5Mbpsにまで向上したとしている。
通常パケットが損失していた場合、受信側はパケットが欠落していたことを送信者に伝える必要があり、代替となる交換パケットが受信されるまで何もできない。「coded TCP」では、これまでのようにパケットを1個ずつ送信するのではなく、パケットのブロック情報がひとまとめに記述された代数方程式を送ることでこれを解決しているという。具体的にはデータの一部が失われた場合、受信側で欠落したデータを代数方程式を解くことで埋め合わせることができるらしい。
各記事では「coded TCP」は、積極的にハードメーカーにライセンス供与されており、近いうちに商品としてそれを見ることができるだろうとしている。
論文ちゃんと読もうね (スコア:5, 参考になる)
> パケットのブロック情報がひとまとめに記述された代数方程式を送ることでこれを解決しているという
ではなく、複数のパケット（今は、p1, p2, p3の３つとします) を、ひとまとめにして送るのですが、3つのパケットをまとめて送るのに、
1) p1, p2, p3 を一つづつという構成、
2) p1, p3 は、一つ、p2 は 2つという構成、
3) p1は、一つ、p2, p3 は、二つという構成
で、3パケット送ります。(係数とかは、元論文の図を参照していますが、この構成でうまくいくかのチェックはしていません)
そのもとで、パケットのいくつかが届かなかったとしても、他のパケットの組み合わせから、残り(p1, p2, p3 のうち受け取れなかったパケットのこと)
が復元できるよ。
だから、再送信不要だね
ということです。
パケットの個数が3じゃなくても、複数のパケットをうまい多重度で組み合わせて、
複数のパケットをまとめて送るようにすれば、上のような方法で復元可能ということ
代数方程式といっても、今回のは線形方程式ですよ(linear combination)。代数方程式というと、1次に限定されませんので。
# ｐ^2 + p + 1 ってなんじゃと思いますよね。
＃エラそうなことをいっても、私自身元論文をななめ読みしただけなので、違ったらごめん
Re:論文ちゃんと読もうね (スコア:5, 参考になる)
タレコミの中の「代数方程式」は「一次方程式」 (線形方程式) に変えるべきだけど、それ以外の点はタレコミは合ってる。あなたの説明の方がよほどおかしい。「p1, p2, p3 を一つずつ」じゃそれだけでパケット三つになっちゃってるじゃん。 p1, p2, p3 のパケット 3 個分の情報を伝えるのにいったい何個のパケットを送る気だよ。
そうではなくて、「p1 と p2 と p3 の和」とか「p1 と 2×p2 と p3 の和」のように、パケットデータの一次結合を送るんだよ。しかも、係数はランダムに選ぶ。で、受信側は連立一次方程式を解くことでパケットデータを復元する。こうすると、ランダムパケットロスによって途中のパケットが受け取れなくても、受信側は何個のパケットを受け取れたかだけ送信側に伝えれば良くて、どのパケットが受け取れなかったかを伝える必要がないので効率が上がる。
Re: (スコア:0)
あー。これ。Network Coding の論文なのか。
"coded TCP" なんて変なところで切るからわからなかった。
上コメにあるように、N個のデータを決定するには最低N個の式があればいいので、
パケットロスがないときは、冗長データはないものとみなせます。
＃係数がランダムだと方程式が解けないこともあるので、「どの係数の式を受け取ったか」は把握していると思います。
Re: (スコア:0)
＞＃係数がランダムだと方程式が解けないこともあるので、「どの係数の式を受け取ったか」は把握していると思います
この部分は撤回。把握しなくても解けない確率は非常に低いし、解けなければもう一個式を送ってもらえばさらに解けない確率は下がるってのが NC の特徴だった。
Re:論文ちゃんと読もうね (スコア:3, すばらしい洞察)
ですよね。元論文は読んでませんが、要はRAID5みたいにパリティ持たせてロスト時に復元できるようにしたよ、と。
一定以上パケットロスが発生する劣悪な環境において、再送のオーバーヘッドがなくなるので改善しますということではないかと。
この場合、まともな環境ではパリティ分だけ効率が悪くなるわけで、それをさておき10倍以上とか詐欺くさいタイトルつけて、シャノン先生に謝れ。
Re:論文ちゃんと読もうね (スコア:4, 興味深い)
この手法のキモは従来の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やリードソロモン誤り訂正符号による冗長化ではなく、冗長化のパラメータは実数で連続に調整可能であるためロスの少ない場合はパラメータを調整して効率の低下を抑えられます。
Re:論文ちゃんと読もうね (スコア:2)
誤解するのは自由だけど、 coded TCP とやらではパケットロスが発生しなければ送るデータ量は通常の TCP とあまり変わらないよ。 RAID 5 と違って送信側が正しいデータを持っているので、当然ながら、パケットロスが発生した場合だけ「再送信」すれば良いようになっている。 (ただし、「再送信」と言っても、普通の TCP とは違い、完全に同じデータを再び送信するわけではない。)
Re: (スコア:0)
そういうあなたのコメントも、卑下した目線に感じられますよ
お互い注意しましょうね
Re: (スコア:0)
ああ、卑下っていやしむって意味もあったんだ。へりくだる意味しか知らなかった。
ところで、これは自分の感覚の話なんだけど、無線の環境ってレイテンシで不利？
ロストしたときのペナルティが大きいからこその効果の大きさという気がするんだけど。
Re: (スコア:0)
まあ「詐欺くさいタイトルつけて、シャノン先生に謝れ」は余計ですな。
読まずに自分で妄想してそれに突っ込む、というのは高速化マッチポンプで面白いですが。
約27倍に通信速度が高速移動中の電車の中でもアップする新技術登場 (スコア:1)
『タイトル』って話なら、
とりあえずGigazineは謝れ、と思う。
Re:論文ちゃんと読もうね (スコア:1)
> パケットの個数が3じゃなくても、複数のパケットをうまい多重度で組み合わせて、
> 複数のパケットをまとめて送るようにすれば、上のような方法で復元可能ということ
情報の多重度をパケットの廃棄率より少なく抑えれば効果はあるってことだね。
ノイズが酷い環境だと役立ちそう。
ただこの方法だと、通信チャネル不足によるアクセス速度の低下には効かないよね。
Re:論文ちゃんと読もうね (スコア:1)
パケットをロストした場合、再送要求と、相手が再送要求に応答してくれるまでの
待ち時間が必要となるため、3%のパケットロスの環境でも、効果は3%よりずっと大きい
というものですね。
再送要求の応答を待つ間も、個々の機器が通信チャネルを占有しているようなら、
これが解消されるので効果はあるでしょう。もっと細かくチャネルの開放と確保を
しているなら、その手間が減る分、少しだけ効果があるかも。
元の論文は読んでいません m(_ _)m
Re: (スコア:0)
TCPだけどIPじゃないからwiredでパケットロスは他の訂正符号で復元できてる現状、普及への道のりは険しそうですね
Re: (スコア:0)
wirelessの話をしてるのに、なんでwiredで普及しないとかドヤ顔なの?
論文 (スコア:3)
ここでリンクされている「論文」は、記事とあまり関係ない。
ネットワーク符号化 (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」が同じものだという前提で書いているけど、本当に同じかどうかは知らない。
TCPv2 (スコア:2)
演算力に余裕があれば再送よりもエラー訂正符号で送ったほうが帯域と遅延で有利。ってのは物理層では基本的になったけど、TCPは下層のロスが（現代の無線通信環境よりはずっと）稀という前提で設計されていて再送だよりだったから、そこを改善したい。と。
無線物理層の訂正に頼るよりも、ハンドオーバ中のロスみたいな場合でもソフトウェアで訂正可能とか訂正符号の強度を最適化出来るとか、その辺りが利点？
Re: (スコア:0)
しかしホップのたびに余計な演算が必要になってしまうのでは？
一番、ロスの大きい無線部分で用いるから効果が大きいのであって……
でも、世界中の膨大なノードの全てでS/N改善すると……ロングテイル効果がでるんですかね？
Re: (スコア:0)
UMTSの無線区間でtarget SIRを下げられるのなら、なんでも歓迎したい。
UTRAN側での再送も不要にできそうだし。
全部END-ENDで宜しくやってくれるようになる希望がわいてきた。
規格制定等々やっている人がうまくやってくれないかな。
Re: (スコア:0)
WiFiのFECってそんなにしょぼいの?
Binaryに落とした後の訂正じゃ、尤度が消えてしまうからたいした符号化利得が得られない気がするんだが。
Re: (スコア:0)
パケットごと消えた奴が対象だから良いんでない？
ヘッダが壊れたようなパケットをどのストリームと結びつけるか試行錯誤したり大半消えたパケットで途方に暮れるより、ロストはロストと割りきってストリーム判別可能なパケットだけで再構築したほうが速いと言えば速い。
コレの利点はパケットより大きい単位でエラー訂正掛けれること。
・・・が、ストリームを同定する為にTCPを置き換える必要があって、無線の時だけ(可能なら無線機近くの通信のみ)このTCPに差し替える・・・ってのはどうやってやるんだろう。
無線アダプタの中でこのTCPと普通のTCPを変換でもするのかな・・・安物WiFiルータの負荷が怖い事になりそうだ。
無線アダプタに内包しちゃうなら、全パケットを一つのストリームにぶち込んでラップしたほうが効率上がるしうーん？
Re: (スコア:0)
TCPの下にもってけばいいだけでしょ
一方日本では (スコア:1)
------------
惑星ケイロンまであと何マイル？
Re: (スコア:0)
Re:一方日本では (スコア:1)
テキィィィィン
で分かり合えたら、無線機器要らなくて便利だなあ。
#何度わかりあったら、あのシリーズ終了するんでしょうね。
Re:一方日本では (スコア:2)
＞#何度わかりあったら、あのシリーズ終了するんでしょうね。
「わかりあえば争いはなくなる」とは日本人特有の思い込みだそうで。
世界中の紛争地では、相手の事だって十分わかっているけど、戦争せざるを
得ないからやっているだけだそうですよ。
御大がそこまでわかってやっているかは知りませんが。
--- de FTNS.
Re: (スコア:0)
むしろZ以降はわかりあう事の出来るNTが沢山いても無駄って感じだからわかっててやってるんじゃないの
Re: (スコア:0)
10倍は何色に塗るんだ。
Re: (スコア:0)
茶色かな。
赤く塗ると100倍になる。
分かる人は限られるのかも (スコア:1)
http://www.jarl.or.jp/Japanese/7_Technical/lib1/teikou.htm [jarl.or.jp]
屍体メモ [windy.cx]
Re: (スコア:0)
47氏がTCP と比較して約 20 〜 30 倍の転送速度を発揮 [srad.jp]させた
きずな (スコア:1)
NICTの一般公開日、きずなのインターネット中継をする部分を担当された方に、一度エラーと再送要求が発生すると、そのとき地上・衛星間にあるデータを全て捨てることになるので極めてロスが大きい、とお伺いしたのを思い出した。
＞無線ネットワークの速度を「10倍向上させる」という新技術 (スコア:0)
問：ネットワークの速度が何倍向上したか10進数で答えよ
a) MIT内のWi-Fiネットワークを使った実験ではパケットロスがなくなり、通信速度も通常1Mbpsのところ16Mbpsまで増加したとしている。
b) また5％のパケットロスが発生していた電車内での通信では、接続速度は0.5Mbpsから13.5Mbpsにまで向上したとしている。
Re: (スコア:0)
> 10進数で答えよ
ここの10は任意の進数で解釈してかまいませんねっ!
# 10倍「以上」って言っておけばよかったのにね。
Re: (スコア:0)
5%のパケットロスが皆無になると、通信速度が10倍になるってのが、いまひとつピンとこない。
Re: (スコア:0)
TCPにはパケット喪失・破損に対する復旧手順は存在するが効率が余り宜しくないから。
・パケット喪失時の再送条件が確認応答のタイムアウトなので、拡張実装でタイムアウトを最適化しても再送までの待ち時間短縮には限界がある
→送信側で1パケット喪失後、1秒でウィンドウサイズを全て消費、2秒後に再送判定だとパケロスの度に1秒無駄になる
・パケット破損時に起きる受信側による再送要求が大雑把で、相互にSACKやD-SACKがサポートされないと無駄な再送が起きる
→送信側で1パケット破損後、1秒で再送要求が返ってきた場合その1秒間に送信した全パケットがゴミになる
・