Getting Inside the Loop
Metadata doesn’t just apply to data science or protocols — it applies to engineering life. Think about the concept of epistemology — the study of how we know what we know — or the concept of hermeneutics — the study of how we understand communication — and you can quickly see that stepping outside what we are doing to examine how we are doing it is a common human experience (see Lewis’ Meditation in a Tool Shed as another instance).
But how does this apply to the engineering life? It’s called process — now, before you click off the page, scurrying away in shock, process isn’t a bad thing. In fact, process can be a good set of “guard rails” in the way we live our lives, something to remind us not to run off the road (like positive thinking signs), or even physically/mentally “bump” us in the right direction.
This week I’d like to kick off a short series on one process I learned in the US Air Force, and have used in many ways over the years — the OODA Loop. Originally developed by USAF Colonel John Boyd, and designed to help pilots deal with quick decision making in life-or-death situations, I’ve found this little model, or process, taught to us airfield folks as one of the bits of “combat training,” if we were ever deployed in the line of fire. What is the OODA loop? It’s four steps:
- Observe
- Orient
- Decide
- Act
For this series, I’d like to work through each of these four steps, thinking through what each one might mean in networking. I’ll generally apply the concept to network security, but it can be applied to network management, deployment plans, and a host of other areas.
Let’s begin with observe.
Just open your eyes, right? Not really — especially not in the world of networks engineering. First, what should you observe, and where should you observe it? In some cases, this is the most important question to ask, and the hardest to answer. Should you measure the average traffic flow across specific points in the network? The average jitter across specific points? The average delay? The number of routes in the routing table? The rate at which the routing table changes?
I would suggest the right answer is — all of the above.
But of course you can’t measure all of it everywhere on the network all the time, so you must decide where and how to measure so you will get a good “feel” for the overall operation of the network on a day-to-day basis.
There is a second point hidden in observe, however — how do you know what you’re observing unless you record? As the old saying goes, “if you didn’t write it down, it didn’t happen” — and nothing is truer than this in the world of observation. There’s no point in knowing what’s happening right now unless you know what has happened in the past.
So the first step in the OODA loop is to decide where, how, and what to observe — and to record it in a way that makes it easy to reference in the future.
The OODA loop is covered in some detail in The Art of Network Architecture, available wherever fine books are sold (because if they don’t sell my books, then they don’t sell fine books — see how that works?).
OODA Part 1: Getting Inside the Loop
OODA Part 2: Orientation
OODA Part 3: Decide!
OODA Part 4: Act!