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

Per seller timeouts #925

Open
rahulkooverjee-google opened this issue Nov 21, 2023 · 5 comments
Open

Per seller timeouts #925

rahulkooverjee-google opened this issue Nov 21, 2023 · 5 comments

Comments

@rahulkooverjee-google
Copy link
Contributor

TLDR

We'd like to propose that the API support a perComponentSellerCumulativeTimeout as part of the top level seller auctionConfig 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 level scoreAd() 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 buggy scoreAd() 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?

@rdgordon-index
Copy link
Contributor

This value could be specified as part of the top level auctionConfig

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.

@patmmccann
Copy link
Contributor

patmmccann commented Nov 21, 2023

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.

@michaelkleber
Copy link
Collaborator

We continue to be happy to discuss additional timeouts and controls. But the one Rahul proposed here is tricky in a few ways.

  1. As Roni points out, this control could lead to the component auction getting bids from some IGs and not others... which means this top-level-seller control would need to come along with some new tools to let component auction sellers figure out how to best use the resources allotted to them.

  2. It may not be easy for a component seller to know how to split up the time budget of a perComponentSellerCumulativeTimeout among buyers, because of parallelism. I don't think it's feasible for us to orchestrate a single buyer in a way that lets it do some bidding, then pauses while others do some bidding, and then come back later if there is time left. (As you can tell from @MattMenke2's descriptions in the in-progres PR Create FLEDGE_implementation_overview.md #906, the lifecycle of worklets is important to the implementation of the auction.)

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.

@michaelkleber
Copy link
Collaborator

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.

@MattMenke2
Copy link
Contributor

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).

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

5 participants