wip: some congestion trickery

[Arqu]

Description

Split off from the original PR as this is dubious whether it's useful but interesting to test a bit.

Breaking Changes

Notes & open questions

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.
  • List all breaking changes in the above "Breaking Changes" section.
  • Open an issue or PR on any number0 repos that are affected by this breaking change. Give guidance on how the updates should be handled or do the actual updates themselves. The major ones are:
    • quic-rpc
    • iroh-gossip
    • iroh-blobs
    • dumbpipe
    • sendme

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/3493/docs/iroh/

Last updated: 2025-10-08T06:39:56Z

[github-actions]

Netsim report & logs for this PR have been generated and is available at: LOGS
This report will remain available for 3 days.

Last updated for commit: 7d926d7

[dignifiedquire]

the jitter part makes sense to me in general, @flub I am wondering is there sth in multipath/quic to deal with this issue, seems like problem that could happen there as well

[flub]

the jitter part makes sense to me in general, @flub I am wondering is there sth in multipath/quic to deal with this issue, seems like problem that could happen there as well

So the idea is to always add some jitter when scheduling a holepunching attempt in the future?

[Arqu]

Closing this PR but keeping the branch as future reference. Unsure if we should file the jitter stuff as an issue to do at a later point?

[flub]

Closing this PR but keeping the branch as future reference. Unsure if we should file the jitter stuff as an issue to do at a later point?

Can you please file the jitter thing as an issue? Because I already forgot the details. Maybe even as a sub-issue of the multipath issue (#3276 ), though definitely on one of the pre-1.0 milestones.