Opened 2 years ago
Last modified 23 months ago
#2512 new defect
Review SSU max concurrent messages
| Reported by: | zzz | Owned by: | zzz |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.9.42 |
| Component: | router/transport | Version: | 0.9.40 |
| Keywords: | Cc: | Zlatin Balevsky, jogger | |
| Parent Tickets: | Sensitive: | no |
Description
As raised by jogger in #2505. See PeerState?.
- Is MIN_CONCURRENT_MESSAGES too low? currently 8, never been changed since the start of SSU in 2006.
- Is strategy to increase the current max too conservative? Or the strategy to decrement too aggressive? I've seen as high as 150, but vast majority of conns seem to hover in 8-15 range
- Do we need this at all, or is congestion window (which counts bytes instead of messages) sufficient? Having a 2nd one punishes conns with lots of small messages.
Adjusting this could potentially increase SSU bandwidth a lot. I don't think we've ever taken a look at this code closely.
Change History (6)
comment:1 Changed 2 years ago by
comment:2 Changed 2 years ago by
yeah, for starters I just want to look to see if there's a stat or log for it being rejected for over the limit. Sounds like you didn't see it happening, which is good.
comment:3 Changed 2 years ago by
| Sensitive: | unset |
|---|
Add a subticket #2576 (Do not use message-based window in SSU).
Note: See
TracTickets for help on using
tickets.
This is a strange one. Depends on your ISP. My setup: 2 identical i2p routers connected to same internet router connected to 2 ISPs. One ISP (poor quality) is IPv4 only, so I am routing IPv4 from one i2p router through it. IPv6 always goes to the other ISP, which is technically known good.
For the good ISP there never (> 1700 rejects sampled) is a reject because of concurrent messages, but lots of rejects for the poor ISP. Changed the routing table to only use the good ISP and these rejects stopped immediately.
Obviously the concurrent messages logic is there for a reason. But to analyze we would need a network specialist sitting on a line that produces these rejects. And even if she comes up with a solution, this solution might not be perfect if a different ISP uses different parameters. Definitely beyond my scope.