debiancdn

AWS, Content Delivery Network and Debian

日別アーカイブ: 2008/03/07

ユビキタス環境におけるパーソナルネットワーク構築法の検討

楠 基池田 旭高見一正創価大

ユーザはパーソナルエージェントを介してPANを構成するデバイスと接続し,さらにPNを構築する.

Touch & Select方式: RFIDタグをデバイスに付帯.手に近いデバイスをタグリーダで認識.

このシステムでは人間が迷わない(あまり質問しない)のがいい点.

SIPモビリティを用いた移動可能なVPN方式の実装報告

加藤淳也川島正久栗田弘之NTT

SIPダイアルアップ方式の実装と評価を説明する.

SIPで確立したメディアチャネル上にIPSec/IKEを交換し,VPNをつくる.RFC3948のNAT-traversalでIPSecをUDP上にしている.

前提: IMS制御.

Fedora8上ノートにwlan,有線LANを両方もつものに実装.802.1xのwpa_supplicantも使う.IKEv2はracoon2.

端末が移動したときはreINVITEでIPアドレス変更を通知.VPN GWはそれをうけて更新する.

VPN確立時間,移動追従時間,IPsec in UDPのスループットを測定した.

VPN確立について,SIP INVITEからOKまでが200msec, IKEが2sec, IKEからkernelへの反映が2secくらい.

(有線からwlanへの移動)ケーブル引き抜き検知981msec,再REGISTER 5279msec, reINVITE 107msec 合計 7秒. というのをみるとHSS/CSCFが重すぎるか.

NAT-TraversalはUDPだと-12%, TCPは-1.8%ほど.

再REGISTERがそれにしても遅すぎ.

得られなかった原因はとしてSigComp未使用なことと,OpenIMSCoreの実装上の不具合(SIP信号を数秒かかえこむ)

QA

  • VPNはったまま移動なんかするの?
    • 今後wimaxとかIMSのカバーする電話を考えると必要.そのためにIMSを選択している.
  • なぜUDPか
    • IMSだから.識別が必要.
  • HSSはcold startしてP-CSCFに一度ロードさせている

オーバレイルーティングによるネットワークただ乗り問題の評価とその緩和手法に関する一検討

平岡佑一朗長谷川 剛村田正幸阪大

ただのりトラフィックの判断は難しい.オーバレイルーティングが普及するとコスト負担が無視できなくなる.

問題評価にはPlanetLabのS-cubeによるものを使用.AS間リンクの種類 from BGP by CAIDA, traceroute

QA

  • 今回は性能よりも,ただのりがどの程度おこっているかに主眼を置いていた.
  • 三角でただのられたら,その中継ユーザから取ればいいじゃないか
    • とれるけど,中継ユーザはそれを知らないので道義的にどうか?
  • ピアリング情報からとればいいじゃないか
    • 今後の課題

分散型仮想ネットワークにおける転送効率化方式の検討と試作機開発

平井 肇斉藤泰孝平野幸男松田哲史三菱電機

業務や行動に応じた特定メンバーからなる仮想ネットワークを動的に構成することを目的とする.

オーバレイネットワークの構築管理に特化したDVCという機械を作る.

DVC間はChordで管理.ID情報ハッシュの上位ビットをユーザが接続する拠点のIDに置きかえられた値に最も近いノードにつける

マルチキャストでも基本は同じだが,送信元ではID情報がリストになっていて,ID情報管理ノードでそのリストだけ送信する.これは拠点内の中継配信ノードに対して投げるようにして問題解決.リダイレクションもできる.

試作機製作,手法検証を実施中

Communication Node Identifying Architecture — Identifier Resolution Architecture —

Ved P. KafleKiyohide NakauchiMasugi InoueNICT

NICTのAKARIの説明.

ID/locator mappingをアーキテクチャのどこでやるかについてのいくつかの考察.

regional network間でやるのがいい?

Identical resolution architectureは素直な交換に見える.

正直これは新情報ないかんじがする.

高ロス率ネットワークにおける分割ダウンロードの性能向上を目指すトランスポートプロトコルについての一検討

舟阪淳一広島市大

TCP/UDP/SCTP/DCCPを用いたHTTPによる並列ダウンロード比較してみる.今回のTCPは通常のTCP.複数のTCPを張るわけではない

並列ダウンロードはHTTP Rangeヘッダを用いて部分を指定.複数のサーバから並列に落とす.

ながれ

  1. 高ロス,高遅延のネットワークではTCPのスループットが低い
  2. TCPは順序制御が厳格だが,ファイル転送についてはアプリケーションで並び替えが可能である.
  3. ならばTCP以外がいいのでは

ns2で実験.

結局UDPが高速.(トラフィック競合がない条件だから?) 実装と実機解析待ち.

帯域確保のための動的冗長TCPの実装と評価

浜 崇之藤田範人NEC)・津川知朗阪大)・下西英之村瀬 勉NEC

TCP-AFECではロス状態と達成帯域,目標帯域に応じた動的冗長度制御.

  1. TCP層内でFEC処理.アプリからロスが見えない
  2. 再送処理,ロスが発生しても再送要求しない特殊ACK
  3. FEC符号アルゴリズムはLDCP符号

TCP layerではMSS毎に分割してパケットを作成,冗長パケットを生成する.受信側は復号不可能なときだけNACK.

ロスが発生してFECでリカバできる見込がある場合はHighest ACKオプションでパケットを進める.

LDCPにしたのは,リードソロモンの100倍速いから.LDCPはマルチインターリーブ行列.

評価: ロスレートが10%くらいまでは,TCP-AVよりも2割増のデータ.40msecのRTTで実験した.

QA:

  • RTT小さいとrenoのほうがいいのでは
    • そう.でもRTT小さいとFECオーバーヘッドも小さくしている
  • ヘッダの変更は?
    • 30バイト程ふえている.TCPのオプションヘッダにいれているので,MSSを小さくすれば現状のrouterのままいれられる
  • どういう環境で使うことを考えているのか.混んだとこで自分だけ幸せになる?
    • TCP-AVと同等程度には他者に影響を与える.ある程度管理されたところでやることになるだろう

沖縄2日目は唯一人とメシくった.

地図画像

今回の沖縄はほとんどひとりで行動していたのだが,今日の夕方にmlabのI君と合流した.

image

適当にはしって,どっかの村だか町の運動場について夕日を撮影.そしてその後にメシにいく.

image

ちゅら花という店.ものすごい混雑で2,3,9,2人のキューの後に名前を書いて待つ.車だから酒はのめないのだが泡盛の充実した店であった.

image

島とうふのチャンプルー+そば+たきこみごはんの定食.I君はゴーヤちゃんぷるー.そしてまだ食べていなかったグルクンの唐揚げは単品で.そして最後にアイスのデザート.たぶんシークワーサー.うまかった.合計3600円.

我が家の納豆朝ごはん

わたしが年間300回以上はまちがいなく食べている朝食.

image

雑穀と玄米のごはん,みそしる,キムチ,納豆+めかぶ+チーズいりオムレツ+フルーツいりカスピ海ヨーグルト のセット.ほぼ朝食はこれで固定されている.

居酒屋でも納豆オムレツがあったりすると頼んで味をチェックなどしている.その様子をみて,そんなもん食えねえ,とか言う人が過去に2人ほどいました.

nnnからのリクエストに答えて:おべんとうの例

image

妻がつくってくれているおべんとうを家から会社に運搬して,食べる直前の絵.こうやってみるとカップ容器がつくりたてとはだいぶ変形してたりしてておもしろいかもしれない.

中央下の「しんじょ」はここのところの一番気にいっているオカズ.