SBA transport beyond HTTP/2: benchmark harness + feature-gated HTTP/3 (or gRPC) SBI prototype

[parlakisik]

Background

The 5G Service Based Interface (SBI) mandates HTTP/2 + JSON as the transport (3GPP TS 29.500). 6G "SBA 2.0" discussions raise alternative transports — HTTP/3/QUIC and gRPC/protobuf — for lower latency, head-of-line-blocking-free multiplexing, and connection migration. There is no frozen 3GPP Rel-20/6G Stage-3 spec for any of this, so any work here is explicitly non-normative research/education, not a conformance target.

This issue scopes a bounded spike: a benchmark harness plus one feature-gated, off-by-default alternate-transport prototype — not a rewrite of the SBI stack.

Current state

Verified against the tree:

• SBI is HTTP/2 only. The client (libs/nextgcore-sbi/src/client.rs) drives hyper::client::conn::http2::SendRequest / handshake (see client.rs:14, :495, :510). The server (libs/nextgcore-sbi/src/server.rs) uses hyper::server::conn::http2. Workspace pins are hyper, hyper-util, h2 (src/Cargo.toml:92-95); Cargo.lock contains no h3, quinn, quiche, tonic, or prost.
• SbiClient and SbiServer are concrete structs, not traits. SbiClient is defined at client.rs:291, SbiServer at server.rs:758. The only trait in the crate is SbiRequestHandler (server.rs:206), the app-level request callback — not a transport abstraction. There is currently no seam to plug an alternate backend into, so introducing a minimal transport trait (or a self-contained parallel module) is part of this work.
• A gRPC type stub already exists but does no I/O. libs/nextgcore-sbi/src/grpc.rs (435 lines, gated by #[cfg(feature = "6g-extensions")], re-exported in lib.rs) defines GrpcServiceType, GrpcMethod, GrpcConfig, GrpcMetadata, GrpcStatus, and GrpcServiceRegistry. Its module doc says it "models service/metadata types but performs no wire-level gRPC I/O" and is "explicitly out of scope for the TS 29.500 conformance work."
• A QUIC placeholder exists, but for the RAN/NGAP plane, not SBI. libs/nextgcore-sctp/src/quic.rs defines QuicTransport/QuicServer/QuicConfig as a "forward-looking placeholder"; connect, send_stream, accept, send_0rtt etc. return QuicError::NotImplemented or are stubbed. It is not wired to SBI and has no real QUIC dependency.
• No benchmark harness. No benches/ directory anywhere in src/, and no criterion dev-dependency.

Net: alternate SBI transports are documented intent + inert type stubs, with zero wire-level implementation and no baseline measurement.

Proposed work

Keep everything behind a Cargo feature and off by default. Do not modify any NF binary's runtime behavior.

• 1. Baseline benchmark harness (do this first — it is verifiable on its own).
  • Add a criterion dev-dependency and libs/nextgcore-sbi/benches/transport.rs.
  • Benchmark the existing HTTP/2 path end-to-end: spin up an in-process SbiServer with a trivial SbiRequestHandler returning a fixed JSON body, and measure SbiClient GET round-trip latency/throughput on loopback (mirror the in-process server setup already used in server.rs tests around server.rs:1444/:1522).
• 2. Pick ONE transport for the prototype. Recommend HTTP/3 (via h3 + quinn) because it preserves HTTP request/response semantics and can reuse the existing SbiRequest/SbiResponse/ProblemDetails JSON types with minimal new surface. gRPC/tonic is the alternative and has a head start in grpc.rs types, but requires protobuf schemas and a different message model — heavier for a spike.
• 3. Add a feature-gated prototype module (e.g. #[cfg(feature = "http3")] in libs/nextgcore-sbi/src/), containing a loopback server that serves one SBI-style endpoint and a client that issues one GET, returning the same JSON body the HTTP/2 path returns. Keep it self-contained; optionally introduce a tiny internal SbiTransport trait so the HTTP/2 and HTTP/3 backends share a request/response shape, but do not refactor the existing HTTP/2 hot path.
• 4. Extend the bench to compare HTTP/2 vs the new transport on the same loopback request, gated so it only builds/runs when the feature is enabled.
• 5. Write a short evaluation section (dependency footprint, build-time impact, latency numbers, TLS/cert story, and whether the new deps are worth carrying) as module doc comments or a doc page under docs/ — clearly labeled non-normative 6G research.

Explicitly out of scope: wiring any alternate transport into NF binaries, NRF transport negotiation, and any default-on behavior.

Acceptance criteria

• cargo build -p nextgcore-sbi (default features) is unchanged — no new default dependencies, no HTTP/3/QUIC/gRPC crates pulled into the default build.
• cargo bench -p nextgcore-sbi runs a baseline HTTP/2 SbiClient→SbiServer loopback benchmark and reports numbers.
• The prototype builds only under its feature flag (e.g. cargo build -p nextgcore-sbi --features http3) and does not compile into the default build.
• A feature-gated integration test proves a loopback round-trip over the new transport returns a body byte-identical to the HTTP/2 path for the same request.
• cargo test -p nextgcore-sbi still passes with default features; cargo clippy -p nextgcore-sbi is clean.
• A short evaluation (numbers + dependency/ build-time trade-off + recommendation) is committed alongside the code, explicitly marked non-normative 6G research.

References

• 3GPP TS 29.500 — 5G System; Technical Realization of Service Based Architecture; Stage 3 (defines the current HTTP/2 SBI baseline; the alternate transports here are not covered by it).
• IETF RFC 9114 (HTTP/3) and RFC 9000 (QUIC) — genuinely apply if HTTP/3 is chosen.
• gRPC (grpc.io) / protobuf — applies if the gRPC path is chosen; note 3GPP has no frozen 6G/SBA-2.0 Stage-3 spec for either.
• In-repo files to touch/reference: src/libs/nextgcore-sbi/src/client.rs, src/libs/nextgcore-sbi/src/server.rs, src/libs/nextgcore-sbi/src/grpc.rs (existing type stub), src/libs/nextgcore-sbi/src/lib.rs, src/libs/nextgcore-sbi/Cargo.toml, new src/libs/nextgcore-sbi/benches/transport.rs; prior-art placeholder src/libs/nextgcore-sctp/src/quic.rs.

Effort

M (Medium). The baseline harness is small; the feature-gated HTTP/3 (or gRPC) loopback prototype plus new async/TLS dependencies is the bulk. Not a good first issue — requires async transport, TLS, and new-dependency judgment.