search

ietf-wg-ppm / draft-ietf-ppm-dap

This document describes the Distributed Aggregation Protocol (DAP) being developed by the PPM working group at IETF.
Other
46 stars 22 forks source link

Discuss lifecycle of various objects and how they relate to each other #560

Open tgeoghegan opened 6 months ago

tgeoghegan commented 6 months ago

On the mailing list, @wbl observed that it's hard for readers to understand the relationship of reports to aggregation jobs to batches to aggregate shares. We should add a section between the introduction and the the sections describing the sub-interactions which discusses the lifecycle and cardinality of these objects.

tgeoghegan commented 6 months ago

Mailing list thread in question: https://mailarchive.ietf.org/arch/msg/ppm/E1OAX-HKwknXGevr5EmVjSEdOtE/

tgeoghegan commented 6 months ago

One reason this can be confusing is the notion of "eager" aggregation, which is doable for VDAFs like Prio3 that don't have aggregation parameters. Simon noted in #385 that this is confusing, and perhaps we could clear this up by making the notion of eager aggregation more explicit in DAP.

There's an awkward tension here: we've avoided explicitly discussing eager aggregation, partial aggregates, etc. because technically those concepts are implementation details of a specific aggregator. For instance it'd be perfectly OK for the helper to do eager aggregation into buckets, but for the leader to retain individual output shares until it's time to construct aggregate shares. Neither needs to know how the other handles this, and for that reason it didn't seem appropriate to discuss the concepts in a protocol document whose principal goal is to specify interfaces between participants, not implementation details. But of course now it seems this implementation detail is leaking into the protocol, in that we take enabling this strategy to be a hard requirement for the protocol.

branlwyd commented 5 months ago

I think it would be useful to discuss lifecycles, but the DAP spec has historically avoided being too prescriptive about lifetimes/deletion -- IMO we should remain descriptive rather than prescriptive, and if we are prescriptive, say as little as possible. (I suppose the goal is to proscribe the minmimal amount of behavior leading implementations to be interoperable.)

cjpatton commented 2 weeks ago

2024/10/24 interim: Now that draft 13 has substantial breaking changes planned, we are going to want to cut it sooner rather than later. I'm therefore punting this to the next draft.