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

50ms for bidding is a bit optimistic #989

Open
martinthomson opened this issue Jan 17, 2024 · 4 comments
Open

50ms for bidding is a bit optimistic #989

martinthomson opened this issue Jan 17, 2024 · 4 comments

Comments

@martinthomson
Copy link

martinthomson commented Jan 17, 2024

The timeout applied to buyer bidding logic defaults to 50ms. This includes the execution of bidding logic, which is fine. However, it also includes:

  • fetching trusted signals
  • fetching k-anonymity status of the bid for each interest group
  • fetching k-anonymity status of all ads in the interest group, if the interest group makes a bid that fails to pass the k-anonymity check

Even with just one interest group, that's three fetches in 50ms. Optimistic starts to look unrealistic.

I get ping of ~10ms to both Google and Fastly servers where I live, so I'm lucky. I can maybe count on being able to make three requests in series within 50ms; maybe four if my machine is fast enough and I'm lucky.

That's assuming that requests are going out using an existing connection to an Oblivious HTTP server for each and that there aren't a lot of other requests going on. Connection setup will eat one more round trips unless I've got QUIC 0-RTT primed. That has zero tolerance for packet loss. If my computer is slow or busy, encapsulation and decapsulation of requests could eat into that budget pretty significantly (X25519 is fast, but it's not free). So too for the execution of bidding and screening logic. Each buyer and interest group could be run in parallel, so maybe if there aren't too many of them active this limit might work, but it seems unlikely.

On the whole, setting such a low default is very likely to cause wonderful "works on my machine" effects for developers living in well-connected parts of the world.

@martinthomson
Copy link
Author

The k-anon checks are - apparently - supposed to occur prior to running auctions, or at least not under this timer. See #988. That reduces the degree to which network delays need to be included.

@palenica
Copy link

palenica commented Jan 29, 2024

I think the timeout you mention covers only execution of bidding logic on device, and excludes network traffic. Trusted signals fetch happens before bidding logic starts executing and doesn't count against this limit.

The trusted signals fetch still contributes to user visible e2e latency, while the k-anon status does not, as it can be pre-fetched.

@martinthomson
Copy link
Author

@palenica, if that is the case, then the algorithm in the specification is wrong. Unless I'm missing something, the fetches for trusted signals occur within the timer. #988 established that the spec was wrong, so I guess this isn't so surprising.

@MattMenke2
Copy link
Contributor

The fetches do not occur within the "per buyer timeout" timer. They do occur within the "per buyer cumulative timeout" timer, which is an entirely different timer, and has no default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants