In this episode of the Hedge, Geoff Huston joins Tom Ammon and I to finish our discussion on the ideas behind DNS over HTTPS (DoH), and to consider the implications of its widespread adoption. Is it time to bow to our new overlords?
In this episode of the Hedge, Geoff Huston joins Tom Ammon and I to discuss the ideas behind DNS over HTTPS (DoH), and to consider the implications of its widespread adoption. Is it time to bow to our new overlords?
The Transmission Control Protocol, or TCP, is one of the foundational technologies of packet switched networks. TCP not only provides windowed flow control, it also manages the retransmission of data when errors are detected, and sockets for addressing individual applications on a host. Doug Comer was involved in the early development of TCP/IP.
We all use the OSI model to describe the way networks work. I have, in fact, included it in just about every presentation, and every book I have written, someplace in the fundamentals of networking. But if you have every looked at the OSI model and had to scratch your head trying to figure out how it really fits with the networks we operate today, or what the OSI model is telling you in terms of troubleshooting, design, or operation—you are not alone. Lots of people have scratched their heads about the OSI model, trying to understand how it fits with modern networking. There is a reason this is so difficult to figure out.
The OSI Model does not accurately describe networks.
What set me off in this particular direction this week is an article over at Errata Security:
The OSI Model was created by international standards organization for an alternative internet that was too complicated to ever work, and which never worked, and which never came to pass. Sure, when they created the OSI Model, the Internet layered model already existed, so they made sure to include today’s Internet as part of their model. But the focus and intent of the OSI’s efforts was on dumb networking concepts that worked differently from the Internet.
When a recursive resolver receives a query from a host, it will first consult any local cache to discover if it has the information required to resolve the query. If it does not, it will begin with the rightmost section of the domain name, the Top Level Domain (TLD), moving left through each section of the Fully Qualified Domain Name (FQDN), in order to find an IP address to return to the host, as shown in the diagram below.
This is pretty simple at its most basic level, of course—virtually every network engineer in the world understands this process (and if you don’t, you should enroll in my How the Internet Really Works webinar the next time it is offered!). The question almost no-one ever asks, however, is: what, precisely, is the recursive server sending to the root, TLD, and authoritative servers?
YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols, described in RFC7950. The origins of YANG are rooted in work Phil Shafer did in building an interface system for JUNOS. Phil joins us on this episode of the History of Networking to discuss the history of YANG.
The Simple Network Management Protocol, or SNMP, was originally specified in RFC1067, and most recently in RFC1157. The original intent was to make “all IP and TCP implementations be network manageable”—an early form of providing a machine-readable interface so operators could “automate all the things.” Craig Partridge played a key role in the early development and standardization of SNMP; he joins us on the History of Networking to discuss the origins and challenges involved in developing SNMP.
Jeff Tantsura recently co-authored a draft in the IRTF defining some of the concepts and parameters for intent based networking. Jeff joins Tom Ammon and Russ White to dig into this new area, and what it means for networks.
Early in the history of the Internet, there were serious discussions about whether IP or CLNS should be adopted. Dave Piscatello joins this episode of the History of Networking to discuss how and why the decision to standardize on IP was made.
Floating point is not something many network engineers think about. In fact, when I first started digging into routing protocol implementations in the mid-1990’s, I discovered one of the tricks you needed to remember when trying to replicate the router’s metric calculation was always round down. When EIGRP was first written, like most of the rest of Cisco’s IOS, was written for processors that did not perform floating point operations. The silicon and processing time costs were just too high.
What brings all this to mind is a recent article on the problems with floating point performance over at The Next Platform by Michael Feldman. According to the article: