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

[Shan Wang <[e-mail]>]

> With that in mind, I wonder if the existing `AggregateShareReq.batch_interval` sent from leader to helper suffices for #3 (this is an alternative to Shan Wang's idea of surfacing the aggregation job ID <=> batch ID mapping in the protocol messages). We can impose a total ordering on reports, so once the leader has identified a set of reports that satisfy the desired batch size, it should be able to devise an interval that captures at least (or I think exactly) those reports and send that to the helper. My thinking is that we can minimize the protocol text and code needed for the helper to support these different modes of aggregations.


There are a few problems with this: 1). The interval that leader devised must also meet requirement with min_batch_duration, so the devised interval cannot end at the moment `min_batch_size` is met, it has to have an ending boundary that aligns with `min_batch_duration`. This extra duration becomes a dead zone, any reports coming in that duration will be dropped on the floor. 2). It complicates the collect logic, since collector no longer knows what interval to include in `CollectReq`. Therefore, I think it's better to surface this requirement on the protocol level.

I agree leader shouldn't send helper a long list of report IDs, and in theory leader can include just one report in each aggregation job, making the aggregation job ID list very long too. But this perhaps should be guarded by a "SHOULD" in protocol text? 

For interval-metadata, one concern I have is that the possibility of metadata is pretty much endless, to guarantee any form of privacy on any of the chosen query metadata combinations will be extremely hard. I think designing separate tasks or encoding metadata in the measurement are better ways to provide such utility.

> 
> From: Tim Geoghegan <[e-mail]>
> Subject: Re: [Ppm] Batch selection and use cases for DAP
> Date: 5 July 2022 at 17:32:09 BST
> To: Simon Friedberger <[e-mail]>
> Cc: Christopher Patton <cpatton=[e-mail]>, ppm <[e-mail]>
> 
> 
> I have one hair to split with Chris' summary of the current state of play:
> 
> > Upon receiving this request from the Collector, the Leader picks a batch of reports with timestamps that fall in the batch interval.
> 
> The important nuance is that the leader and helper independently figure out what set of reports fall within the collector's chosen batch interval. Obviously, the helper's view of what reports exist is determined by what reports the leader forwards to it (that is, until we move to a split upload model[1]), but the leader doesn't send the helper a list of report IDs (I believe this is an important property because that list would be quite large). I bring this up so that everyone remembers that the protocol must guarantee that leader and helper agree on the set of reports included in an aggregation.
> 
> With that in mind, I wonder if the existing `AggregateShareReq.batch_interval` sent from leader to helper suffices for #3 (this is an alternative to Shan Wang's idea of surfacing the aggregation job ID <=> batch ID mapping in the protocol messages). We can impose a total ordering on reports, so once the leader has identified a set of reports that satisfy the desired batch size, it should be able to devise an interval that captures at least (or I think exactly) those reports and send that to the helper. My thinking is that we can minimize the protocol text and code needed for the helper to support these different modes of aggregations.
> 
> I have two thoughts on use case #2: First, if we want the leader to be able to select reports based on metadata provided by the collector, then I think the `Report`[2] message needs to include some metadata that can be matched against `CollectReq.interval-metadata.metadata`. Would we then also need DAP to define some kind of query language, so that a collector could express something like "aggregate over the reports where `report.foo = bar && 0 <= report.qux <= 100`"?
> 
> Second, I worry that this means aggregators can't begin accumulating prepared output shares into aggregates until they get the `CollectReq.interval-metadata.metadata` value. If a deployment knows it wants to break out aggregations by something like the client's country, could it not define distinct tasks for each value? I'm perfectly willing to be convinced that this is not practical, but I feel it's important to consider doing nothing, and also I think it'd be nice to have potential deployers of DAP spell out more explicitly what kinds of aggregation use cases they have.
> 
> Thanks,
> Tim
> 
> [1] https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/130 <https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/130>
> [2] https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap#section-4.2.2 <https://datatracker.ietf.org/doc/html/draft-ietf-ppm-dap#section-4.2.2>
>