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

Public report extensions #620

Closed martinthomson closed 1 month ago

martinthomson commented 1 month ago

I don't know how I missed this earlier, but I think that the design of report extensions is very much suboptimal for the sorts of things that are in this draft. Those extensions carry public information, so having that data repeated is not ideal.

This draft makes a case for submissions with a reduced overhead. The efficiency gains depend on having extensions to the public report metadata. I'd like to request that report metadata be made extensible.

I can't conceive of any reason to use private report extensions, as currently defined. I'm not saying that it is a bad idea to provide that extension point, though a lack of reasons to use them makes their inclusion questionable. I guess I'm saying that moving upload extensions from private to public might be possible, rather than just adding another extension point.

cjpatton commented 1 month ago

See https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/619#issuecomment-2422794129 for historical context. Extensions used to be public, but we decided after draft 02 to make them private. In fact, it was your suggestion to encrypt them: see https://github.com/ietf-wg-ppm/draft-ietf-ppm-dap/issues/369#issuecomment-1289958837.

I'm open to doing something here, but given how far along we are, I think we need to be careful to not change the expectations of existing implementations. In particular, I'm hesitant to get rid of the private extensions altogether.

I'd be fine with adding public extensions to the report meta data. Would the semantics of these extensions need to be any different than for the existing private extensions? Other than the fact that they are necessarily shared by both aggregators.

cjpatton commented 1 month ago

2024/10/24 interim: We will put up a PR to add a public extension point. If we decide the protocol complexity is too great, then we'll consider removing the private extension points as well. (There are no publicly known use cases for this, but in the future an "encrypted extension" could be defined that makes this use case possible.)

martinthomson commented 1 month ago

One thing that came up was that a public "encrypted" extension might end up being a little cumbersome (not just in definition, but also implementation). If that is the case, and we've removed the private extensions, DAP version 2 is always possible. A new version doesn't need to be a whole big deal. QUIC demonstrated that versioning can be done fairly cheaply with the right motivation.