Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cloud.google.com

Post reply on HN
Print view View original

131–140 of 158 posts

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

#131

Post by windexh8er »

sa46 wrote: post #89
otabdeveloper4 wrote: post #82

Earlier quoted context omitted.

> let me open my big yellow pages of globally unique MAC addresses Yeah, well, you've basically described IPv6.

How do networks manage the larger number of IPv6 addresses? My cursory digging indicates that the secret sauce is to grant large IPv6 prefixes and delegate routing to the prefix. An informative-looking Reddit comment says there are 100k IPv6 prefixes (as of Oct. 2020), and each active route takes 1 KiB. [1] So, IPv6 differs significantly from MAC addresses because you only need to track prefixes. [1]: https://old.red…

Prefixes are routed. ARP, in IPv6, is replaced by a function of Neighbor Discovery Protocol (NDP) called Neighbor Advertisment (NA) and Neighbor Solicitation (NS) where L2 MAC is sent in it's messaging. The NS messaging leverages multicast to communicate with the broader set of hosts for discovery. Basically it sends a message to the multicast address containing the IPv6 address such that it can discover it's MAC. So the flooding/broadcasting for MAC of v4 is replaced by a much more efficient L3 to L2 lookup in v6.

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

#132

Post by em-bee »

sirtaj wrote: post #99
em-bee wrote: post #87

Earlier quoted context omitted.

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.

well, it's merging MAC and IP into one address. there is no need for two if the MAC address can be assigned dynamically. and it's extending the auto-discovery of the address to work over larger networks. so it's not reinventing but simplifying things. (or not, i am not familiar enough with the details to be aware of other problems that could complicate things again)

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

#133

Post by tenebrisalietum »

MiddleMan5 wrote: post #49
genmud wrote: 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…

MAC is just one way to identify ("address") directly connected/visible nodes on a network. Not all L2 technologies use MAC addresses.

- "Directly connected/visibile" means node X can contact node Y simply by throwing something on the medium (wire, radio, etc.) and doesn't have to knowingly send to a middleman (router).

When Ethernet was invented in the early 80's there were a lot more L2 technologies. Most are uncommon now (Frame Link DLCIs I think fall in this category, and PPP/dialup was common at one time - no MACs there) except for one: I don't think the cellular network uses MAC addresses at all. I could be wrong with newer 4G/5G stuff which overlaps with Wi-Fi in various places.

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

#135

Post by Grazester »

bluGill wrote: post #134

Google has lost trust with so many of the things they have released in the past becoming unsupported and obsolete.

If this is an open standard then anyone who uses it and wishes to support it can do so no, or am I mistaken?

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

#136

Post by pkhuong »

MichaelMoser123 wrote: post #103
mintplant wrote: post #17

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…

There are systems like this: Fibre Channel has it's own data link layer, actually they do reliability at the data link layer! I think InfiniBand is similar to this respect. Actually it's interesting that google didn't choose any of these, for their high bandwidth storage needs. They have the money to do their own thing, but why should they?

Google migrated away from IB years ago. IIUC, the failure modes at the time (e.g., fully locked up fabric) were too painful at the time, and they preferred to work with a mostly vanilla Linux kernel for userspace networking.

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

#137

Post by DanielHB »

mintplant wrote: post #17

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…

take a look at CBOR if you want a little more power in your payloads. It is basically binary space-efficient JSON

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

#138

Post by sargun »

DrReachAround wrote: post #23

I'm confused by this because we've been using Falcon at work for over a year now, perhaps longer, as I just started a year ago. What are they making available that wasn't already?

What were you using Falcon in, and for what?

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

#139

Post by Zandikar »

kortilla wrote: post #78
Dylan16807 wrote: post #37

Earlier quoted context omitted.

1. In a single data center scale computing system, though? 2. Use some bytes outside of the header? 3. I get the impression this needs hardware to really use well anyway.

2. Don’t do this. It causes reordering between flows and software doesn’t like out of order packets.

I get the impression that if this comment chain continues we're just gonna reinvent UDP

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

#140

Post by tuetuopay »

Dylan16807 wrote: post #37
wmf wrote: post #33

Earlier quoted context omitted.

1. Your forwarding table would have to be larger because Ethernet uses exact match instead of longest prefix match. For example, you might be limited to 128K servers total while Google has millions. 2. The Ethernet header has less entropy for ECMP than a UDP/IP header. Maybe you could add entropy somewhere but ASICs may not support it. 3. You're breaking compatibility with... everything. Maybe Google could afford thi…

1. In a single data center scale computing system, though? 2. Use some bytes outside of the header? 3. I get the impression this needs hardware to really use well anyway.

1. Especially in the datacenter. When you add VMs to the mix you get LOADS of devices to address. Add on top that a single device has multiple connections (management, internet, storage, etc), you'd run out of capacity almost instantly.

2. The point is to find some bytes that are constant for a given logical stream of related packets. Taking bytes outside of the header means taking bytes from the payload, that is by definition not deterministic. That's why everything identifies flows using the IPs + ports + protocol.

Post reply on HN