"Cooperative Traffic Offload" proposal, and the future of Blixt with L7 ingress

[shaneutt]

In the past, we mentioned that we weren't focused on L7 ingress, but we kept the option open. During our community meetings, we even considered using projects like Pingora or River for L7 support in Blixt, if someone in the community wanted to lead that effort. This topic has come up repeatedly, and we've stayed receptive.

However, things have changed recently. Our friends and neighbors next door have started an L7 ingress project with the Gateway API at ingate, and our next three milestones will focus more on L3/L4, which aligns better with our project's strengths.

Personally I want to support Ingate's L7 work and not diverting any community members to us when they could go work with them. Instead, I believe we should concentrate on lower-level L3/L4 use cases for our upcoming v1.0.0 release. That said, Blixt was originally conceived as capable of being standalone OR being integrated with another Gateway API implementation to provide L4 ingress support seamlessly via Gateway API where there previously was none (or when you need a faster datapath). This was referred to in passing as "cooperative traffic offload". We haven't been striving for that as a goal for some time, but Ingate seems to provide an opportunity to explore that once more. I propose the following with all that in mind:

• we update our README to officially declare L7 as a non-goal
• in that same section, reference Ingate and encourage L7 interested folks to go join the community there
• create a pre-v1 issue to spike/explore "cooperative traffic offload", and aim to see how Ingate and Blixt might be able to be packaged together and complement each other

Think on this and let me know your thoughts!

[EandrewJones]

Quick thoughts:

we update our README to officially declare L7 as a non-goal

+ 1 from me. Although I am personally interested implementing L7 features in rust, I think the project would benefit from refining it's scope and clarifying goals.

create a pre-v1 issue to spike/explore "cooperative traffic offload", and aim to see how Ingate and Blixt might be able to be packaged together and complement each other

I very much like the idea of treating blixt as a (or the?) L4 implementation for ingate for numerous reasons:

1. I personally believe projects benefit greatly from having a clear, focused and pragmatic use case. Blixt by itself may have very limited appeal, but ingate will surely have healthy adoption, so that's a boon for us.
2. "Cooperative traffic offload" is also an interesting concept to explore from a Gateway API perspective. If we can achieve it with ingate, that can serve as an example from which to build a standard for doing this more broadly.
3. The above reason provides a raison d'etre for Blixt to continue existing in sig-network which I know we've been grappling with
4. If ingate can benefit from L4 work we've already done, awesome!

But I do have a few questions:

1. Would be the L4 implementation for ingate or just something users opt into?
2. Would blixt be "dataplane-only" under this scenario and the controlplane logic stays in the primary gateway implementation the user is using? A "headless" implementation so to speak...

[shaneutt]

The above reason provides a raison d'etre for Blixt to continue existing in sig-network which I know we've been grappling with

Exactly, this was one of the motivations for this proposal 👍

Would be the L4 implementation for ingate or just something users opt into?

I can't speak for James and the other InGate folks, but I'm thinking what we could propose is a future where they could simply package in Blixt to add seamless (the users never have to know its Blixt) L4 support, and see what they think.

Would blixt be "dataplane-only" under this scenario and the controlplane logic stays in the primary gateway implementation the user is using? A "headless" implementation so to speak...

So I looked and I don't think we ever documented the "cooperative traffic offload" idea in the early days, we only discussed it maybe on zooms or on Slack, but to recap: the idea is that any particular GatewayClass could configure a deployed Blixt control-plane in such a way that it would be responsible for TCPRoute and UDPRoute (and heck maybe even TLSRoute) but from the API and user perspective that's opaque they just see it as the implementation as named in the GatewayClass. So the answer is technically "no", because the control-plane would indeed exist and we wouldn't require the implementation (e.g. InGate) to add controllers and integration with the Blixt data-plane, but from a users perspective the control-plane would be an implementation detail.