Live data from Hacker News

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

cloud.google.com

111–120 of 158 posts

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

#111

Earlier quoted context omitted.

Are you suggesting that it would have been better for Google to use off-the-shelf databases etc? Because at their scale it seems clearly necessary to bring that in-house.

At Google's scale a lot of the ordinary limitations do not apply. Unfortunately many companies believe that because Google does it it must be good. It's cargo cult reasoning and the result is endless NIH projects. As for Google's 'Falcon' project: it smacks of NIH to me, but maybe their use cases are specific enough that none of the off-the-shelf bits were usable.

Which part of falcon, specifically, do you think duplicates off-the-shelf software that accomplishes the same things? Swift? Carousel? PLB?

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

#112

Earlier quoted context omitted.

0C:F9:31:D2:DB:51 AB:33:C6:C6:19:74 I used a MAC address generator to get those two, but I think two is enough to make the discussion. Current reality aside, would you be able to identify those with binary math as being on the same network device, different network devices, across the world? MAC addresses on physical NICs are provided by the manufacturer, sure you can adjust them but I think that leaves the good-fait…

So it seems like the primary use of IP, as you describe, is to define a way to narrow the search to sub address groups so as to not require enumerating every address in the scheme. Still, there's doesn't seem to be any reason you couldn't just say "device 1 gets MAC 00:00:00:00:00:01" and "device 2 gets 00:00:00:00:00:02" and the gateway controller gets :::00 and there's a special address on :::FF that can be used to…

You could. Assuming all your equipment supports setting the MAC, and you make sure to operate on prefixes so you can route by prefix. There's nothing stopping you from doing so.

The reason we don't is because at the time IP was introduced, there were many alternative physical layers in active use. And while Ethernet is near ubiquitous now, what we learnt from that was that it is unreasonable to assume that all your data will go over the same physical layer. And so you need a standard addressing format that will work elsewhere too.

Nothing stops you from stripping it back locally and using MAC addresses for everything internal to you, and ditching IP, and "just" gateway to/from IP. Lots of people did gateway between different protocols before IP became the dominant choice.

But you won't get everyone else to change because it'd require new firewall and new routers, and all kinds of software rewrites, and you can see how long the IPv6 transition has taken, so you'd still need to wrap and unwrap TCP/IP and find a way to address IP for everything that isn't 100% local, and even for lots of local-only stuff unless you want to rewrite everything.

There would be potential ways. E.g. you could certainly use a few bits to say "this is external" and then have some convention to pack an IPv4 address into the MAC or let an IPv6 address overflow into the data, and use that to make gatewaying and routing to external networks easier, while everything else just relies on the MAC. But you'd still need a protocol header for other things too, and then the question is how much benefit you would gain from ditching pretty much just ARP, which isn't exactly complex, a lookup table, and replacing the IPs in the header with just a destination MAC. Because the rest of the complexity is still there.

And you can gain most of the benefit of that by getting an IPv6 EUI64 address [1]. They'll work with "normal" IP equipment, and you can optimize in your own software by having the IP stack ditch ARP lookups when they see a local EUI64 address. Whether that optimisation actually makes a difference is another question.

[1] https://community.cisco.com/t5/networking-knowledge-base/und...

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

#113

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…

If you're flexible enough to forgo UDP/IP, why not use infiniband instead of ethernet? That gets rid of all the complexity you mentioned but still gives you ordered streams

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

#114

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…

We used to have something like that and didn’t like it https://networkencyclopedia.com/netbios/

The fact that there used to be a lot of alternative lower level network layers is incidentally also the best argument for IP: We needed a common shared layer because it was shit trying to gateway between multiple different protocols that user-level software had to know about. And as much as ethernet is dominant now, it's still not the only thing.

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

#115

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…

When I read the title I thought this is going to be an ethernet competitor similar to Infiniband.

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

#116

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…

You're my man, I'm thinking about the same! E.g. Look at TIPC.

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

#117

Earlier quoted context omitted.

At Google's scale a lot of the ordinary limitations do not apply. Unfortunately many companies believe that because Google does it it must be good. It's cargo cult reasoning and the result is endless NIH projects. As for Google's 'Falcon' project: it smacks of NIH to me, but maybe their use cases are specific enough that none of the off-the-shelf bits were usable.

Which part of falcon, specifically, do you think duplicates off-the-shelf software that accomplishes the same things? Swift? Carousel? PLB?

I think you are reading something into my comment that I did not actually write.

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

#118

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…

>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 Internet. Not that I see any advantages to the approach but it's almost workable(?), if a little silly, at internet scale: If every device had a 64byte ID, guesstimating 10billion people * 100 devices/head gets us a 'measly' 64TB of stora…

Nice maths. Would each router then hold 64TB and doing a lookup per request in that volume of data would be slow

Question: how does dns lookup differ from MAC lookup. Why is domain name lookup feasible, but not MAC?

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

#119

Earlier quoted context omitted.

At Google's scale a lot of the ordinary limitations do not apply. Unfortunately many companies believe that because Google does it it must be good. It's cargo cult reasoning and the result is endless NIH projects. As for Google's 'Falcon' project: it smacks of NIH to me, but maybe their use cases are specific enough that none of the off-the-shelf bits were usable.

Which part of falcon, specifically, do you think duplicates off-the-shelf software that accomplishes the same things? Swift? Carousel? PLB?

There seems to be quite a lot of overlap between Falcon and what the Ultra Ethernet Consortium is ostensibly working on. As well as Amazon's Scalable Reliable Datagram (SRD) thing. All of them, in a way, are about addressing deficiencies in RoCEv2 for large scale latency sensitive networking that you see in HPC and DL training.

But none of these are things you can buy today. Well, there's InfiniBand, but if you're wed to Ethernet..

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

#120

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…

[deleted]
Post reply on HN