面白いことを発見してそれを面白がる

SDNとネットワーク性能特性の関係

先週SantaClaraで開催されたOpen Networking Summitが大盛況だったこともあり，SDN (Software Defined Network), 即ちVirtualization, Programmability, Management (Orchestration)について再度考えている．（このBlogはその時々の思考を記述しておくために書いているが，自分の過去のエントリーは，恥ずかしいやら情けないやらで，あまり読み返す気がしない．しかし，状況が刻々と変わるとはいえ，ある程度意見に一貫性がなければ，技術者としての信頼性にもかかわる．そこで，数か月前の自分がこの件についてどう考えていたかを，仕方なく振り返った．前回の記事）

今の考えは，前回の記事から根本的に変わっていないけれど，集中管理か分散かの議論は，適用領域と捉え方を明確にしない限りは意味が無い（例えば自律分散システムの代表のようなルータであっても，Routing EngineがForwarding Engineの動作を決めている，という意味で，捉え方によっては集中システムである）し，そもそもちょっと斜に構えていて真の要望や意義を捉えきれていない，という意味で，やはり前回の投稿内容は少し情けないと言わざるを得ない．

今言えることは，まず，「ネットワークを再定義したい」という，市場の大きな波があることは確かである．これはとてもわくわくすることだ．一方，このことにより，ネットワークやシステム機器ヴェンダが無価値化する，という論調もある．これも，冷静に受け止める必要がある．実際，ある領域においては既に起こっていることだ．この擾乱期においては，これからのネットワークの在り方についての真の要望や意義を捉え，かつ，それを実現して行くことが重要と思う．

ところで，SDNで一つ疑問なのは，ネットワーク性能特性をアプリケーションソフトウェアがどの程度指定すべきか，という点である．

SDNのNetwork Programmabilityによって，ネットワークの自動化，オンデマンド化，最適化，シナリオ化が進むであろう．しかし，それは構成，トポロジー，エンカプスレーション，パス計算やパス決定，その他イヴェントと言った，ネットワークの一面を捉えたものに過ぎない．ネットワーク技術の進歩は，その性能特性の進歩である，と言えるにも関わらず，である．

帯域・伝送効率，スループット(pps)向上は勿論，各種コントロールプレーン，Leaky Bucket Modelに基づくpolicing, Queue Service Scheduler, Congestion Management,　Load balancing, 冗長，異経路化，Fast Convergence, Fast Protectionなどなどの技術は，ひとえに性能特性，SLA特性を上げるために開発されてきた．だから，一言でA地点からB地点への接続性と言っても，そのネットワークがどのような設計コンセプトでどのように構成されているかによって，得られる性能特性が全く異なる．また，ネットワークの性能特性は相対的なものでなく，数値を特定しているものも多い．帯域やppsのみならず，50msec以内の迂回時間，99.99%の稼働率，など．SDNでは，このような性能特性を，アプリケーションが活用すべきなのか．活用できるのか．

基本的に，ソフトウェアは，自身の性能の記述ができない．その性能は専らそのソフトウェアが実行される環境に依存するためである．したがって，その性能特性は，外側からベンチマーク試験等で計測するしかない．自分の性能を記述できないのに，性能指標をプログラムに取り込むことには無理があるかもしれない．

実際，例えば現在のOpenstack Quantumでは，指定するのはNetwork IDとPort程度で，とりあえずConnectivity確保とIsolationができればよいという感じ．確かに，そのネットワークの性能特性を抽象化されたセットにして，それを"Network ID"に紐づける，というのが，現実的な運用方法なのかもしれない．

一方，折角のProgrammabilityなのに，この程度の結合度でよいのか，という気もする．この程度であれば，別にProgrammableである必要はないのでは．（勿論，Programmabilityの目的は別のところにあるのかもしれないけれど．）

そこで，ネットワークを「環境」として捉えるのではなく，「オブジェクト」として捉えるのはどうだろう．「オブジェクト」であれば，性能指標もプロパティとして与えることができる可能性があるのではないか．実は以前，ネットワークのコネクティヴィティ／トランスポートをオブジェクトとして捉える提案を，論文にしたことがある．2007年のことだ．勿論，論の運びが学術的でなく，論理的根拠も実際の裏付けもなく，不採録になったが，目の付けどころは悪くなかったかもしれない．練り直して再チャレンジしようかなぁ．

見方・捉え方の違い

長年技術者をしていると，「えー，そんなアホな」という場面に遭遇することがある．そのような場合，「アホですか」とは言わずに，なんでそのような事態に立ち至ったかをまずは理解するようにしなくてはならない．自分の感覚からすればどんなにばかげているように見えても，それは単に見方・捉え方の違いに過ぎない，ということがよくあるからだ．

私も，「アホですか」と言われた（いや，実際にそう言われた訳ではなくても，あからさまにそういう雰囲気になった）ことは何度もある．

大分昔，KAME(BSD系IPv6 protocol stack)の開発者の一人に「何故IPv6に下位互換性を持たせなかったんですか？」と訊いたら，「へ？（アホですか）」，と呆れられ絶句された．「だってヘッダのアドレススペースが足りないんだよ？！いくつか互換性を提供するための技術はあるが(IPv4 mapped addressとかNAT-PTとか(当時)）根本解決にはならない．そもそもNATが蔓延しend-to-end原理が崩壊したIPv4なんかさっさとやめて，ネットワークを再構築した方がよい．」当時はこういう論調だった．

一方， これは2年前，Systems Engineeringの大家で，現在はNUS(シンガポール国立大学)でSystem Thinking, Critical Thinkingを教えられているJoseph Kasser教授に，インターネットにおいてIPv6がなかなか普及しない話をしたとき，「全く新たな価値をもたらすものでない限り，下位互換性を持たせなければ普及しないのは当然．（アホですか）」と言われ，ここでもそうですよねと引き下がらざるを得なかった．

立場，見方，捉え方，パースペクティヴの違いにより，そしてその時の状況により，現象の捉え方がこんなにも異なるのだ．

人間は，成長するに従い，ある見方・捉え方を身につけて行く．しかしそれは，同じコミュニティに属するごく親しい間柄でも，人によって異なることが多いし，ましてや広く普遍的なパースペクティヴというものは存在し難い．だから，何かを他者と一緒に成し遂げようとする場合は，できるだけ理にかなった仮説を提示し，それについて，言葉をつくし，場を共有して，相互理解を醸成する必要がある．これは，相手が一人ないし少数であれば対話であり，多数の場合は，このことこそが「リーダーシップ」というものなのだろう．

 

（おまけ）

私は職業柄0から数え始める習性がついてしまっているが，一般常識的には1から数えるのが普通だろう．そのため音楽の合奏練習で困ることがある．小節番号や練習番号がついている場合は問題ないのだが，「2番かっこの小節から2小節目」とか言われるとだめだ．脳が勝手に「2番かっこの小節」を0として，そこから1,2と数え，都合3小節目から弾き始めてしまう．先日も，うまくいかず雰囲気がぴりぴりしているときにやってしまって，「アホですか」状態になった．これも捉え方の違いではないかと思うが，勿論言い訳はできない．

一方，音程の表し方（ドとレは2度，ドとミは3度とかいうやつ）で，「同音なのに1度というのはおかしいのではないか．ドとドだったら0度，ドとレで1度なのでは」，という人がいるが，音程は，｢数」ではなくて「比」なので，同音は1度でよいのです．

 

Programmability, Virtualization, そしてCentral Control －Openflow考

• Programmability  --- コンピュータ言語を使って動作を記述できること
• Virtualization      --- 物理的なリソースに捉われない抽象化
• Central Control    --- 集中制御

Openflowはこれらの，各々は従来からあった概念を一つにまとめることにより，これまでのネットワークに対する新しい技術として，注目をあびることになった．何となく新しいものを求めていた人々が一気にここぞと群がる構図，そして，一見わかりやすいが本質を間違った解説の氾濫は，どうにもかたはらいたい感じがするけれど，エコシステムはこのようにして生成される，という側面もあるのだろう．（どんなに技術が優秀でも，エコシステムができないために普及しない，というものは山ほどあるので．）

ところで，ProgrammabilityとVirtualizationは，コンピューティング高度化に伴う，ネットワーク進化の自然な方向に思える（特にProgrammabilityについては，大分前からできるのに，運用慣習的に，今まであまりやらなかっただけだ）．しかしCentral Controlは，どうも私はあまり好きではない．集中制御に対する自律分散制御のよいところは，ボトルネックのないスケーラビリティ，障害時の自動回復，状況に対応する弾力性，などであるが，何といっても，「知が偏在する」，というシステムのあり方自体が好きだ．全知全能の神はいなくても，それぞれが限定合理性(*)の中で持ち場を果たすことにより，システム全体が機能し，さらに成長進化する．

現在なぜCentral Controlが見直されているか，というと，Virtualizationとの組合せによりScale outさせることができるため，Single Point of Bottleneckを克服できるようになったからだと思う．しかし根源的問いとして，「全知全能性」を達成できるのか，という問題が残る．

勿論，データマイニングによる統計の高度化は言を俟たない．これまでの，局所的な専門知識や技のようなものは，どんどん凌駕されて行くだろう．ネットワークのパス計算や決定も，統計的に最も合理的な判断により，集中的に行いたい，という要望が出てくるであろうことは理解できる．しかし，それでも，解けない問題はあるし(NP-Complete, NP-Hard)，当然間違えることもある．また，現実の実装を考えると，最適性よりも即応性が求められる場合もある．

なので，集中制御を導入した場合も，Last resortとしての自律分散は残す，というハイブリッドアプローチが求められると思う．（で，その場合は，「ネットワーク機器に機能はいらない→コモディティで価格破壊...」，ということにはなりませんよ．残念ながら:)）

(*) オリジナルはH.Simonだが，ここではStanford福田先生の論文を掲げたい．

http://www.panda.sys.t.u-tokyo.ac.jp/ohsawa/SysInPDF/002-Fukuda.pdf

 

"Carrier Grade" - 再定義が必要

通信事業者（キャリア）のシステムは「キャリアグレード」と呼ばれる。通信システムは、企業や社会の基幹を担うため、高い信頼性が求められる。その要請に応えるためのシステム特性が、「キャリアグレード」という言葉に集約される。

「キャリアグレード」の具体的条件としては、「High Availability(高可用性)」、「Guarantee(帯域・性能などの保証)」、「Predictability(予測可能性)」、（「Security(機密性・安全性)」、「Transparency(透過性)」、「Continuity(継続性)」などがあり、サーヴィスの性質により、これらの要素が適宜組み合わされ提供される。特に信頼性の観点からは、高可用性・性能保障・予測可能性が最重視されるので、ネットワークエンジニアは、可用性を保証するために必要なメディア特性、冗長度、検知・切り替え手法、また最繁時に予測されるトラフィック量、許容される遅延などから、必要な回線や設備を算出する。そのためにはシャノンの情報理論、そしてオペレーションズリサーチ（特に、信頼性工学、トラフィック理論、待ち行列理論）を駆使する必要があるから、これらは通信技術者の必修科目であった。DNAと言ってもよいかもしれない。

そんな中、1996年にNTT-Communicationsが開始したインターネットサーヴィス「OCN」は、「ベストエフォート」を強調して画期的だった。安価である代わりに「通信品質を保証しない」と宣言したのだ。脱「キャリアグレード」宣言(!!)である。

でもそんな画期的な宣言ができたのは、あくまでも代替的サーヴィスであったからであろう。1996年の時点では、基幹通信網としては専用線が主流だった。例えばATMメガリンクが開始されたのはOCNサーヴィス開始の翌年の1997年である。こちらの方は勿論「キャリアグレード」だった。

あれから15年の歳月が経過し、殆どの通信がIPになった今も、「キャリアグレード」は健在である。通信事業者がIPv4枯渇対策のために導入するNATは「キャリアグレード」だし、スイッチやルータには、いかなるモジュールや回線の故障時にもsub second（１秒未満）で切り替わることが求められる。

しかし、今、「キャリアグレード」の再定義が必要ではないだろうか。これまでの「キャリアグレード」を追求している限り、通信事業者は自らの首を絞めることになると思えてならない。以下、論拠を述べる。

---------------------------------------------------------

• トラフィック理論では、トラフィック生起率や処理時間はポアソン分布で近似できるとする。（事象は離散的ではあるが、集積されれば正規分布のように平均と分散で表現できる。）しかし、現在、実際に起こっている事象のいくつかは、べき乗分布に従うことがわかっている。べき乗分布の場合、「平均」という概念は無意味となり、トラフィック理論は使えない。

• 設備計画のためには、ある程度トラフィック量の推移を予測する必要がある。しかしスマートフォンの急成長など状況がめまぐるしく変わる現在、需要予測はほぼ不可能である。

• 可用性をある程度以上に向上するためには、経済的にもネットワーク設計的にも高いコストがかかる。

•  
  • 分散並列処理が可能でない場合、システムにはボトルネックが生じ、その可用性を上げるために冗長度を上げようとしても、収穫逓減になる。

•  
  • 分散並列処理が可能な場合は、「Consistency（一貫性）、Availability（可用性）、Tolerance to Network Partitions（耐分散性）の3つ全てを成立させることはできない」という、BrewerによるCAPの法則（*）に当てはまってしまう。即ち、分散処理系の場合、可用性か一貫性のどちらかを犠牲にしなければならない。ここでは可用性を上げる前提のため、一貫性をある程度妥協し、システム全体で何らかの補完をするような手立てが必要となる。（*）http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

• Ethernet Aggregationが主流の現在、回線信号断(LoS)では障害を検知できないので、sub secondで切り替えるためには、Continuity Checkをmsec単位で行う必要がある。（このこと自体がスケールネックになる可能性を持つ。）一方、殆どのトラフィックがTCP/IP、HTTPに収斂されている現在、許容通信断時間は変わってきているのではないか。例えそうでないとしても、ネットワークのある一部分を取り出し、そこでsub secondの切り替えに固執することは、あまり合理的とは言えない。

---------------------------------------------------------

東北の震災のときに、「キャリアグレード」である電話・携帯電話は不通になったが、無料のSNSは使えていた。（私事で恐縮だが、震災の日、世界中の同僚や友人からは次々と連絡が入るのに、子供たち(SNSやPCメールはまだ使っていない)と連絡が取れない、という状態が半日以上続いた。今思い返しても本当に切ない。）勿論、電話システムの場合は呼制御があるので、同列に比較することはできないことはわかっているが、それでも、「キャリアグレード」っていったい何なんだ、と思わざるを得ない。

しかも、安価なクラウドサーヴィスに、「キャリアグレード」は、このままでは対抗できない。クラウドサーヴィスは、必要に応じてスケールアウトでき、かつ、ノード障害時も他ノードに処理を引き継ぐことができる。一方、「キャリアグレード」なのに（いや、だからこそ?）、docomo sp mode障害のような事故は起こる。通信事業者の報道発表資料で、「原因は通信設備故障、サーバふくそう」とか、「容量のさらなる増強をし今後に備える」という言明を聞くたびに、痛々しい気持ちになる。トラフィック需要なんかこれからも予測できないし、スケールネックを解消しなければ、どれだけ容量を増強しても、コストばかり嵩み、焼け石に水であろう。

「キャリアグレード」という概念自体は、通信事業者の社会的責任、コミットメントを表すものとして、有意義で価値のある概念だと思う。しかし、この概念が、従来の設計・計画・管理手法を踏襲し、局所最適を助長させるものとなってしまっているのではないだろうか。

 

今、「キャリアグレード」の再定義が必要だと強く思う。信頼性とは何か。どのようにしたら、現代の複雑多様な社会要請に応え、増えるトラフィックをさばき、企業活動や個人の生活を充実させることができるようなサーヴィスを提供することができるのか。根本に戻って考え直す必要がある。

 

 

 

 

技術の「融合」を考える MPLS-TPのケース

技術変遷の過程では、相補的対立的な概念や技術が生まれる。例えば、

• Circuit vs Packet
• Intelligent vs Stupid
• 集中 vs 分散
• Control vs Open
• Top down vs Bottom up
• ATM vs Ethernet
• Connection oriented vs Connection-less
• IP vs other Networking Protocol (SNA, Appletalk, IPX, etc.)
• ...

それらは、時代の流れにより、どちらかが凌駕したり（*1）、共存しながら勢力変化を繰り返したり（*2）、融合したり（*3）して、技術は次のステージへと変遷する。

(*1) L2としては、Ethernetがクライアントとしてもインフラとしても使われるようになり、ATMは縮退した。L3はIPに収斂し、他のプロトコル(SNA, Appletalk, IPX, etc...)は使われなくなった。

(*2) 集中と分散というアーキテクチャ概念は、形を変えながら、出現する。たとえば通信分野では、管理システムによるパス制御（集中）→自律的ルーティング（分散）→Openflowのような、Controllerによるパス制御（集中）...。コンピューティング分野でも、ホスト・端末/TSS（集中）→クライアントサーヴァー（分散）→クラウド（分散された集中）...。

(*3) MPLSは、Connection-Oriented概念とConnection-less概念を包含、融合した。

 

そしてここ数年では、CircuitとPacketの融合が起こっている。Ethernet over SONET/SDH、Circuit over MPLS、PacketとOptical(OTN)の統合、などなど。そして最近各所で最も話題になっているのが、MPLS-TP(MPLS Transport Profile)である。

MPLS-TPは、もともとITU-Tが、MPLSのConnection Oriented的な要素を利用して、伝送的特徴を持つパケットトランスポート技術を開発しようとしたことに端を発する。そこに、MPLSを開発したIETFが"待った"をかけた。「MPLSはひとつの統一的技術であるべき。他の標準化団体が独自に拡張することは好ましくない。」そして、ITU-TとIETFでの共同作業が開始され、MPLS-TPとして標準化されることになった。

私はこれまでこの技術にあまり関わっていないが、最近になって顧客からの要請も多く、我々のルータでも一部実装が行われつつある。今回チュートリアルの依頼を受けたことをきっかけに、ここ数日で集中的にキャッチアップし、勉強した。そして....、愕然とした。

相補対立的なものが融合するためには、お互いの技術の良さが共存でき、よい協調、よい使い分けができなくてなはならない。

しかしMPLS-TPの場合は、それどころか、それぞれの技術のよさを打ち消しあう。IPの弾力性（resiliency）、自律性（autonomy）を失うのみならず、回線交換の、決定論的な予測可能性（遅延・ゆらぎ・紛失が起こりえない）という特徴も失う。（MPLS-TPは統計多重である。）

MPLS-TPの主要な要件は、「IPへの非依存性」と、「伝送技術的なOAM」である。パスの疎通確認(Continuity Check)、トレース、ループバックに代表されるOAM制御は、伝送では、Framing Overheadに組み込まれている。IP/MPLSはそうではないので、別の方法で実装した。しかし機能面から見れば、既にある機能を、別の方法で実装することに他ならない。何か有益な機能が新たに追加される訳ではない。

そのため、同じ機能要件に対して複数の実装を許容すべきか、という議論が白熱している訳であるが、それよりも大きな問題は、「IPへの非依存性」という要求は、ルータ、というか、コンピューティングプラットフォームにとって非常に困難、という点である。これら装置は、プロセス間通信を行うためにも、普通にTCP(UDP)/IPを使う。IPに依存しない、となると、複雑かつ余計なステップが必要となり、非常にトリッキーな実装になってしまう。（Pseudo WireのOAMもIP非依存が求められるが、Pseudo Wireは、LSP上のアプリケーションだからよい。LSP自体のIP非依存というのが厄介なのだ。）

技術自体の良し悪しを論じるつもりはない。市場が決めることだ。そして、現在のMPLS-TPへの要求の高まりは、伝送技術に長けた勢力が統計多重を取り入れようとしている、ということだと理解できる。しかし、IPを技術の機軸に据えるIETFが手を出すべきではなかったのではないだろうか。それぞれの技術の良さを共存させ、よい使い分けを実現できるとは思えない。お互いの良さを打ち消しあい、疲弊するだけだ。混ぜるな危険。少なくとも、我々は手を出すべきではないと思った。

 

 

哲学 - 思考のフレームワークか、底知れない深淵か

ルータエンジニアとして、そして、インターネットコミュニティの一員として、「インターネットのこれから」を考えることは、いつの間にか私のライフワークになっている。で、最近は、少し哲学を勉強中。

その昔、少しだけ哲学少女だったことがあった。すぐに挫折したけれども。その後幾年月を経て、結局、倫理学（非帰結論的）はニーチェで終焉し、論理学はウィトゲンシュタインとゲーデルで終焉し、哲学は脱構築・ポストモダンで終焉した、と思っている。「絶対的な価値基準は無い。」「語りえぬものについては沈黙せねばならない。」「世界を記述できる一つの理論は無い。」理論としてはましに見える社会主義が終焉したことも、ある一つの理論により設計・計画されているシステムよりも、自由度が高くゆるやかなシステムの方が、複雑な世界に適応する能力が高い、ということを例証している。

ではなぜ今哲学か。まず、哲学者たちが必死に思索し記述してきた、根源的なものに対する視点と考え方は、思考のフレームワークとして極めて強力であり、それらを理解し内包することができれば、少しは「巨人の肩の上に乗る」ことができるのではないか。また、現在の問題意識は、やはり根幹まで戻らないと解けないような気がしているからである。

インターネットは、対象やステークホルダが複雑に絡み合い、かつ、常に変化しているので、予め「こうあるべき」という姿を定義することはほぼ不可能である。そして、その目的も、いつからかは自己目的化している。そのインターネットのこれからを考える、というのはどういうことなのか。対象が多様で巨大、かつ、自己（主体）と対象（客体）を明確に分けることができないような場合、自己とは一体何か、どのようにモデル化すればよいのだろうか。－これは、これまで哲学が散々やってきたことである。

哲学は終わっているかもしれないが、それでも、社会は廻っているし、インターネットは動いている。これはすごいことで、私はここに希望を持つ。新たなシステム論や科学哲学のようなものを整理し提示することによって、これからの方向性を考える助けにならないかと思っている。勿論、「思考のフレームワーク」なんて虫がよくて、単に底知れない深淵に沈むだけかもしれないが。

　「哲学は終わったが、しかし、遍在している。」(ジャック・デリダ)

評論家はキライ

評論家というのはどうも好きではない。

 

新聞の夕刊にはよく演奏会評が載っていて、ついつい読んでしまうが、辛口批評を見ると、そんなによーくわかっているんだったらご自分で弾いてみたら、と思ってしまう。勿論、評論家が演奏家の賞賛や応援ばかりしている訳にはいかないし、それでは評論の意味が無い。しかし、イマジネーションを具体的な音に射影 し、その「欲しい音」を紡ぎ出すための飽くなき研鑽に比べたら、後からどうこう言うのは簡単でしょう、と思ってしまう。

 

経済評論家もそう。既に起こったことに対し、後知恵で尤もらしい理屈をつけることについて、意味がないとは言わない。しかし、リスク承知で困難なことに挑戦する人々に比べたら、一体どれだけの価値があるのでしょう。それなら、後知恵でなく予測すればよいのか、というと、その予測が的を射ていなければ大勢に影響ないし、もしも的を射ている場合はそのこと自体がシステムの挙動に組み込まれることになるので、どのみち予測にはならない。

 

しかししかし、ふと我が身を振り返ってみると、自分の仕事が何だか評論家っぽくなっていないだろうか。現在実際にコードを書いている訳でもなく、製品を使って実際にサーヴィスを提供している訳ではない。製品開発に間接的に携わっているものの、自分が手を下していないのに批判してしまうようなことがある。自分があんなに嫌っていたことを自分でやっているのではないか?!

 

でも自分の今の適性を考えると、コーダに戻ってもあまり生産性が上がらないだろう。せめて、開発者と話すときは開発者の土俵に立って、サーヴィス提供者と話すときはサーヴィス提供者の立場に立つようにしよう。後知恵ではなく、常に自ら考えて結果を謙虚にフィードバックしよう。常に修行僧の気持ちでいよう。新たな視点を探してみよう。問題を発見して面白がるだけでなく、解決方法を考えよう。

 

ところで、余談だが、実は評論家よりもさらにキライな人種がいる。...それは政治家。

 

抽象化の功罪 - 実装の問題

　何のために抽象化、モデル化するかというと、ごちゃごちゃと複雑な現実を整理し、理解し易く、設計・開発・保守し易く、また再利用しやすくするためである。コンピュータ通信の分野で言うと、レイヤ化がその一例である。

　レイヤ化モデルで代表的なものはOSIの7階層モデルであろう。ここで書くまでもないが、同一ノード間では、あるレイヤnはn+1レイヤおよびn-1レイヤのみとインタラクションし、対向ノードとは同じレイヤ同士のみ(peer)がコミュニケーションする。下位レイヤはカプセル化され、上位レイヤに対して下位レイヤの機能は隠ぺいされる。整然としているが、実際には、今日OSIモデルのサブセットが断片的に使用されているだけで、そのフルスタックの実装が普及したことはなかった。必要以上に機能分化され、必要以上にオーヴァヘッドが大きいためだと思う。

　TCP/IPプロトコルスタックも、一応はレイヤモデルに基づくが、理論後付け的なところがあり、あまり整然とした階層にはなっていない。例えば、IP（ネットワーク層）を補完する機能としてARPやICMPがあるが、ARPはEthernet専用の機能でEthernet Frameを使用する一方、ICMPはIPにカプセル化される、等、図に書いてもきれいなレイヤ構造にならない。（rfc3439では、"Layering Considered Harmful"とさえ言ってる:)）トップダウンで設計されたOSIと、時とともに漸次進化してきたTCP/IPの違いである。

　レイヤによる抽象化は、モジュール化に加えて相対化という側面を持つので、いろいろ面白いことが起こる。ある問題を解決したつもりになっていても、実は、単に新たなレイヤを追加しただけだったり、他のレイヤの問題を増やしただけだったり。“Any problem in computer science can be solved with another layer of indirection.” “But that usually will create another problem.”という箴言もある。（これを言ったのは誰か、というのは、どうも諸説あるらしい。David Wheelerだと思っていたが、WikipediaによるとButler Lampsonと書いてあった。 )

　ところで、IPv6では、OSIモデルのような必要以上の機能分化は行わず、しかしIPv4の時よりは、もう少し整然とした抽象化を行おうとした。まず、ARPやIGMPに相当するIPレイヤを補完する機能(Neighbor DiscoveryやMLD)を、ICMPの拡張メッセージとして統合し、また、ヘッダを階層化した。前者は、「ICMPへの統合によるメディア非依存」、という抽象化であり、後者は、「再帰」による抽象化である。

　これは結構素敵である。IPv4の時よりもすっきり整然とするとともに、OSIよりも実践的だし、実際のプロトコルスタック実装にも適性が高い。

　しかし、しかし。特にハードウェアに近くなればなるほど、やはり実装と抽象化は相容れにくくなる。

　まずメディア非依存。Neighbor Discoveryに関するメカニズムは実際はメディア種別に依存するが、rfc4861(IPv6 Neighbor Discovery)は、メディア非依存であらゆるリンク属性｛point-to-point, multicast, NBMA, shared media}を対象とする。属性によって適用するメカニズムを取捨選択することになるのだが、これは実装に任されるところになる。point-to-point linkではNS/NA(Neighbor Solicitation, Neighbor Advertisement)は行わない。ではDAD(Duplicate Address Detection)はどうか。これもpoint-to-pointでは無くてもよいのではと思うが、rfc4862(IPv6 Stateless Address Configuration)では、特にlink種別の記述はない。また、subnet-router anycast address(interface-id = 0)も、point-to-pointに必要とは思えないが(shared linkであっても使ってないのでは）、rfc4291(IPv6 Addressing Architecture)は、実際のinterface-id生成アルゴリズムについてリンク依存性(EUI64など)を言及しているに留まる。

　そして再帰。Fragment処理に関しては、エンドに委ねたのはよいと思う。ただ、ヘッダ階層化による柔軟性・拡張性は、ついそれを有効利用したくなってしまうというところが悩ましい。Routing Header 0 は廃止されたが、1(Nimrod), 2(MobileIP)は残っており、これからも追加される可能性がある。再帰処理によるオーヴァヘッドやリスクと、得られる効用をよく見極めたい。

　一番悩ましいのは、これらがセキュリティホールになることだ。pingpong問題(*)は、point-to-point linkではNS/NAが行われず、同一サブネット上のアドレスで自身のアドレス以外のものは着信したインタフェースへと送り返す動作に起因する。さらにsubnet長を一律/64にするというガイドラインもあるため、リスクの確率が大きくなる。

(*)
http://atm.tut.fi/list-archive/ipng/msg00163.html
http://www.apnic.net/meetings/26/program/apops/matsuzaki-ipv6-p2p.pdf

　/127が使えればこの問題を防げるが、rfc3627(Use of /127 Prefix Length Between Routers Considered Harmful)にDADやAddressingとの不整合が記述されている。但し、ここに記述されている点は、point-to-point linkには適用外だと思う。下位メディアは、概念としては抽象化されていても、現実の実装の際はl属性を個別に考えた方が良い。

　rfc4443(ICMP for IPv6)には、このpingpong問題を回避するためのソリューションが記述されているが、これもハードウェアフォワーディングにとってはかなりハードルが高い。抽象化のためにパフォーマンスを劣化させるのはあまりぱっとしない。

　Routing Headerのセキュリティリスクについては言うまでもない。itojunさんのことが思い出され、今も胸が痛む。抽象化と実装が背反するような場合があれば、私だったら実装面を優先させるだろう。たぶんitojunさんも賛成してくれるのではないだろうか。

知ってない問題 (3)

「知ってない問題」とは、「知ってる？」の否定応答が、なぜ「知ってない」ではなくて「知らない」になるのでしょう、という問題。依然としてすっきりしないままでいる。

英語(know)やフランス語(savoir)では、このような非対称は無い、と、前のエントリーには書いた。しかし、それら言語では、状態を表す動詞（have, love, liveなど）と、行為(go, play, takeなど）を表す動詞が、同じ一般動詞として存在しているため、「○○ている」というように、状態を表す時に語尾を変化させる日本語とは異なり、同列に比較はできない。「知識を得るだけでは知ったことにはならないのではないか。」というのは、仮説としては悪くないとは思うが、ちょっと無理があるかもしれない。

日本語では、状態を表す時には、「○○ている」になるので、「知っている」状態を否定するのは、普通に考えたら、やはり「知っていない」が自然であろう。実際、言葉を覚え始めたばかりの子供はこう答える。しかし大人は「知らない」と言う。この質問と応答の非対称性は、単なる偶発的なものではなく、やはり「知る」ということが特別であることを示しているのではないか。従って、この点に関しては、前のエントリーでの仮説（↓)はあながち外れていないように思える。

「ｘｘを知っている？」と質問された人は、質問されたという事実により、そのことに関する知識を得てしまった、ということになる。そのため、常識を持った 大人であれば、質問を受けた途端、そのことについて「知っていない」とはパラドクスになり、そうは言えなくなってしまうのではないか。だから、「そのこと は過去も知らなかったし、こんな風に質問されなければ、これからもたぶん知らなかっただろう」という意味をこめて、「知らない」と答えるのではないだろう か。

しかし勿論、根拠にも確信にも欠ける。

......という訳で、悶々としていたところ、養老孟司先生の著作に、やはり「知る」ということの特別さを記述した文章を発見。

「知ることの深層」

知ることとは、どういうことか。（中略）
一般的に、知ることというのは、知識を増やすことと考えられています。しかしもちろんそうではありません。私はよく学生に、自分が癌の告知をされたときのことを考えてみなさいといいます。「あなた癌ですよ」といわれるのも、本人にしてみれば「知る」ことです。「あなた癌ですよ。せいぜいもって半年です」といわれたときにどうか。知るということを考えるとはそういうことです。
あと半年と宣告されて、それを納得した瞬間から、自分が変わります。ですから、知ることというのは、じつは自分が変わることだと私は思うわけです。

　　　　　　　-　「知」の毒　自分は死なないと思っている人へ　大和書房　より

やっぱり。我意を得たり、という気がする。知ることは、単に知識を増やすことではない。知る前と知った後で自分が変わるということもあり得るのだ。勿論、「知ってない」問題への十分な根拠や確信にはなる訳ではないけれども、「知る」ということは、やはり特別で重大なことなのだと思う。

インターネットと、エリザベス キューブラー=ロス "On Death and Dying"

一時期、「生きるって何のため？」、「死とは何？」、ということを考えあぐねていた時があって、死に行く人の闘病記や医師の手記、そしてアルフォンス デーケンやエリザベス キューブラー=ロスの、死生学に関する本を読み漁っていた。中でも、スイスの精神科医キューブラー=ロス著「死ぬ瞬間」は世界的にも著名な書で、200人の余命宣告された患者とのインタヴューによって導かれた死の受容に至る5段階のモデルは、それまで思い至らなかった捉え方であったため非常に印象的だった。（ところで、この書をなぜ「死ぬ瞬間」と訳したのかよくわからない。"瞬間"ではなくて"プロセス"だと思う。なので、タイトルには邦題ではなく原題"On Death and Dying"を載せておく。）

その5段階のモデルとは次のとおり。

[Stage 1: Denial (否認）]
　予期せぬ事態、衝撃を直視できず、「そんな筈はない」と否定する。

[Stage 2: Anger (怒り）]
　なぜ私が？理不尽だ。怒り。不満。

[Stage 3: Bargaining (取引）]
　生活を改めるから生かして欲しい。せめて○○までは生きたい。

[Stage 4: Depression (抑うつ）]
　あきらめ。無気力。落ち込み。

[Stage 5: Acceptence (受容）]
　解脱。穏やかな心境になり、自らの死を受け入れる。

私の方は、そのうち子供が生まれたりして、目前の生を育てる（というよりは活かしておく）のに精一杯になり、この本のことは記憶の底に深く沈んでいた。

...それなのに、最近、なぜか仕事関係で、このキューブラー=ロスの5段階モデルが言及されているのを相次いで発見して、ちょっと面喰っている。

●例その1　- 「製品に脆弱性が発見された時！！」

James Duncanの資料より。

[Stage 1: Denial (否認）]
　「それはセキュリティホールではない。機能仕様だ。」

[Stage 2: Anger (怒り）]
　「一体誰がそんなこと言い出したんだ。いい迷惑だ。」

[Stage 3: Bargaining (取引）]
　「条件を変えれば脆弱性は無いのでは？」

[Stage 4: Depression (抑うつ）]
　あきらめ。無気力。落ち込み。

[Stage 5: Acceptence (受容）]
　解脱。正しい手を打ち、また将来同じことのないように備える。

●例その2　- 「IPｖ6の受容 」

Tony Hainの資料より。

[Stage 1: Denial (否認）]
　「IPv6なんて来ないだろう。」

[Stage 2: Anger (怒り）]
　「ひどい。そんなの聞いてないよ。」

[Stage 3: Bargaining (取引）]
　「せめて自分が引退するまではこのままで...。」「NATがある。」

[Stage 4: Depression (抑うつ）]
　「NATだと、いくつかのアプリケーションが正常に動作しなくなる。仕方ないか...。」

[Stage 5: Acceptence (受容）]
　「IPv6をdeployしよう！」

うーん、何だか笑えるような笑えないような......。しかし、元のコンテクストは「生命体による死の受容」ですよ。こちらはお仕事の話。お仕事の場合、通常であれば、まぁかなり理不尽であっても、かなり困難であっても、それが重要なのであれば、只管やるのである。「仕様追加がどうしても必要だ。でも納期は変えられない。よろしく。」などという事態になった時、ぶーぶー文句を言いながらも、やってきたではないか。

このような事態に、キューブラー=ロスが引用される、ということは何を意味するか。

これらのセキュリティ脆弱性やIPv6移行問題が、「死」に匹敵するような、致命的な困難さを持っている、ということなのだろうか。それとも、システムが多くの要素と有機的に連携し過ぎていて、生命体と同様になっている、ということなのだろうか。いや両方なのだろう。勿論、多少の誇張と冗談が交じっているにせよ、「生命体（のようなもの）に対する死（と同じくらいの困難）」が、最近は起こっている、ということか。