Congestion and Deployment EN

English · 简体中文

Congestion and deployment boundaries

What the library controls

Reliable delivery uses ACK/NACK, ACK-gap fast retry and bounded timeout backoff. The original send path has a fixed reliable flight limit; optional SendOptions exposes explicit frame/byte limits, queue budgets and flush bursts. These are local flow/queue controls, not an adaptive bandwidth estimator or TCP/QUIC-style congestion window algorithm.

RecoveryOptions can wake at retry deadlines and probe eligible tails. It does not add congestion detection, rate pacing or a dynamic bandwidth controller. Independent reliability channels share one underlying network path.

When a link collapses

If available bandwidth falls from 100 Mbps to 2 Mbps and RTT grows from 30 ms to 800 ms, a producer maintaining its old rate can fill application, transport, kernel and bottleneck queues. The fixed flight window bounds part of the outstanding reliable work; it cannot by itself keep bottleneck latency low. Some queues may drop packets.

Queue drops produce the same ACK/NACK symptoms as random loss. Fast retries can add offered load; timer backoff delays repeated retries, while fresh unambiguous RTT samples adjust SRTT/RTO. The implementation does not classify loss as random versus congestion. Karn exclusion and time for fresh feedback mean adaptation is not instantaneous. ACKs can continue while business messages wait behind ordering gaps.

Do not promise stable low latency under arbitrary sustained overload. The historical recovery step experiment tested a particular link and workload; it is not a congestion-fairness guarantee. The README's random-loss loopback benchmarks do not validate congested WAN behavior.

Application controls

1. Bound pending jobs and active sessions before submitting sends. Monitor application queue age as well as throughput.
2. Choose UnreliableSequenced for replaceable state and coalesce stale updates in the application. A pending unreliable message is not automatically a globally prioritized packet.
3. Set flight limits for measured RTT and payload sizes. A smaller window can reduce offered bursts but can also cap throughput; larger queues can increase waiting without adding link capacity.
4. Apply explicit application rate limits or pacing when several peers share a known bottleneck. SendOptions has no packets-per-second or Mbps setting.
5. Compare default/policy builds, random loss/queue loss, abrupt steps/recovery, and sparse/sustained load. Record RTT ranges, verified delivery, queue/drop counters and fairness against other traffic.

For link tests, use task-specific private network namespaces or disposable VMs and namespace-local shaping only. Do not change host qdisc, routes or sysctl.

Security and Internet exposure

This library does not provide TLS, authenticated encryption, peer identity or business authorization. An address, GUID or successful transport handshake is not identity verification. Reliable delivery does not authenticate message contents.

Receive/reassembly bounds protect finite resources; they are not a complete Internet-facing abuse defense. Applications need admission limits, bounded deserialization, per-peer quotas and their chosen authentication/security layer. Adding a payload security layer must respect message framing, MTU and interoperability requirements.

Platform and integration

Ordinary async/blocking APIs target the platforms supported by their dependencies. Socket sharding and recvmmsg receive batching are Linux-only; guard these calls with #[cfg(target_os = "linux")]. Do not assume Windows/macOS expose those methods.

There is no built-in Sans-I/O interface, nonblocking polling API or Bevy plugin. Use asynchronous tasks or a dedicated blocking network worker and bounded application queues for event-loop integration.

Send policy · Recovery · High concurrency