New HTTP outcalls pricing model #6101
Conversation
github-actions
bot
added
the
interface-spec
|
🤖 Here's your preview: https://h6x2v-daaaa-aaaam-aenha-cai.icp0.io |
…est args (#7447) This PR adds the price version, as described in dfinity/portal#6101 to the management canister `http_request` endpoint. This PR also persists the version in the replicated state. In the future that will be used to determine which pricing strategy should be applied. The flag is a candid opt nat32, which, if missing, defaults to "1", which corresponds to the "current" pricing. Similarly, if set to "2", the flag will default back to 1, as version 2 is not implemented yet. In the future, we will support pricing_Version = 2, which corresponds to the "pay-as-you-go" pricing. --------- Co-authored-by: kpop-dfinity <[email protected]>
| http_roundtrip_time_ms : nat64; | ||
| raw_response_bytes : nat64; | ||
| transformed_response_bytes : nat64; | ||
| transform_instructions: nat64; |
There was a problem hiding this comment.
It would be more developer-friendly to have all those fields as opt nat64 and describe the default values used in case they are not specified. I think it's a bit unclear for a developer what reasonable values should be put in http_roundtrip_time_ms or transform_instructions. WDYT?
There was a problem hiding this comment.
The only default values I can think of are the maximum possible values, i.e., a transformed response size of 2MB and transform instructions of 5B.
There was a problem hiding this comment.
The only default values I can think of are the maximum possible values
yes, exactly. Also if those values change (e.g. max transform instructions is now 6B), then it could be changed here, instead of having to update every caller.
There was a problem hiding this comment.
That makes sense to me. What do you think, @mihailjianu1 ? (Switching from nat64 to opt nat64 is backward-compatible so it should be fine although the API has already been rolled out in production.)
| } | ||
| ``` | ||
| The function may trap if `params_src` and `params_size` do not describe a valid Candid encoding of a value of the above type, or if the encoding contains additional fields other than the ones above. The function returns the cycle cost of an HTTP outcall whose execution uses up exactly the amount of resources specified by the individual fields: |
There was a problem hiding this comment.
Shouldn't we also describe how the estimated cycles cost evolves based on those parameters?
There was a problem hiding this comment.
You mean explicitly including the formula that the computation is based on?
There was a problem hiding this comment.
For example, or having a link to that formula. Otherwise, how am I supposed to know that if say transformed_response_bytes increases, then the cycles cost of the HTTPs outcall also increases?
There was a problem hiding this comment.
how am I supposed to know that if say transformed_response_bytes increases, then the cycles cost of the HTTPs outcall also increases?
I wouldn't expect the cost to decrease if some input parameter increases. In other words, it should be natural to assume monotonicity of the cost in all its input parameters.
I'm not sure if we need to specify the exact formula - isn't the main purpose of this API to hide the complexity of the formula (and facilitate its change in the future without a need to update all docs and clients)?
6 participants
This PR describes the interface for the new, finer grained pricing model for HTTP outcalls, which should enable lowering the costs of outcalls by around 4x on average.