ACM SIGCOMM 2013 メモ
2013-08-20 by Daisuke KotaniACM SIGCOMM 2013に参加してきました。自分が取っていたメモの一部を公開します(途中で分からなくなってメモ取れなかったものは省きました^^;)。印象に残っていることが主だったり、抜けていたりするので、詳しくは論文を参照していただければと思います。
途中、台風で一部のセッションが延期になることがありましたが、無事全部の発表が行われました。
Statistics
- 700人超の参加者
- 246本の論文の投稿、そのうち第2ラウンドの査読に残ったものが96本、PCミーティングで80本、最終的に採択されたものは38本(15%)。採択率は増加傾向。
- Best Paper は "Ambient Backscatter: Wireless Communication Out of Thin Air"
- ACM SIGCOMM Test of Time Award (約10年前に公表された論文で、インパクトを与えたものに贈られる賞)は、PlanetLab
Keynote
- XaaS (Everything as a Service) という言葉が心に残った
Software Defined(Driven) WAN, by Google and Microsoft
- Google が Software Defined WAN、Microsoft が Software-driven WAN という言い方をしていた
- どちらも、Traffic Engineering によってWANの利用率を上げるのが目的
- サービスに直接影響しないトラフィックの割合が高く(バックアップとかデータの転送とかかなぁ?)、それらを制限したり迂回させたりしている。エッジで帯域制御。
- MSはもうちょっといろいろしている
SIMPLE-fying Middlebox Policy Enforcement Using SDN
- 今日のMiddleboxのchainや負荷分散をSDNを使ってやるとかなんとか
Ambient Backscatter
- 目的: バッテリーレスで通信するデバイスを作りたい
- アイデア: 既存の電波を使う
- どうするか: 平均の振幅をちょっと変化させる。RC回路を使う。CSMAを使ったMAC。
Accurate RFID Positioning in Multipath Environment
- 目的: RFID の位置推定を10cm〜15cmぐらいの精度でやりたい
- アイデア: Multipath effect (反射)を使う
- RFIDリーダーは電波の方向と強さが分かる。RFIDリーダーをちょっと動かして音源の位置推定の技術を応用した?
See Through Walls with Wi-Fi!
- 壁の後ろにいる人の位置を推定する
- 送信機を2台使って、壁とかで反射してくる電波をキャンセルするように2つの電波を出す
- 動かないものから反射されてくるものはキャンセルされるので移動する人を検出できる
Maple: Simplifying SDN Programming Using Algorithmic Policies
- 「パケットがもし〜だったら〜する」みたいなものを書きたい
- OpenFlow で Reactive にフローエントリーを入れるような感じで書いて、Proactive にフローエントリーをセットしたい?
- decision tree を作ってtraceする
- runtime tracing と言ってたけどどこでその必要が出てくるのか聞き取れなかった
Forwarding Metamorphosis: Fast Programmable Match-Action Processing in Hardware for SDN
- flexible にパケットとmatchさせたり処理させたりできるチップを作りたい。今のチップはプロトコルの仕様に縛られている
- RMT abstract model というものを作ったらしい。Parse Graph と Table Graph
- どんなチップになるのか、チップとして作れるのかよく分からなかった
TCP ex Machina: Computer-Generated Congestion Control
- 今の TCP の輻輳制御: 簡単なルール、複雑な挙動
- TCP Remy: 複雑なルール、簡単な挙動
- ネットワークのトラフィック、遅延、パケロスの状態がどういうときに、どのように輻輳ウインドウを制御すればよいかをシミュレーションで求めておく。それに従って輻輳制御を行う
- 想定から外れた時の頑健性が課題
FCP: A Flexible Transport Framework for Accommodating Diversity
- いろんな輻輳制御をどのように共存させるかという話(end host oriented なものと network oriented なもの)
- エンドホストに「価格」の概念を持たせる
- エンドホストは全部でW円のお金を持つ、それを各フローに割り振る
- 輻輳している回線を通るものは高いし、輻輳してない回線を通るのは安くなる
Reducing Web Latency: the Virtue of Gentle Aggression
- Google の Web のレスポンスの速度を上げる話
- 特に tail drop (フローの最後のパケット) の再送に時間がかかる
- public network (サーバのみ実装を変えられる) : fast retransmit を速くする
- private network (サーバもクライアントも実装を変えられる): パケットを重複して送ることで再送を減らす
- corrective: FEC とか使ってTCPのパケットのpayloadに冗長性を持たせる
A Provider-Side View of Web Search Response Time
- Bing の検索の応答速度の話
- 時間帯別のブラウザのシェアのグラフとか、JavaScript の処理速度とか、いろいろ見てておもしろかったw
Trinocular: Understanding Internet Reliability Through Adaptive Probing
- インターネットの全ての/24をモニタリングしたい
- CPUの性能やトラフィック等の問題がある
- 常に生きているっぽいホストがあればそこに定期的にpingを打つ、もしpingに反応がなければ他のホストを試す、/24内の過去のホストの密度やup/downの履歴を元にする
- BGPの経路ベースよりも細かいデータが取れる
An Empirical Reexamination of Global DNS Behavior
- ISC の SIE (Secure Information Exchange) から得られたDNSのRecursiveサーバのパケットを分析
Mosaic: Quantifying Privacy Leakage in Mobile Networks
- モバイルトラフィックのユーザの追跡をする話
- cookie があればそれを追跡すればよい
- 「一定時間内に同じIPアドレスを使っているのは同じユーザ」というのを使ってサービス間でユーザの照合ができる
- DNSサーバへの問い合わせのパターンでユーザの識別をしたりとか
Expressive Privacy Control with Pseudonyms
- ユーザをtrackするサイトに対してプライバシーのコントロールをユーザができるようにしたい
- 複数のIPアドレスを持ったり、複数のcookieを持ったりして、アプリケーションからどれを使うかコントロールできるようにする
Towards Efficient Traffic-Analysis Resistant Anonymity Networks
- Torみたいな匿名の通信で、通信量の変化を見ることでユーザの追跡を行う攻撃をどう防ぐか
- Goal は k-anonymity を与えること
- 複数のエッジで同時に Padding を追加することで、通信量の変化を見てもユーザを追跡できないようにする
Participatory Networking: An API for Application Control of SDNs
- SDN の Network OS のアプリケーション間の conflict をどう解決するかという問題?
- "Share" というものを使う。コントロールされるヘッダの値の範囲、誰がownerなのか、どんな操作が許されているのか
- Share Tree
- conflict の解決: Share Tree のノードで、そのleavesにあるものの演算を行う。andを取るとか
- もうちょっとよく読まなければ、という感想
An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance
- LTE の設計目標である、低遅延、広帯域が、アプリケーションで生かされているか?という話
- 某キャリアの匿名化されたパケットヘッダ+HTTPヘッダを分析
- High Queue Delay が TCP のタイムアウトとかを起こして予期しない Slow Start をしている
- TCPのスループットはLTEの帯域の50%しか出てない
zUpdate: Updating Data Center Networks with Zero Loss
- ネットワークの設定変更やアップグレードに関する面倒な調整業務や夜間の作業をなくしたい
- 現在のトラフィックの分散と、変更後のトラフィックの分散を入力すると、どのようにトラフィックの分布を変更していけばよいのか出力してくれる
- パケロスないので調整しなくてよい!
pFabric: Minimal Near-Optimal Datacenter Transport
- 現在のデータセンターへの要求: ユーザのリクエストに早く応答を返すこと
- 小さいフローは遅延が、大きなフローは帯域が課題
- パケットはpriority numberを持つ
- pFabric Switchは非常に小さいバッファを持つ。priority numberが高いパケットから順に送信する
- ホストはaggressiveに再送するのと、輻輳を防ぐためにminimum rate controlをする
- pFabric Rate Control: line rate で送信する、timeoutの時間の推定はしない、パケットがドロップしたらwindow sizeを減らす
HotSDN
- 84本の投稿、24本を採択、14本はポスターで採択
- Towards an Elastic Distributed SDN Controller: OpenFlow のコネクションをあるコントローラから別のコントローラに変更させたいときに、どういう手順でするべきか。Equal という State を導入する
- Leveraging SDN Layering to Systematically Troubleshoot Networks: SDN のトラブルシュートを自動でしたい。せめてトラブルの範囲を絞りたい。今あるツールとないツールの整理
- High-Fidelity Switch Models for Software-Defined Network Emulation: OpenFlow スイッチの性能はものによって違う。特に短いフローにとってはスイッチのCPUの性能が大きい。いろんなスイッチでデータを取って、ソフトウェアスイッチにいろんな遅延を加えてシミュレーションできるようにした
- EtherPIPE: an Ethernet character device for network scripting: SFCの村井研の空閑さんの発表。シェルスクリプト書くみたいにパケットを操作したい
- Protocol Oblivious Forwarding: Unleash the Power of SDN through a Future-Proof Forwarding Plane: OpenFlow はパケットのフォーマットやParseの方法が固定だけど、もっとflexibleに(フォーマット自体を指定できるようにとか)したい。http://www.poforwarding.org/
- Incremental Consistent Updates: ポリシーの変更があったときに consistency を保ったまま変更の処理をしたい。Per-packet Consistency: 全てのパケットは変更前か変更後のポリシーのどちらかで処理される(SIGCOMM 2012)に基づいて、よりオーバーヘッドが少ない方法を提案
- HotSwap: OpenFlowコントローラの切り替えをどうするか。OpenFlow Proxyを作って、そこでネットワークのイベントを記録、変更後のコントローラにそれらのイベントを送って、新しいコントーラが処理し終えてから切り替える
- FatTire: バックアップのパスとかも含めたポリシーを表現する言語がほしい。決定性有限オートマトンではなくて非決定性有限オートマトンで書く
- Best Paper は Towards an Elastic Distributed SDN Controller
- Best Student Presentation Award は High-Fidelity Switch Models for SDN Emulation
感想
- ニーズをちゃんと捉えて説得できるように説明して、現実的なデータセットで評価をしっかりすれば、日本からでもMain Conferenceに通る論文は書けそう
- ポスターはちゃんと書けば通りそうだし、人がいっぱいいてたくさんフィードバックをもらえるので、出したい
- HotSDN は、SDN のバズワード的な雰囲気が抜けないなぁ... という感じ。OpenFlow を使った研究というよりは、SDN のプラットフォームをどう実現していくかという研究が主流になりつつある感じがした。
- SDN の研究でネットワークの処理を表現するモデルが確立されれば、もし仮にOpenFlowがだめになったとしても、トラブルシューティングやネットワークの設定や挙動の検証みたいなところで使えそう
Tweet