Opened 5 years ago

Closed 5 years ago

#1319 closed defect (not a bug)

Router seems to be rejecting tunnels (bandwidth limit) when bandwidth is not even near capacity

Reported by: somewon Owned by:
Priority: minor Milestone:
Component: router/general Version: 0.9.13
Keywords: bandwidth, tunnels, limit, rejecting, network, performance, router Cc:
Parent Tickets: Sensitive: no

Description

What I did:

After my router had been up for some days, and was puttering along happily using pretty much its full bandwidth capacity for participating tunnels (yay!), I needed some of that bandwidth back for a short time.

So, I went to the bandwidth config page at http://127.0.0.1:7657/config and reduced my available I2P upstream bandwidth approximately in half.

After an hour or three, I was done with that bandwidth and returned to /config and set my upstream limit back to where it had been, or possibly a value within a couple of KB of the original, higher value.

However, it now seems like my router is still behaving under the old upstream limit - I'm getting "Rejecting tunnels: Bandwidth limit" errors even when the 3sec bandwidth figure after the slash is well, well below anything like the proper, original limit. It is in fact right in the range of the temporary, lower limit that I had set.

I tried adjusting the upstream bandwidth again, and also changed the downstream limit, just to see if an additional change would "stick," and I was still getting the Rejecting message, even after a full day or so.

Just a few minutes ago, I tried setting the % bandwidth share to a different value, and now it seems like the router is behaving more properly, but it's still a bit soon to tell. But it seems possible that changing the % snapped the router out of its confusion.

It's hard to say exactly what the cause is, but I think this is a somewhat significant problem that could harm the capacity of the network, if other routers are affected as mine is/was.

Thanks for all the work that you devs do, I wish for you all to find some free chocolate today!

Subtickets

Change History (5)

comment:1 Changed 5 years ago by somewon

It's official, now: I2P is behaving as it should after adjusting the bandwidth share percentage. The significant thing seems to have been the change itself - after changing the percentage back, it is still working as expected.

comment:2 Changed 5 years ago by somewon

Hold on. It's more complicated than I first thought.

I'm now back to getting inappropriate tunnel rejections at modest bandwidth use. I've tried adjusting the percentage shared again, and the inappropriate rejections remain.

I'm beginning to suspect that actually what might be going on is that the router is declaring my bandwidth "full" based on my DOWNstream usage, even though my downstream limit specified in /config is more than ten times my upstream limit.

This trend started happening at about the time that I added about a dozen new torrents into I2PSnark, which began increasing my downstream bandwidth usage a great deal. Where previously my downstream and upstream tended to stay at about the same rate, since this "bug" appeared my downstream is pretty consistently about double my upstream amount. However, the downstream traffic is still only about one-fifth of the specified downstream limit, but often over the specified upstream limit (sometimes nearly double it).

The router is clearly not just rejecting tunnels when the downstream traffic exceeds my upstream allowance - right now, my downstream is just over my upstream limit and I'm still "Accepting tunnels." But it DOES begin to reject tunnels when my upstream traffic is only about half of the allowance, while the downstream is about four times that (double my upstream allowance).

I suppose there's a good chance that this isn't a "bug" at all - that I2P has some algorithm which is a bit conservative to determine when to reject tunnels that allows some "room for expansion" in the bandwidth usage. But I would say that rejecting tunnels at only half capacity seems a little TOO conservative, in my opinion.

I would love to provide some good logs for this stuff - can anyone help me figure out how to get logs that would be relevant? Are tunnel rejections at level "WARN"? Or is there some log override that is specific to tunnel rejection based on bandwidth ("socketfull"?)?

Any advice, including telling me that I'm a fool and this is good behavior, is completely welcome.

Thanks again to all the devs working on this project, towards a better world!

comment:3 Changed 5 years ago by somewon

Bandwidth limits are behaving as normal after restarting the router and rebooting. So whatever it is, it's transient, but real.

comment:4 Changed 5 years ago by zzz

Component: unspecifiedrouter/general
Milestone: 0.9.14

comment:5 Changed 5 years ago by zzz

Resolution: not a bug
Status: newclosed

Transient rejections can happen. We gather stats and make decisions based on what happened recently. All this is normal. We can fine-tune the estimation and filtering and time periods but it all comes down to an assessment of what various limits are and when we exceed them or get close. There's about 20 possible places in the code where a tunnel can get rejected.

Note: See TracTickets for help on using tickets.