Category: networking fundamentals

The last Fallacy of Distributed Computing I addressed in the introductory part of How Networks Really Work webinar was The Network Is Homogenous. No, it’s not and it never was… for more details watch this video.

One of the most annoying part in every training content development project was the ubiquitous question somewhere at the end of the process: “and now we’d need a few review questions”. I’m positive anyone ever involved in a similar project can feel the pain that question causes…

Writing good review questions requires a particularly devious state of mind, sometimes combined with “I would really like to get the answer to this one” (obviously you’d mark such questions as “needs further research”, and if you’re Donald Knuth the question would be “prove that P != NP”).

Avery Pennarun continued his if only IPv6 would be less academic saga with a must-read IPv4, IPv6, and a sudden change in attitude article in which he (among other things) correctly identified IPv6 as a typical example of second-system effect:

If we were feeling snarky, we could perhaps describe IPv6 as “the String Theory of networking”: a decades-long boondoggle that attracts True Believers, gets you flamed intensely if you question the doctrine, and which is notable mainly for how much progress it has held back.

In the end, his conclusion matches what I said a decade ago: if only the designers of the original Internet wouldn’t be too stubborn to admit a networking stack needs a session layer. For more details, watch The Importance of Network Layers part of Networks Really Work webinar

In early April 2020 I ran another live session in my How Networks Really Work webinar. It was supposed to be an easy one, explaining the concepts of packet forwarding and routing protocols… but of course I decided to cover most solutions we’ve encountered in the last 50 years, ranging from Virtual Circuits and Source Route Bridging to Segment Routing (which, when you think about it, is just slightly better SRB over IPv6), so I never got to routing protocols.

That webinar was supposed to be an introductory one, but of course I got pulled down all sorts of rabbit trails, and even as I was explaining interesting stuff I realized a beginner would have a really hard time following along… but then I silently gave up. Obviously I’m not meant to create introduction-to-something material.

It’s incredible how many people assume that The Internet is a thing. In reality, it’s a mishmash of interconnected independent operators running mostly on goodwill, misplaced trust in other people’s competence, and (sometimes) pure dumb luck.

I described a few consequences of this sad reality in the Internet Has More than One Administrator video (part of How Networks Really Work webinar), and Nick Buraglio and Elisa Jasinska provided even more details in their Surviving the Internet Default-Free Zone webinar.

Way too many people still believe in Security Fairy (the mythical entity that makes your application magically secure), fueling the whole industry of security researchers who happily create excruciatingly detailed talks of how you can use whatever security oversight to wreak havoc (even when the limitations of a technology are clearly spelled out in an RFC).

In the Networks Are Not Secure (part of How Networks Really Work webinar) I described why we should never rely on the network infrastructure to provide security but have to implement it higher up in the application stack.

A lot of people are confused about the roles of network layers (some more than others), the interactions between MAC addresses, IP addresses, and TCP/UDP port numbers, the differences between routing and bridging… and why it’s so bad to bridge across large distances (or in large networks).

I tried to explain most of those topic in How Networks Really Work webinar (next session coming on April 2nd), but as is usually the case someone did a much better job: you MUST READ the poetic and hilariously funny World in which IPv6 was a good design by Avery Pennarun.

After decades of riding Moore’s law curve, the networking bandwidth should be (almost) infinite and (almost) free, right? WRONG, as I explained in the Bandwidth Is (Not) Infinite and Free video (part of How Networks Really Work webinar).

There are still pockets of Internet desert where mobile- or residential users have to deal with traffic caps. If you decide to move your applications into any public cloud you better check how much bandwidth those applications consume, or you’ll be the next victim of the Great Bandwidth Swindle, for more details, watch the video.

After the “shocking” revelation that a network can never be totally reliable, I addressed another widespread lack of common sense: due to laws of physics, the client-server latency is never zero (and never even close to what a developer gets from the laptop’s loopback interface).

After introducing the fallacies of distributed computing in the How Networks Really Work webinar, I focused on the first one: the network is (not) reliable.

While that might be understood by most networking professionals (and ignored by many developers), here’s an interesting shocker: even TCP is not always reliable (see also: Joel Spolsky’s take on Leaky Abstractions).

What better way to start How Networks Really Work webinar than with fallacies of distributed computing… and that’s exactly what I did in late August 2019.

Original TCP/IP and OSI network stacks had relatively clean layered architecture (forgetting the battle scars for the moment) and relied on end-to-end principle to keep the network core simple.

As always, no good deed goes unpunished - “creative” individuals trying to force-fit their misdesigned star-shaped pegs into round holes, and networking vendors looking for competitive advantage quickly destroyed the idea with tons of middlebox devices, ranging from firewalls and load balancers to NAT, WAN optimization, and DPI monstrosities.

Russ White wrote a great blog post explaining why you have to understand the problem you’re solving instead of blindly believing the $vendor slide deck… or as I said a long time ago, think about how you’ll troubleshoot your network in because you won’t be able to reformat it once it crashes.

The previous videos from the How Networks Really Work webinar covered an overview of networking challenges and the importance of networking layers.

Now it’s time to put it all together.

A subscriber sent me this intriguing question:

Is it not theoretically possible for Ethernet frames to be 64k long if ASIC vendors simply bothered or decided to design/make chipsets that supported it? How did we end up in the 1.5k neighborhood? In whose best interest did this happen?

Remember that Ethernet started as a shared-cable 10 Mbps technology. Transmitting a 64k frame on that technology would take approximately 50 msec (or as long as getting from East Coast to West Coast). Also, Ethernet had no tight media access control like Token Ring, so it would be possible for a single host to transmit multiple frames without anyone else getting airtime, resulting in unacceptable delays.