ccascone
commented
4 years ago Regarding the accounting problem, an alternative could be that of using P4 registers instead of counters and implement an equivalent read-increment-write logic, but considering the byte size we care about (i.e. pre or post encap/decap depending on traffic direction). However, P4Runtime support for reading registers is not available in stratum_bmv2 (and bmv2 in general, because of this https://github.com/p4lang/PI/issues/376), so we would not be able to test that via PTF.
Currently, bng.p4 is based on v1model, a P4_16 architecture originally introduced to model the capabilities of the older version of the P4 language (P4_14). While v1model is widely adopted by different targets, including BMv2 (switch we use for testing), it prevents us to improve the modeling of the reference BNG pipeline.
PSA is the P4_16 Portable Switch Architecture: https://p4.org/p4-spec/docs/PSA.html
PSA provides a number of improvements wrt v1model, but unfortunately, support for it in BMv2 and other targets is still in early stages.
We can use this GitHub issue to track problems related to v1model and to motivate switching to PSA or other architecture.
Accounting
In v1model, byte counters in the egress pipe are incremented with the same pkt size seen at ingress. For example, even if upstream packets get decapsulated in ingress, egress counters will still account for access headers (VLAN and PPPoE). That might be a problem for operators that do volume-based billing, which need to maintain stats only for data effectively sent/received by an attachment, i.e., without counting bytes for the access headers. While the control plane can approximate such stats (e.g., by knowing the pkt count and for access headers with fixed size), the right solution to this problem would be to use a different architecture other than v1model, such as PSA, where pkts are deparased at the end of ingress, and parsed again at egress. With PSA, if we decapsulate pkts in the ingress pipe, the egress pipe should see shorter size pkts.