Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

generateBid - query time left #241

Open
jonasz opened this issue Nov 26, 2021 · 2 comments
Open

generateBid - query time left #241

jonasz opened this issue Nov 26, 2021 · 2 comments
Labels
Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility

Comments

@jonasz
Copy link
Contributor

jonasz commented Nov 26, 2021

Hi,

During the last FLEDGE call we discussed potential approaches to learning how much time is left from within generateBid before a timeout occurs.

As I understand, exposing an accurate timer would introduce certain privacy risks.

One idea proposed was to allow to query whether "at least 3ms is left". An extension of this idea would be to provide a function getApproxTimeLeft(), which returns a lower bound on time left. A potential implementation could return time left minus some random number, or time left rounded down to a multiple of 5ms. Even a very limited version, where we can learn whether there's "at least 1", "at least 5", "at least 25" would be quite useful already.

I'd be curious to hear if that sounds feasible to you.

Best regards,
Jonasz

@brusshamilton
Copy link
Contributor

Something like that may be feasible (with appropriate noising and rate limiting), but I'm curious if another solution could fit this use case.

In the 2022-02-02 FLEDGE call it was suggested FLEDGE allow multiple calls to reportLoss in generateBid and just use the last one. Would something similar to this where FLEDGE offers a setBid function to specify what bid to use if the worklet times out before returning also apply to your use case?

Part of my concern is that given the wide range of performance for devices that may run FLEDGE, the time left may not be a good measure for how much more work could be done.

@jonasz
Copy link
Contributor Author

jonasz commented Feb 15, 2022

Hi @brusshamilton ,

Such a setBid sounds great, indeed it should be more reliable than getApproxTimeLeft. Thanks for proposing this!

To expand a bit, I think in future it could be useful to have both setBid and getApproxTimeLeft, as they provide somewhat different functionalities ("let's make sure I don't lose my result so far" vs "let's decide which computation to perform next - heavy or lightweight"). That said, if we were to choose now, we'd definitely go with setBid and perhaps come back to discussing getApproxTimeLeft sometime in future.

@JensenPaul JensenPaul added the Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility label Jun 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Non-breaking Feature Request Feature request for functionality unlikely to break backwards compatibility
Projects
None yet
Development

No branches or pull requests

3 participants