Skip to content

PSA meeting minutes: Jul 24, 2017

Jump to bottom
Calin Cascaval edited this page Jul 25, 2017 · 4 revisions

Notes courtesy of Andy Fingerhut.

Attendees:

  • On Stanford campus: Calin Cascaval (Barefoot), Nate Foster (Cornell/Barefoot), Andy Fingerhut (Cisco), Tom Rodeheffer (Google), Antonin Bas (Barefoot), Han Wang (Barefoot), Vladimir Gurevich (Barefoot)
  • Remote: Andy Keep (Cisco), Tom Tofigh (AT&T), Heidi Ou (Alibaba), James Coole (Cisco), Bapi Vinnkota (Netronome), Samar Abdi (Google)

Agenda

Discussion

Announcements

  • AndyF is taking over as Working Group co-chair from Dan Daly.

Counting https://github.com/p4lang/p4-spec/issues/352

  • packet counter: increment by 1

  • byte counters: increment using a platform specific packet_lenght

  • packets and bytes: each of the above

  • update from the data plane, read from the control plane

  • direct counters - directly associated with table entries

    • Q: P4_14 semantics -- automatically updated on entry matched. Current PR has an explicit count call in the action. Do we revert to P4_14?
    • TomR: issues: conditional calls which misses updates?
    • Vladimir: explicit to be similar to direct meters (P4_14 was handling them inconsistently)
    • AndyK: issues with giving access to this api because now people can call multiple times.
    • Vladimir: can we have actions that do not count? E.g.: the default action (including in BMv2)
    • AndyF: for a miss entry there is no direct counter associated with it, and therefore no explicit count. For an installed default action the counter is 0.
      • No implementation is PSA compliant unless they have a counter that can be used for a default action.
      • default-default -- no counter
      • installed default -- should have a counter

  • Vote:

    • Explicit: Antonin, Vladimir, Samar,
    • Implicit: AndyK, James

  • TomR: how does the controller pulls out the values of the count?

  • Nate: where is the direct mapped state handled? What is the status of direct meters and counters when entries get added and removed. (new issue to be opened)

AI: AndyF to revise the PR following the agreement:

  • packets, bytes, and packets_and_bytes counters, as in P4_14
  • explicit call to count in methods for direct counters
  • counter resources available for control plane installed actions
  • no counter resources for default-default actions

AI: open issue on direct mapped state when entries are added and deleted. Issue opened: https://github.com/p4lang/p4-spec/issues/359

Reject Semantics https://github.com/p4lang/p4-spec/issues/339

  • there will be standard metadata that captures the reason and can be passed to the follow through blocks
  • library function to handle how to deal with the reason
  • Vladimir: what do we want to do with the verifyChecksum block (new issue)
  • packet always goes to ingress with the status assigned
  • a reject is a global reject from anywhere in the hierarchy

AI: open issue on verifyChecksum semantics. Opened: https://github.com/p4lang/p4-spec/issues/360

AI: PR for the spec (Vladimir)

Write-only methods https://github.com/p4lang/p4-spec/issues/316

  • Option 1: Writing metadata
  • Option 2: Methods in the PRE
  • We need precedence rules for these operations
  • Undoing actions.
  • If going with metadata - then we need to fully specify exactly what the metadata is and the state machine that it represents.
  • Vladimir - PRE methods require computing into metadata and then call the method
  • Nate: wants to have the programmer read the program and understand what it does
  • TomR: it is easier to make the semantics precise based on metadata. And then you can define the metadata only.
  • TomT: metadata forwarded to collectors for further processing. Capture metadata in the flows.
  • Calin: encapsulation. Methods allow encapsulating the state and implementing it in different ways, without the state leaking.
  • Bapi: would write the functionality in such a way that it calls once to the PRE (and store in user-defined metadata)
  • AndyF: clone/recirc/resubmit -- can we have someone devote time to put the details on these -- Han will look into it.
  • Vote:
    • Metadata: Vlad, TomR, Bapi, TomT
    • Methods: _

AI: proposal for option with metadata and the ordering semantics (AndyF)

AI: proposal for clone/resubmit/recirculate (Han)

Index out of bounds for counters, meters, and registers (https://github.com/p4lang/p4-spec/issues/323)

  • AndyF: defined as a safe no-op, not undefined behavior
  • Bapi: return error?
  • AndyF: there will be no return from the function, but the register read will give an undefined value. Is it guaranteed to be one of the known values? No, you can not rely on that value. Models like BMv2 will log an error.
  • TomR: restricted undefined behavior - will not change state, no effect on any counters, packet state, etc. Truly a no-op.
  • Nate: no error mechanism in P4_16. There is no error state. Should we add bits for tracking errors?
  • TomT: DDoS protection? No, write your program such that you don't step out-of-bounds
  • Bapi: wants to know whether some error has happened
  • Nate: the language already has these types of undefined values. Addressing all errors will require other instances to flag such errors (e.g., valid headers).

AI: PR for the spec (Calin)

AI: Future discussion in the lang group on what to do about error checking (Nate)

Unspecified forwarding op behavior (https://github.com/p4lang/p4-spec/issues/317)

  • AndyF: if the ingress doesn't set any metadata, what should happen to the packet. Proposal: packet is dropped.
  • Vlad: Minimal program -- do nothing and that's drop the packet.
  • Explicitly different from P4_14, which forwards to port 0.
  • Counters still get updated. This is for PRE behavior.

AI: PR for the spec (AndyF)

Packet arrival time (https://github.com/p4lang/p4-spec/issues/336)

  • Timestamps: keep track of telemetry, netflow, sflow

At a minimum:

  • Ingress: packet arrival time.

  • Egress: time when you start egress processing

  • Unit of measurement: clock ticks?

  • TomT: Geolocation? separate topic, open issue for later discussion if you feel strongly about it.

  • Nate: target specific precision

  • AndyF: at least something that doesn't wrap often. With clock ticks, control plane can define timeout as long as it knows the relationship between ticks and time

  • Antonin: compile-time extern that gives you the ticks to time resolution for the target

Next level:

  • convert the tick value to ns or ms

  • Nate: what happens if these values get put into packets? Control plane should have the means to disambiguate these values through some other mechanism.

  • Bapi: are we assuming synchronized times? No, outside the scope of PSA.

  • Nate: are these the only places where we should have timestamps? Looks like pragmatically, yes.

  • Bapi: what guarantees do I get w.r.t. to packet ordering based on timestamps? We'll be close, but we can't guarantee the events can be ordered and timestamps incremented in a deterministic way.

  • Vladimir: strongly recommend that parser time is as close to arrival time

  • Vladimir: Can two consecutive packets guarantee that they have different timestamps? Depends on the resolution.

AI: PR proposal (Andy).

AI: open issue for Geolocation if needed (TomT)

Reminders

Roadmap

(will need adjusting)

  • initial draft of PSA document - 2017-Jul-31

  • PSA v1.0 - 2017-Sep-30

  • bmv2 support - 2017-Jul-31

  • p4c support - 2017-Aug-30

Forums for discussion:

  • [email protected] email list
  • Github issues on p4lang/p4-spec, for which people will be assigned issues they will drive to completion.
Clone this wiki locally