Re: [Ppm] Batch selection and use cases for DAP

[Christopher Patton <[e-mail]>]

Hi Shan (please forgive the late reply!),


> I definitely support adding first class support for different batch
> selector in the protocol, especially for the size based selector. I can see
> it benefits the following use cases:
>
> 1). Tasks that need aggregate result as soon as privacy guarantee is met,
> rather than waiting for a fixed interval to elapse.
> 2). Tasks that need similar sized batches (therefore similar
> signal-to-noise ratio) to compare results of different batches.
> 3). Tasks that need strong privacy guarantee based on batch size, for e.g.
> central differential privacy.
>
> With batch size based collection, aggregators just need to make sure each
> client report falls in only one batch, and only emit a batch when its size
> has met `min_batch_size`. This selection is easier to understand and
> arguably simpler to implement, also it doesn't subject to privacy
> concerns associated with interval slicing, as mentioned by issue195 (
> https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/195)
>

Thanks for pointing to these use cases. And I agree, this seems somewhat
conceptually simpler than what we have today.


> I think Chris's straw man design is a good starting point. For
> `BatchSelector.fixed` type, collector creates a `batch_id` to identify a
> collection, so multiple request to the same `batch_id` return the same
> result (if `max_batch_lifetime` > 1).
>
> Upon receiving `CollectReq` of fixed type, leader does
> {{batch-parameter-validation}} but skipping any checks to do with interval,
> instead it checks if the same batch_id has been collected before. Then
> leader begins working with the helpers to prepare shares for this
> `batch_id` (or continues this process, depending on the VDAF).
>
> In {{aggregate-flow}}, instead of sorting each report share into interval
> based buckets, leader and helper can save them to `aggregate_share`
> identified by `aggregate_job_id`. The leader can send `batch_id` along with
> `aggregate_job_id` to helpers using `AggregateReq`, so helper can associate
> `batch_id` with multiple `aggregate_job_ids`. The same `batch_id` can be
> used to collect prepared `aggregate_shares` during {{collect-aggregate}}
> flow.
>
> Alternatively leader can associate `batch_id` with `aggregate_job_ids`
> internally, then send helpers the list of `aggregate_job_ids` for a
> `batch_id` during {{collect-aggregate}} flow. This way `AggregateReq` can
> remain unchanged.
>
> Also `batch_interval` is used as AAD in Aggregate Share Encryption (
> https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/blob/main/draft-ietf-ppm-dap.md#aggregate-share-encryption-aggregate-share-encrypt). For
> the `fixed` selector, `batch_id` or hash of `aggregate_job_ids` list should
> be used instead.
>

Yup, this all sounds reasonable to me. We can work out the details in a PR.

Chris P.