Monthly Archives: 6月 2007

鉄道における公衆無線LAN

ITmediaモバイル:ドコモの公衆無線LANがエリア拡大、首都圏私鉄71駅に

6月1日より京浜急行線の全駅で公衆無線LANサービス提供開始 – GIGAZINE

無線LAN大好きな自分でも、公衆無線LAN、特に駅内の公衆無線LANが理解できない。待ち時間が5〜10分くらいの路線にしか乗っていないからだろうか。車内で使えない無線LANに意味はあるのか。

逆に考えると、一般向けではなく、”もともと駅員および駅ナカで商売する人間のためのもの”と考えれば合点がいく。その仮定が正しければ、構築したものを”ついでに”公開しただけの話。小金稼ぎに。

駅ナカで無線LANが関われそうなサービスといえば、自動販売機の進化にみるFeliCaとバーコードとかドコデジやSuipoだったり色々ありそう。要するに、ネットワーク使う商売やりたいんで情報コンセントを用意して欲しいけど有線は敷設し辛いし3G使うと金かかるしどうする?PHSじゃ帯域足りないし遅いよ、というサービスな話で、そこで無線LANですよ、と。

いや、もっと、ビジネス的な展開考えてもいい時期とは思うんだけど、プレスリリースには見えてこない。直接的じゃなくて間接的にサービスを通してお客さんは無線LANの恩恵を受けられるはずなんだけどね。

WiMAXパブコメが出た

総務省が2.5GHz帯無線BBのパブコメを公開,NTTドコモとKDDIが反対:ITproにて各社の概要が伝えられている。

総務省(報道資料)が原文。特に個人のコメントを見ていると、第3世代事業者を毛嫌いしていることが分かる。その毛嫌いの理由は、価格と飼い殺しにあるようだ。

かつてNTTとKDDIが所持していたPHSは携帯電話を超えることのないサービスとして飼い殺しにあった、と。そうした声を考慮して総務省は方針を決めたのだろうか。それとも談合?

WiMAXまとめ

  • イー・アクセスxソフトバンク
  • アッカ・ワイヤレス(アッカ100%子飼い舎)
  • 総務省は華麗にスルー(本命はアッカとウィルコム)
  • KDDI「議決権の3分の1しか持たなくても、当社が中心になって取り組む子会社戦略を取ることができるだろう」
  • ウィルコム「2009〜2010年を想定している」

その他行方不明社

  • YOZAN「!?」
  • NTT「!?」

WiMAXでイー・アクセスとソフトバンクが提携 − @IT
WiMAX事業展開に向けアッカが子会社設立 − @IT
ITmedia News:WiMAX「既存4社認めず」 総務省と深まる対立
KDDI株主総会、WiMAXに積極的に取り組む姿勢は変わらない
第4回 最有力候補に浮上,アッカとウィルコムのキーパーソンを直撃:ITpro

ルータファームウェアOpenWrtを拡張するX-Wrt

Open Tech Press | ルータファームウェアOpenWrtを拡張するX-Wrt

ユーザインターフェースを改良しましたよっと。作者コメントがツボ。

フォン・ジャパン、動画広告表示で公衆無線LANを15分間無料提供

フォン・ジャパン、動画広告表示で公衆無線LANを15分間無料提供:ITpro

単なる広告じゃなくて動画広告を利用するところがミソですな。

課金制サービスのAliensも始めるようだが、さて、どうなることやら。

L3アドホックネットワークのアドレス割り当て問題

半年頃前、アドホックネットワークにおいてアドレスの割り当てはどう行うのか、という疑問があり考えていた。

答えとしては、IPv6リンクローカルアドレスを使えば解決する、という結論に達した。

その答えを実証する記事があったので、紹介。

「Vistaは“IPv6に対応する”が決めごと」マイクロソフト及川氏

 また、IPv6の利点として、ルータやDHCPがないケースにおけるアドホックネットワークの構築を挙げた。IPv4環境でルータやDHCPがない場合、Auto IDによる自動構成に63秒かかる一方、IPv6ではリンクローカルアドレスによって即座に自動構成するという。マイクロソフトではこのIPv6環境でのアドホックネットワークに注目し、アドホックネットワーク内でアプリケーションを共有する「People Near Me」機能も実装した。

及川氏は古川氏のブログでも触れられている通り、VistaへのIPv6等の対応のため尽力されたようで。

「People Near Me」という言葉すら知らなかった。Vistaは色々と面白そうじゃないデスカ。

あと、この及川氏、Vista出荷前にすでにマイクロソフトを辞めていて、現在はグーグルに居るらしい。YouTube – Google Developer Day Tokyo – 及川 卓也 -グーグル最新情報-にて彼がGoogle Gearsを紹介している、ということに繋がる。

DCCPの検証 (12)

LinuxのCCID実装の挙動について調査を行った。

無線LANアドホック1対1環境においてttcpで測定したところ、TCPでは24Mbps、CCID2では20Mbps、CCID3では16Mbpsという結果が出た。TCPではMACのキュー捨てが発生しているがDCCPではCCID2、CCID3ともに発生しない。CCID2ではTCPの輻輳制御を持っているという話であり、TCPと同じくキュー捨てが発生するものと期待していたが、期待通りではなかった。

VLCの伝送においては、CCID2ではかなりのノイズが見られたのに対して、CCID3ではかなり改善された環境で見ることが出来た。キュー関連の挙動についてはttcpと同じく、捨てが見られない。VLCによる実際の映像データの伝送では、ttcpで測定できた16Mbps以上のスループットのデータを出力できている。よってttcpの測定パラメータが間違っていたということか。

ともかく、CCID3はかなり良い、期待通りの結果であり、MAC送信キューの溢れを防ぐ手としてシェーピングとして本環境については期待された仕事を行っていることが確認できた。まだVLC側のアプリケーションバッファの振る舞いがUDPに近いものなので、それをTCP的に動作するようにしてVLCにおけるDCCPの仕事は終わることだろう。

この結果を踏まえて次の論点は、本当にスループットが落ちている場合に、最後の最後まで再送した方がいいのか(TCP)、それは捨てて再送を待つことなく、とりあえず持っている映像を再生したほうがいいのか(DCCP)ということになるかもしれない。

DCCPの検証 (11)

DCCPはデータの再送はおそらくしない…はず。データ以外の再送についてか。

CCID3について調べたがレート制御周りがよく分からない。外からレートを設定するのか、自らレートが一定になるよう制御するのか。

DCCPは次世代UDP、SCTPは次世代TCPと呼ばれているが、どっちかというと、DCCPもSCTPもTCPの亜種だ。UDPの正統進化系譜としてはUDP-Liteこそふさわしいと思う。

現在UDPに残されている作業はブロードキャスト・マルチキャストしかない。

そしてユニキャストならTCP系譜からの進化系と言った方が皆が分かりやすいと思っている。輻輳制御のあるUDPという言い方よりかは、再送とフロー制御のないTCPという方が通りがいい。

(SCTP)Stream Control Transmission Protocolの方が異常な進化だ。複数アドレスを指定可能である点からして、まさに、家庭内複数インターフェースを実現するのに適しているのではないか、と思える位だ。

…最近、IPv6の話題が盛り上がっているが、IPv6が普及する前に、リライアブルIPマルチキャスト・DCCP・SCTPの仕事が終わっていることが望ましいと思う。どれもベストエフォートで非NGNな環境を上手く活用するための必要なプロトコルである。

DCCPの検証 (10)

linux/Documentation/networking/dccp.txtより

request_retries
The number of active connection initiation retries (the number of
Requests minus one) before timing out. In addition, it also governs
the behaviour of the other, passive side: this variable also sets
the number of times DCCP repeats sending a Response when the initial
handshake does not progress from RESPOND to OPEN (i.e. when no Ack
is received after the initial Request). This value should be greater
than 0, suggested is less than 10. Analogue of tcp_syn_retries.

retries1
How often a DCCP Response is retransmitted until the listening DCCP
side considers its connecting peer dead. Analogue of tcp_retries1.

retries2
The number of times a general DCCP packet is retransmitted. This has
importance for retransmitted acknowledgments and feature negotiation,
data packets are never retransmitted. Analogue of tcp_retries2.

手早い話がそれぞれ、tcp_syn_retries, tcp_retries1, tcp_retries2の類似品だということ。

retries1

listenしているDCCPサイドがその接続しているpeerが死んでいると思うまで、DCCPレスポンスがどれくらい再送されるのか。

retries2

一般的なDCCPパケット再送されるときの数。これは再送されたACKやfeature negotiationに対して重要性を持っており、データパケットは再送されることはない。

DCCPの検証 (9)

2.6.21…素晴らしきLinuxカーネル。

VLCにおける検証でkernel BUGが現れることはなかった。

94MB相当の映像データの伝送を行い、ローカルに保存する設定で93MB相当が保存できた。インターフェースで輻輳を起こし、フレームが捨てられることもなかった。DCCPではRTTでWINDOWを絞っているから、ということだろうか。

査読で「DCCPという仕事を知らないのか」と言われた理由が今なら分かる。これでカスタマイズが効けばかなり使えるような気がする。お次はDCCPのRetry関係の仕事を調べてみようか。

カーネルを変更するたびにカーネルモジュール、研究のためのパッチを適用してのカーネルコンパイル、そして全ての実験のやり直しが必要なのは苦痛だが、それ以上に新しいものを触り、検証し、応用する楽しさがある。