41–50 of 158 posts
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?
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.
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.
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…
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?
Nobody wants to depend on hardware development cycle hence “fuck it, ill do it in software”
It's just not realistic to take all the switches, routers, and other garbage you've got in between points in the network off the rack/ceiling/wall/pole because the hardware can't support some protocol.
Good evidence for this is the rollout of fiber, which has been happening neighborhood by neighborhood and house by house for a decade.
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
https://www.researchgate.net/publication/350711603_Adding_is...
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…
Maybe for a LAN that's fine, but for connecting devices between broadcast domains, it just doesn't cut it.
Earlier quoted context omitted.
Nobody wants to depend on hardware development cycle hence “fuck it, ill do it in software”
I don't think it's that hard to rely on hardware development, it's more of a problem of rolling out a fleet of new hardware. It's just not realistic to take all the switches, routers, and other garbage you've got in between points in the network off the rack/ceiling/wall/pole because the hardware can't support some protocol. Good evidence for this is the rollout of fiber, which has been happening neighborhood by neig…
I was confused by the reference to “lossy” networks in this page. Does this have a different meaning in this context than something like lossy compression where data is actually discarded?
A “lossy” protocol is one that doesn’t attempt to compensate for that. In most cases, but not all, that means a higher level protocol will need to ensure that every bit of data has made it through. (An example protocol that might not care is one for watching broadcast TV on the Internet… if you miss a few seconds it’s not a big deal).
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…
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.
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 reset tomorrow, how might you design the perfect layer 2 addressing and routing system?
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…
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.
Because else you need ARP, IP, UDP, TCP, etc.