A93: xDS ExtProc Support#484
Conversation
|
@kannanjgithub @eshitachandwani @rishesh007 FYI, it looks like we don't actually have a use-case for the mode override feature, and the logic for that is a little ugly, so I've removed it from the design. We can consider adding it in the future if/when we encounter a use-case for it. |
| control back to the sender) until its corresponding write has passed | ||
| flow control. For example, for path (1) above, when reading client | ||
| messages from downstream, the filter will not release flow control back | ||
| to the downstream until its write to the ext_proc sidestream has cleared |
There was a problem hiding this comment.
What does until its write to the ext_proc sidestream has cleared flow control. mean? Does it mean until we have written that message to side stream or does it mean until we have received window update for that message?
There was a problem hiding this comment.
We don't actually have to have it fully written to the sidestream, but we do have to have allocated enough flow control to send it at both the ext_proc layer and the HTTP/2 layer.
I've attempted to clarify the wording here.
| DATA frames as HTTP/2 does, which would allow making incremental | ||
| progress. | ||
|
|
||
| The initial window sizes for all four paths are set by the filter in |
There was a problem hiding this comment.
Where are FlowControlInit initial window sizes to be set by the filter taken from? Should we add them to GrpcService config?
There was a problem hiding this comment.
I think each data plane implementation needs to figure this out on its own. A simple implementation would be to just use hard-coded values. But data planes may ultimately want some mechanism to dynamically tune these values when they are under memory pressure. In C-core, we plan to eventually use our ResourceQuota mechanism to do that.
I don't think it's appropriate to set these values from the control plane, because the control plane cannot know how much memory pressure a given data plane is under.
| send a window update that reduces the window, but it must be prepared | ||
| to handle any data that the sender has already sent. | ||
|
|
||
| As the receiver reads data, it must send back a window update telling |
There was a problem hiding this comment.
The design doc says : The receiver SHOULD reset the GRPC stream with a protocol error otherwise. Should we add that here too? Also what does it mean to reset the stream? Is it equivalent to the stream failing with non-OK status or something else?
7 participants
No description provided.