Live data from Hacker News

Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem

cloud.google.com

91–100 of 158 posts

Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem

#91

Is it just me getting older / less smart, or did articles about products really start to sound like a jumbled mess or buzzwords lately? What is "Hardware transport", what is "the ecosystem"? And then there is dozens of random products and technologies that I've never heard of... This sounds more like a humble brag, than an article trying to inform people about technologies that might actually be useful to them.

This is how you get promoted at Google.

Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem

#92

I guarantee that there will eventually be a vaguely similar (but different!) stack published by each of: NetFlix, Microsoft, Amazon, and Apple. Just kidding, Apple won't publish anything. The IT ecosystem has fragmented into mutually incompatible cliques. You are either in the Google ecosystem, the Amazon ecosystem, or some other one, but there are no more truly open and industry-wide standards. Look at WebAuthN: it…

Not sure why Netflix would be in your list. AFAIK, they run their cloudy stuff on AWS, which isn't too unusual; chaos monkey is neat though? Their CDN boxes are exotic because they run a lot of sessions at relatively pedestrian bandwidths and a lot times 5-20Mbps adds up to a huge number. There's real work there and it's impressive, but it doesn't need exotic network protocols. Bulk encryption offloading NICs are super handy for their use case, which is certainly somewhat exotic.

They haven't said much lately about sending content updates to their CDN nodes, but I think the throughput requirements on that isn't as high.

Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem

#93
post #55

Earlier quoted context omitted.

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…

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.

Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem

#95

Is it just me getting older / less smart, or did articles about products really start to sound like a jumbled mess or buzzwords lately? What is "Hardware transport", what is "the ecosystem"? And then there is dozens of random products and technologies that I've never heard of... This sounds more like a humble brag, than an article trying to inform people about technologies that might actually be useful to them.

"Hardware transport" is kind of a misnomer, because this is a networking protocol. It just happens to be a networking protocol that requires hardware acceleration on the NIC. We already had that in things like Infiniband and Omnipath, but Nvidia bought one and Intel rugpulled the other. Meanwhile ethernet has been approaching parity in terms of throughput, but TCP introduces unpleasant latency, so this is Google's NIH-flavored DIY on the topic. It's something of a rite of passage for a company to convince itself that building this sort of thing in-house is necessary, and that it will revolutionize high-performance computing in all the ways that previous, nearly-identical projects have not.

"The ecosystem" is The Open Compute Project [1], a trade association which mostly puts together quasi-standards that provide targets so computer manufacturers can produce bleeding-edge gear with some hope that it will be interoperable. An example OCP production is the newer 21" racks that are starting to appear in datacenters.

1 - https://www.opencompute.org/

Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem

#96

I guarantee that there will eventually be a vaguely similar (but different!) stack published by each of: NetFlix, Microsoft, Amazon, and Apple. Just kidding, Apple won't publish anything. The IT ecosystem has fragmented into mutually incompatible cliques. You are either in the Google ecosystem, the Amazon ecosystem, or some other one, but there are no more truly open and industry-wide standards. Look at WebAuthN: it…

This criticism is a little weird. This is an internal protocol in Google’s datacenters. Why should it have to be compatible with anything?

Because the whole point of the linked article is that they're making it part of the Open Compute Project, whose entire existence is devoted to making sure things are compatible with other things.

Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem

#97

Oh, I was hoping this would be something built more directly over Ethernet, rather than on top of UDP/IP (if I'm understanding the layer diagram correctly). I've been working with Ethernet devices a lot lately, using the network as a communication bus, essentially. I find that there's a lot of complexity that we simply don't need: ARP, DHCP, DNS... So many points of failure. We know all the devices on our LAN and the…

It's been done. There's XNS, and there's QNX networking over raw Ethernet. Both worked well. Look them up. You probably don't want to go that route, but it is technically possible on a LAN.

Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem

#98
post #46

Earlier quoted context omitted.

But you can't route MACs... you can't associate domain names to MACs... Maybe for a LAN that's fine, but for connecting devices between broadcast domains, it just doesn't cut it.

Why though? You can't route MAC because... ? Because ipv4 provides a higher entropy address? Because MAC is self-assigned and reduplication would require a higher level system? or just because we just don't use MAC addresses that way? I'm certain there are reasons IP came to live alongside/on top of MAC, but saying you can't do multi-hop routing with it just isn't true. If all the technologies of the Internet were re…

> I'm certain there are reasons IP came to live alongside/on top of MAC

There were different teams/universities working on what today we would call LAN and WAN. I forget the details and history (I'm sure someone here, who was involved, could chime in, hah) and might have this wrong, but the result is LAN networking is MAC based while WAN networking is IP based.

It's one of those accidents of history that things are just the way they are and many don't question it. I run into it a lot describing basic networking concepts or early cisco material when people ask _why_ both MACs and IP addresses exist and its just... not always the correct time to explain those details to them.

Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem

#99
post #87

Earlier quoted context omitted.

IP addresses have structure because a single ISP buys a contiguous block, like 123.234.*.*. A simple routing table sends that whole block to a single network port. The table required for the whole Internet is large, but not gigabytes. You can't route by MAC-address because it's effectively random. You'd have to store the port number for every device separately. This works fine at LAN scale, but not for the whole Inte…

MAC addresses being random is a historical accident (because of hardware limitations). today we can define them in software. and just like we have link-local addresses we could self-assign link-local MAC addresses. and i think the self assigning protocol in link-local could even go a step further. instead of hard coding a subnet, it could detect the subnet by copying the one from its nearest neighbor. so start with a…

This sounds suspiciously close to re-inventing ARP and IP.

Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem

#100
To this day I still haven't seen a more sensible API for low-latency Ethernet than Exablaze (was the market leader in low-latency trading, then got bought by Cisco).

The only thing blocking these from becoming standard is that it means userland has direct control of hardware.

Post reply on HN