Review SSU max concurrent messages

[zzz]

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.

[jogger]

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.

[zzz]

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.