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.
Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem
51–60 of 158 posts
Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem
#52I 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…
Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem
#53Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem
#54Can anyone explain the difference between Falcon and RoCE v2?
Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem
#55Earlier 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.
Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem
#56Earlier 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…
It just isn’t suitable for this.
Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem
#57Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem
#58Oh, 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…
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
#59Earlier 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…
Re: Google opens Falcon, a reliable low-latency hardware transport, to the ecosystem
#60Earlier 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.