-
Notifications
You must be signed in to change notification settings - Fork 219
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
Per seller timeouts #925
Comments
Would this be made visible to the seller via the contextual auction? In other words, will seller know that they're subject this timeout prior to building their component auction configuration? Also, #814 is somewhat relevant here, as is #906 -- especially as it relates to "fairness" and in what order the browser executes the aspects of the on-device auction. |
appears to be a dupe of #787 (comment) ; there are a variety of signals that component buyers could use from the top; particularly if top has set a floor a component seller/buyer is otherwise unaware of. |
We continue to be happy to discuss additional timeouts and controls. But the one Rahul proposed here is tricky in a few ways.
That's not to dismiss this request; it certainly sounds like a valuable way to help with resource usage! But I think we need a bigger picture of how component sellers would want to handle such a budget. |
Ah, and certainly the information-passing that Pat mentions is relevant also! But since sellers build their component auction configs before the auction even starts, this also has some similarities to the ad-slot-size information flow we discussed in last week's call. |
FLEDGE auctions currently have no real notion of time taken by a seller, just time by buyers - Chrome starts all sellers at once, and then they compete with each other for seller and buyer process slots (In a FIFO order, with anything with a life matching process jumping the queue). So if we just added perSellerCumulativeTimeouts as requested naively, all sellers would start their timeout immediately (modulo promise resolution), and all time out at once, which would make it more of a whole-auction-timeout (modulo time for the top-level seller's scoring script). We'd either need to introduce some new notion of an "actually started" seller based on some heuristic, or rework how we run auctions (which could actually slow them down, particularly if some sellers share a buyer). |
TLDR
We'd like to propose that the API support a
perComponentSellerCumulativeTimeout
as part of the top level sellerauctionConfig
to limit the risk of a slow component auction leading to an entire multi-seller Protected Audience flow timing out. We’d also like to propose that the top level seller be able to set a maximum timeout across all component auctions, leaving some time for the top levelscoreAd()
before the overall process times out.Details
In the context of a multi-seller auction, there is a risk that if the top level seller implements a timeout using
AbortSignal
, a slow component seller (e.g. with a buggyscoreAd()
implementation) might use the entire time leading to the entire Protected Audience flow timing out and adversely impacting all other sellers.Therefore, we think it makes sense for the top level seller to be able to support a per component seller timeout that applies to each the component auction(s) for a given seller origin. This value could be specified as part of the top level
auctionConfig
.Semantically, we think it'd make sense for the behavior to be similar to that of
perBuyerCumulativeTimeouts
, where the timeout specifies wall time for a seller across all component auctions for that seller and any bids scored before the timeout are considered valid - with the highest scoring bid entering the top level auction.Moreover, in the interest of fairness, we think it makes sense for each component seller auction to be subject to the same timeout so this could be a single field that sets a uniform timeout across all component sellers.
Finally, we think it also makes sense to be able to reserve for some short amount of time for the top level
scoreAd()
script to run in order to evaluate whatever bids may have been submitted to the top level auction before the component auction timeouts were reached.Is this something the API could support?
The text was updated successfully, but these errors were encountered: