Implement multipath functionality from RFC 9622/9623

[zamderax]

Overview

This issue tracks the implementation of multipath functionality as specified in RFC 9622 (Transport Services API) and RFC 9623 (Implementation Guide). The current implementation is single-path TCP only, and multipath support needs to be added for protocols like MPTCP and QUIC multipath.

Areas Where Multipath Functionality Was Omitted

1. Connection Endpoint Management

Location: src/connection.rs:625-626, 654-657, 676-677, 704-707

• When adding remote endpoints via add_remote(), the implementation currently only supports single-path TCP
• Comments indicate: "In a real implementation with multipath support (like MPTCP or QUIC), we would add this to a list of available endpoints"
• Similar limitations exist for add_local() endpoint management

2. Path Monitoring Integration

Location: src/path_monitor/integration.rs:54, 58, 63

• TODO comments indicate missing connection migration support when paths change
• Missing implementation for triggering failover when current path goes down
• Path monitoring events are captured but not acted upon for multipath decisions

3. Connection Racing/Happy Eyeballs

Location: src/preconnection.rs:100-146

• The initiate() method only attempts connection to the first endpoint
• No implementation of parallel connection attempts (racing) as specified in RFC 9622
• Missing Happy Eyeballs algorithm for IPv4/IPv6 dual-stack scenarios

4. Multipath Protocol Selection

• Current implementation hardcodes TCP as the only transport protocol
• No support for MPTCP or QUIC multipath variants
• Transport protocol selection doesn't consider multipath capabilities

5. Platform-Specific Considerations

Location: src/path_monitor/windows.rs:149

• Windows implementation has TODO for detecting expensive connections via connection profile API
• This information is needed for multipath policy decisions

Path Monitor Module

We have added the path_monitor module (src/path_monitor/) to assist with multipath implementation. This module provides:

• Platform-specific network interface monitoring (Apple, Android, Linux, Windows)
• Detection of interface changes, additions, and removals
• Interface type detection (WiFi, cellular, ethernet, etc.)
• Connection expense detection (partially implemented)
• Integration points for multipath policy decisions

Implementation Requirements

1. Extend Connection State

   • Track multiple active paths/subflows per connection
   • Implement path selection and scheduling algorithms
   • Add support for path migration and failover

2. Implement Connection Racing

   • Parallel connection attempts to multiple endpoints
   • Happy Eyeballs algorithm for IPv4/IPv6
   • Proper cancellation of redundant connection attempts

3. Protocol Support

   • Add MPTCP support for multipath TCP
   • Add QUIC multipath support
   • Implement protocol negotiation based on multipath requirements

4. Policy Implementation

   • Implement Active, Passive, and Disabled multipath policies from RFC 9622
   • Consider interface types and expense in path selection
   • Implement proper path scheduling based on policy

5. API Completeness

   • Fully implement add_remote() and add_local() for multipath scenarios
   • Add methods for querying available paths
   • Implement path-specific statistics and properties

References

• RFC 9622: Transport Services Architecture
• RFC 9623: Transport Services Implementation Guide
• Section 6.2.14 of RFC 9622: Multipath Transport Properties
• Section 7.2 of RFC 9623: Path Changes Handling

[zamderax]

Note MPTCP is already supported Network.framework but Tokio doesn't use it. However take a look at https://crates.io/crates/mptcp (this library says it's only for macOS but I"m not sure if it supports other Apple / Darwin platforms)