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

31–40 of 158 posts

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

#31

Post by smokefoot »

wmf wrote: post #25
smokefoot wrote: post #22

I don’t understand networking all that well. Is it interesting that the telcos and non-tech companies are moving away from specialized hardware toward software defined networks while the hyperscalers are using hardware acceleration?

"Software defined networks" doesn't mean anything. If you want to understand networking you have to strike it from your vocabulary. It's possible for different vendors to be on different points on the wheel of reincarnation at the same time. https://www.computerhope.com/jargon/w/wor.htm

Ha, I get it. That is a helpful model.

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

#32

Post by tgma »

bhawks wrote: post #26
tgma wrote: post #15

Earlier quoted context omitted.

This is exaggerated to the point that I consider it fiction. BTW Google doesn't substantially use gRPC within their datacenters. The industry has always been this way. Back in the day there were many many processor ISAs that are now consolidated. There was been many networking standards that consolidated (IPX/SPX anyone?) New things often diverge because of new requirements not out of spite. There is a push and pull…

> This is exaggerated to the point that I consider it fiction. BTW Google doesn't substantially use gRPC within their datacenters. For explicitness Google uses stubby which shares a lot of interface level commonality with gRPC but there's differences at a runtime level. Nobody is slinging json or soap around Google data centers.

And gRPC is basically HTTP/2. Difficult to get more standards-friendly than that.

I suppose when some people advocate for "standards" they just mean the shitty systems prevalent in the industry they happen to have been used to.

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

#33

Post by wmf »

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…

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 this but no one else could.

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

#34

Post by petters »

marcosdumay wrote: post #21
jiggawatts wrote: post #12

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…

> Another random example is HTTP/3, which is basically the "What's best for Google" protocol. HTTP/2 is that. The version 3 is... quite great, and not really originary from there. And gRPC is some self-contained thing that doesn't bother anybody. I do really agree with your point. But those examples are bad, and yet another non-standard cloud service isn't also a good example.

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

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

#35

Post by Bluecobra »

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…

“Layers are only ever added, not removed.”

This is a long read but you might find it enjoyable:

https://apenwarr.ca/log/20170810

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

#36

Post by eightysixfour »

smokefoot wrote: post #22

I don’t understand networking all that well. Is it interesting that the telcos and non-tech companies are moving away from specialized hardware toward software defined networks while the hyperscalers are using hardware acceleration?

These things are partially related - telcos running things in the cloud, in software, is actually running on top of these hardware innovations, it is just abstracted from them.

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

#37

Post by Dylan16807 »

wmf wrote: post #33
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…

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.

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

#38

Post by jiggawatts »

marcosdumay wrote: post #21
jiggawatts wrote: post #12

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…

> Another random example is HTTP/3, which is basically the "What's best for Google" protocol. HTTP/2 is that. The version 3 is... quite great, and not really originary from there. And gRPC is some self-contained thing that doesn't bother anybody. I do really agree with your point. But those examples are bad, and yet another non-standard cloud service isn't also a good example.

For example, HTTP/3 uses QPACK, which has a static predefined list of HTTP header strings included in the standard.

What strings you ask?

The top hits Google captured from their data centre egress.

E.g.: https://www.ietf.org/archive/id/draft-ietf-quic-qpack-20.htm...

Notice that "content-encoding" includes br (Brotli), a Google compression algorithm that essentially only they were using at the time.

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

#39

Post by marcosdumay »

petters wrote: post #34
marcosdumay wrote: post #21

Earlier quoted context omitted.

> Another random example is HTTP/3, which is basically the "What's best for Google" protocol. HTTP/2 is that. The version 3 is... quite great, and not really originary from there. And gRPC is some self-contained thing that doesn't bother anybody. I do really agree with your point. But those examples are bad, and yet another non-standard cloud service isn't also a good example.

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

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

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

#40

Post by AlotOfReading »

cjensen wrote: post #14
luma wrote: post #11

Earlier quoted context omitted.

OSI is just a model, there’s not all that much to understand there. It’s simply a way to categorize network technologies using a common language.

OSI is an entire networking stack designed by committee that died from disuse [1]. The only thing we now remember of it are the functional layers within the protocol. For example, people sometimes refer to TCP as a "Layer 4" protocol even though (a) TCP predates the invention of Layer 4 and (b) TCP is a square peg that does not exactly fit into the round hole that is Layer 4. [1] https://en.wikipedia.org/wiki/OSI_mod…

I wish we could forget the other remnants of OSI like x.509, ASN.1, and LDAP. Those were the things good enough to be used for real systems, and I'd still rather crawl over broken glass than implement any of them.

Imagine how bad the rest of it was.

Post reply on HN