CONTENT TYPE
The Hedge 66: Daniel Migault and the ADD Working Group
The modern DNS landscape is becoming complex even for the end user. With the advent of so many public resolvers, DNS over TLS (DoT) and DNS over HTTPS (DoH), choosing a DNS resolver has become an important task. The ADD working group will, according to their page—
In this episode of the Hedge, Daniel Migault joins Alvaro Retana and Russ White to discuss Requirements for Discovering Designated Resolvers, draft-box-add-requirements-02.
Agglutinating Problems Considered Harmful (RFC2915, Rule 5)
In the networking world, many equate simplicity with the fewest number of moving parts. According to this line of thinking, if there are 100 routers, 10 firewalls, 3 control planes, and 4 management systems in a network, then reducing the number of routers to 95, the number of firewalls to 8, the number of control planes to 1, and the number of management systems to 3 would make the system “much simpler.” Disregarding the reduction in the number of management systems, scientifically proven to always increase in number, it does seem that reducing the number of physical devices, protocols in use, etc., would tend to decrease the complexity of the network.
The wise engineers of the IETF, however, has a word of warning in this area that all network engineers should heed. According to RFC1925, rule 5: “It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.” When “conventional wisdom” and the wisdom of engineers with the kind of experience and background as those who write IETF documents contradict one another, it is worth taking a deeper look.
A good place to begin is with other RFCs that might provide examples, or otherwise shed light on this situation. Two of particular interest are RFC1776 and RFC3093.
RFC1776 describes a very simplified transport protocol for use in the Internet and private networks. In normal packet formats there are many different components, such as a header and data sections. The header is normally made up of many different fields, such as the source address, the destination address, the quality of service, etc. The data section of the packet may also be divided into many different fields providing information for such functionality as error detection, flow control, and indicators of which application on the destination host this information is destined to (the port number is an example).
The authors of RFC1776 decided that the wisdom of making a single appliance which provides many services, the firewall being the classic example, and the wisdom of using a single protocol for everything, for instance using BGP for data center fabrics and interdomain connectivity, should be applied fully to the formatting of transport packets. In the spirit of agglutination common to all network engineering, RFC1776 recommends replacing the entire contents of a transport packet with a single address. The address must be a bit longer, of course, to carry the actual data, but using a single large field is inherently simpler than using many different fields. To accomplish this task, RFC1776 specifies a packet with 1696 octets (bytes) of address space. The number of octets originally selected is compatible with ATM, an older technology which uses a 53-octet cell but should also be compatible with all modern transport systems.
While the many advantages of this system are not fully described in the specification, it should be obvious packets containing a single field—the destination address—will be easier to hosts to generate and transmit, and easier for hosts to receive and process. The entire processing of the packet will just be transferring the address field directly into memory for consumption by any application running on the host that desires to consume it. The specification does note, however, that security is much simpler because there is no “user data” to secure.
RFC3093, a more recent example of agglutination in order to simplify network design and operation. This authors of this RFC note that applications are already moving to using a single port, 80, for all traffic, as most firewalls already pass traffic transmitted through this port without restrictions. The authors note the operation of the Internet would be much simpler if all applications ran over port 80. In this way, all applications could pass through firewalls without modification, while the firewalls themselves remain perfectly operational, fulfilling their intended purpose. Implementing this specification would also simplify the absolute mess of port and protocol numbers used in transporting data today, agglutinating them all down to a single port. As less is always simpler, this would create a simpler, easier to manage, global Internet.
The lessons to learn, after examining the options, may not be what was originally intended. Reducing the number of parts does not necessarily reduce the complexity of the overall system. If you haven’t found the tradeoffs, you haven’t looked hard enough.
Focus is a Virtue
The modern world craves our attention—but only in short bursts. To give your attention to any one thing for too long is failing, it seems, because you might miss out on something else of interest. We have entered the long tail of the attention economy, grounded in finding every smaller slices of time in which the user’s attention can be captured and used.
The problem is obvious for anyone with eyes to see. What is the solution? The good news is there are solutions. The bad news is these solutions are swimming upstream against the major commercial interests of our day, so it’s going to take work and determination. The problems are platform based, while the solutions are personal and hard.
Begin here—treat focus as a virtue. We normally think of virtues as things like being kind, or giving money to charity, or (in the modern world) signaling that we support the right things and think the right way. But virtue reaches far deeper than just believing the right things or being “nice.”
Sertillanges, in The Intellectual Life, says the virtues are bound together. A person with only one virtue will often find that virtue twisted into something it is not. A clump of trees, no matter how small, is more likely to survive a storm than the singular tree, no matter how strong the single tree might be. You must not only develop the virtue of quick thinking, or of curiosity, but also of focus. \
How do you develop focus? I can tell you the wrong way: try to make yourself focus for a long period of time. Maybe this will work for some people but forcing attention onto a single topic often backfires in very spectacular ways.
Instead, I would counsel a two-step program: eliminate distractions and expand slowly.
Sertillanges says, “As to the public, if it sometimes stimulates, it often disturbs, scatters the mind; and by going to pick up two pennies in the street, you may lose a fortune.” What is social media other than “the public?” Simply having too much information to hand can also be problematic, as well—”There are books everywhere and only a few are necessary.”
A distraction people don’t often think about is reading too many books at once. Most of the people I know are reading (if they are, really) five or ten books at once. They switch back and forth between books, picking up a little here and a little there. It’s a dandy application of multitasking to an old technology.
But I don’t think it actually works. Pick up a book and read it. Learn to follow the line of a single argument from start to finish. I find it helpful to outline information-rich books, or books that have complex lines of argument. The act of rethinking what the author is saying, and rebuilding their line of thought, is really helpful.
As for expanding slowly, this means two things. First, don’t try to jump from a six-minute attention span to an hour-long attention span in a day. Try to go from six minutes to eight, and then eight to twelve, etc. Don’t try to have an infinite attention span, either—it just is not humanly possible. Setting unrealistic goals is a recipe for failure.
Second, expand slowly by building mental maps, rather than trying to consume the outer shell first. The outer shell (“what does this command do?”) might be the most immediately useful, but if you stay on the outer shell your entire life, jumping all over the place to find the next bit of useful information, you’re never going to learn to focus.
Further, if you jump all over the place, you’re never going to build the mental maps that will allow you to focus. When I first started reading philosophy, I was often more confused than anything else. It was like jumping into the middle of a conversation—there were (and still are) terms and ideas I had no idea how to relate to. Over time, I built a mental map. While I’m still not able to read philosophy (or theology) like many of my friends who have spent their lives reading this stuff, I am at least becoming somewhat competent.
So… slow down. Remove distractions. Set goals. Build mental maps.
If you want to find the path to success in life, it is going to be through focus.
The Hedge 67: Daniel Beveridge and the Structure of Innovation
Innovation and disruption are part the air we breath in the information technology world. But what is innovation, and how do we become innovators? When you see someone who has invented a lot of things, either shown in patents or standards or software, you might wonder how you can become an innovator, too. In this episode of the Hedge, Tom Ammon, Eyvonne Sharp, and Russ White talk to Daniel Beveridge about the structure of innovation—how to position yourself in a place where you can innovate, and how to launch innovation.
IPv6 Buzz: Is IPv6 Baked Enough?
I was recently a guest on the IPv6 Buzz podcast. Ed, Scott, Tom, and I talk about IPv6 operational maturity, IPv6 standards, and the IETF process. This was a great episode, you should really listen to it … and listen to IPv6 Buzz in general.
The Hedge 66: Tyler McDaniel and BGP Peer Locking
Tyler McDaniel joins Eyvonne, Tom, and Russ to discuss a study on BGP peerlocking, which is designed to prevent route leaks in the global Internet. From the study abstract:
Technologies that Didn’t: ARCnet
In the late 1980’s, I worked at a small value added reseller (VAR) around New York City. While we deployed a lot of thinnet (RG58 coax based Ethernet for those who don’t know what thinnet is), we also had multiple customers who used ARCnet.
Back in the early days of personal computers like the Amiga 500, the 8086 based XT (running at 4.77MHz), and the 8088 based AT, all networks were effectively wide area, used to connect PDP-11’s and similar gear between college campuses and research institutions. ARCnet was developed in 1976, and became popular in the early 1980’s, because it was, at that point, the only available local area networking solution for personal computers.
ARCnet was not an accidental choice in the networks I supported at the time. While thinnet was widely available, it required running coax cable. The only twisted pair Ethernet standard available at the time required new cables to be run through buildings, which could often be an expensive proposition. For instance, one of the places that relied heavily on ARCnet was a legal office in a small town in north-central New Jersey. This law office had started out in an older home over a shop in the square of a smaller town—a truly historic building well over a hundred years old. As the law office grew, they purchased adjacency buildings, and created connecting corridors through closets and existing halls by carefully opening up passages between the buildings. The basements of the buildings were more-or-less connected anyway, so the original telephone cabling was tied together to create a unified system.
When the law office decided to bring email and shared printers up on Novell Netware, they called in the VAR I worked for to figure out how to make it all work. The problem we encountered was the building had been insulated at some point with asbestos fiber filling in the walls. Wiring on the surface of the walls and baseboards was rejected because it would destroy the historical character of the building. Running through the walls would only be possible if the asbestos was torn out—this would be removing the walls, again encountering major problems with the historical nature of the building.
The solution? ARCnet can run on the wiring used for plain old telephone circuits. Not very fast, of course; the original specification was 2.5Mbit/s. On the other hand, it was fast enough for printers and email before the days of huge image files and cute cat videos. ARCnet could also run in a “star” configuration, which means with a centralized hub (which we would today call a switch), and each host attached as a spoke or point on the star. This kind of wiring had just been introduced for Ethernet, and so was considered novel, but not widely deployed.
ARCnet deployed to well over ten thousand networks globally (a lot of networks for that time period), and then was rapidly replaced by Ethernet. The official reason for this rapid replacement was the greater speed of Ethernet—but as I noted above, most of the applications for networks in those days did not really make use of all that bandwidth, even in larger networks. Routers were not a “thing” at this time, but you could still connect several hundred hosts onto a single ARCnet or Ethernet segment and expect it to work with the common traffic requirements of the day.
At the small VAR I worked at, we had another reason for replacing ARCnet: it blew up too much. The cables over which POTs services run is unshielded, and hence liable to induced high voltage spikes from other sources. For instance, we had to be quite intentional about not using a POTs lines located within a certain distance of the older wiring in the buildings where it was deployed; a voltage spike could not only cause the network to “blank out” for some amount of time, it could actually cause enough voltage on the wires to destroy the network interface cards. We purchased ARCnet interface cards by the case, it seemed. After any heavy thunderstorm, the entire shop went from one ARCnet customer to another replacing cards. At some point, replacing cases of interface cards becomes more expensive than performing asbestos mitigation, or even just running the shielded cable Ethernet on twisted pair requires. It becomes cheaper to replace ARCnet than it does to keep it running.
An interesting twist to this story—there is current work in the Ethernet working group of the IEEE to make Ethernet run on … the cabling used for very old POTs services. This is effectively the same use case ARCnet filled for many VARs in the late 1980’s. The difference, today, is that much more is understood about how to build electronics that can support high voltage spikes while still being able to discriminate a signal on a poor transmission medium. Much of this work has been done for the wireless world already.
So ARCnet failed more because it was a technology ahead of its time, in terms of its use case, but in line with its time, in its physical and electronic design.