You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Event-level epsilon is used to compute the channel capacity of a source and obtain a randomized source response. Currently, if a source's event configuration exceeds channel capacity it will be rejected; however, a lower event-level epsilon may be provided during source registration to increase noise and reduce channel capacity to accord with the limit.
The flexible-event utility currently advises on the highest such event-level epsilon. For example:
npm run flexible-event -- -w 1,2,3 -b 4,5,6
advises that by providing event-level epsilon 11.405 (default is 14.0), randomized trigger rate is increased from 0.0072807 to 0.0894337 to accord with the channel capacity limit for navigation sources.
Rather than reject source registrations that exceed channel capacity limits, ARA implementations could default to automating setting such an epsilon on the client, with the ability for consumers to turn it off per registration. This would give API callers a tradeoff between more possible event-level configurations and higher noise.
The text was updated successfully, but these errors were encountered:
To make sure I understand: This proposal doesn't add any capabilities to the API, but rather allows the reporting origin to avoid having to compute epsilon itself?
To make sure I understand: This proposal doesn't add any capabilities to the API, but rather allows the reporting origin to avoid having to compute epsilon itself?
It not only avoids -- the proposal is to default to this automation. In the current version of the API, the consumer does not have to compute epsilon. They can just have registrations rejected. With this change, the default would be to accept registrations by altering epsilon automatically.
Got it. Have we received feedback that it's difficult to compute epsilon ahead of time?
As for the defaulting -- We'd have to consider whether silently changing the default behavior here is OK. If not, we could instead allow sources to set something like "event_level_epsilon": "auto" to opt-in to this.
Event-level epsilon is used to compute the channel capacity of a source and obtain a randomized source response. Currently, if a source's event configuration exceeds channel capacity it will be rejected; however, a lower event-level epsilon may be provided during source registration to increase noise and reduce channel capacity to accord with the limit.
The flexible-event utility currently advises on the highest such event-level epsilon. For example:
advises that by providing event-level epsilon
11.405
(default is14.0
), randomized trigger rate is increased from0.0072807
to0.0894337
to accord with the channel capacity limit for navigation sources.Rather than reject source registrations that exceed channel capacity limits, ARA implementations could default to automating setting such an epsilon on the client, with the ability for consumers to turn it off per registration. This would give API callers a tradeoff between more possible event-level configurations and higher noise.
The text was updated successfully, but these errors were encountered: