-
Notifications
You must be signed in to change notification settings - Fork 232
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
Comments
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. |
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. |
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. |
The timeout applied to buyer bidding logic defaults to 50ms. This includes the execution of bidding logic, which is fine. However, it also includes:
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.
The text was updated successfully, but these errors were encountered: