I'd like my game client to download some extra assets in the background, but I want it to rate limit itself so it has less effect on any other network traffic.
I imagine I could rate limit on the server side through a web server setting, but I'd rather the client gets to choose its own rate limit so it can also have times when it downloads at a faster rate.
What is the right way to do this?

I'll be using HTTPS for the downloads.
Is there some way to inform the TCP or HTTP stack that you only want to receive data at a certain speed for a particular connection?
Or do I have to just slow down the rate at which I am reading it from the HTTP stream?
Slowing down my rate of reading seems like I am relying on TCP fallback logic to handle my slow processing speed, rather than informing it up front that I want to be a good citizen and use less bandwidth.

You have to just read at a slower rate. By reading more slowly you will be sending acknowledgements more slowly and thus effectively performing the rate limiting you're after. TCP is designed to handle this properly.

Ok, thanks to both of you.
I did some reading on the TCP receive window, window scaling, TCP congestion control, and HTTP ranges.

Wikipedia said: Windows Vista and Windows 7 have a fixed default TCP receive buffer of 64 kB, scaling up to 16 MB through "autotuning", limiting manual TCP tuning over long fat networks.
https://en.wikipedia.org/wiki/TCP_window_scale_option

I am using C# and see that the HttpWebRequest.ServicePoint.ReceiveBufferSize is set to -1 after constructing a new HttpWebRequest (despite the method documentation saying the default is 8192).
I assume the -1 indicates "unset" and allows the operating system to auto tune it.
My game clients will be run on Windows, and the download servers and game servers will be run on linux.
Would I be better off letting the OS auto tune the window scale / receive buffer size, rather than choosing it myself?

Thanks, that makes sense.

I expect this background asset downloader to run at the same time as network game play.
If I know the max download bandwidth for a client, is there a percent threshold I should keep the combined asset download and game play traffic under in order to avoid lost game play packets?
Is running an asset downloader in the background a bad idea?
I want to utilize the extra bandwidth by downloading assets ahead of time and not making the player wait at download screens as often or as long, but not if it will negatively affect network game play.

@swiftcoder, thanks. I guess I was wondering how much that margin needs to be, whether that be a percentage of total bandwidth, or just a set amount.
I intended on subtracting the exact bandwidth requirements of the gameplay from the total available bandwidth as you say.
Then the decision is how much of that remaining bandwidth can I use for downloading assets in the background without negatively affecting the gameplay traffic.
I suppose my main concern is that using 90% of the available bandwidth would result in a greater than linear increase in lost packets as compared with using 10%, even though both are clearly under 100% with a margin.
My hope would be that I can expect a linear increase (or less) in lost packets as I saturate the the available bandwidth.
If the increase in lost packets is more than linear, then that might make it worth staying at much lower bandwidth usage for the background asset downloader, even though more bandwidth is available.
I hope that better explains my concern. Thanks for the help.

@khawk, thanks, I will probably be using Digital Ocean "spaces" / object storage.
They may have a rate limit setting built in to their admin interface.
I prefer to limit on the client, since I'm writing the client anyway, and each player's available bandwidth will be different, so they can rate limit at different speeds based on that.
The rate limiting is to protect the client's gameplay experience while still downloading assets in the background, not to protect the server from being overwhelmed.

Lost packet proportion is unlikely to depend on how much bandwidth you use, but again I'd argue this is mostly a problem you don't need to concern yourself with at the application level.

The fact is, a typical computer these days is probably performing all sorts of internet traffic in the background alongside your game - OS updates, updates to whichever obnoxious software demands to change every day, browsers left open and polling advert networks, etc. From your game's point of view it's probably sufficient to just give the user a drop-down box to say how much bandwidth they want to use for background asset loading.