Live data from Hacker News

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

cloud.google.com

51–60 of 158 posts

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

#51
post #5

Earlier quoted context omitted.

> 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.

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

#52

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?

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

#55

Earlier quoted context omitted.

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.

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

#56
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…

You would need to structure mac addresses in such a way that they can be easily grouped for routing a-la IP subnets.

It just isn’t suitable for this.

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

#57
post #34

Earlier quoted context omitted.

It’s not from there? HTTP/3 is QUIC, right?

Oh you are right, QUIC is from there. I misremembered it.

And QUIC/HTTP3 was invented by Google to deliver more ads, faster. Yay.

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

#58

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…

Not first, but eventually the layers are needed to solve problems that evolve when your software needs to operate in someone else's network.

That said, it's not very hard to directly talk "ethernet" using raw sockets. Here's an example if you're interested: https://gist.github.com/austinmarton/1922600.

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

#59
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…

You can't route MAC because there is no prefix matching - only exact matching. That's exactly why you need to "switch" them... and incidentally this is what your proposal accomplishes – it's equivalent to a fully-switched network. Switches (especially L3 switches) maintain port-MAC association tables to switch packets between ports and they're available off the shelf.

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

#60
post #7
post #3

Earlier quoted context omitted.

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

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.
Post reply on HN