I’ve been an engineer (en·gi·neer – noun: a person who designs, builds, or maintains engines, machines, or public works. Verb: design and build) in one form or another since I made the move from worker bee to Warrant Officer in 2007. What exactly I’ve engineered has changed a little bit from assignment to assignment, but regardless, I was always the one trying to solve someone’s problem. In order to solve a problem, we’re generally fed requirements (re·quire·ment – noun: a thing that is needed or wanted). Once we’re given requirements, we provide solutions (so·lu·tion – noun: a means of solving a problem or dealing with a difficult situation.)
The process works because the customer tells us what they need the something to do as well as specific constraints or restraints, and then we figure out ways to solve the problem. Once we figure out ways, either we make a decision and move forward, or we make a recommendation to the customer and let them decide.
In the tactical world, we see this happen frequently. For example, the Commander is planning a ground attack on a target 30 miles away. During the attack, he needs to have voice communications with his commanders on the ground, as well as the Brigade main. The entire operation is expected to take about 5 hours. (Requirements)
As the S6 (a signal engineer), we would start to look at possible solutions to this problem. Sure, I could deploy a CPN to the target but it takes a lot of time to set up, isn’t mobile as the battle progresses, and likely wouldn’t give the Commander what they need. I could use HF radio, but 30 miles is pretty close for HF, the terrain doesn’t really support its use, not to mention I know that most people in the unit haven’t touched an HF radio in years. I could use SINCGARS, but 30 miles is out of range for the radio. On the other hand, I do have a retrains team that’s available, there is a nice hill with a good line of sight to both the main and the target that is about halfway between and the unit uses SINCGARS all time. I recommend that the order be updated to use SINCGARS, that the signal company deploys a retrans team onto hill 1234, and that the infantry battalion provides a squad to help secure the site. (Solution).
This scenario works and works well because the Commander told me what he needed, and I was able to tell him how to get what he needed.
Contrast this with a slightly different scenario. The same attack is going to take place, but rather than the Commander telling me what he needed and when, he simply said, I need you to put a retrans team on hill 1235. What changed? First, the commander didn’t give us a requirement, he gave us a solution to an unknown problem. Does the solution he directed solve his problem? I don’t know, I never actually got the requirements. Is it the best solution? Again, I have no idea? Will the solution even work? I mean sure we can absolutely put a team on hill 1235 instead of 1234, but what the commander didn’t take into account was that between 1235 and the Main there was another taller hill that blocks the line of sight and significantly impacts communications. When the mission goes forward, he is able to talk to his commanders on the ground but can’t talk to the Main and loses visibility on the rest of the fight. The BDE S6 gets fired because “his” plan doesn’t work. Unfortunately, I’ve seen this scenario happen more than a few times when I was at NTC.
Today, I deal with similar situations every day. Take for example a recent problem I’ve been working on (a bit of an exaggeration to make the point but still pretty close to being accurate). The customer says that they need a sensor with 500 cores of processing power, 1 TB of RAM, and 1 PB of storage. What I’ve been presented with, is a solution (that doesn’t likely even exist when you consider some of the other requirements, but that’s beside the point), not requirements. Does this solution solve his problem? No idea, I don’t actually know what the problem is. Is it the optimal solution? Still have no idea.
So, we start to talk and try to uncover what the actual requirements are. We’re told that they need to be able to store PCAP for 30 days to allow enough time to fully investigate something before it ages off. Ok, that’s a good solid requirement. How big of a network are we talking about? Somewhere between 100 Mbps and 100 Gbps. Well, that’s a bit of a range of numbers separated by 3 orders of magnitude. I can do some simple math and know that to record an average bandwidth of 100 Mbps, I go through about 45 GB an hour or right about 1 TB a day. That means, with 30 TB of storage (completely doable) I can meet this requirement. On the other hand, at 100 Gbps, I need about 45 TB of storage an hour or about 1 PB per day which means about 30 PB of storage to meet the 30-day requirement. Is that in the realm of possible? Sure, you can absolutely buy 30 PB of storage, but it’s going to fill an entire rack (probably more) and cost an ungodly amount of money. But does it fill the requirement? Yes.
So here, we see that the originally proposed solution fills the requirement (at least as far as space goes) if we’re talking about 100 Mbps but doesn’t come remotely close if we’re talking about 100 Gbps.
Likewise, I know that with a sensor with 32 cores and 64 GB of RAM, I can easily sense a network working at about 4.5 Gbps. Their proposed solution absolutely fills the requirement at 100 Mbps but comes up short by about 17,000 cores when I’m trying to do 100 Gbps.
So now you’re left with the question of, is the 100 Mbps – 100 Gbps requirement actually a valid requirement? It may well be that the team ultimately may be on networks that require either extreme, but the chances of that being the same network are about zero. Because of that, do we need a single solution that fits both extremes? I would argue that the most feasible, and cost-efficient solution is one that simply scales to meet the particular mission requirements.
Likewise, back to the topic of PCAP storage, do I need to store the full PCAP or am I good enough to store just the headers for everything, and the data for some stuff (i.e., unencrypted traffic)? Having an answer to that can mean the difference between storing 100 GB of data vs 30 PB of data.
The point here is not to tell you about the solution I came up with (all of those numbers are made up by the way), but to show the difference, between being given a set of requirements, vs being given a solution. I have had customers tell me that they needed this solution. Did it work? Many times, sure. Was it the best solution? Who knows? As an engineer, it’s important that we educate our customers about why we do what we do, work with them to identify their true (reasonable) requirements, and that they allow us to use our knowledge in our area of expertise to figure out the best solution.