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

[shaneutt]

Previously in this project we have been open to adding L7 ingress support. Recently, the Ingate project has emerged for L7 ingress with Gateway API. So first off I propose we update our README to officially declare L7 as a non-goal, and let L7 be focused on in Ingate so we're not stepping on each other's toes.

Secondly: This project was originally conceived to be capable of deployment as standalone OR being integrated with another Gateway API implementation. We've referred to the integrated mode as "cooperative traffic offload", and the basic idea is that any GatewayClass that doesn't support TCPRoute or UDPRoute could use Blixt to handle those route types for it, but in a way that's fairly seemless for the user (e.g. they use the same GatewayClass and Gateway that they otherwise would use, but the offload to Blixt happens under the hood).

I want to propose that we make this an explicit goal of the project, and work with the Gateway API community for any API-enablement that would be needed to support it.

[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 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 they would operate on the same resources so the user doesn't perceive it.