生暖かく見守ろうP2PSIP「SIProp勉強会(2008/9/19)」

少し時間があいてしまいましたが、2008/09/19にSIProp勉強会に参加してきました。
のべ参加人数は26人で、結構盛況だったと思います。

SIProp勉強会 告知 (講師Tomoさん提供の資料もあります)
http://www.siprop.org/ja/2.0/index.php?%B3%AB%C8%AF%2F%A5%B3%A5%DF%A5%E5%A5%CB%A5%C6%A5%A3%A1%BC%2F%CA%D9%B6%AF%B2%F1%2F2008%2F09%2F19

Tomo’s HotLine「P2PSIPの解説講演をします＋近況報告」 (講師Tomoさんのblog)
http://toremoro.tea-nifty.com/tomos_hotline/2008/09/p2psip-5e45.html

無印吉澤 [P2P][SIP]第10回P2P SIP勉強会（9/19）と第3回オーバレイネットワーク研究会（9/27）のお知らせ
http://muziyoshiz.jp/20080907.html

また私的メモを残しておきます。
講師のTomoさんから、主に以下の解説がありました。

• P2PSIP-WGコンセプト "draft-ietf-p2psip-concepts"
• P2PSIPにおける経路確認 "draft-zheng-p2psip-diagnose"

P2PSIPメインプロトコルである、"RELOAD ("draft-ietf-p2psip-reload")"は、130ページの大作なので、今回は対象外になりました。:-D

で、個人的な結論は、「生暖かく見守ろうP2PSIP」でした。

draft-ietf-p2psip-concepts

P2PSIP-WGの "infomational" draftです。このI-DにてP2PSIP-WG自体の方針を決めて、その上でその方針を具体化する技術議論を行うということらしいです。

そのP2PSIP-WGの活動を理解する上で最も重要なI-Dについての解説が講師Tomoさんにて行われ、SIP関連、P2P関連、その他それぞれの有識者からの厳しい意見でかなり熱い議論が交わされました。

まずは、用語定義の説明。
このI-Dが定義している用語は主に以下でした。（個人的に重要だと思ったもののみ抜粋）

• P2PSIP Peer
  • P2PSIP Peer Protocolをしゃべる
  • DHTなどによってlocation infomationを格納/参照/修正する
  • location infomationを元に、メッセージのルーティングを行う

• P2PSIP Client (Optional)
  • P2PSIP Client Protocolをしゃべる
  • location infomationの参照/修正をする
  • その役割などは、still under discussion

• Bootstrap Peer
  • オーバーレイに参加するノードが最初に参加要請するノード

• Bootstrap Server
  • Bootstrap Peerを不特定のノードに教えることができるサーバ

• P2PSIP Peer Protocol
  • DHT(など)をベース
  • P2PSIP Peer同士がやりとりするプロトコル

• P2PSIP Client Protocol
  • SIPをベース
  • P2PSIP PeerとP2PSIP Clientの間でやりとりするプロトコル

• Peer-ID (≒ Node-ID)
  • オーバーレイ上のユニークなID
  • DHTにおけるhash値などを想定しており、ユーザフレンドリーなものではないことを前提とする

• User Name
  • SIPにおけるSIP-URIなどを想定しており、ユーザフレンドリーなものであることを前提とする

• Resource-ID
  • Userã‚„Serviceといったリソースを特定するユニークなID
  • 分散アルゴリズムによってオーバーレイ上の返信可能なPeer(s)を確定する
  • ユーザフレンドリーなものではないことを前提とする

とりあえず、この用語定義の段階で既に議論が紛糾 :-D

議論を簡単にまとめると、以下。

• 用語が既存のものと誤解を生じやすく、わかりにくい
• Peer-IDとResource-IDはどう違うのか？分ける意味があるのか？
• Peer-IDã‚„Resource-IDなどの一意性は誰が保証するのか？

結論が出ず、もやっとしたまま次に進みました。

続いて、シーケンスイメージの概要説明。
まずは、「シーケンスイメージ1」

   Peer X           Peer Z           Peer Y
    |                 |                |
    |                 |       Put(U@Y) |
    |                 |<---------------|
    |                 | Put-Resp(OK)   |
    |                 |--------------->|
    |                 |                |
    | Get(U)          |                |
    |---------------->|                |
    |    Get-Resp(U@Y)|                |
    |<----------------|                |
    | INVITE(To:U)    |                |
    |--------------------------------->|

ここで、会場の思考が止まりました。
せっかくGetで"Y"を教えてもらったのに、結局最初から知っている"U"を使って Peer X がINVITEするんだったら、Getの意味なくね？

続いて、「シーケンスイメージ2」

   Peer X           Peer Z           Peer Y
    |                 |                |
    |                 |       Put(U@Y) |
    |                 |<---------------|
    |                 | Put-Resp(OK)   |
    |                 |--------------->|
    |                 |                |
    | INVITE(To:U)    |                |
    |-----------------| INVITE(To:U)   |
    |                 |--------------->|
    |                 |                |

これは、シーケンスイメージ1と較べて会場納得。
まだ動きそうな気がする。

次は、「シーケンスイメージ1」を発展させた「シーケンスイメージ3」

   Peer X           Peer Z           Peer Y           Peer W
    |                 |                |                 |
    |                 |       Put(U@W) |                 |
    |                 |<---------------------------------|
    |                 | Put-Resp(OK)   |                 |
    |                 |--------------------------------->|
    |                 |                |                 |
    |                 |                |                 |
    |                 |                | REGISTER(To:U)  |
    |                 |                |---------------->|
    |                 |                |             200 |
    |                 |                |<----------------|
    |                 |                |                 |
    |                 |                |                 |
    | Get(U)          |                |                 |
    |---------------->|                |                 |
    |    Get-Resp(U@W)|                |                 |
    |<----------------|                |                 |
    | INVITE(To:U)    |                |                 |
    |--------------------------------------------------->|
    |                 |                |    INVITE(To:U) |
    |                 |                |<----------------|
    |                 |                |                 |

なんじゃこりゃー。やめてくれー。

最後に、「シーケンスイメージ2」を発展させた「シーケンスイメージ4」

   Peer X           Peer Z           Peer Y           Peer W
    |                 |                |                 |
    |                 |       Put(U@W) |                 |
    |                 |<---------------------------------|
    |                 | Put-Resp(OK)   |                 |
    |                 |--------------------------------->|
    |                 |                |                 |
    |                 |                |                 |
    |                 |                | REGISTER(To:U)  |
    |                 |                |---------------->|
    |                 |                |             200 |
    |                 |                |<----------------|
    |                 |                |                 |
    |                 |                |                 |
    | INVITE(To:U)    |                |                 |
    |---------------->| INVITE(To:U)   |                 |
    |                 |--------------------------------->|
    |                 |                |    INVITE(To:U) |
    |                 |                |<----------------|
    |                 |                |                 |

このあたりから、みんなに疲れが見え始める。

このシーケンスイメージの議論の簡単なまとめは、以下。

• とりあえず、図の"Peer Y"と"Peer W"の位置は逆にするべき
• シーケンスイメージ1は、何がしたいのかがわからない

この後、NATやセキュリティの説明もあったのですが、「P2PSIPだめだ」という空気が広がってて、「なぜだめか？」「どうだめか？」という話が盛り上がりました。

• 無理矢理DHTとSIPをまぜていて、それぞれの利点を失っている
• 重要な課題は、スコープ外または先送りにして、本当に実装できるのか疑問
• プロトコル設計ばかり先行して、実装や実際のサービスを無視している様に見える

ということで、「この場で、正しいP2PSIPを作って提案してみますか？」という半分冗談も出してみましたが、kibayosさんから「それ、もうPIAXでやってますけど」という発言が出て確かにそうだと納得。
http://www.piax.org/

私個人の意見としては、Skypeの成功(?)をきっかけとして、P2P, DHT, オーバーレイなどの流行語を、オープンアーキテクチャとしてIETFで議論したら面白そうだと誰かが思いつき、比較的親和性が高そうで良くも悪くも盛り上がっているSIPとくっつけるとみんなの注目を集められそうだと考えたのかなぁと（そして、現にIETFでも、この勉強会でも人が集まっているので、その考えは成功している）。

私としては、現在やっている開発に取り入れられるか？と微かな期待を持っていたのですが、しばらく静観することにしました。

でも、P2PSIPをネタにして、様々な分野の有識者の意見を聞き、議論できたのは非常に楽しかったです。

draft-zheng-p2psip-diagnose

P2PSIPの上で、pingやtracerouteと似た機能を提供することにより、経路到達性の確認が出来るようにするI-Dです。

pingに似たシーケンスイメージ。

    Peer-1              Peer-2               Peer-3               Peer-4
      |                    |                    |                    |
      | (1).Echo Request   |                    |                    |
      |------------------->|                    |                    |
      |                    | (2).Echo Request   |                    |
      |                    |------------------->|                    |
      |                    |                    | (3).Echo Request   |
      |                    |                    |------------------->|
      |                    |                    |                    |
      |                    |                    | (4).Echo Response  |
      |<-------------------|--------------------|--------------------|
      |                    |                    |                    |

                           Figure 4 P2PSIP Ping example

tracerouteに似たシーケンスイメージ。

    Peer-1              Peer-2               Peer-3               Peer-4
      |                    |                    |                    |
      | (1).Echo Request   |                    |                    |
      |------------------->|                    |                    |
      |                    | (2).Echo Request   |                    |
      |                    |------------------->|                    |
      | (3).Echo Response  |                    |                    |
      |<-------------------|                    |                    |
      |                    |                    | (4).Echo Request   |
      |                    |                    |------------------->|
      |                    | (5).Echo Response  |                    |
      |<-------------------|--------------------|                    |
      |                    |                    | (6).Echo Response  |
      |<-------------------|--------------------|--------------------|
      |                    |                    |                    |

                       Figure 5 P2PSIP Traceroute example

これまた議論が紛糾。

• 下の仕組みが何も決まっていないのに、上の仕組みを先に決めても動くわけがない
• 上の仕組みを先に決めて、下の仕組みをそれにあわせるということなのか？
• オーバーレイでは、送信元や途中経路などを隠蔽するのもセキュリティ的な目的の一つなのに、tracerouteできたら意味がなくなる

私としては、K井さんの次の言葉が妙に納得でした。

• MPLSのときにping/tracerouteができないと議論になってから、とりあえずどのプロトコルでもping/tracerouteの機能は提案される傾向にある
• P2PSIPでも早い者勝ちとばかりに出したが、ベースの仕組みができていないので勇み足っぽい感じになってしまっている

懇親会

懇親会は、いつも通りとても楽しかったです。
特に印象的だったのは以下。

• mohta先生＆F川さんとのPKIè­°è«–
• T橋さんがCGN (China Grade NAT) draftを書く(!?)