PSA Meeting Minutes Sep 7, 2017

Attendees

At Google: Samar Abdi (Google), Tom Rodeheffer (Google), Han Wang (Barefoot), Calin Cascaval (Barefoot)
online: Andy Fingerhut (Cisco), Andy Keep (Cisco), Vladimir Gurevich (Barefoot)

AIs from last time (10 mins each = 30 mins)
- Action Profiles/Action Selector
- Port_Id
- Checksum
Traffic classes https://github.com/p4lang/p4-spec/pull/403 (30 mins)
Should there be in PSA some kind of auto-generation packets based on timer firing, and maybe other events like link up/down? (15 mins)
Random number generation – what should PSA support? (10 mins)
Need volunteer to expand digest generation section of PSA (currently called packet generation)

Samar: P4runtime annotation to communicate the controller type
translation in the P4 runtime layer (logical->physical and physical->logical)
Andy: related to enum translation in P4runtime, if P4Runtime API chooses to support enums
unique name in PSA or annotation on the type that is global across the entire program
AI Calin: Check with Mihai/Chris whether a single annotation on the typedef for PortID_t type will be visible across all uses of that type everywhere in a P4_16 program, or whether every occurrence would need to be annotated.

From Nate: separate control block or just extern that can be invoked?
Andy/Vlad: separate control blocks guarantee that the computation is invoked in the correct place
Andy: calling in deparser: headers are in args, so they can't be modified, and if checksum needs to be computed, signature will need to change
Calin: programmers will have to write correct code. Compiler can check whether data used in the checksum computation is potentially modified after the checksum computation invocation.
Vlad: control block allows grouping several checksum computations
Andy: how about add/remove?
Vlad: incremental checksum and checksum vs. hash and checksum (with add remove)
hash functions are currently static
do we allow a runtime parameter to the extern?
- Vlad: yes
- Andy: P4 program will have to translate the polynomial to an predefined enum
if only static, then we can decide statically whether incremental APIs are supported
Decision for PSA: go with the static algorithm selection, add/remove depend on the algorithm
AI Nate to incorporate feedback on the discussion

Andy: after the ingress control there is a metadata field that allows for traffic control
left unspecified what implementations (different priority FIFOs) and what types of algorithms
Open questions: P4runtime APIs
- desirable property: count the packets dropped for different classes of traffic
cloning behavior: is there a possibility to specify different classes of service for packets sent to CPU?
- AI Andy to add a separate metadata field for class of service for cloned copy
number of classes of service: may require another translation in P4runtime, since this is defined by the platform
What happens if you specify a class that's not supported by the platform
- right now: drop (and error count)
- AI Andy: fall back on an exisiting class (class 0) -- consensus on having this as the default behavior
AI Andy: packets sent to CPU need to also support classes of service

Andy will be happy to add it
Vlad: thinks this is advanced functionality. Most of the interaction is on the control plane side.
Tom: difficult to standardize
Samar: what kind of packets and where are they sent
Vlad: very platform specific
Han: can these packets be generated by the host?
Tom: there are events that are not traffic related, e.g., port up/down
Current state of the art is to go through OpenConfig -- slow
Decision: above and beyond minimum PSA functionality and will not be incorporated.

Andy: uniform numbers in the range. with that you can generate any other distributions
- Vlad: any
Decision: Uniform it is (AI Andy to update the spec).

p4-arch@lists.p4.org email list
Github issues on p4lang/p4-spec, for which people will be assigned issues they will drive to completion.