Russ

Author Archives: Russ

Research ‘net 0x1339ED3: Traffic engineering versus network complexity

Since spending quality time with complexity theory when writing Navigating Network Complexity, I’ve started seeing the three sided complexity problem crop up all over the place. Remember this? Fast, high quality, cheap: choose two. We face this problem in a number of ways in network design. A recent (last year) paper by researchers from University of Louvain, ETH Zürich and Princeton have figured out how to engineer traffic in a straight IP network (no MPLS) by injecting false nodes into the shortest path tree. You can read the paper here, and listen to Ivan’s podcast with one of the authors here.research-net

What’s interesting to me is the direct tradeoff this paper represents between the amount of state in the control plane and optimal traffic flow through the network. Adding state does, in fact, allow you to optimize traffic flow—at the cost of calculating the state and injecting it into your control plane (in this case OSPF). This state must be carried through the network, increasing the amount of state in the network, and it must change as traffic flows change, increasing the speed at which the state changes in the network. Finally, this idea opens up a new interaction surface Continue reading

Security ‘net 0x1339ED2: Security begins with you

I’m a couple of days late with this post for Data Privacy Day,, but not too late for Data Privacy Month (February). I wanted to highlight it anyway (and maybe I’ll put it on my calendar so I don’t forget next year). The point, of course (“you don’t need to have a point to have a point”) is that each and every one of us—that’s you and I, in case you’ve not gotten it yet—need to take security seriously. Security begins with you. To this end, the Cloud Security Alliance has a good post up on what you can do to improve data privacy.

Why are end users so mistake-prone? Because, frankly, most don’t care. They think data security is IT’s problem—that if IT does its “job” and filters out the threats, they have nothing to worry about. Moreover, when they do something stupid, they think it’s IT’s job to come to the rescue. They don’t understand the risks they create for the company or the fact that once rung they can’t unring the bell. So, they go on ignoring security policies and finding creative workarounds for security measures that inconvenience them—such as utilizing “shadow IT.”

Continue reading

Technology ‘net 0x1339ED1: Cloudy Business Cycles

The cloud is definitely having an impact on business cycles, but how much? There are at least two sides to this story; let’s take a look at both. First there is the continued growth of Amazon Web Services (AWS). According to the Next Platform, this chart represents the various options for the growth of AWS over the next decade or so:

aws-financials-revenue-forecast-log

It looks like, based on this projection, that AWS can keep growing at a fairly strong pace for a while yet longer. Of course, there are many factors that might impact this growth. For instance, one thing the original post points out is that recessions slow down spending in fixed IT and drive up spending in flexible IT. A recession, then, might improve the bottom line for AWS. The opposite of this, however, is that when companies can afford to build infrastructure, they tend to. There are, believe it or not, still justifications for building your own data center, especially if you can afford it.

There are other points to consider, however, as well, in the relationship between the network and business cycles. For instance, if open source and white box start bleeding out of the largest networks into Continue reading

Cultivate questions

Imagine that you’re sitting in a room interviewing a potential candidate for a position on your team. It’s not too hard to imagine, right, because it happens all the time. You know the next question I’m going to ask: what questions will you ask this candidate? I know a lot of people who have “set questions” they use to evaluate a candidate, such as “what is the OSPF type four for,” or “why do some states in the BGP peering session not have corresponding packets?” Since I’ve worked on certifications in the past (like the CCDE), I understand the value of these sorts of questions. They pinpoint the set and scope of the candidate’s knowledge, and they’re easy to grade. But is easy to grade what we should really be after?

Let me expand the scope a little: isn’t this the way we see our own careers? The engineer with the most bits of knowledge stuffed away when they die wins? I probably need to make a sign that says that, actually, just to highlight the humor of such a thought.

The problem is it simply isn’t a good way to measure an engineer, including the engineer reading this Continue reading