MEHS / Knowledge base

MEHS transport migration and recovery

Status: The client has live TCP/QUIC path selection, migration wiring, and reconnect/recovery. The migration state controller and bounded retransmission/reordering behavior have been tested with deterministic fault injection. Live migration was manually verified on loopback (TCP to QUIC under injected TCP latency, with downloads continuing); that end-to-end scenario has not received broader interoperability validation. This document describes evolving behavior, not a stable cross-implementation protocol guarantee.

1. Goals

Switch between TCP/TLS and QUIC data paths without resetting the logical MEHS session. Both carry the same MEHS frames under the selected profile (mehs-data/1, xhttp, trusttunnel, or notmehs; HTTP/2 over TCP, HTTP/3 over QUIC). Preserve ordered reliable stream data and deduplicate retransmissions. A transport change should not require the application to reconnect, provided at least one path and the server-side logical session remain alive.

This does not promise zero latency or uninterrupted delivery through permanent server failure or a total network outage.

2. State machine

  1. ACTIVE(A): path A carries new data.
  2. PREPARING(B): establish and authenticate path B while A remains active.
  3. READY(B): B passed peer authentication, session binding, and path-health checks.
  4. MIGRATING(A→B): new frames are assigned to B; A can still deliver in-flight frames and ACKs.
  5. DRAINING(A): resend unacknowledged logical frames over B using their original sequence IDs; accept late frames and ACKs from A; deduplicate at the session layer.
  6. ACTIVE(B): all outstanding data assigned to A has been acknowledged or safely retransmitted and accepted through B; close A.
  7. ROLLBACK(A): if B fails while A is healthy, cancel A's close timer and return all new traffic to A.
  8. FAILED: no eligible path is usable or the server-unreachable threshold is reached; notify the application and stop attempts if terminal.

Only one path is the authoritative sender for each newly assigned frame at a time. Retransmissions may travel on the replacement path, but the same sequence ID must never be delivered twice to the logical flow.

2.1 Transitions and invariants

A path-failure event is applied by path ID; events naming a path outside the current state are stale and ignored.

StateEventNext state
Active(A)A failsFailed
Preparing(A→B)B failsActive(A)
Preparing(A→B)A failsFailed
Draining(old A, new B)B failsActive(A) (rollback)
Draining(old A, new B)A failsActive(B)
Failedanyerror (new controller needed)

Sender/receiver sequence, ACK, and deduplication state is path-independent and survives every transition. Unacknowledged frames stay queued until acknowledged, so after any transition retransmitting all outstanding frames on the surviving path redelivers them with their original sequence IDs. Stale-epoch frames are rejected; duplicate ACKs/data are no-ops; buffers are bounded and full buffers apply backpressure (SendBufferFull/ReceiveBufferFull) rather than dropping acknowledged data.

3. Timers and thresholds

These are initial defaults for benchmarking, not universal network-optimal values. Server policy may tighten limits.

A candidate timeout alone does not trigger terminal failure while another path remains healthy. The 15-second terminal threshold applies only when all eligible paths are unreachable. If an active path remains healthy, keep it while testing candidates.

4. Packet handling during migration

5. Drain deadline

At the 60-second deadline, stop using A for new traffic. Before closing A, resend all still-unacknowledged logical frames over B and keep the receiver's deduplication state long enough to cover delayed packets. The deadline is not permission to discard reliable stream data.

If B is not healthy at the deadline but A is healthy, cancel retirement and roll back to A. If neither path is healthy, enter the failure policy. Never close the only healthy path merely because the timer expired.

6. Rollback

If B fails before A has been retired:

The initial user requirement explicitly calls out rollback to TCP. The same safe rule should generalize to any still-healthy old path, unless server policy pins a transport and forbids rollback.

7. Server reachability and terminal failure

When no eligible path can reach/authenticate with the server for 15 consecutive seconds:

Do not infer a server restart from one failed socket alone. Use the threshold across all allowed paths and authenticated health checks. If a protocol-level terminal server error is received, it can trigger immediate terminal failure.

8. Device sleep/wake

The OS may suspend timers and sockets during sleep; continuous connectivity cannot be guaranteed by core behavior alone. On wake, check active-path health, preserve the logical session if the path remains valid, and otherwise run the normal candidate evaluation and migration flow. If the server-unreachable threshold is reached, follow terminal failure rules.

9. Acceptance tests