Nines are not enough
How many 9’s is your network? How about your service provider’s? Now, to ask the not-so-obvious question—why do you care? Does the number of 9’s actually describe the reliability of the network? According to Jeffery Mogul and John Wilkes, nines are not enough. The question is—while this paper was written for commercial relationships and cloud providers, is it something you can apply to running your own network? Let’s dive into the meat of the paper and find out.
While 5 9’s is normally given as a form of Service Level Agreement (SLA), there are two other measures of reliability a network operator needs to consider—the Service Level Objective (SLO), and the Service Level Indicator (SLI).
Weekend Reads 012420
There is a lot of public sentiment against placing small cell sites on residential streets. There is a particular fear of broadcasting higher millimeter wave frequencies near to homes since these frequencies have never been in widespread use before. —Doug Dawson
The Hedge Podcast Episode 19: Optional Security is not Optional
The History of Programmable Control Planes
On this episode of the History of Networking, organized through the Association of Computing Machinery, Jennifer Rexford joins Donald Sharp and Russ White to discuss the history of programmable control planes. Dr. Rexford is the Gordon Y. S. Wu Professor in Engineering at Princeton University in New Jersey.
Knowing Where to Look
If you haven’t found the tradeoffs, you haven’t looked hard enough. Something I say rather often—as Eyvonne would say, a “Russism.” Fair enough, and it’s easy enough to say “if you haven’t found the tradeoffs, you haven’t looked hard enough,” but what does it mean, exactly? How do you apply this to the everyday world of designing, deploying, operating, and troubleshooting networks?
Humans tend to extremes in their thoughts. In many cases, we end up considering everything a zero-sum game, where any gain on the part of someone else means an immediate and opposite loss on my part. In others, we end up thinking we are going to get a free lunch. The reality is there is no such thing as a free lunch, and while there are situations that are a zero-sum game, not all situations are. What we need is a way to “cut the middle” to realistically appraise each situation and realistically decide what the tradeoffs might be.
Weekend Reads 011720
There was a man I saw last week in the Salvador Dali museum, a middle aged tourist in a Nike t-shirt, who acted as if he was doing a scavenger hunt speed-run of the absurd artistic labyrinth designed by the famed artist. His phone camera permanently on, he rushed from framed painting to hand-carved sculpture to meticulously-made mechanical inventions, tapping away at the button to capture the blurry images of ornate creations. —Ben Domenech
All of this fiber activity is going to mean a shortfall of industry resources of all kinds. I’ve already witnessed construction delays in projects this year due to resource shortages and I fear delays will increase in 2020 and beyond. —Doug Dawson
When I walked out the door on my last day as Google’s Head of International Relations, I couldn’t help but think of my first day at the company. I had exchanged a wood-paneled office, a suit and tie, and the job of wrestling California’s bureaucracy as Governor Schwarzenegger’s deputy chief of staff for a laptop, jeans, and a promise that I’d be making the world better and more equal, under the simple but powerful guidance “Don’t be evil.” —Ross LaJeunesse
The Hedge Podcast Episode 18: Programming Fundamentals for Network Engineers
Network engineers do not need to become full-time coders to succeed—but some coding skills are really useful. In this episode of the Hedge, David Barrosso (you can find David’s github repositories here), Phill Simmonds, and Russ White discuss which programming skills are useful for network engineers.
Is it Money, Flexibility, or… ??
Raise your hand if you think moving to platform as a service or infrastructure as a service is all about saving money. Raise it if you think moving to “the cloud” is all about increasing business agility and flexibility.
Put your hand down. You’re wrong.
Let’s be honest. For the last twenty years we network engineers have specialized in building extremely complex systems and formulating the excuses required when things don’t go right. We’ve specialized in saying “yes” to every requirement (or even wish) because we think that by saying “yes” we will become indispensable. Rather than building platforms on which the business can operate, we’ve built artisanal, complex, pets that must be handled carefully lest they turn into beasts that devour time and money. You know, like the person who tries to replicate store-bought chips by purchasing expensive fryers and potatoes, and ends up just making a mess out of the kitchen?
Weekend Reads 011020
The 5G story is everywhere in the American press these days, and not just the American press. You can barely turn around to scratch some needy body part without encountering another article about the wireless telecommunications technology. But the stovepiping in this coverage—the narrowing of the questions asked or answered—is acute. —Adam Garfinkle
First observed in 2009, Slow Drip attacks hit the world stage in a dramatic fashion in early-2014, wreaking havoc on the important middle-level infrastructure of the DNS, particularly on ISPs. Japanese service provider QTNet described the disruption not just of caching resolvers, but of load balancers too. —Renée Burton
On the ‘net: It is always something…
While those working in the network engineering world are quite familiar with the expression “it is always something!,” defining this (often exasperated) declaration is a little trickier. The wise folks in the IETF, however, have provided a definition in RFC1925. Rule 7, “it is always something,” is quickly followed with a corollary, rule 7a, which says: “Good, Fast, Cheap: Pick any two (you can’t have all three).”