Go-ipfs: Different bandwidth limits for LAN and WAN (subnet-based bandwidth limits)

[Avamander]

When https://github.com/ipfs/go-ipfs/issues/3065 gets implemented it would be nice that it had the option to differentiate between LAN and WAN devices when it comes to bandwidth limiting.

This could maybe be done using IP subnet-based configuration of bandwidth limits.

[RubenKelevra]

As you explained in your forum post, you request this change because multiple instances of IPFS would 'kill' your upload.

This issue is not related to IPFS, but is commonly known as bufferbloat.

When you remove the bufferbloat and mark IPFS packages send by your local nodes with a lower priority than Best Effort, the traffic of IPFS should not affect the network performance at all.

Here's some basic information on bufferbloat (a bit outdated):
https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/

I recommend giving sch_cake a try:

https://www.bufferbloat.net/projects/codel/wiki/Cake/

[Avamander]

You're absolutely incorrect. This is in no way related to bufferbloat.

[RubenKelevra]

You're absolutely incorrect. This is in no way related to bufferbloat.

Interesting, can you give more insight why IPFS would result in a degraded network performance, if you're not having bufferbloat issues and use prioritization on the packages IPFS is generating?

Run this test on the internet connection you're having trouble with, please:
http://www.dslreports.com/speedtest

[bonedaddy]

@RubenKelevra because IPFS is horribly unoptimized and floods your servers with traffic. And there is absolutely no way of limiting the bandwidth.

Telling users to solve their problems by installing some third-party library is a horrible solution. IPFS needs to be fixed really badly because it is garbage with resource utilization

[Avamander]

Run this test on the internet connection you're having trouble with, please: http://www.dslreports.com/speedtest

Just for reference I get an A+ there about bufferbloat.

[bonedaddy]

If the solution to fixing IPFS performance is literally

You need to find a router whose manufacturer understands the principles of bufferbloat, and has updated the firmware to use one of the Smart Queue Management algorithms such as cake, fq_codel, PIE, or others. Here are some resources:

Than IPFS has failed. Stop asking users to try arbitrary fixes when the fix is simple: IPFS is broken AF and needs to be redesigned. That is the ONLY option.

Anything else just pushes the problem under the rug and will never solve the issue

[Avamander]

@bonedaddy there's a thread about this on the forums for discussion of solutions: https://discuss.ipfs.io/t/lan-only-peers-in-a-swarm/7127/14

[RubenKelevra]

@RubenKelevra because IPFS is horribly unoptimized and floods your servers with traffic. And there is absolutely no way of limiting the bandwidth.

Telling users to solve their problems by installing some third-party library is a horrible solution. IPFS needs to be fixed really badly because it is garbage with resource utilization

I can't confirm your findings. I'm currently at around 600 connections and my background traffic is below 200 kbit/s combined in+out.

But there will be some fixes in the upcoming version today/tomorrow to fix some possible issues in the current version - so maybe you're just experiencing one of the bugs?

The only thing I was recommending is sch_cake, which isn't a third-party library - but part of the Linux kernel.

[bonedaddy]

@Avamander unfortunately I don't think that will help. Once official devs at IPFS make up their minds on something they will likely never change their minds, and it seems like they've already decided these things are unnecessary 🤦‍♂️

Overall I don’t see any reason to implement more network options than currently implemented, because you can easily address your edge case with simple firewall rules, which are much more flexible, since they can be changed by the network manager based on your network connections, and don’t have to be handled by the application.

[bonedaddy]

600 connections?? There's literally 50k+ peers on the network. You're not even connected to a noticeable fraction of the network and you're using that to asses your solution???

My findings are from literally 2 years of using go-ipfs on a daily basis and at least once a week for the last 6 months recording benchmarks and profiles on a node with 40k peers.

[RubenKelevra]

If the solution to fixing IPFS performance is literally

You need to find a router whose manufacturer understands the principles of bufferbloat, and has updated the firmware to use one of the Smart Queue Management algorithms such as cake, fq_codel, PIE, or others. Here are some resources:

Than IPFS has failed. Stop asking users to try arbitrary fixes when the fix is simple: IPFS is broken AF and needs to be redesigned. That is the ONLY option.

Anything else just pushes the problem under the rug and will never solve the issue

This is an open source project, I'm sure any pull request with optimizations will be well received.

But I think your tone in the conversation has to change. Cursing about other people's work isn't honorable.

[Avamander]

This is an open source project, I'm sure any pull request with optimizations will be well received.

That model is unsustainable for an individual.

But there will be some fixes in the upcoming version today/tomorrow to fix some possible issues in the current version - so maybe you're just experiencing one of the bugs?

No, I am not experiencing a bug, ipfs is just using bandwidth I don't want it using.

[RubenKelevra]

Ok guys, feel free to discuss this on your own. I'm sure you'll find the perfect solution that way.

I'm out. :)

[bonedaddy]

This is an open source project, I'm sure any pull request with optimizations will be well received.

Maybe the company whose raised millions of $ should fix their product. I've committed dozens of fixes upstream already.

[Avamander]

Ok guys, feel free to discuss this on your own. I'm sure you'll find the perfect solution that way.

I did propose an ideal solution that would allow me and for sure many other to use go-ipfs nicely, but then you suggested terrible hacks and how everything except this single piece of software is at fault. I don't get it. It's like suggesting people to wear sunglasses or to squint when viewing a screen instead of taking into consideration of implementing dimming.

[Avamander]

The lack of bandwidth control also means go-ipfs is unusable on metered connections, that's a major bug IMHO, because as far as I understand, large majority of people have such connections. And that's not something people could change easily (meaning, it's not their fault).

[bonedaddy]

The lack of bandwidth control also means go-ipfs is unusable on metered connections, that's a major bug IMHO, because as far as I understand, large majority of people have such connections. And that's not something people could change easily (meaning, it's not their fault).

Absolutely. BitTorrent clients like deluge, uTorrent, etc... ALL let you configure bandwidth limitations.

[Stebalien]

@Avamander thank you for the report. go-ipfs absolutely should support per-protocol and ideally per-subnet/peer-d QoS rules. I've updated the original meta-issue to address this. For now, you should consider running ipfs config profile apply lowpower (or at least ipfs config Routing.Type dhtclient to turn off the DHT server). You're likely running your node in the default configuration as a DHT server which tends to be very resource intensive.

You're absolutely right, go-ipfs is not usable on metered connections out of the box, by itself.

---

On the other hand, this conversation is going absolutely nowhere fast.

@bonedaddy escalating arguments wastes my time. Wasting my time will delay work on go-ipfs. Delaying work on go-ipfs will prolong your issues. Please consider this before responding to issues, forum posts, and matrix threads.