Hacker News Reader

Comment by KingLancelot | Hacker News Reader

Replace “The Ecosystem” with “The Jungle”.

Edit: It’s yet another meta protocol built on top of TCP/UDP.

I want to see more layer 4 protocols, not stuff built on top of them, personally. That's where things get interesting.

Honestly I think there’s a lack of talent for that, not only to develop the protocol, but to support it. How many of us really understand OSI?

OSI is just a model, there’s not all that much to understand there. It’s simply a way to categorize network technologies using a common language.

OSI is an entire networking stack designed by committee that died from disuse [1]. The only thing we now remember of it are the functional layers within the protocol.

For example, people sometimes refer to TCP as a "Layer 4" protocol even though (a) TCP predates the invention of Layer 4 and (b) TCP is a square peg that does not exactly fit into the round hole that is Layer 4.

[1] https://en.wikipedia.org/wiki/OSI_model

I wish we could forget the other remnants of OSI like x.509, ASN.1, and LDAP. Those were the things good enough to be used for real systems, and I'd still rather crawl over broken glass than implement any of them.

Imagine how bad the rest of it was.

There's no interesting distinction between a "native" transport protocol and a transport protocol running on top of a UDP shim. The UDP header is probably necessary for ECMP.

? Maybe i'm misunderstanding what your trying to say, but there are major differences between an ethernet + IP transport and other transports like fiber channel (or even token ring, atm, etc) which has built into the lowest layers buffer crediting / flow control, retransmission, prioritization, etc. Sure you can build much of that higher in the stack but it requires everything in the network to be playing the same game to assure QoS metrics, and if that's the case you don't really have a normal IP network anymore.

By transport protocol I mean layer 4. FC/TR/ATM/IB are (mostly) layer 2 protocols.

I think the idea is that Falcon assumes the underlying network is semi-crappy and works around that (e.g. Falcon assumes that packets arrive out of order then it puts them back in order).

> Edit: It’s yet another meta protocol built on top of TCP/UDP.

What are you basing that on? Nothing in the article implies that as far as I can see.

The diagram in the article shows it layered over UDP.

The diagram shows it layered on top of RDMA and NVM Express, and supporting UDP and IP. Unless you think the reverse makes sense. The diagram is just upside down.

It's not upside down. RDMA and NVMe run on top of Falcon which runs on top of UDP.

RDMA is a low-level physical transport. You are saying that they are going to emulate RDMA on top of Falcon. Are they going to run Ethernet and then IP on top of that?

The diagram is confusing since it upside down to layering direction, but the article is clear. Falcon is a hardware transport protocol, replacing Ethernet. Like Ethernet, it runs on top of physical transport like RDMA. And IP runs on top of Falcon and Ethernet.

RDMA is a low-level physical transport.

It's not. For example, RDMA can run on top of TCP (iWarp). NVMe can also run on TCP. Now replace TCP with Falcon.

RDMA stands for Remote Direct Memory Access. The version that runs on ethernet is known as RDMA over Converged Ethernet, or RoCE. Until recently, the most common hardware interconnect used to support RDMA was Infiniband. Omnipath existed for a while.

The point is: RDMA is just a term for a computer reading memory on another computer without involving the operating system. The interconnect hardware and physical transport must support RDMA but that doesn't mean it is RDMA, as there are several different implementations of RDMA, and each kind of hardware supports a different subset of those implementations.

Reply on news.ycombinator.com