Name: UECプレゼンツ：カオスを脱するウルトライーサネット (Ultra Ethernet Escaping the Chaos of Order presented by UEC)
Uploaded: 2025-11-15T01:18:07.000Z
Duration: 16 min 59 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

はい、皆さん、ようこそいらっしゃいました。

We're getting started a little bit earlier today.

様態の副詞

Let's spend a minute talking about ultra Ethernet and how we're approaching networking differently.

ultra Ethernet について、そして私たちが networking にどのように異なるアプローチを取っているかについて、少しお話ししましょう。

Basically, since the dawn of networking, people have been designing end to end transport protocols that assume the network in the middle is ordered.

基本的に、networking の黎明期から、人々は中間の network が順序付けられていると仮定した end to end transport protocols を設計してきました。

And as soon as they make that assumption, as soon as the ink's dry on the specification, the network engineers say, hey, it'd be a lot easier if we didn't have to maintain order going across the network.

そして、その仮定をした途端に、specification のインクが乾くやいなや、network engineers は、network を横断する order を維持する必要がなければ、もっと簡単なのに、と言うのです。

そして、そのサイクルを何度も繰り返しています。

And so we did a little something different in ultra Ethernet.

そこで、ultra Ethernet では少し違うことをしました。

Okay, so a little bit about the consortium.

さて、consortium について少しお話しします。

We were formed in 2022, announced in 2023, fairly quickly opened up to a broader way of members, and

私たちは2022年に結成され、2023年に発表され、かなり早く幅広いメンバーに開かれました。

All of a sudden we were at 100 companies and we could feel it in the working groups.

あっという間に100社になり、ワーキンググループでもその勢いを感じました。

電話会議への参加者がものすごく増えたんです。

Our mission was not quite as bold as this when we first started.

最初は、ここまで大胆なミッションではありませんでした。

I do not think anybody actually walked into this thinking we were going to a high performance full stack architecture.

高性能フルスタックアーキテクチャを目指すなんて、誰も思っていなかったと思います。

でも、それが今日の私たちです。

If we look at what's going On Inside the UEC, we have created our first specification, release 1.0 in June of this year.

UECの内部を見てみると、今年の6月に最初の仕様、リリース1.0を作成しました。

そこには4つのレイヤーがあります。

There's software working group work, there's results from the transport working group, the link working group, the physical layer working group one specification.

ソフトウェアワーキンググループの作業、トランスポートワーキンググループ、リンクワーキンググループ、物理レイヤーワーキンググループ1の仕様からの結果です。

Now, okay, so when you give these talks on behalf of an organization, you get some boilerplate slides, and

さて、組織を代表してこうした講演をすると、決まったスライドがいくつかあるのですが、

このスライドは修正が必要でした。

The spec is really not that big compared to other existing standards.

仕様は、他の既存の規格と比べると、それほど大きくありません。

So if you open Infiniband, it is a 2000 plus page specification for volume one.

Infinibandを開いてみると、ボリューム1で2000ページ以上の仕様があります。

And we do that because we're built on top of an ecosystem.

そして、エコシステムの上に構築されているため、それができています。

We leverage Ethernet, we leverage ip, we leverage the switch ecosystems and the software ecosystems that are built around that.

Ethernet、ip、そしてその周りに構築されたスイッチエコシステムやソフトウェアエコシステムを活用しています。

So the thousands of pages that make up 802.3, the thousands of pages that make up 802.1, the thousands of RFCs that are out there from ITF, we build on top of that legacy and leverage that infrastructure.

つまり、802.3を構成する何千ページ、802.1を構成する何千ページ、IETFから出ている何千ものRFCの上に構築し、そのレガシーとインフラストラクチャを活用しています。

So a little bit on why we exist, you know, RDMA is.

では、なぜ私たちが存在するのかについて少しお話ししますと、RDMAは。

Well, RDMA as we know it in verbs today is 25 years old now.

さて、私たちが今日知っているRDMAは、動詞としては25年前のものです。

Remote memory access has been around a lot longer than that.

リモートメモリアクセスは、それよりもずっと前から存在しています。

HPC has had remote memory access concepts baked into it for basically as long as there's been HPC networking.

HPCには、HPCネットワーキングが存在する限り、リモートメモリアクセスの概念が組み込まれていました。

There's a lot of performance to be achieved by Doing kernel bypass, networking hardware implementations of the whole protocol stack really low overhead things in the host.

カーネルバイパス、プロトコルスタック全体のネットワーキングハードウェア実装、ホストでの非常にオーバーヘッドの低い処理を行うことで、達成できるパフォーマンスはたくさんあります。

Rocky B2 is the RDMA over IP version of that story.

Rocky B2は、そのストーリーのRDMA over IPバージョンです。

It was based on the InfiniBand specification which was standardized in 2000.

2000年に標準化されたInfiniBandの仕様に基づいています。

And it has all the hallmarks of a network transport that was designed before the turn of the century.

そして、世紀の変わり目より前に設計されたネットワークトランスポートのすべての特徴を備えています。

そのため、順序を戻す必要があります。

It does not have really a multi pathing definition.

マルチパスの定義はあまりありません。

It doesn't include an integrated security Solution.

統合されたセキュリティソリューションは含まれていません。

Back in 2000, nobody cared about security in high performance networks.

2000年当時、ハイパフォーマンスネットワークでセキュリティを気にする人はいませんでした。

This was all designed in an era when transistors were precious.

これはトランジスタが貴重だった時代に設計されたものです。

And so you wanted to keep everything simple and it made sense at the time.

そのため、すべてをシンプルに保ちたかったのです。当時はそれが理にかなっていました。

But as RDMA has aged, the industry had started to diverge in its solution space.

しかし、RDMAが古くなるにつれて、業界はソリューション空間で分岐し始めました。

So kind of the earliest thing you saw published in that domain was AWS with their SRD protocol spraying packets all over the network.

その分野で最初に公開されたのは、AWSがSRDプロトコルでネットワーク全体にパケットを散布したことです。

Google recently announced their Falcon protocol.

Googleは最近、Falconプロトコルを発表しました。

Those are not the only people who are building customized versions of rdma.

RDMAのカスタマイズ版を構築しているのは、彼らだけではありません。

And so it was time for new industry standard.

そのため、新しい業界標準が必要な時期でした。

And everybody wants that standard to look and feel and interoperate like Ethernet.

そして誰もが、その標準がEthernetのように見え、感じられ、相互運用されることを望んでいます。

So the problem with ordering is that it makes a real mess in the network.

順序付けの問題は、ネットワークで大きな混乱を引き起こすということです。

So ordering means that you really can't see, can't tell the difference between real congestion and false congestion places where flows happen to collide because it's not really easy to move those flows.

ですから、順序付けということは、本当の輻輳と、フローがたまたま衝突する偽の輻輳場所との区別がつかないということです。なぜなら、それらのフローを移動させるのは実際には簡単ではないからです。

A flow takes one path through the network.

フローはネットワークを1つのパスで通過します。

If it happens to hit somebody else, well, even if you did load balancing at the start, you're just kind of out of luck.

もしそれが他の誰かとぶつかった場合、たとえ最初にロードバランシングをしていたとしても、運が悪かったということになります。

So we can take a look at some examples here.

そこで、いくつか例を見てみましょう。

If you noticed, I built my example factory here with seven port switches so that I can have a four to three taper.

もし気づいたなら、私は7ポートスイッチで例のファクトリーを構築しました。それによって4対3のテーパーを作ることができます。

ですから、この例を挙げることができます。

So in the bandwidth taper case, everybody on one switch talks to everybody on the next switch that goes over three paths.

帯域幅のテーパーの場合、あるスイッチ上のすべてのものが、3つのパスを越えていく次のスイッチ上のすべてのものと通信します。

For four flows, two of those flows are going to take the same path.

4つのフローの場合、そのうち2つのフローは同じパスを取ることになります。

And so your application's going to run half as fast because two of those flows took the same path.

そして、その2つのフローが同じパスを取ったため、アプリケーションの実行速度は半分になります。

And so they're effectively running half as fast.

そして、それらは実質的に半分の速度で実行されます。

You can't tell the difference between NCAST and a bandwidth taper in this ordered network, that one is really going to run slower.

この順序付けられたネットワークでは、NCASTと帯域幅テーパーの違いが分かりません。そのため、実際には遅くなります。

他にできることはありません。

You got false contention, you got two flows that just happen to pick the same uplink at the top of the network and now they're stuck because they're ordered flows.

偽の競合が発生し、2つのフローがネットワークの最上部で同じアップリンクを選択してしまい、順序付けられたフローであるため立ち往生しています。

And the reality is that people will tell you that you can stop and move flow and sure you can, but

そして、フローを停止して移動できると人々は言うでしょうが、確かにできますが、

most of the flows, our notes so long that it's going to be a good idea to start a flow, realize there's contention, stop the flow, start the flow somewhere else and hope you didn't hit somebody else.

ほとんどのフローは非常に長いため、フローを開始し、競合があることに気づき、フローを停止し、別の場所でフローを開始し、誰かにぶつからなかったことを願うのが良いでしょう。

どうしてこうなったのでしょうか？

So kind of, why did we go and take a full stack approach to this problem?

では、なぜこの問題に対してフルスタックアプローチを取ったのでしょうか？

Well, when you have a hammer, everything looks like a nail.

ハンマーを持っていると、すべてが釘のように見えます。

So when you give an architect a connection, they're going to use it.

したがって、アーキテクトに接続を与えると、それを使用するでしょう。

They're going to use it and they're going to tangle it up with the semantics that are over top of it.

それらはそれを使用し、その上に重なるセマンティクスと絡み合わせるでしょう。

They're going to tangle it up with how you pick a buffer, they're going to tangle it up with how you manage resource exhaustion.

バッファの選択方法やリソース枯渇の管理方法と絡み合わせるでしょう。

There's no reason not to put the connection into an error state.

接続をエラー状態にしない理由はありません。

You've got one process connected to another process and it incurs some error, you might as well put the whole connection into an error state.

あるプロセスが別のプロセスに接続していて、何らかのエラーが発生した場合、接続全体をエラー状態にするのが良いでしょう。

You might as well couple the security to that connection state, because while you've got the connection there, you might as well use it.

接続状態にセキュリティを結合するのも良いでしょう。接続がある間は、それを利用する方が良いですから。

Then when you make that connection ordered, well, then you'll get people who do clever things.

そして、その接続を順序付けすると、人々は巧妙なことをするようになるでしょう。

I mean, you're going to use that ordering for liability.

つまり、その順序付けを責任のために使用するということです。

それが最も簡単なことだからです。

And then somebody's going to say, well, I don't really need this entire header on every packet and I can get 1% more efficiency by putting a different header on my first packet than my second packet and my third packet.

そして誰かが、「すべてのパケットにこのヘッダー全体は必要ない。最初のパケットと2番目、3番目のパケットで異なるヘッダーを使用すれば、1%効率が向上する」と言うでしょう。

そして、彼らはそれを実行するでしょう。

And your resource management will depend on that ordering.

そして、リソース管理は、その順序付けに依存することになります。

And the ordering will be part of your error model.

そして、その順序付けは、エラーモデルの一部となります。

And you'll say, well, this packet encountered an error, so every packet after it will encounter that error until somebody comes along and cleans up.

そして、「このパケットでエラーが発生したので、誰かがそれを修正するまで、その後のすべてのパケットで同じエラーが発生するだろう」と言うでしょう。

And this is the state of the world in the the Rocky V2 specification.

そして、これがRocky V2 specificationの状態です。

And by the time you realize what's happened and you've made that visible to software and given it software to manage, well, you've dug yourself in a hole that's kind of hard to get out of.

そして、何が起こったかを理解し、それをソフトウェアに可視化して管理するソフトウェアを与えた頃には、抜け出すのが難しい穴を掘ってしまったことになります。

では、どのようにアプローチを変えるのでしょうか？

Well, the most important thing is we did not change the application, we didn't change the frameworks we use, we didn't change the middleware libraries that you use, we didn't change Ethernet and ip.

最も重要なのは、アプリケーションを変更せず、使用するフレームワークを変更せず、使用するミドルウェアライブラリを変更せず、Ethernetとipを変更しないことです。

This will run over the data center network as it exists today.

これは、今日のデータセンターネットワーク上で実行されます。

It will use the same software stacks that exist today.

これは、今日のソフトウェアスタックと同じものを使用します。

But from there it kind of goes like the fable of stone soup.

でもそこから、まるで石のスープの寓話のようになっていくんです。

So these two Hungry travelers show up in a village, nobody will give them something to eat.

それで、お腹を空かせた旅人が二人、村にやってきたのですが、誰も何も食べさせてくれません。

So they take a pot or a JDF and they put a stone in it and some water or ethernet and IP and, and

そこで彼らは鍋、あるいはJDFのようなものを取り出し、石と水、あるいはEthernetとIPを入れて、

they start to boil it and people say, what are you doing?

それを煮込み始めると、人々は「何をしているんだ？」と言います。

彼らは「石のスープを作っているんだ」と答えます。

So the story progresses on until they managed to actually make a soup that everybody would like to eat.

そして物語は、みんなが食べたいと思うようなスープを実際に作れるようになるまで進んでいきます。

そして、それが私たちがここでやったことのようなものです。

We took LibFabric, which is an open source API.

私たちはオープンソースAPIであるLibFabricを使いました。

これはコネクションレスになるように設計されています。

字幕リスト動画再生

UECプレゼンツ：カオスを脱するウルトライーサネット (Ultra Ethernet Escaping the Chaos of Order presented by UEC)

process

access

impact

achieve