Evaluation
9.5 Discussion
9.5.1 Likely Causes for Failure
This evaluation found that in every case where Shoehorn was unable to find a mapping, it was due to a virtual table that could not be supported by any
table in the physical pipeline. For the flexible pipelines—the Aruba, the Nvidia, and the Cisco—this is likely to always be true, as the tables can be arranged in any order. Provided they can support all of the virtual tables, and have enough tables available, these pipelines can simply recreate the virtual pipeline directly.
The fixed-function pipelines, however, might fail due to unsupportable access sets. The fixed-function pipelines rely heavily on their ACL tables to support a variety of virtual tables, and the ACL tables apply to all packets. Any virtual table that is accessed following a hit in another table cannot be mapped to the ACL table, unless it uses theflexible_mappingannotation. Virtual tables that are accessed following a miss in another table can more easily be supported by the ACL table, as ternary tables can be concatenated (§6.3.4).
9.5.2 Programming Pipelines
To ensure that Shoehorn has the best possible chance of finding a mapping, it is important when programming virtual pipelines to ensure that tables are not being restricted arbitrarily. Most importantly, programmers should use the flexible_match_kinds annotation whenever the update rate for a table is low. The fixed-function physical pipelines, SAI and OF-DPA both relied heavily on ACL tables to support virtual tables, often aggregating tables to- gether to be supported by the ACL table, then recirculating to allow tables in the next control block to be mapped to the ACL table as well.
The flexible_mapping annotation was only simulated to merge tables with termination MAC tables—with the VIP table in the Faucet pipeline, and with the ingress routing table in the VPNs PE pipeline. The flexible_mapping annotation not only reduces the update rate, but also increases the memory
usage, so it is only practical for very small tables, or when the controller developer knows that two tables can be combined without increasing the overall number of entries.
In some cases the definition of the physical pipeline can reduce the complexity of finding mappings. For instance, the OF-DPA always carries internal VLAN tags, this is not included in the pipeline definition however, as a pipeline where all packets arrive and exit the datapath untagged, and internally only carry the default VLAN tag, is—from the perspective of Shoehorn—identical to one with no VLAN tags.
9.5.3 Ideal Hardware
From these results, it is easy to propose a hardware pipeline that supports all the controllers in this evaluation. Simply by adding a table that does exact 5-tuple matching, as well as adding ARP TPA matches and set IPv4 address actions to the Polcy ACL table, the OF-DPA pipeline would support all the controllers.
Changing the Policy ACL table to useconfigured_anymatches does not allow Shoehorn to find mappings to the OF-DPA for all pipelines that use exact 5- tuple matches. A table usingconfigure_anymatches, cannot support multiple tables when one of them uses exact matches, unless all the tables use the same matches. Instead, a new table that can performexact5-tuple matches is required. An exact match table that matches arbitrary combinations of fields would also allow supporting other controllers such as FlowTags [33].
Two controllers aggregated tables to simulate the flexible_mappingannota- tion, and the OF-DPA supported both in the Policy-ACL table. This would not have been necessary with a two stage Policy-ACL table, where the second
table is optionally accessed after a hit in the first.
This approach, of including a small number of flexible tables in a fixed-function pipeline, is similar to that proposed by PINS [86].
9.5.4 Other Algorithmic Mapping Systems
This evaluation does not compare Shoehorn directly to FlowConvertor [89]
or the system proposed by Sanger, Luckie, and Nelson [100], as these pre- vious system map populated OpenFlow flow tables, whereas Shoehorn maps pipelines defined in P4. This evaluation demonstrated mapping complicated real-world controllers to real physical pipelines, which neither previous algo- rithm achieved.
Unlike the previous algorithms, Shoehorn ensures that real-time translation is practical, FlowConvertor demonstrated their system is practical for real- time translation with simple pipelines, but do not guarantee the update rate will be preserved, and likely cannot achieve real-time translation with larger pipelines. Sanger, Luckie, and Nelson found their algorithm is not suitable for real-time translation. Likewise, by preserving the match kinds used by each table, Shoehorn ensures the power consumption of the pipeline is not negatively impacted.
FlowConvertor relies heavily on metadata to control the path of packets through the pipeline. Metadata is poorly supported by the target hardware, however.
Shoehorn does not have this requirement.
FlowConvertor has not been demonstrated to work with flexible hardware.
Sanger, Luckie, and Nelson found that their solution was unable to scale to work with flexible hardware. Shoehorn is able to support flexible hardware as
well as fixed-function pipelines.