Proposal: Native SCION Transport & Multipath Support

[martenwallewein]

Hi everyone,

We have developed a native transport for SCION (a path-aware, next-gen Internet architecture) in go-libp2p. We want to align with the core team before opening a PR, as our implementation introduces some unique multipath behaviors.

1. SCION Addressing (Multiaddr)

To enable dialing and listening on SCION, we have defined a new multiaddr format that encapsulates the SCION ISD-AS (Isolation Domain - Autonomous System) identifier.

Format: /scion/<ISD-AS>/<Host-Multiaddr>

Example:
For a node in ISD 19, AS ffaa:1:f, wrapping a standard UDP/IP endpoint:

/scion/19-ffaa:1:f/ip4/10.0.0.1/udp/123

Status:

• We have registered the codec in multicodec PR #325.
• We have submitted a PR to implement this in go-multiaddr: multiformats/go-multiaddr#285.
• Note: The merge of the go-multiaddr PR is currently a blocker for opening our PR against go-libp2p, as the transport relies on validation logic within that library.

2. Multipath Transport (QUIC)
To leverage SCION's multipath capabilities, our transport differs from standard QUIC:

• Path Pinning: Instead of migrating a single connection, we establish distinct QUIC connections for each available SCION path.
• Pooling: These connections are pooled to allow upper layers (like Bitswap) to stripe requests across multiple paths simultaneously.
• Current Code: netsys-lab/go-libp2p/feature/scion-quic-transport, needs to be rebased on newest version of go-libp2p

Questions for Maintainers:

1. Architecture: Do you see any issues with our "connection pooling" approach (multiple physical connections per logical peer) fitting into the current Transport interfaces?
2. Dependencies: Since we rely on the unmerged go-multiaddr PR, what is the preferred workflow for proposing the transport implementation here?
3. External Components: Any concerns regarding a transport that relies on communication with a local daemon (the SCION dispatcher)?

Thanks!

[MarcoPolo]

Do you have any technical resources to learn more about SCION?

The biggest concern for me is the local daemon aspect. It is a big difference from how other transports work in go-libp2p.

Is there something about the current project that prevents this transport from living out of tree? Same question applies to the the go-multiaddr PR. I think you should be able to keep all of this in a separate repo. Would it help to have a separate Go package for the core interfaces as done here: #3384?

[martenwallewein]

Hey @MarcoPolo thanks for the reply!

Here are some more links to SCION:

• Github Repo
• Docs
• Connectivity Check and Getting Started

The aspect with the daemon is a reasonable concern. In current efforts, the daemon will be replaced by a pure end-host API, which means we remove the dependency on this additional service.

Regarding your question about keeping this out-of-tree:

We are open to maintaining the core logic of the transport in a separate repository (similar to how go-libp2p-quic-transport started). However, there are specific reasons why we are pushing for upstream changes, particularly regarding go-multiaddr:

1. First-class Multiaddr Support: For the transport to be usable by the wider community without forking the entire dependency chain, /scion needs to be a recognized protocol in go-multiaddr. Without this upstream support, any application trying to use our transport would fail address validation before it even reaches our code.
2. Multipath & Connection Management: As mentioned, our transport stripes data across multiple SCION paths. This "connection pooling" interacts complexly with the go-libp2p Network and Swarm logic. Developing this fully out-of-tree risks implementing "hacks" to bypass standard connection managers. Collaborating on this ensures that the interfaces for next-gen multipath architectures are defined correctly in the core.
3. Adoption & Standardization: SCION is moving toward production readiness. Having native support in the go-libp2p ecosystem (even if the heavy implementation lives in a separate module) would lower the barrier to entry significantly for decentralized applications wishing to experiment with path-aware networking.

In summary: We are happy to keep the heavy implementation logic in a separate module/repo, provided that the Multiaddr definitions and necessary Transport interfaces for multipath support can be upstreamed.

Does that sound like a reasonable path forward?

In any case, we're happy for further input to bring SCION and libp2p together!
Cheers,
Marten