AcceleratedDHTClient causes modem crash, revert to experimental and discourage from using about kubo HOT 8 CLOSED

I don't think it is sane to revert #9703. We can't be asked to write applicative protocols while keeping in mind how a router is gonna react 5 layers down.
This needs to be handled in the network layer because applications have no control over packet pacing, resource limits, congestion control, or anything really. It's the job of libp2p to provide reliable TCP semantics streams, and part of theses semantics since between October 1986 to August 1988 now include that they wont cause network collapses.
This also looks like a limited issue on some routers, if I hear more peoples having issues I might change my mind.

If you want to help on this I would like you to fill in a report on #9998 using the template (it's best effort). And this issue should be closed. thx

from kubo.

This also looks like a limited issue on some routers, if I hear more peoples having issues I might change my mind.

I'm sorry, but you really should reconsider how you think about this.
The fact that you don't have an issue with it doesn't mean that there is none. There very clearly are fundamental issues in IPFS that you cannot and should not discard as a limited case.

To make my point even more clear. I had IPFS on 2 completely different internet connections. 2 different modems.
On both connections I can now let IPFS crash my modem.
Those ISPs in the netherlands are "Vodafona/Ziggo" and "T-Mobile".
For reference, these two together serve about 50% of the broadband connections in the netherlands.

Granted, the T-mobile one (~7% of the broadband usage here in NL) requires AcceleratedDHTClient to be on before it finally gives in and crashes too.

Now to put it even more into perspective.
I was using default IPFS configurations and following suggestions that kubo itself gives me which made it crash.

If you go by just the default configuration then every user on "Vodafona/Ziggo" (say about 42% of all the broadband users here in NL) will make their modem crash. If you include just following suggestions (thus eventually enabling AcceleratedDHTClient if you host a lot of data) then that 42% will go up.

Or in other terms, half of all the people having broadband (you might as well say half of the population) therefore can't possible ever run IPFS because it will crash their modem.

So cut it out with your nonsense argument that this is a one-off modem issue. It's widespread. The still fairly limited use of IPFS gives the impression that it's a rare issue. The usage of IPFS in datacenters (which is a substantial amount!) skews the image too, as those "modems" just work way differently. Just google on how many times the router kill issues show up with IPFS in it, you'd be shocked.

If you want to help on this I would like you to fill in a report on #9998 using the template (it's best effort). And this issue should be closed. thx

No and no.
I'm not going to help with that anymore. I've spend my time being annoyed with that and getting nowhere. And yesterday i spend another full day reconfiguring my modem (which is super painful if all smart lights/appliances run on it!) just to discover that i didn't have to do any of that and that i instead just should have disabled AcceleratedDHTClient. If IPFS/KUBO can't get it fixed then i'm faster off not using it anymore and instead go for Iroh.

This issue should not be closed. It is certain that this feature amplifies the possibility of your modem crashing thus this feature should be disabled. It is entirely possible (likely even) that a true fix in libp2p would make AcceleratedDHTClient just work as intended too. But we're not at that point in time so this feature is therefore bad and should be disabled and discouraged (and warned that it can crash modems!) as temporary mediating issue. Once a true fix is found this one can probably be turned on safely again too. What is important now is to finally act upon this and start actually investigating with people who know the network layers (not me!) to figure this issue out, properly understand it and fix it.

from kubo.

I havn't red your latest message yet, if you were happy with the situation before turning on AcceleratedDHTClient feel free to turn it off.
Your content wont be properly announced in the DHT.
Instead you can change your reprovider strategy to something lighter instead but it makes partial and intersecting queries less reliable.
https://github.com/ipfs/kubo/blob/master/docs/config.md#reproviderstrategy

from kubo.

"Vodafone/Ziggo" has about 4 million users in the Netherlands. All getting the same modem. 0 are able to run Kubo, it would crash their modem within 30 minutes.
Enabling AcceleratedDHTClient crashes their modem in mere minutes, I know cause I tested this about a year ago.

You can disagree with the TCP stack implementations, with all the protocols in the world and push for your idealistic approach. Pushing for ideals is commendable!! But at some point idealistic approaches and reality collide and it turns into an uphill battle you can't win. You can't make hardware vendors fix the TCP stack to IPFSs needs. And even if you can, then you'd still have to wait decades for that new implementation to be so widely used that you can ignore the broken ones. You need to adapt to fit in what is on the market whether you like it or not.

You can opt to stay idealistic and thus ignore really. It does mean that the KUBO implementation of IPFS will always be a niche project. It literally can't scale as it itself just crashes on a large subset of modems out there.

I should not need to try and convince you that this is bad....

from kubo.

@markg85 is it possible for you to run this with

ipfs config --json Swarm.Transports.Network.TCP false
ipfs config --json Swarm.Transports.Network.Websocket false

If the router sluggishness is because of anything other than bandwidth usage by kubo, go-libp2p should handle it.

from kubo.

Thank you for your suggestion @sukunrt!

I just tried it, sadly it solves nothing.
Upon restarting IPFS with AcceleratedDHTClient enabled along with your suggestions gives me immediate network connectivity issues. Connections timing out, internet music stops playing. It's not crashing yet but it's near unusable. So i didn't even leave it on for more then a minute before reverting.

Yes, I am aware this feature has a high initial startup load. It might settle down after that but i'm not willing to even wait for that. As it means that an accidental IPFS crash or reboot also has a - then unintended side effect - of the network becoming effectively unusable at seemingly random times.

from kubo.

1. The feature is opt-in
2. The feature has been useful to various groups
3. The text telling you you're falling behind on provides asks the user to consider the accelerated DHT client (

   kubo/core/node/provider.go

   Lines 76 to 77 in f17a064

   	💡 Consider enabling the Accelerated DHT to enhance your system performance. See:
   	https://github.com/ipfs/kubo/blob/master/docs/config.md#routingaccelerateddhtclient`,

   ) and links to the config https://github.com/ipfs/kubo/blob/f17a06419355afbae3cdb1675675500fa5e17b9d/docs/config.md#routingaccelerateddhtclient.
4. The config docs contain a list of caveats

Your issue seems to have been covered by "Users that are limited in the number of parallel connections their machines/networks can perform will likely suffer" however if you'd like to add a sub-bullet like "some users have reported consumer routers having degraded behavior during connection bursts" that seems fine (if redundant).

Aside: Obviously the world we'd all like to get to a world where we're not falling behind on provides by default and it's not eating many resources in the process. That's not this issue though, there are other ones about this. If this is the area you're interested in you can comment on one of the existing issues (in here, boxo, or go-libp2p-kad-dht) or create a new one.

from kubo.

Thank you for your suggestions @aschmahmann. I have a lot of interests, but figuring out network layers at the protocol level function is one that's i'm not going to skip. That stuff is hard and should be left to people passionate about that tech.

I'm disappointed in the conclusion here. In my view i'm exposing a symptom that amplifies ill behavior. If the root cause can't be mitigated, the symptoms should be mitigated. This is going to bite back as kubo gains adoption on user equipment. Oh well, i tried.

from kubo.