Hi Umesh,
On Fri, Jun 02, 2023 at 10:27:48AM +0530, umesh patel wrote:
> Hi There,
>
> I am looking for SCTP protocol based load balancer. I see that HaProxy has
> a solid platform for TCP load balancing. However, SCTP is not supported. I
> would like to develop and contribute to HaProxy SCTP support. I will start
> with SCTP unihomed connections and then graduate on to support the SCTP
> multi-homing support.
>
> I would like to know, how can I join the development and contribute to the
> enrichment of the HaProxy load-balancer.
There are several aspects in your question. Some of them are purely
technical (i.e. use IPPROTO_SCTP vs IPPROTO_TCP), other aspects will
touch the architecture (SCTP being multi-stream, how to support this),
and the last one is how to integrate yourself into the development
process.
As for every significant addition, what is important is to figure how
the feature will be added, not in the short term but in the long term,
so that it is possible to identify the changes to be performed on the
various areas to be compatible with what you'll need. This is critically
important because we don't want to add a partial feature, then figure
we're in a dead end and say "sorry users, we're driving back, there's
no exit here, we'll completely change the way you're using it and trying
another approach". This often means that it can take quite some time to
add some new features, but when you finish, you feel like they fit
perfectly in place. There will always be rough edges, but they must not
affect how end users will use them over time, nor hinder the evolution
of the rest of the features around. Most of the features that have been
delayed were delayed because of a road block in the way that was left
there along another change completed in a hurry. That's why we've become
extremely cautious over time not to leave road blocks anymore on the way.
QUIC is a great example of how things have evolved. Initially a PoC was
needed to progress on the code, so it was based on a static code base
that didn't change. In parallel, the various identified parts that were
identified as problematic were improved. Then the code started to be
rebased on more recent versions to benefit from these parallel changes.
Over time the muxes API, listeners, protocols, threads, datagram
processing, polling, buffers etc had to evolve to offer a natural
interface to the lower layers that QUIC needed, and if you look at it
today it fits smoothly there, but internally it has not always been the
case.
Similarly I expect SCTP to require some changes. Which ones, I don't
know. It also depends what you want to transport on top of it. For
example, right now our muxes deal with low-level stream multiplexing
that is found in HTTP/2 and QUIC, and to a less extent HTTP/1 (which
supports multiple streams per connection but one at a time but
perfectly delimited for the request and the response). Thus it would
seem natural that SCTP gets its own mux and offers multiple streams
per connection. But to transport what ? Because if we need to place
some HTTP on top of it, then we'll face a new problem given that the
various HTTP versions already have their own muxes. And if the goal
is to just transport SCTP from a client to a server and maintain the
streams together over the same connection, this could probably be
done as well but it will involve outgoing connection reuse and for
now this is only done for HTTP. Also the action of choosing a server
(and possibly inspecting contents) is currently done per stream, so
if we want to tie them all together it will mean again something a
bit different that has to be defined.
Last, but not least, a very important aspect is the maintenance. Are
you sufficiently interested in SCTP to accept to keep working on it
for 5-10 years after it's offered to end users ? That's important
because you don't want the feature you freshly added to start failing
in field with nobody able to debug it. And sometimes when analysing
the cause of some failures, the conclusion is harsh, like "OK the
design is totally f*cked, it needs to be redone from scratch", which
indicates that you'll need to continue supporting existing code base
in best effort mode (i.e. plugging holes) while trying to rework on a
better approach for a future version.
We've seen all this over time, that's why I prefer to warn in order to
gauge your motivation ;-)
If you think this matches what you have in mind, I can recommend you to
start to think about what your longterm goal with SCTP would be, and
what intermediary steps would be acceptable, then study how that would
fit with what exists and if it looks sane or hackish. Then you'll need
to think, based on the services that will be transported over that
protocol, what will users need in the future and if it will be possible
at all to serve them (e.g. interface TCP<->SCTP, mux/demux SCTP
connections, content inspection and processin
