fix: lowpower config in Swarm.ConnMgr

[lidel]

Closes #2039 by applying lowpower values to Swarm.ConnMgr for new and existing users:

  config.Swarm.ConnMgr.GracePeriod = '1m'
  config.Swarm.ConnMgr.LowWater = 20
  config.Swarm.ConnMgr.HighWater = 40

I've run it for a while and works fine, peer count jumps to few hundreds when needed, and then dials down after a minute or two.

This is a pretty safe one-time migration.
We can always adjust it further in the future releases.

[RubenKelevra]

Agreed, I use similar values for a long time. But I would recommend to extend the grace period to something like 3 minutes to avoid that connections get dropped too early.

One minute seems a bit too restrictive if you consider usual user behaviour in a browser.

[RubenKelevra]

@lidel have you seen my comment? :)

[lidel]

@RubenKelevra yes, but we already increased it to 1m, when compared to go-ipfs defaults.
If you feel this should be increased, feel free to open a new PR with rationale why (the benefit is unclear to me, but i am happy to learn) 🙏

[RubenKelevra]

@lidel let's discuss this here. I'm happy to make a PR after we came to a decision :)

So the idea of setting it to 3 minutes is simple:

If you open a webpage etc. you open a lot of new connections to search in the network for the data you're looking for.

After this, a user usually "uses" a webpage for a while until the next navigation event.

If the navigation event happens after one minute has passed, the chance is high that we have already terminated the connections, as they are so new that they are not deemed "useful" for IPFS (yet). If the navigation is within the same webpage we will significantly slow down the browsing experience, as bitswap can't flood-ask the node which provided the current webpage for the next one, but we instead need to go through the DHT to find the providing node.

This might have been an issue before, but probably not as serious, as the connections were not cut down to such a low amount. So there was a much larger chance that a connection stays open if we currently fetch data from them in short intervals.

[lidel]

@RubenKelevra your reasoning is sensible, but the "3 minutes" value seems arbitrary, just like "1 minute" was, right? I could say that either the user navigates to the next page within 1 minute, or stays there for longer (e.g. spends 4 or 10 minutes reading an article or watching a video) :)

I am ok with changing GracePeriod but we should avoid gut feelings going forward, and base value on some UX research data.

Namely: how long people spend on a web page withing a single Origin, on average/median?

I think such papers/stats exist somewhere, if you have time to dig them out, I'm happy to accept change. 👍
(it would also be good basis for creating desktop profile in go-ipfs itself with these values)

[RubenKelevra]

Well if the user streams a video the connection(s) will provide a lot more data. So if the website and the video is send from the same source there shouldn't be an issue, as IPFS would surely rate this node more useful than those used find the server via DHT query in the first place.

There are some (a bit older) statistics about the "length of stay" on a single webpage which is quoted to be 40 seconds.[0]

I picked 3 minutes because it "feels" sufficiently above the 40 seconds average and is close to the quoted read time I often see on news articles. I found some statistics on that.[1]

Additionally I looked up the default keep alive timeout for Firefox[2] which is like 2 minutes. Given that we need to do substantially more work if we disconnected I think it is safe to assume that 3 minutes is a good value.

[0] https://de.m.wikipedia.org/wiki/Verweildauer_(Internet)
[1] https://www.google.com/amp/s/blog.chartbeat.com/2020/04/15/most-read-articles-engagement-data/amp/
[2] http://kb.mozillazine.org/Network.http.keep-alive.timeout

[RubenKelevra]

@lidel wrote

(it would also be good basis for creating desktop profile in go-ipfs itself with these values)

You're sure we need an additional profile? I always thought the default profile is for desktops (and that's the reason why we have a server profile).

[lidel]

re: 3m proposal, see my reply in #2096 (review)

You're sure we need an additional profile? I always thought the default profile is for desktops (and that's the reason why we have a server profile).

Yes, we need it to remove ambiguity like this, and to make it easy to undo server settings.

[RubenKelevra]

Ah okay. So the default stays there as "works in most cases" while the server/desktop profiles are optimized for the usecase.