Stanford prof is beating the drum for a new protocol to replace TCP

TCP, the data transport protocol upon which pretty much the entire web and most of cloud computing is built, is ill-suited for emerging AI workloads, a retired Stanford University professor argues. To solve the problem, he's promoting a new protocol called Homa. “TCP, for all the amazing things it has done, is not a good match …

[Anonymous Coward]

I wonder if he was funded by Alphabet?

[BossHobo]

I will always downvote snarky "First!" comments that have nothing to say.

...

And I am unanimous in that position!

[alain williams]

Senders do not always know ...

how much data they will send, it can be generated on the fly, added slowly -- think of an SSH session but also many others.

By all means add it but TCP must remain for a looong time - preferably forever. We do not want AI (which has not been around long and may have different needs in a few years time) to further wreck things.

[Jou (Mxyzptlk)]

Re: Senders do not always know ...

I see the same: There is no need to replace TCP. "replace TCP" is more like a marketing thing to gain some attention. If you look into the linked documents the tone is much less aggressive.

[FirstTangoInParis]

Re: Senders do not always know ...

Correct. As TFA points out, Homa runs alongside TCP and can be used for applications that work best with it. The headline is a bit misleading.

Let's not get all uppity. TCP isn't going anywhere anytime soon.

[Anonymous Coward]

Re: Senders do not always know ...

We can't even move past ipv4. TCP is going nowhere.

[John Robson]

Re: Senders do not always know ...

This feels like it's mostly an "in a DC when you control everything" protocol..

There may be times when it fits really well, and AI workloads might match that. It might sit alongside TCP and UDP with certain workloads preferring it... I don't think TCP will disappear.

[BartyFartsLast]

Re: Senders do not always know ...

Nope, TCP is way too entrenched and perfectly fine for the majority of cases.

Interesting for DC use though

[Chris Miller]

Re: Senders do not always know ...

The really vast DCs (Google, Amazon, Microsoft, …) already make use of 'home-brew' protocols internally, tailored for the type of traffic they see. If you can shave a few ms off a trillion transactions a day, that has real value.

[Jou (Mxyzptlk)]

So Checksum no more...

It is mentioned in the article, although only indirectly: Yes. Receiver defines how many, and what is described as "grants" is effectively a buffer control on the receiver side, no data packet order is defined. It also means the receiver can use a logic to make the sender send four or 10 packets before the next "grant".

From the atc21-ousterhout.pdf: "The first few packets of each message (unscheduled packets) are transmitted unilaterally by the sender, but the remaining scheduled packets are sent only in response to grants from the receiver.", see section 4.1 too.

But I see no checksum, and there is none? https://dl.acm.org/doi/abs/10.1145/347059.347561 from 2003 says 1 ind 1000 for bad links, 1 in 32000 for good links...

Up to the application to catch those. Argument is "application can checksum over larger blocks", i.e. saving those two bytes.

[tip pc]

Re: So Checksum no more...

So Checksum no more...

everything along the path at L2 is doing checksums

ultimately its up to the app to decide if the received data is valid so little pint doing checksums in the l3 protocol as well.

[Jou (Mxyzptlk)]

Re: So Checksum no more...

Yeah, L2 is doing some checksum, which is kinda useless after a few steps of routing since you cannot rely on EVERY "L2" link to do its job since some have no checksum defined.

The L3 checksum does make sense, but it is not needed for every use case.

[runt row raggy]

Re: So Checksum no more...

l2 check summing is piecewise. so Ethernet segment a has a different checksum than the next because the Mac addresses are different. this means that an l2 checksum cannot detect corruption caused by a switch or router.

[Kevin McMurtrie]

Probably another silly protocol

Homa is going to show amazing throughput on specific benchmarks and fail miserably on others. No matter what tricks you play, the end result is trying to get erratic flows of data over a serial line.

[VoiceOfTruth]

Re: Probably another silly protocol

So the sensible thing would be to move workloads that shine on Homa to Homa.

The average car does not make a good racing car. That doesn't mean we should not have racing cars.

[Albert Coates]

Re: Probably another silly protocol

My old Metro 1.4a surprised a number of drivers of considerably more expensive vehicles. But then I have a biker's attitude, even behind the wheel.

[Sproggit]

Been Down This Road Before

Once Upon A Long Ago someone invented ATM - “Asynchronous Transfer Mode” - which was going to revolutionise our use of networks.

It fixed packet lengths at 53 bytes - which meant that silicon could be optimised to shunt packets through at blinding speeds; it had prioritisation meta-data in packet headers, which meant that service thresholds could be met. Even better, wonder of wonders, it would allow the mixing of voice and data traffic on a single network.

Initial ATM cards were released that supported fibre connections running at 155Mb/s… and it was by all measure, the “best thing since sliced bread”.

It was also shockingly expensive, provided through very limited hardware and - in my limited experience - had interoperability issues between some of the vendors.

Meanwhile, humble Ethernet running TCP/IP, was dawdling along at mostly 10Mb/s, had no real support for voice, had no service management and looked tired by comparison.

Yet in a very short window of time, the TCP/IP networks had stepped up to gigabit speeds; IPv6 brought packet optimisation for those who needed it, the address space was expanded to cover *galaxies* and (drum roll please)… it just worked.

I love the idea of someone willing to challenge established orthodoxy for something like this… but I really hope they have done their homework and not only have something that is markedly better than the technology they are proposing to replace, but have a near-seamless migration plan for existing and heavily-invested users. I hope their proposals are completely unencumbered from an IP/patent perspective (remember Rambus, anyone?) and they have actually discussed this with the network fabric manufacturers before starting to push it in to the Linux kernel.

But most of all I hope their justification business case has a genuine problem to solve. You only need to look at programming languages these days to realise our industry is furiously generating mountains of technical debt as we adopt and abandon programming languages like they are seasonal things… As someone far wiser than me once said:

“Whilst all progress is change, not all change is progress…”

[Anonymous Coward]

Re: Been Down This Road Before

your comparing apples & oranges

Once Upon A Long Ago someone invented ATM - “Asynchronous Transfer Mode” - which was going to revolutionise our use of networks.

It was & it did, ATM was initially conceptualised in the late 1970s and early 1980s, with its first experimental implementations occurring around 1984.

It began broad commercial deployment in the early to mid-1990s as part of the Broadband ISDN standards.

TCP/IP, was dawdling along at mostly 10Mb/s,

This was because it was running over ethernet that was limited to those speeds. As ethernet got faster so did TCP transmission rates because the transport was faster.

just as ATM was getting popular Ethernet was running at 100mb/s

Ethernet succeeded because it was cheaper & simpler. Telco's loved ATM as it had lots of inherent advantages in their transmission environments (WAN's) but ethernet excelled in LAN's for corporates.

Gig ethernet became a thing ~ 2000 & 10Gig within the next decade.

You should be comparing ATM to Ethernet as they are both L2 transport mechanisms.

Packet Transfer Mode has succeeded ATM.

[Roland6]

Re: Been Down This Road Before

Both a bit off the mark in your apples and oranges comparison.

ATM was envisaged as a high-speed shared access WAN technology, at a time when available telco WAN services, for example X.25, were basically multiples of 64Kbps...

"Ethernet" was a LAN technology, and back then referred exclusively to CDMA/CD signalling intended for private LANs.

[hammarbtyp]

Re: Been Down This Road Before

More importantly at the time, a large amount of traffic was voice. ATM was optimised for low jitter and latency, so that delays on the line would not impact voice quality. By defining fixed packet size you could create the myriad of virtual circuits required to send your voice traffic around the world with low latency. Another benefit is the switch fabric could be largely hardware drive so in the days of limited processor power it was easy to scale.

It was never designed as a TCP alternative, since it was designed for WAN infrastructure

[Anonymous Coward]

Re: Been Down This Road Before

"It began broad commercial deployment in the early to mid-1990s as part of the Broadband ISDN standards."

And that explains how ATM became such a much loved roaring success everywhere.

[Anonymous Coward]

Re: Been Down This Road Before

Telcos running backbones have given up on ATM and are running TCP directly over fiber.

I never understood why ATM was bundled into ADSL. Since switching and addressing where never fully implemented it could never become an end-to-end mechanism.

[Sproggit]

Re: Been Down This Road Before

The impression I took was that ATM was originally sold as the perfect hybrid protocol for handling both voice and data traffic.

The argument went that the small, fixed size of the packets made them easy to manage, route and prioritize in order to ensure that voice users got a reasonable quality of service.

The problem was that ATM is woefully inefficient. The basic data payload is/was 48 bytes, but the header is/was 5 bytes, for a total cell size of 53 bytes.

That might not sound like much, but it is much less efficient than TCP, which has since gone in the opposite direction [funnily enough] and given us "Jumbo Frames". When you're an end user sitting at your desk with a single cable for voice and data in an ATM network, that inefficiency probably won't amount to a whole hill of beans. But when you're a telco, in a constant fight of capacity, contention ratios and throttling, that inefficiency really matters.

The telcos were left with an easy choice, because they were able to run tests which showed that their main trunks and backbones could carry more traffic with TCP than ATM.

[John Miles]

Re: The basic data payload is/was 48 bytes

At a training session on fast WANs - I was told when defining the specifications every country, but one country wanted it to be 64 bytes, the odd one out wanted it to be 32 bytes so they compromised - one of the few things I remember from the course (and no idea if true). I've never actually used anything from the course, but it was a day out of office.

[Dom 3]

Re: The basic data payload is/was 48 bytes

Almost. The US wanted 64 bytes, Europe wanted 32. The wikipedia page has a nice summary.

[Roland6]

Re: The basic data payload is/was 48 bytes

Fundamentally, back to the differences of voice/telecomms/circuit-switching networking and data/packet-switching networking.

We forget voice over IP is “best endeavours” service that works well enough most of the time.

I like how the 48-bit compromise favoured neither of the two camps. Plus the 5 octet header - which probably should have been padded to 8 octets…

[containerizer]

Re: Been Down This Road Before

You're getting your layers mixed up.

ATM was intended to be adaptable to multiple traffic types, hence the 'ATM Adaptation Layer" specifications. AAL2 (voice) and AAL5 (IP networking) were the major ones if memory serves.

ATM was/is not an alternative or a competitor to TCP/IP. The small fixed size packets were designed to be easily switchable by hardware, at a time when telco operators were working to get away from TDM/circuit-switched technologies. It was not intended to be a global networking protocol which is what TCP is. TCP is not intended to be operable in hardware - and indeed it isn't, as there's a lot of state tracking e

ISDN and earlier DSL (eg ADSL) if memory serves used AAL5. It behaved more like dialup in that a connection would be created and then a PPP session would run, so IP packets would sit on top of PPP frames which would in turn sit on AAL5. When Ethernet came along, ethernet frames could be shipped using PPP-over-ethernet-over-ATM for compatibility, then these were changed just to regular PPPoE.

ATM's real killer with IP networking was when an ATM cell got dropped. If that happened, TCP would retransmit the whole packet, even though only one ATM cell out of the 30 or so cells sent for a regular IP packet got lost. The receiver would simply discard all of those good cells and they would all be retransmitted again. Any slight lossiness could therefore cause a traffic storm. With the much larger ethernet frames, a bad packet would be dropped at the point of detection without things getting out of hand. As computation became cheaper and more powerful, the overriding need to have hardware-native capbilities became less important.

The thing that replaced ATM was ethernet. The ATM stack was well engineered and carefully designed for the problems it was intended to solve. But ethernet was easier to bolt onto, and when it became ubiquitous in datacentres it became logical to make the network core work with it natively. Had the cards fallen differently I expect ATM would have been extended to support different cell sizes or mechanisms to group cells together to avoid retransmissions etc.

[Anonymous Coward]

Re: Been Down This Road Before

I never understood why ATM was bundled into ADSL. Since switching and addressing where never fully implemented it could never become an end-to-end mechanism.

because it was a transmission mechanism, DSL is getting your data from 1 LAN to another LAN over a WAN owned by the telco. your LAN data is encapsulated over the DSL transmission mechanism, sent to the telco that un-encapsulates it & then encapsulates again over its WAN before reversing the process to send over that last mile to the other end.

DSL/ATM/MPLS/DOCSIS doesn't matter to either end so long as the data is received at either side in the format it was sent in.

most telco's had ATM backbones so thats where the relationship with DSL was.

[that one in the corner]

Re: Been Down This Road Before

And all these discussions boil down to:

There have been, are now and will be forever many protocols at each level in the stack.

As time passes, conditions change - the content of the data, the availability of physical infrastructure, the cost of hardware - all of which are unpredictable (whichever one becomes a commodity, for whatever reason, will become cheaper - but may also become grottier).

At any time, whatever gives the working bang for the buck is "better".

TCP/IP isn't forever and always "better" than ATM, nor the other way around. And the same goes for any other comparisons. The fact that telcos use more TCP/IP today doesn't even mean it is "the best" today. It means that, at the point the decision to buy more TCP/IP kit was made the telcos reckoned they'd be financially better off for doing so, in whatever timeframe they chose to consider.

All out techie arguments about packet length (which, btw, are woefully incomplete, only considering payload/overhead percentages and ignoring hardware buffer sizes and physical timing) are as nothing compared to the CFO's gut feelings.

[martinusher]

Re: Been Down This Road Before

ATM was designed to fit data traffic onto existing voice protocols. POTS -- legacy telephone systems -- ran on relatively short fixed length frames fitted in precisely timed slots in the transmission link. It was a good solution for what it was. It became redundant because data links are a lot more versatile, they could easily carry voice traffic as just 'yet more data'.

[Groo The Wanderer - A Canuck]

Another pipe-dream protocol by some whack job who doesn't grasp that a byte array is a byte array is a byte array and that the only other attributes you need except sender and receiver connection data is the size of the byte array. The rest is irrelevant in reality because the hardware protocols that underpin it all are not based on TCP-specific packets.

[Androgynous Cupboard]

"pipe-dream" - I see what you did there.

You're correct for a single array but the world is more complicated than that, and your point is akin to saying processes on a Linux box are going to take the same amount of time, so why not dump the process scheduler and just run them all sequentially? What matters to people is apparent throughput - they can make a video call without lag while downloading a file in the background and while their email and chat clients are polling for content.

I know nothing about this new protocol but good luck to him; My suspicion is for 95% of people (and judging by the comments so far, 100% of commenters) what we have now is good enough, but as the article notes there is a 5% for whom it isn't. It's their opinion I'd like to hear.

[Groo The Wanderer - A Canuck]

Yes, but you have no control over that, and you still wouldn't with his "new protocol." The hardware layer is the only protocol that truly matters for throughput and bandwidth values, not your chosen "protocol." Your "protocol" is expressible as byte arrays of data, with the major "throughput" difference you might claim based almost entirely on trying to optimize the packet/block sizes for your ISP's hardware, but that's a non-portable approach to trying to get performance out of a network. Those sequential byte arrays are all the hardware layer sees or concerns itself with other than the actual address information of the endpoints.

Any "performance improvement" resulting from this software layer protocol are misleading, misquantified, and their root cause misidentified, resulting in a very non-portable final "optimization solution" that will prove to be far from optimal for other significantly differently provisioned ISPs.

[Androgynous Cupboard]

You've just discounted the entire concept of QoS and network packet priority. This is below (layer-wise) my level of expertise, but it strikes me as a very bold claim.

You've also somehow missed the entire second paragraph of the article: "TCP, for all the amazing things it has done, is not a good match for datacenters". He's not proposing a solution for routing packets around the world, he's proposing a solution for routing packets within a datacenter. Your point about differently provisioned ISPs is probably true, but is also irrelevant.

[Paul Hovnanian]

So ...

"But adding Homa into a network is fairly simple"

Why not both? I mean, the Internet seems to work pretty well with TCP, UDP and a bunch of other fiddly stuff flying back and forth that most of us just don't see.

[RoboJ1M]

Re: So ...

It's in the article, they run side by side.

Designed that way.

And every other bespoke closed source solution that's also in there.

This is supposed to replace them all eventually.

[Anonymous Coward]

Re: So ...

"This is supposed to replace them all eventually."

Juxt like IPv6?

[Schultz]

Is TCP the problem?

Or is it that datacenters abuse the TCP protocol for busing data because it's more convenient than building a proper architecture for their really big computers?

[Matthew "The Worst Writer on the Internet" Saroff]

John Ousterhout Lost Me at handling, " emerging AI workloads."

If it is good for AI and Data Centers, I'm against it.

[RoboJ1M]

A response to what everybody else said

Kevin McMurtry said, "it's all multiple clients taking over a serial line", implying that it can't be solved better than we've already done.

2 people trying to talk

1 trying to listen

How do you control it?

At the source with no coordination?

Or at the destination, which knows how many people are talking and what they want to say?

And has traffic control over the sources?

And this is all latency in a AI SERVER RACK.

Then between server racks.

And it's a problem that's already being solved by a bunch of bespoke solutions.

In that small arena, where the data-centres say what goes, this could work.

Remember, it's ALL about latency.

It's ALL about RPC.

Somebody else mentioned we tried it before with bespoke hardware that failed because ethernet got faster.

Back then an order of magnitude was EASY

You just used all the pairs first!

How do you get that now?

Diamond plated fibre.

What if you use what you have better?

Milli to micro is THREE orders of magnitude faster in an arena where ONLY latency matters.

Certainly the only gains right now are in latency.

Using a general solution, in software, over existing hardware.

In this arena, TCP isn't dying.

TCP is DEAD.

[Anonymous Coward]

He has enough gray hair to remember Severnet.

Apparently, 1 byte signalling between sender and receiver with wormhole routing is a clustering technology this "prof" doesn't want to acknowledge. It also had a small message component as well as shared remote memory. Awesome cluster technology from Tandem. Tandem also had some of the best multithread programmers with great non blocking algorithms.

This fell out of favor in the late 90's due to requiring expertise beyond sockets to implement. The same happened with native Infiniband. Almost all Infiniband implementations were done over sockets. TCP wins because any half assed programmer can code it. That is why "Homa" has been dead in the water since its introduction in 2018. Not a good solution, just a retired prof trying to sell an unimplentable solution that isn't in conflict with patented solutions that are far better.

I would be far more impressed if he discussed the challenges of implementing large scale cxl clusters.

[Softsuits]

Hmmm about those Routers in Space

QOS seems the point. Recievers having adjudication seems like a OSPF nightmare. Main trunk IP is elegant All else is a Packet Driver IMO.

Neat idea. However; it still streams. Transport layer ordering.

[Locomotion69]

Obligitary xkcd

https://xkcd.com/927/

[Neil Barnes]

Re: Obligitary xkcd

Amazing how we are coming to remember the classic three XKCDs without having to click the link to check...

#327 (Little Bobby Tables)

#697 (Spirit)

#927 (Standards)

One of these for Randall --->

[Flightmode]

Re: Obligitary xkcd

I'll add...

979: Wisdom of the Ancients, and

2347: Dependency

... to that list.

(And Spirit is 695.)

[Neil Barnes]

Re: Obligitary xkcd

Yup, I have no idea how that happened. I _typed_ 695, but somebody must have moved the keyboard between 9 and 5.

[Androgynous Cupboard]

Re: Obligitary xkcd

The Spirit of Dolly Parton!

[Persona]

Re: Obligitary xkcd

Thank heavens you posted the correction. There I was looking at a completely unfamiliar XKCD and wondering if I was experiencing early onset dementia.

[asdfasdfasdfasdf]

Ipv6

Hopefullywe learnt the lesson and made it backward compatible!

[Jamie Jones]

Re: Ipv6

How much longer are we going to be hearing this sort of ignorant comment, or the one that "IPv6 addresses are too hard to remember"

Wherever it can be, IPv6 is compatible. Stacks can natively accept both protocols. There are oodles of compatibility layers, and translation layers. You can still use DHCP, 'private lan addressing' and NAT. If you really want.

The only incompatibility stems from the longer address - now that would be the same even if they extended the address by only 1 bit.

Now, the header could have been kludged in a way that made the packet natively parsible to IP4 routers, but that would have been an unnecessary overhead for all traffic - besides, IP6 over IP4 tunnelling already exists without forcing the whole protocol to be tunneled-ish.

But the problem isn't the routers anyway. The core network has long ago been upgraded. Like the "last mile" problem, the problem is the end stack.

I've yet to hear anyone explain how a new protocol can be compatible with an unmodified IP4 stack.

[tip pc]

Re: Ipv6

How much longer are we going to be hearing this sort of ignorant comment, or the one that "IPv6 addresses are too hard to remember"

yep hopefully ipv6 will die its death and we can all move on.

[Anonymous Coward]

Re: Ipv6

IPv6 struggled because hardware that didn’t support ipv6 couldn’t handle process the packets

It’s not a secret or a surprise. You always needed two stacks - one for ipv4 and one for IPv6. Ie not compatible.

Now if IPv6 was an ipv4 address with an optionally larger address range… it would have been really easy to adopt.

[Kevin McMurtrie]

Re: Ipv6

IPv6 struggled because it took decades for people to settle on a common terminology and stop using NAT. Coders found a way to hack it working and stuck with that even when it only worked by luck.

Docker is the poster child for how not to use integrate IPv6 into your legacy codebase.

[Bartholomew]

Re: Ipv6

> Now if IPv6 was an ipv4 address with an optionally larger address range… it would have been really easy to adopt.

Lookup the IPv8 draft, lots wrong but it is essentially that.

Dumbed down summary: All existing IPv4 addresses have 0.0.0.0. prepebded when entering the global IPv8 system.

[Jamie Jones]

Re: Ipv6

If only IPv6 had that ..

Oh, it does. https://findipv6.com/ipv4-to-ipv6/ipv4-mapped-ipv6

[Jamie Jones]

Re: Ipv6

Now if IPv6 was an ipv4 address with an optionally larger address range… it would have been really easy to adopt.

How? IPv6 *is* fundamentally ipv4 with a larger address range. Don't let the hex representation for humans fool you. IPv4 is 32 bits and a netmask. IPv6 is 128 bits and a netmask. Yes, there are other improvements requiring changes, but if there have to be changes anyway, may as well do it properly.

You know what IPv4 with a larger address range isn't? IPv4. As soon as you hit your "optionally larger address", you've got a packet that won't work without protocol modifications to the stack And if you're going to need that...

And tunnelling is not an argument because IPv6 can be tunnelled too.

[mevets]

Re: Ipv6

`google: vpn disable ipv6` pretty much sums up the state of ipv6 as it turns 30.

That isn't necessarily a fatal indictment.

Many myths proclaim deities that waited until their 30s to enter service.

While people mumble about address size, i don't understand it, yada yada, the shortcomings of ipv6 are observable by layers far up the stack.

It is silly to think that *homa* will somehow manage a feat of transparency that ipv6 couldn't.

[Jou (Mxyzptlk)]

Re: Ipv6

> `google: vpn disable ipv6` pretty much sums up the state of ipv6 as it turns 30.

Disabling ivp6 is a bad recommendation. What you should google for is: Prioritize ipv4 over ipv6. This can be set in Windows and Linux in a surprisingly similar fashion on the level of prefix reorder, and not much difference on another level in the registry / config. You should change both.

[Jou (Mxyzptlk)]

Re: Ipv6

Homa comes AFTER the IP(v4|v6) header. The addressing is not Homa's business. IPv4 would save 20 bytes, but if this is datacenter/storage targeted it would use jumbo frames anyway so those 20 bytes difference can be neglected.

[big_D]

Switches and Routing

One thing that was missing was how this will be switched and routed, VLANs etc. If it isn't TCP traffic, do the switches (at least Layer 2 & 3), firewalls and routers need updating/replacing as well?

[Jamie Jones]

Re: Switches and Routing

If it runs on ethernet it can be switched and bridged. If it runs on IP it can be routed. I understand that this runs on IP, so yes

Particular firewalls with specific protocol matching may need updating to deal specifically with this kind of packet, but I doubt they'd have firewalls in these situations - I'd expect everything to be on exclusive land, or at the very least, vlans

[big_D]

Re: Switches and Routing

The article says that this replaces IP, so the servers aren't running IP, or at least this traffic is not running over IP.

[Jou (Mxyzptlk)]

Re: Switches and Routing

> The article says that this replaces IP

Article title: "replace TCP"

Article text: "Shedding TCP", "Homa works side by side with TCP", "Homa different from TCP", "tossing TCP", "to bypass the TCP stack" etc etc etc

Not in article text: "IP"

[IGotOut]

Again?

I must have heard about 1/2 a dozen protocols that will replace TCP over the 20 years I worked in Tech, and yet here we are still using it.

How's your RDP set up going? XTP? PGM?

[Jamie Jones]

Re: Again?

Correct me if I'm wrong, but I thought the proposal was to replace TCP in specific situations, not that it is a total TCP replacement.

[frankvw]

Yeah, good luck with that

Ages ago the world started to run out of IPv4 addresses and IPv6 came along to extend the available address space simply because it was utterly necessary and there was no choice but to do something like that. That worked well and as intended, but IPv6 never replaced IPv6. As of today IPv4 is still very much around, alive and (occasionally) kicking.

And now the proposal is to just simply replace TCP? Not extend it, mind you, but simply scrap it and replace it with something entirely different?

Get out of here.

[Anonymous Coward]

L2 is still king

whats not discussed is that these L3 replacements still ride on top of what ever they are doing for L2.

they seek to resolve perceived issues in how the machines send & receive to each other via their L3 addressing mechanisms.

Its fascinating how Ethernet has endured all this time, yes newer faster standards have emerged and across differing mediums like from coax to twisted pair to fibre & radio (reminiscent of its roots with ALOHAnet).

[Roland6]

Re: L2 is still king

>” Its fascinating how Ethernet has endured all this time”

It’s called marketing…

The brilliance was back in the late 1980s in branding LAN over UTP as Ethernet and keeping ownership of the Standard with the IEEE802.3 working group.

The laugh is I doubt any one in the last circa 30 years has deployed any traditional Ethernet/CSMA/CD LAN infrastructure.

[xyz123]

Just retrieve from a repository, compile it and install. Simples

Now tell that to people who literally CRY when they have to buy a new mouse and plug it in because "it's too technical"

[xyz123]

I propose we all switch to the new network standard E.V.R.I

OK so it has 50% packet-loss and those packets that DO arrive are thrown at neighbouring devices, but its cheap.

[imcdnzl]

Brittleness and new protocols

I worked on a protocol called DCCP as part of my PhD (UDP with sessions, or TCP without reliability you could say) and we got it into the Linux kernel and also the IETF working groups that I was part of was very active with some of the smartest people involved with it.

Ultimately it failed because of what is called the "middlebox problem" - all the routers, firewalls, SDNs, offload engines etc which won't support it. A case we found in point was that the NAT code in the Linux kernel blocked DCCP as it blocked any new protocols by default. This sort of change takes years and years to go through - look at how long IPv6 takes. In the end the protocol got removed from the Linux kernel even though it worked well as nobody used it. Basically QUIC superceded it as it could be layered on UDP.

So I think that homa could be useful potentially just within a network, but on public Internet it's chances are slim - though to be fair he's positioning for data centre.

[Roland6]

Re: Brittleness and new protocols

>Basically QUIC superceded it as it could be layered on UDP.

And be deployed as part of the web browser.

> though to be fair he's positioning for data centre.

which is basically LAN and thus if latency and performance were so critical, just layer it directly on to the layer 2 API... But that probably doesn't sit well on datacentre SDN...

[Anonymous Coward]

Re: Brittleness and new protocols

yep, if its all local dc traffic whats the point messing with l3?

if they want routing then that requires extra hardware to support the new protocol which is a different thing.

[Roland6]

Re: Brittleness and new protocols

Probably the reason is because those behind it don’t understand LANs.

We saw similar with Bonjour and related single LAN subnet protocols, which worked really well until until some wanted them to work over a L3 routed infrastructure…

[Bartholomew]

Will history repeat itself ?

I remember using XNS (3+Share) on 3Com networks (They eventually pivoted to TCP/IP with 3+Open).

And IPX/SPX on Novell networks (They eventually pivoted to TCP/IP with NetWare/IP)

Both network stacks worked reasonably well on small to almost medium local installations. But to go country wide or global neither XNS or IPX/SPX was a good option.

Homa sounds interesting for local internal DC traffic for extremely specific workloads, but I suspect that this will be its final resting place.

[Lord Baphomet]

Better?

We've always had better protocols. IBM's SNA LU6.2 was much better 30 years ago, but still not adopted? Could it be because we don't want to have to rewrite the entire network stack for an upstart that may be worse in practice, and maintain the old stack too because it'll take another 30 years for everyone to switch over? FFS. 2-years ago I killed a big project at a European bank that was designing a new security protocol to fix the problems with the initial TLS handshake. It required distributed verification by multiple third-parties. I took me nearly 3-months to kill it. "But it's better", "Doesn't matter, nobody will adopt this", "but it's better", "doesn't matter, nobody will adopt this", for 3 months, until finally I convinced some more senior managers that this plan was really dumb and finally the project was cancelled.

[Stoic Skeptic]

SCTP

SCTP works well for the telecom industry at layer 4

[BartyFartsLast]

If these claims stack up

The job ads will be full of agencies wanting Homa experts with ten years experience to work for hedge funds and trading houses at "competitive salaries"

[Gavsky]

TCP means something else to the non-tech people: a UK over-the-counter, antiseptic liquid. Halogenated phenols & phenol, with a smell that instantly transports you back to childhood.

[ThePalsyP]

I'm all for this. TCP stung like heck when I was a kid.

[Roland6]

Still does - it hasn’t been diluted or replaced with a “kid safe” “gentle” version…

[martinusher]

TCP Was Always an Abomination

TCP was designed primarily to emulate the operation of a serial console over a network. The design had a distinctly "hold up a dampened finger to figure out how the wind was blowing" feel to it, the designers never thought of it in terms of feedback and stability but it appeared to work because a fast network disguised all of its inefficiencies and shortcomings. Once it started being used on real networks with real (and often asymmetrical) latency it exhibited stability problems. These were fixed by the time honored practice of sligging things -- timers to slow things down (the rough equivalent of covering an unstable analog circuit with capacitors in the hope that it will eventually work properly).

To add to the kludge the FTP protocol introduced the idea high level framing to convert the stream back into datagrams. This protocol -- those three digit numbers at the start of frames -- spilled over to HTTP which provided the foundation for the Web and thus most Internet traffic.

Relatively few people have implemented TCP from the ground up so don't see it in all its gory detail. They just know it as a "reliable protocol". It really is not, it requires all sorts of user level care and feeding to work reliably (dropped links and so dangling ports are a perennial problem). The simpler datagram oriented alternative, UDP, works well for nearly all applications.

[Anonymous Coward]

Re: TCP Was Always an Abomination

TCP was designed primarily to emulate the operation of a serial console over a network. The design had a distinctly "hold up a dampened finger to figure out how the wind was blowing" feel to it, the designers never thought of it in terms of feedback and stability but it appeared to work because a fast network disguised all of its inefficiencies and shortcomings. Once it started being used on real networks with real (and often asymmetrical) latency it exhibited stability problems. These were fixed by the time honored practice of sligging things -- timers to slow things down (the rough equivalent of covering an unstable analog circuit with capacitors in the hope that it will eventually work properly).

yet here we are in 2026 & Tcp is still running the show since flag day in Jan 1st 1983. 43 years is a good innings for something described as an abomination & kludge.

whats your alternative|?

[Roland6]

Re: TCP Was Always an Abomination

>” whats your alternative|?”

Way back, possibly early 1990s, I started referring to TCP/IP as the QWERTY keyboard of networking. Ie. Love it or loath it, you just have to get used to living with it.

As for an alternative, ISO OSI isn’t one, as it is rooted in early 1980’s network thinking. Thus we are back to sending the boffins away and blue sky for 10+ years, in the expectation that what ever they come back will present us with a variant of the IPv4 to IPv6 migration problem…

[Roland6]

Re: TCP Was Always an Abomination

>” but it appeared to work because a fast network disguised all of its inefficiencies and shortcomings”

Fast? Surely you meant the slow, high latency WAN connections that formed the ARPANET.

With the increase in network speeds, there has been a steady stream of RFC’s sorting out many of the shortcomings. QUIC, whilst often positioned as a replacement for TCP and thus be regarded as another fix (to TCP), whereas in reality it adds connection management and orchestration - functionality missing from the long established TCP/IP protocol suite, but needed by modern webpages (and applications) that draw content from multiple sources for presentation.

[trindflo]

disappointing

I was hoping to hear about proposals to secure the internet by improving the TCP/IP the internet runs on. Turns out this is only about a stripped down protocol designed to run in data centers in order to improve AI performance ... in hacking other AI systems running in the same datacenter?

[Random as if !]

Like Electricity

But unregulated, lying AI electeicity from 110v through 415v and back, as its all good, innit?

[mevets]

Is the little endian of homa maho?

I think `maho` would be more likely to be adopted; because it is funny, if insensitive.

I don't think you need to be a belly scratching nerd at the Stanford centre for the criminally insane to understand that the connection problem is not about checksum efficiency.

Yes, we all read the end-2-end essay decades ago.

As a rebut, it has taken nearly 40 years to have a reasonable software interface to enable a user to connect to the internet without a soul destroying video that amounts to menu-picking.

How long will it take for `MaHo` to reach this integration?

I am certain that there is a new wave of plumbers that want to replace the fundamental mechanics of toilets, drains, and whatever else goes on down there.

I am equally sure that they passionately believe the new version of managing effluent dispersal will improve everyone's life.

Best of luck.