Most active commenters
  • stego-tech(5)

←back to thread

188 points ilove_banh_mi | 14 comments | | HN request time: 0s | source | bottom
1. stego-tech ◴[] No.42172794[source]
As others have already hit upon, the problem forever lies in standardization of whatever is intended to replace TCP in the data center, or the lack thereof. You’re basically looking for a protocol supported in hardware from endpoint to endpoint, including in firewalls, switches, routers, load balancers, traffic shapers, proxies, etcetera - a very tall order indeed. Then, to add to that very expensive list of criteria, you also need the talent to support it - engineers who know it just as thoroughly as the traditional TCP/IP stack and ethernet frames, but now with the added specialty of data center tuning. Then you also need the software to support and understand it, which is up to each vendor and out of your control - unless you wrap/encapsulate it in TCP/IP anyway, in which case there goes all the nifty features you wanted in such a standard.

By the time all of the proverbial planets align, all but the most niche or cutting edge customer is looking at a project the total cost of which could fund 400G endpoint bandwidth with the associated backhaul and infrastructure to support it - twice over. It’s the problem of diminishing returns against the problem of entrenchment: nobody is saying modern TCP is great for the kinds of datacenter workloads we’re building today, but the cost of solving those problems is prohibitively expensive for all but the most entrenched public cloud providers out there, and they’re not likely to “share their work” as it were. Even if they do (e.g., Google with QUIC), the broad vibe I get is that folks aren’t likely to trust those offerings as lacking in ulterior motives.

replies(3): >>42173315 #>>42174871 #>>42179283 #
2. klysm ◴[] No.42173315[source]
If anybody is gonna do it, it's gonna be someone like amazon that vertically integrates through most of the hardware
replies(2): >>42173489 #>>42173592 #
3. stego-tech ◴[] No.42173489[source]
That’s my point: TCP in the datacenter remains a 1% problem, in the sense that only 1% of customers actually have this as a problem, and only 1% of those have the ability to invest in a solution. At that point, market conditions incentivize protecting their work and selling it to others (e.g., Public Cloud Service Providers) as opposed to releasing it into the wild as its own product line for general purchase (e.g., Cisco). It’s also why their solutions aren’t likely to ever see widespread adoption, as they built their solution for their infrastructure and their needs, not a mass market.
replies(2): >>42174545 #>>42174831 #
4. iTokio ◴[] No.42173592[source]
They already started researching that in 2014 and have integrated the resulting protocol in some products like EBS:

https://www.allthingsdistributed.com/2024/08/continuous-rein...

5. wbl ◴[] No.42174545{3}[source]
Nevertheless Infiband exists.
replies(2): >>42174698 #>>42176020 #
6. MichaelZuo ◴[] No.42174698{4}[source]
Which makes the prospects of a replacement for either or both even more unlikely.
7. panzagl ◴[] No.42174831{3}[source]
Amazon's solutions to 1% problems are the next batch of cargo cult corporate solution speak that we're going to have to deal with. How can we have a web scale agile big data devops monorepo machine learning microservice oriented architecture if we're limited by TCP? I mean, it was developed in the 70s...
replies(1): >>42175966 #
8. skeptrune ◴[] No.42174871[source]
> Even if they do (e.g., Google with QUIC), the broad vibe I get is that folks aren’t likely to trust those offerings as lacking in ulterior motives.

It's pretty unfortunate that we've landed here. Hordes of venture-backed companies building shareware-like software with an "open source" label has done some severe damage.

replies(2): >>42175688 #>>42176080 #
9. getcrunk ◴[] No.42175688[source]
Quic is an attack on network based filtering (ad blockers) similar to doH. There likely are convenient ulterior motives.
10. stego-tech ◴[] No.42175966{4}[source]
Ugh, the fact I have to explain that we don’t need any of that cult-speak for our enterprise VMs (because enterprise software hasn’t even moved to containers yet) makes me grimace. I loathe how marketers and salesfolk have turned technology from a thing that can be adapted to solve your problems, into a productized solution for problems you never knew you had until the magazine they advertise in told your CIO about it.
11. stego-tech ◴[] No.42176020{4}[source]
As does Fibre Channel and a myriad of other solutions out there. The point wasn’t to bring every “but X exists” or “but Company A said in this blog post they solved it” response out of the fog, but to point out that these issues are incredibly fringe to begin with yet make the rounds a few times a year every time someone has an “epiphany” about the inefficiencies of TCP/IP in their edgiest of edge-case scenarios.

TCP isn’t the most efficient protocol, sure, but it survives and thrives because of its flexibility, cost, and broad adoption. For everything else, there’s undoubtedly something that already exists to solve your specific gripe about it.

12. stego-tech ◴[] No.42176080[source]
Which is ironic, because I remember TCP/IP maturing in the protocol wars of the 90s. My Cisco course specifically covered the protocols separately from the media layers because you couldn’t know if your future employer still leveraged Token Ring, or ATM, or IPX, or TCP; a decade later, the course had drastically simplified to “ethernet” and “TCP/IP” only.

Many of these came from companies who created the protocol solely to push products, which meant the protocols themselves had to compete outside of the vacuum chamber of software alone and instead operate in real world scenarios and product lines. This also meant that as we engineers and SysAdmins deployed them in our enterprises, we quite literally voted with our wallets where able on the gear and protocols that met our needs. Unsurprisingly, TCP/IP won out for general use because of its low cost of deployment and ongoing support compared to alternatives, and that point is lost on the modern engineer that’s just looking at this stuff as “paper problems”.

replies(1): >>42199285 #
13. Shawnj2 ◴[] No.42179283[source]
Obvious answer is to run something on top of UDP like QUIC does
14. kjs3 ◴[] No.42199285{3}[source]
I remember TCP/IP maturing in the protocol wars of the 90s

Good times. But it didn't matter because ATM was the future. /s

Many of these came from companies who created the protocol solely to push products

Like 100Base-VG? That was a good laugh.

TCP/IP won out for general use because of its low cost of deployment and ongoing support compared to alternatives, and that point is lost on the modern engineer that’s just looking at this stuff as “paper problems”

Welcome to my world...