Remove drain-on-cancel from TCP receive path

[lance0]

Summary

Resolves #54. Removes the 200ms drain_after_cancel step from TCP receive paths (receive_data and receive_data_half), which was polluting time-boxed throughput measurements by continuing to eat peer retransmits after cancel.

For a bandwidth tool measuring a fixed duration, RST-on-close is the correct semantic: abort immediately, don't skew stats with tail retransmits. Natural end-of-test still uses shutdown()/FIN (unchanged).

Background

matttbe (upstream Linux MPTCP maintainer) reported the drain was making it hard to pick a good cancel timeout and skewing results with tail retransmissions:

"To me, if the goal is to measure the transfer during a certain time (vs. a fixed amount of bytes), it feels like the different streams should get reset to stop transferring as quickly as possible."

Codex consultation confirmed no code in the repo depends on the drain — cancel ack and final result travel on the control connection, not the data sockets.

Changes

• Remove drain_after_cancel() function and RECEIVE_CANCEL_DRAIN_GRACE constant
• Remove the two if cancelled { drain_after_cancel(...) } callsites in receive_data() and receive_data_half()
• Remove the now-unused cancelled local variable tracking in both receive loops
• Remove unused AsyncRead import

Side effects

• Peer will see more ECONNRESET on cancel — consistent with 'abort test now' semantics
• Also resolves the WARN Timed out waiting 2s for N data streams to stop that matttbe saw with -P 4 --mptcp + rate limiting — streams now exit in milliseconds instead of waiting for the drain window
• Final TCP_INFO timing in bidir/MPTCP may shift slightly (Codex flagged as non-load-bearing)

Test plan

• cargo fmt --check clean
• cargo clippy --all-features -- -D warnings clean
• cargo test --all-features — all 180 tests pass
• Manual: 30s test with -P 4, Ctrl+C at 3s → exits in 6ms (was up to 2s before), full per-stream summary preserved with accurate 3.00s duration
• Manual: natural end-of-test still uses FIN (graceful shutdown unchanged)

[lance0]

Hi @matttbe — I've pushed a fix here that removes the 200ms drain-on-cancel from the TCP receive path, which should address both the inaccurate time-boxed stats and the "Timed out waiting 2s for N data streams to stop" warning you saw.

Local testing shows cancel now exits in ~6ms (was up to 2s) with full per-stream stats preserved. But before merging, would you mind giving it a try against your MPTCP test setup? Specifically interested in:

1. Does the 2s timeout warning go away with -P 4 --mptcp + rate limiting?
2. Do your time-boxed throughput numbers look cleaner (no tail retransmit drift)?
3. Any new peer-side errors or unexpected ECONNRESET on the sender that weren't present before? (I believe the existing 250ms SEND_TEARDOWN_GRACE on the sender absorbs this, but you'd see it first.)

Build instructions:

gh pr checkout 55
cargo build --release

No rush — I'll leave the PR open until you've had a chance to take a look.

[matttbe]

Hi @lance0,

Thank you for having already implemented this!

I just tried with my old test script, and I still have the issue. It is easy for me to reproduce with a timeout of 1sec.

ip netns exec "${NS}_cli" ./target/release/xfr 10.0.0.1 -P 4 --no-tui --mptcp -t 1sec
 INFO Connecting to 10.0.0.1:5201...
 INFO Connected to 10.0.0.1:5201
 INFO Client connected: [::ffff:10.0.10.2]:44422
 INFO Test requested: MPTCP 4 streams, Upload mode, 1s
[0.163]  0.0 Mbps  0 B  rtx: 0  rtt: 29.69ms
 INFO Test aed0e105-2d65-4844-9b66-ab3bcdb98f8c complete: 22.37 Mbps, 2796160 bytes
 WARN Timed out waiting 2s for 4 data streams to stop; aborting remaining tasks
────────────────────────────────────────────────────────────
  xfr Test Results
────────────────────────────────────────────────────────────
(...)

Did I miss something? I build commit 44b812e after a cargo clean

[matttbe]

I just took a packet trace, I don't see any RST. Did you explicitly reset the streams? (e.g. with setsockopt(SO_LINGER, 0) + close() or shutdown() + handling TCP_INFO)

[lance0]

Great diagnosis — and exactly right. The first commit only removed the receive-side drain, but the actual blocker was stream.shutdown().await on the send side waiting for all buffered data to ACK through the rate-limited path (which easily exceeds the 2s join timeout under MPTCP + tc drops).

I just pushed commit 54dd1c3 which does exactly what you suggested: SO_LINGER=0 on send sockets via socket2::SockRef::set_linger(Some(Duration::ZERO)), and removed the now-redundant shutdown().await calls. TCP_INFO is captured immediately before the socket is dropped, so we keep the final sender-side stats before the RST goes out.

Would you mind giving the updated branch another try? Same build steps, just git pull or gh pr checkout 55 to pick up the new commit. You should now see RSTs in your packet trace and the "Timed out waiting" warning should be gone.

Local repro of your exact case (-P 4 -t 1sec) now completes cleanly with no warning.