GigaBit Ethernet も少しは前向きに

僕はGigaBit Ethernet が余り好きではない。その保守性の強さに疑問を感じているのだ。（『GigaBit Ethernet : 後ろ向きの先端技術』）

GigaBit Ethernetをひとことで言うと、論理フォーマットを Ethernet と同じまま、物理層で100 倍の基準速度を達成した技術だ。つまり論理的なつくりを変えない。
そのせいで決めた最小パケット 512 バイトというのは、ネットワークのバンド幅を相当に無駄づかいすることになるだろう。
たとえばインターネットのTCPトラフィックの中で、Ethernet の最小長パケットが占めるビット量は全体の 7% に及ぶことが実測でわかっている。ATMのビット無駄づかいを嘆く前に Etherne と TCP の無駄を気にしなければいけないという情勢なのに、最小パケット長が 512 バイトとは。いったい無駄は何 % になるのだろう。
この無駄は複数のショートフレームをまとめて送ることで解決すると言う話を GigaBit Ethernet の開発コミュニティから聞くが、やれるものならやって見せて欲しい。ちょっと話を聞いただけでは信じられない。

そして最大パケット長(MTU)も Ethernet の互換性のためにいじらないのだ。
そのせいで決めた 1.5Kバイトの MTU は、今度は CPU を無駄づかいするだろう。Ethernet はその物理仕様も、論理構造も、当時のコンピュータの能力をうまく活かしたバランスのとれた設計だった。FDDIはたとえば MTU を 4.5K バイトに伸ばすなどしてバランスをとり直している。しかし GigaBit Ethernet は何もしない。MTUが伸びたらもっと効率が良くなるのに。今のままでは短かすぎる。

しかし、先日 Arteon 社の日本支社長、杉本さんからいい話を聞いた。GigaBit Ethernet のために MTU を伸ばし、6K バイトのロングパケットを使えるようにしようというのだ。これは理にかなっている。特に GigaBit Ethernet が主としてやりたがっている Point to Point の全二重接続においては、接続の当事者だけがロングパケットに対応していれば最低限機能するというのも良い。
彼らが実際にベンチマークに掛けてみた結果、ロングパケットを使うとネットワーク利用効率が上がったのにCPU利用率が下がったという。このことで僕は少し GigaBit Ethernet を見直した。

ただし最小パケット長が 512 バイトなのはやはり気になる。CPU やデバイスにとって 1GHz の 64 バイト (512bits/1Gbps= 0.5x10^6 sec) は短時間過ぎるのかもしれないが、やはりこれは実際の利用シーンで使えるデータ転送レートが上がらない原因となるに違いない。

ところで今後は Ack パケットなどを返すことによる無駄を抑えることを考え始めなければならないだろう。その理由はネットワークのバンド幅の拡大にともなって、今度は遅延が無視できなくなってくるからだ。光の速度が早くならないのだから、地球の裏側までのパケット到着遅延はネットがどんなに太くなっても変わらない。（LFP, long Fat Pipe 問題と呼ばれる。これについてはまた別に書く。『ネットは速くならない、太るだけ』（仮題）としておこう。）
そのために、アプリケーションはパケットの交換を極力少なくして通信するように求められるだろう。はたして偶然か、GigaBit Ethernet の全く小さくないショートパケット問題は、このアプリケーション（とプロトコル）の変化が解決するかも知れない。

Yutaka Yasuda

1998.12.13