In the last week, I’ve done a couple of blogs mentioning P4. It should be clear that I’m a fan of the concept, but I want to point out that P4 is (like many other tech developments) at risk for being overhyped. Does it, as SDxCentral says, “take[s] software-defined networking (SDN) to the next level”? Not exactly, but P4 is an important piece of the future of SDN, and also a signal for what should happen in areas like IoT.
Network devices are packet processors. They examine a message header formatted in some protocol standard, apply forwarding rules, and dispatch the message along its way. In the most general examples, “along its way” could mean into an output queue or into a process that handles the message internally. The output queue could be part of a data flow end-to-end, or an on-ramp to a central control element like an SDN Controller.
The general practice for building network devices has been to use fixed logic and software control in combination to implement the packet processing logic. Appliances, like switches or routers, have increasingly relied on hardware enhancements like ASICs to accelerate their logic. Software switches and routers, lacking custom hardware since they’re designed for commercial off-the-shelf (COTS) servers, do everything in software. But appliances also use software, and there is considerable interest in using some off-the-shelf silicon in network adapters and custom boards in COTS servers.
In addition to this desire to exploit the best of software and hardware, there’s also increased interest in being more “flow aware” in devices, meaning looking deeper into the header structure to recognize new forms of tunneling or encapsulation. A pure software instance of a packet processor could be updated to handle new flows, but it might be less efficient as the combination of new headers and flows increases. Hardware appliances would be harder to upgrade, of course.
What P4 does is provide a high-level language to describe flow-based processing on a per-device basis as a combination of high-level logical tasks. These tasks are then mapped to actual, arbitrary, hardware and software combinations. Vendors of software packet handling and custom hardware devices could build “plugins” that would translate P4 functions into the form their own products require, so a properly written P4 program, supported by properly written “P4 compilers” by vendors, would be portable.
Improperly-written stuff clearly won’t be portable (or even perhaps workable), but that level of functionality is easy to determine. The broader problem is what could be called the “P4-in-a-cooperative-system” problem.
Networks are systems of functional units that cooperate to support a common mission. What, exactly, is that mission? P4 can define how a unit cooperates within the mission, but not the mission itself. A P4 programmer could author a router/switch program or a white-box handler for OpenFlow, but a bunch of disconnected P4 programmers could all come up with wonderful whiz-bang switch functionality that, when joined with the results of others’ work in a network, would do absolutely nothing. The cooperative behavior is not defined; only unit behavior.
This isn’t an issue where P4 is used to define a “standard” implementation like IP routing, Ethernet switching, or OpenFlow forwarding, but it does have implications where you’d try to define a new forwarding/flow paradigm, add in a new encapsulation strategy, etc. There, you’d need to lay out the cooperative behavior expected among the devices, meaning either any exchanges between devices or any exchanges with central management processes.
Coordinating inter-element behavior is something that the P4.org community has dabbled in. The In-Band Network Telemetry draft describes how state/status information can be communicated for the purpose of supporting network analytics. What’s not there so far is a general notion of defining cooperative behavior models that build a community of elements and not just an element alone. There’s no reason why P4 could not provide this sort of modeling of community practices; the tools to coordinate between devices could be added. The body just doesn’t do it now, and therefore we need to understand that it needs to be done somehow and that (obviously) other bodies may have to step up to do it.
Software-defined networking is more than software-controlled per-device forwarding, so P4 is not going to take SDN to the next level. What it does is remove a barrier to implementing new levels at the element or node level, if those new levels involve a different model of node packet processing. We still need to define the overall systemic relationships, and to me that’s what any given level of SDN is really about.
You could argue that P4 makes this systemic-level definition of SDN harder, not easier. In the past, design of a network device would usually start with the specifications of the data, signaling, and management exchanges among devices, and from that build per-device specifications. With P4 it’s possible to do the opposite; define per-device behavior from which systemic behavior could theoretically then be synthesized. That’s a risk of classic bottom-upness that poses risks overall in the tech and networking space.
That doesn’t mean that P4 is a bad idea, of course. If you want to define new network paradigms it’s sure nice to think that it’s possible to implement, at the node level, what you’ve defined. It’s even nicer to know that as new hardware technologies emerge, they can be incorporated in devices and used by the node packet processing logic. The systemic whole can’t be generated without nodal parts behaving as expected.
There are two truths that emerge from the reality of P4, IMHO. One is the obvious one—we need to have somebody thinking about systemic-level network behavior and what it could be made to look like if constraints on quickly defining nodal behavior and exploiting modern hardware were erased. The second one is that packet handling isn’t the only place where something like P4 would be helpful.
Event processing and network packet processing are similar in many ways. If you believe that the trends in cloud provider interest in event-driven apps are real, then you have to believe that some form of P4-ish event processing language would be very helpful. Event processing also illustrates the need to have a systemic and local vision of “handling” because events typically have to be correlated or contextualized to be useful.
A further extension to the event story comes in image processing. We have zillions of security cameras, wildlife cameras, process monitors, and so forth. Might it be useful to have some form of image processing to facilitate automated recognition of certain conditions? For sure; we just need to think about images differently.
Every video stream is a stream of images, and it could be the source of a stream of events. If you could process video images in at least near-real-time, you could extract things from the stream that were significant and trigger processes with the resulting events. We already do some of this in the work on self-drive vehicles, and the applications are as wide-ranging as improved ad targeting and intelligence.
In all these areas, we need to take another lesson from P4 and start looking from the top instead of focusing exclusively on the bottom. The lack of an organized framework can lead to so much variability (in the name of flexibility) that compatibility in implementations and ease of use both suffer, to the point where the whole value proposition could be jeopardized.
