Holy Wars
Great article. However in defence of ATM, it was designed to allow highly efficient hardware switching and therefore high throughput. It was designed around the limitations of the day, but as general purpose processors became more powerful and more of the stack could be done in software that need waned
Not really. I still argue that MPLS is kinda ATM's revenge. ATM was designed to replace circuit switched networks, support Multiple Protocols (hint, hint) and perhaps most importantly, provide some deterministic behaviour. But ATM was complicated, scarey, and a lot of the net-heads didn't understand it. So then as the article says, it often came down to cell tax..
Saying that the TCP/IP protocol has a lot to be blamed for. The fixed header, poorly defined elements etc has meant over the years it has been abused that has led to a spaghetti of work arounds.
Such is the nature of network engineering. Like the cell tax argument was mostly true, but the fault of the IP headers being so damn fat.. And mostly unused, and became even more bloated with IPv6. Plus curiosities inherited from the DoD days, where sender was more important than recipient, so source address came first. Then stuff like this-
https://en.wikipedia.org/wiki/Differentiated_services
DiffServ uses a 6-bit differentiated services code point (DSCP) in the 6-bit differentiated services field (DS field) in the IP header for packet classification purposes. The DS field, together with the ECN field, replaces the outdated IPv4 TOS field
Which then allowed marketing types to look at... 64 classes of service! Make it so! This differentiates our service compared to our competitors who only offer 5! And then generally ignoring boring details like explaining how CoS really works, configuring it, training support to handle calls about packets ending up in the bit-bucket or why 64 classes don't really matter when there's only maybe 4 hardware queues.
And at the same time-
https://en.wikipedia.org/wiki/Type_of_service
Prior to the redefinition, the ToS field could specify a datagram's priority and request a route for low-latency, high-throughput, or highly-reliable service. Based on these ToS values, a packet would be placed in a prioritized outgoing queue, or take a route with appropriate latency, throughput, or reliability.
So ToS was actually rather useful, at least within a service provider's domain, but rarely got implemented. Despite my best <cough> efforts. And it was much the same with ECN. A rather handy thing to know, but became 'obsoleted' with the introduction of DSCP.. Just as VoIP was coming along and a firehose of UDP traffic aimed in the general direction of the bit bucket, even if that was given EF. And then there were VPNs, so FUN! with more headers, and trying to cram those down other L2VPNs. And then having to explain to customers that a 1500byte packet ain't going to fit down an xDSL circuit with a 1492byte MTU, and if you've set the DF bit, it's going to end up in the bit bucket..
So luckily, and thanks to our dear author, MPLS came along so network engineers could sleep easier. F'it and forward it, along the most appropriate LSP, and all those IP annoyances (mostly) became an edge problem. Gimme a compact & bijou lable with the relevant information and I can forward/switch that faster than routing it. And then for additional FUN!, the Internet became just another VRF.
Which is also getting back to the traceroute thing. As the author says, you can traceroute across LSPs, assuming you know how to drive traceroute. And it's implemented in the MPLS domain, which I'd argue it shouldn't be.. Because a) it gives the switch/routers more work to do and b) as an end-user, what can you do with the output anyway given actionable stuff like IP ToS and ECN have been 'obsoleted'? If a switch (router) or circuit is having a bad day, then floods of ICMP traffic needing to be processed might just make that worse. And in a well-behaved (mostly) SP, we already know about the problem(s) and are working on fixing them.
But as an unashamed Bell-head. I love MPLS because I can switch Tbps of traffic, and most of the IP stuff became a software problem. It's still FUN! sometimes because in the kinds of networks I tend to deal with, there's no longer 'The' Internet, but potentially multiple Internets, all happily pretending not to be best-efforts in their own VRFs. But the late, great Jon Postel described the Internet best-
https://datatracker.ietf.org/doc/html/rfc791
The internet protocol does not provide a reliable communication facility. There are no acknowledgments either end-to-end or hop-by-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is no flow control.
But at least MPLS gives us network engineers a fighting chance of managing some of that stuff..