To achieve provably correct networks without requiring verification expertise from network operators, CORNET takes a novel approach to network verification. It runs the control plane as given, but intercepts the outputs (heading to the data plane). It verifies at runtime these control plane outputs, checking that the resulting network (data plane plus control plane forwarding rules) behaves according to the specification. When an error is detected, this is flagged to the network operators and optionally prevented from being inserted in the network (when this is possible). An overview of this approach was published in the Hotnets workshop in 2017 (Integrating Verification and Repair into the Control Plane – Raiciu et al.).
The cornerstone of this approach is the ability to quickly check whether a given dataplane behaves correctly as per its specification. In the first part of CORNET, much of our work has focused on verifying programmable dataplanes specified in the P4 language; hardware targets capable of running P4 programs emerged roughly at the time when our project was starting, cementing the way for programmable dataplanes. The CORNET project is leading the way in verifying programmable dataplanes, having published two papers in Sigcomm 2018 and 2020.
Vera was our first project targetting P4 verification, and one of two papers that first tackled this problem; the other project is p4v, from Cornell and Barefoot networks (both papers were published in Sigcomm 2018). Vera did verify quickly (under one second) that P4 programs behaved according to spec for small and medium-sized programs, but took much longer to test complex programs (hours). This meant it can be used at program development to find out possible bugs, but not at runtime to make sure the network is bug free, as we envisaged.
bf4 (bug-free P4 programs) is our second project on this topic (Sigcomm 2020). It uses verification techniques to generate simple conditions which must be obeyed at runtime by the controller, and these can be enforced at runtime very quickly (milliseconds). bf4 ensures that a running P4 program does not contain any of list of possible bugs arising from cases when the P4 program behaves in an undefined way. bf4 is reasonably also fast at development time, checking complex programs and generating the control-plane conditions in a few minutes.
Another focus of CORNET has been on helping operators specify correctness requirements. Formal languages are normally used to this effect, but these are cumbersome to use for most network administrators. Instead, we devised a simpler way to describe the desired properties: by equivalence to a simpler network: for instance, an operator can specify that the real network must behave in the same way as an idealized network which is much easier to understand. netdiff is the tool we have built that automatically checks the equivalence of two network data planes given as input; if the two data planes are not equivalent, it provides to the users an example of behaviour that is different across the two programs. Using netdiff we were able to find bugs in a widely used network virtualization software (Openstack Neutron).
The work above applies to the Internet at large and was performed in the first three years of CORNET. In the latter phase of the project, our focus moved to datacenter networks which is where network impairments created most issues operationally. Our work was two-fold: first, we designed, implemented and tested EQDS (NSDI22), a new datacenter protocol that aims to offer high and predictable network performance by tunneling existing legacy protocols (TCP and RoCEv2). EQDS can offer near-optimal performance assuming the network does not have gray failures or performance-related misconfigurations; the second part of this work is monitoring the achieved performance to detect network impairments automatically.
