Working system that has just done the job for 40 years to be superseeded by some complex, process intensive turdulence that does NOTHING except crash regularly, fail to do the job and requires patching every week until it almost works when it will be replaced by something even worse.

It works, leave the fucking thing alone.

Ir's attitudes like that which keep COBOL programmers in business (and I should know since I benefitted from them).

Good thing, too. COBOL programmers keep business world-wide running.

The job TCP was designed to do, has done and continues to do is to provide what looks like a reliable connection over a wide-area network which was not necessarily reliable and just fired packets around which is not a connection-oriented thing. There was always UDP as an alternative, relying on higher level protocols to fix up the reliability bit if it was needed.

In an environment where the connectivity can be taken for granted TCP isn't necessary so they could have been using UDP anyway although I doubt that that's what he's suggesting.

We use TCP/IP on our LANs because it's there and easier than having to worry about whether your printer is local rather than in head office 2000 miles away. It's worth remembering that your LAN's TCP packet, inside which your data sits, itself sits inside an IP packet which is designed to be routed over a WAN even though it's delivered locally inside and that sits inside an Ethernet packet. If this is using point-to-point fibre it won't need the IP packet or the Ethernet packet.

Before that there were other networking protocols for local networks so in a sense it goes back to those days.

@Doctor Syntax - "easier than having to worry about whether your printer is local rather than in head office 2000 miles away"

So no worries walking 2000 miles to pick up your printout?

Printing is one of the few tasks where knowing the location of the device serving you is always going to be significant.

icon - I'll just pick on the poorly-chosen example and ignore the significant points.

Singing Oh, I would walk 500 miles, and I would walk 500 more, just to be the man to walk 1000 miles and go "PC LOAD LETTER?!?!?!?!? WHAT THE F-"

Mines the one with The Proclaimers embroidered on the back.

> We use TCP/IP on our LANs because it's there and easier than having to worry about whether your printer is local rather than in head office 2000 miles away.

I think you are getting confused, yes we use TCP/IP across our LANs and WANs, however to resolved the local/remote printing problem we use services based on mDNS such as Bonjour, which locate devices such as printers on the same network segment as your computer; the computer transfers the print job to the printer via TCP/IP using Airprint, Mopria etc..

The only problem is with RDS servers either not correctly detecting the site a user is connecting from or the user selecting their favourite printer, forgetting they aren't actually at that site...

No, not quite at all.

My secondary shell is Wireshark, and I've been doing network programming since, ah, 1992 or so. There is much to be desired about what is going on upon the wires. The TCP start takes three packets before the actual data stream starts. If it's a secure connection, then more packets are exchanged. As the stream progresses, acknowledgement packets must be sent back relatively frequently, enough to be a burden on the traffic.

The RFCs have plenty of solutions that have been tried over the years. Simply using UDP can be just fine, but all of this takes programmers who really know their stuff. Bluffing doesn't cut it with network performance.

I haven't read all of John Ousterhout's paper, but there isn't anything in there about HOMA being published in an RFC. At least there's a GitHub project: https://github.com/PlatformLab/Homa

For most programs, the abstraction offered by TCP is just a reliable stream (pipe) between two endpoints that can be addressed by a short piece of text.

If you have the source code, it really wouldn't be hard to slip in an alternative "reliable stream" transport protocol.

I think it interesting that they've identified a stream transport as a problem. If one looks at how we actually use networks, it's via libraries like ZeroMQ, or (as the paper / article states) some sort of RPC, etc. All of these synthesize a message passing paradigm on top of a stream protocol. Even "streaming" of media these days boils down to discrete https transfers of files - messages - rather than having a continuously open socket through which bytes are streamed. Programming with a raw socket is a battle for the developer to synthesize a message protocol on top of tcp.

So it is perhaps a good idea to bump that message paradigm down a few layers, get some benefits from having done so.

The peak of folly will be somewhere having to transistion between Homa - a message orientated transport - to http - a message/file orientated protocol built on top of a streaming transport like tcp. Could make for a very busy edge of one's data centre.

ZeroMQ is it. I was going to bring this up myself but you already nailed it. I don't know why anyone would use some "HAMA" when tools like ZeroMQ are available. And thing about ZeroMQ is, you don't have to run it on top of TCP. Implement it exactly as you want to take advantage of your network microcosm.

That's it. These problems are already solved. and RPC of all things is hardy generic data transport. So you want to write an application without using TCP? Go right ahead. It sure as hell isn't going to replace TCP!

Perhaps the problem is we don't have 7 whole layers to play with any more like we did with OSI.

If I understand correctly ZeroMQ doesn't actually do transport, hence HOMA would be just another transport sitting under ZeroMQ.

I'm old enough to recall multiple network protocols on PCs and servers. It wasn't that big a deal, and with modern hardware ought to be straightforward enough. Its very easy to believe that there can be a better protocol than TCP for short range high speed networking.

In many ways, it's surprising TCP has survived as long as it has - and more so that we've got this far with essentially one network protocol and one transport protocol and that they've provided a sufficiently adequate basis for everything from e-mail to high definition video streaming and the transition from noisy, slow analogue lines to fibre.

It's not just that there are transport protocols better suited to data centre operations. IP (whether v4 or v6) combined with Ethernet framing (and the consequent need for mapping between datalink and network layer addresses) is less than optimal too. The requirement is for something that functions much more like a bus or backplane interconnect than a general purpose network.

One of the (ultimately doomed) innovations of DECnet Phase V was that the equivalent of DNS recorded the protocol stacks available on the target host (at least a network layer and transport layer) and the resolver would return the protocol stack(s) that were mutually supported by the communicating parties along with the addressing information for each layer. Sounds like an idea whose time might finally have come.

Why not use UDP if the congestion avoidance and resending of packets is their issue? Or is it is just the congestion avoidance but they want the resending of packets to happen in the rare cases they are lost, RDP (reliable datagram protocol)

What are the advantages of their new thing supposed to be, aside from not being supported by any layer 3 switch in the world?

At a guess I would say they are interested in at least the following:

Reducing the time between the network stack receiving data from the application and it being sent out on the network. (TCP has the NODELAY option to disable the Nagle algorithm and remove the default 200ms delay that every send call incurs otherwise.)

Reducing the 20 byte header sent with every TCP packet.

Removing the need for every packet to be acknowledged by the receiver.

My title isn't fair - replacing Ethernet would be a major, major change.

These days the key thing that makes performance increase is development in switch chips - be it for Ethernet or Infiniband or whatever. The price of developing a new one is very high, and there needs to be a very large market to justify it.

There are alternatives to Ethernet, e.g. RapidIO. This always used to outstrip contemporary Ethernet, and was found largely high performance embedded processing systems, often for military applications. It reached a dead end, because to develop a new version of it and actually design the necessary switch chips was too much for the military market to bear. So, now it's all Ethernet. But it's a pity - with a proper peripheral for it transfer latencies were 75ns (from sending application's memory buffer, to the first bytes starting to show up in the destination application's memory buffer on another computer).

When one looks at the most impressive super computers - e.g. Japan's Fugaku - the thing that makes them stand out is the inter-compute node transport. For Fugaku, the transport (called Tofu) is built directly into the processor chips, hotwired to the memory bus, with huge bandwidths, lots of point to point interconnect topology, and lowest possible latency.

Each processor node is also a network switch, in the 6dimensional hypertoroid and 4dimensional hypercube of point to point links between processors. It's bumping the job of network routine all the way back up to the application layer. When one thinks about it, a classic Ethernet router is kind of a sop for developers; packets fired into the network will eventually get to where they're going, but the developer isn't telling the router in advance what to expect, it has to work that out as and when stuff turns up. Whereas making the software developer do the routing themselves means that the routing that gets done is optimisable around the application needs. This is hard on developers - Fugaku and K were / are apparently quite hard to develop for - but that's where you have to go to reach ultimate peforamance.

You can think of a super computer these days as the ultimate design of a datacentre, and data centres are going to have to copy them.

TCP was the thing we "slipped in" to make local calls over simple sockets work of the long distances of the ARPAnet. The HPC crowd(called them kids at the time, when I was still a younger man) have been doing the same thing for the various MPI generations since forever. If you can think of a wacky high bandwidth technology, they have ported a stack to it a tested it at least. SerDes? Who needs the other side of the SFP, check. PCI-E? Just build an interposer to bridge those lanes, check. Thunderbolt 400 cables in a compact 3-d torus connecting nodes in a Beowulf cluster? The cables were damn short but it was fun in the late 90's, 10-4 on the 1394 good buddy.

I remember the team having to explain to a Java programmer that had joined us that there was more than one kind of socket, and that UNIX sockets were a thing. If you haven't already been using short haul technologies, you may have left a ton of performance on the table. That said, many of these solutions were very brittle, taking custom drivers on specific hardware, or were eye wateringly expensive to buy as off the shelf parts, but there are 31 flavors of socket/RDMA/RPC/MPI layers out there already.

If this new proposal leads to a fast local link technology in the 10-30m range that is reasonably priced and not direct link only, it may be a welcome addition, though in the end people will just write a TCP stack on top of it, so you may as well assume you have a three piece project, a transport layer(one that isn't solely optimized for TCP), a fast message passing stack that favors smaller messages that may sacrifice some things like order of delivery or reliable delivery, and because some idiot will do it anyway, am overlay stack that provides ip services, as you will end up bridging these zones somehow and hand having to route them in a virtualized network, even if there is a performance hit.

From the paper, I feel like the author scores there best hits with discussion of the problems cause buy the streaming model and the legacy of the OSI layer model. Performance dictates that devices close to wires and metal benefit from being able to make smart choices for routing, instead of being dumb and blind and leaving those decisions to higher levels of the stack. While the claims TCP is "beyond repair" are an apparent attempt to get cheap heat, I agree that it's cleaner to design a parallel stack that people can choose to use as needed then to try to force TCP to change to meet their specific demands. The long push is getting buy in from enough big players to make this version relevant, stable, and reasonably priced. Though due to the choices the author made for the Homa stack there may be reasons to rely on other link architectures to push large messages or data streams. That and there a couple of places where the protocols assumptions could lead to fun behavior in the event of a bad acting host. In any event, I think what we are building towards is a network with more parallel transports that are well develped. Right now TCP can be generally assumed, and UDP is similarly pervasive. We need to raise the best of breed of some of the others to the same level, not sure if Homa will make the cut, but it seems designed to be good where the others are weakest, so there may be a place for it or something very like it. That said, there are standards aplenty.

Having now read the paper and scanned the github repo, it looks to me like the goal is not to replace TCP in general, but to only replace TCP within a well-controlled data-centre network.

For starters, it only supports ipv4 addressing (in 2022 that seems odd unless it's in a closed network environment) and it relies on things like DSCP markings to survive transit between end-points.

Is that the reading that other people are getting, or have I missed something?