Request for community feedback: Component auction + top-level auction timeouts

[MattMenke2]

One issue that has come up a number of times is how and whether fields, and in particular timeout fields, from the top-level auction should affect component auctions.

There are currently 3 timeouts, with a fourth being added soon:

• sellerTimeout: This limits the time allowed for each individual scoreAd() invocation.
• perBuyerTimeouts: This limits the time allowed for each generateBid() invocation. It can be specified for each buyer, with fallback to a wild card value.
• perBuyerCumulativeTimeouts: This attempts to limit how long a particular buyer can delay an auction, going roughly from worklet process construction time, through downloading a bidding script, and running generateBid() calls. This is basically wall clock time starting from when we start work specific to a buyer, and can run concurrently for multiple buyers.
• [new] reportingTimeout: This is like sellerTimeout and perBuyerTimeouts, but affects reportResult() and reportWin() - one value applied independently to each method.

In component auctions, the sellerTimeout and reportingTimeout of the top-level auction only affects calls to the top-level seller script, and the perBuyer values from the top-level auction are ignored entirely.

It might make sense to use a combination of the top-level seller value and component seller-value in component auctions. The two obvious ways to do this would be either the min of the timeouts from the two auctions, or to prefer the component seller's values, if it has them, to the top-level seller's values.

The perBuyerTimeouts case is potentially a bit problematic with either option, though - the top-level seller could effectively give one particular bidder in a component auction so little time that it always times out. Is this a reasonable behavior? Or perhaps the top-level seller should only be able to set a wildcard per-buyer timeout? Also, should the top-level seller be able to set perSellerTimeouts, which would potentially limit the time of each scoreAd() call for each component seller?

We'd love to hear feedback on whether we should do some sort of application of specific timeouts from top-level timeouts to component auctions. Note that we're not looking for suggestions of new timeouts here (which is a reasonable thing to talk about - feel free to file a new issue to discuss that, or weigh in on an old issue about it), we're just thinking about whether top-level auctions should impact the existing timeouts in component auctions.

[dmdabbs]

Thanks Matt.

In component auctions, the sellerTimeout and reportingTimeout of the top-level auction only affects calls to the top-level seller script, and the perBuyer values from the top-level auction are ignored entirely.

👍

Apropos of the new timeout, do please add it to the _Protected Audience Implementation Overview_ that for whatever reason remains an open PR.

[rdgordon-index]

Re: perBuyerTimeouts / perBuyerCumulativeTimeouts -- I believe this came up at a WICG meeting earlier -- but if we're going to review the timeout configurations, I find the interplay between these values somewhat confusing; there's no way to indicate that I only way to provide perBuyerCumulativeTimeouts, because perBuyerTimeouts has a default value, and there's no setting to 'disable' it. Can that be considered? Concrete example: sellers are used to defining timeouts per DSP in programmatic auctions, as a way to ensure responsiveness to the publisher -- hence cumulative buyer timeouts seems like a reasonable parallel, without need to worry about 'per bid' timing, which seems like for a buyer configuration.

[MattMenke2]

Re: perBuyerTimeouts / perBuyerCumulativeTimeouts -- I believe this came up at a WICG meeting earlier -- but if we're going to review the timeout configurations, I find the interplay between these values somewhat confusing; there's no way to indicate that I only way to provide perBuyerCumulativeTimeouts, because perBuyerTimeouts has a default value, and there's no setting to 'disable' it. Can that be considered? Concrete example: sellers are used to defining timeouts per DSP in programmatic auctions, as a way to ensure responsiveness to the publisher -- hence cumulative buyer timeouts seems like a reasonable parallel, without need to worry about 'per bid' timing, which seems like for a buyer configuration.

There are two potential concerns with that, related to worklet process provisioning: 1) Without a per-script timeout, one runaway worklet could entirely lock out all of that buyer's other IGs from bidding - not just in the current auction, but in all auctions that run concurrently with it, globally for that Chrome profile. Once there's no longer a running/queued bidder worklet for that buyer origin, we would end the process. We could try to do a bit better in terms of cancellation here, but it would still potentially lock things until the cumulative timeout expires. 2) There's a global bidder process quota, which again, one runaway script would eat up.

Admittedly, we're pretty generous in letting perBuyerTimeouts be increased, anyways (Is there a maximum value? I'm not sure), and large numbers of IGs with slow scripts have a similar effect, so arguably, having no perBuyerTimeout just exacerbates potential problems already there. Also worth noting slow network fetches for scripts or signals can have very similar effects.

Anyhow, not saying the idea is clearly unworkable or definitely something we shouldn't pursue, just bringing up some potential concerns we should think about in making a decision to allow disabling it.