Hi Abhijeet,
On Mon, May 22, 2023 at 12:30:52PM -0700, Abhijeet Rastogi wrote:
> Hi Willy,
>
> Thank you for the response. It's great to know that this might be
> considered as a feature request in future versions, pending
> prioritization though.
>
> Could you comment on why this isn't already a feature yet?
Huh ? It's not easy to comment on an existing state. It's the combination
of what people needed, what is already available and what can cause trouble.
> It is hard
> to believe that we're the first to come across this draining problem
> when using a chain of "L4 to L7 proxies". Are there any alternative
> approaches that we should look at, to get around the current
> limitations?
Others are likely doing this using a regular soft-stop. During the
soft-stop, there will be a combination of active and passive closures
on idle connections (you can even decide over how long a time you want
to close them all so that you don't suddenly close too many of those
such as to avoid an inrush of traffic on other nodes). So the "normal"
way to stop traffic to an L7 node in an L4+L7 setup is:
1) disable sending new connections to the L7 node (set its weight
to zero or make it fail a health check for example)
2) send the soft-stop signal to haproxy
3) wait for the process to be gone after the last connection is
closed
If you're dealing with a reload, the old process automatically passes
through the soft-stop phase and does this without having to fiddle with
a front L4 LB.
The case where users would like to close H2 connections actually is more
when they want some connections to re-establish on another node without
reloading the first one. Typically when moving a small portion of the
traffic on a node having a new config just to test it. In such cases it
would indeed be desirable to make it possible to close connections
earlier. But doing so is not without consequences. For example, if you
close immediately after finishing the last stream, you could make your
local TCP stack send RSTs due to the client sending WINDOW_UPDATEs to
acknowledge receipt of the data, because TCP doesn't know that
WINDOW_UPDATES are just ACKs and do not convey useful data that could
be drained like empty ACKs. I do have some plans to work around this
protocol deficiency that's already in an old issue (I think it's #5 but
not sure) which would consist in sending an ACKed frame after the GOAWAY
(or in any case before closing), so that we know when the peer received
the last frame. This could be a PING or a SETTINGS frame (more interesting
as we could advertise max_stream=0 there). But it means adding a new state
to the existing state machine and validating that we don't break existing
implementations for example.
Nothing is impossible and I would really like to have a way to gracefully
close connections, at least because there are situations where it's
desirable. But it must not be seen as a one-size-fits-all solution. In
you case, if it's only for taking off a node from an L4 LB farm, I can't
see any limitation to the existing solution.
Regards,
Willy
