Title: Bandwidth management in go-IPFS

	Title: Bandwidth management in go-IPFS
	Author: Solène
	Date: 18 April 2021
	Tags: ipfs
	Description:

	# Introduction

	In this article I will explain a few important parameters for the
	reference IPFS node server go-ipfs in order to manage the bandwidth
	correctly for your usage.

	# Configuration File

	The configuration file of go-ipfs is set by default to
	$HOME/.ipfs/config but if IPFS_PATH is set it will be
	$IPFS_PATH/.config

	# Tweaks

	There are many tweaks possible in the configuration file, but there are
	pros and cons for each one so I can't tell you what values you want. I
	will rather explain what you can change and in which situation you
	would want it.

	## Connections number

	By default, go-ipfs will keep a number of connections to peers between
	600 and 900 and new connections will last at least 20 seconds. This
	may totally overwhelm your router to have to manage that quantity of
	TCP sessions.

	The HighWater will define the maximum sessions you want to exist, so
	this may be the most important setting here. On the other hand, the
	LowWater will define the number of connections you want to keep all the
	time, so it will drain bandwidth if you keep it high.

	I would say if you care about your bandwidth usage, keep the LowWater
	low like 50 and have the HighWater quite high and a short GracePeriod,
	this will allow go-ipfs to be quiet when unused but responsive (able to
	connect to many peers to find a content) when you need it.

	Documentation about Swarm.ConnMgr

	## DHT Routing

	IPFS use a distributed hash table to find peers (it's the common way to
	proceed in P2P networks), but your node can act as a client and only
	fetch the DHT from other peer or be active and distribute it to other
	peer.

	If you have a low power server (CPU) and that you are limited in your
	bandwidth, you should use the value "dhtclient" to no distribute the
	DHT. You can configure this in the configuration file or use
	--routing=dhtclient in the command line.

	Documentation about Routing.type

	## Reprovider

	### Strategy

	This may be the most important choice you have to make for your IPFS
	node. With the Reprovider.Strategy setting you can choose to be part
	of the IPFS network and upload data you have locally, only upload data
	you pinned or upload nothing.

	If you want to actively contribute to the network and you have enough
	bandwidth, keep the default "all" value, so every data available in
	your data store will be served to clients over IPFS.

	If you self host data on your IPFS node but you don't have much
	bandwidth, I would recommend setting this value to "pinned" so only the
	data pinned in your IPFS store will be available. Remember that pinned
	data will never be removed from the store by the garbage collector and
	files you add to IPFS from the command line or web GUI are
	automatically pinned, the pinned data are usually data we care about
	and that we want to keep and/or distribute.

	Finally, you can set it to empty and your IPFS node will never upload
	any data to anyone which could be consider as unfair in a peer to peer
	network but under some quota limited or high latency connection it
	would make sense to not upload anything.

	Documentation about Reprovider.Strategy

	### Interval

	While you can choose what kind of data you want your node to relay as a
	part of the IPFS network, you can choose how often your node will
	publish the content of the data hold in its data store.

	The default is 12 hours, meaning every 12 hours your node will publish
	the list of everything available for upload to the other peers. If you
	care about bandwidth and your content doesn't change often, you can
	increase this value, on the other hand if you may want to publish more
	often if your data store is rapidly changing.

	If you don't want to publish your content, you can set it to "0", then
	you would still be able to publish it manually using the IPFS command
	line.

	Documentation about Reprovider.Interval

	## Gateway management

	If you want to provide your data over a public gateway, you may not
	want everyone to use this gateway to download IPFS content because of
	legal concerns, resource limits or you simply don't want that.

	You can set Gateway.NoFetch to make your gateway to only distribute
	files available in the node data store. Meaning it will act as an
	http·s server for your own data but the gateway can't be used to get
	any other data. It's a convenient way to publish content over IPFS and
	make it available from a gateway you trust while keeping control over
	the data relayed.

	Documentation about Gateway.NoFetch

	# Conclusion

	There are many settings here for various use case. I'm running an IPFS
	node on a dedicated server but also another one at home and they have a
	very different configuration.

	My home connection is limited to 900 kb/s which make IPFS very
	unfriendly to my ISP router and bandwidth usage.

	Unfortunately, go-ipfs doesn't provide an easy way to set download and
	upload limit, that would be very useful.