Bandwidth estimation (possible rough ETA? Use-case feedback)

Hello!

I've recently got the Steamworks version of the library integrated with my project thanks to your additions (like the flat interface for C#)!

It's mostly working great, it's a lot more robust/efficient than our other protocol, except for one thing: the fixed bandwidth.

I know this is on the roadmap, so I just want to share my experience and add my +1 for this feature to be re-implemented. If you have any rough ETA on when it might come back that would also help, but I of course understand if you do not!

Our use-case:

Anyway, our project has a bit of varied network requirements. Initial connection can transfer a lot of data (hundreds of kB to MB) due to initial state sync (it's a VR world-building, so the entire data model gets synced).

During the session itself there are usually small deltas (using reliable channel) and position/voice and other stream data (sent as unreliable). Additionally there can be P2P asset transfers, which can be dozens, sometimes even hundreds of MB in addition.

For the assets, I technically establish a second independent connection (+1 for the ENet like channels, but it's workable without them https://github.com/ValveSoftware/GameNetworkingSockets/issues/95 ) so it's better interweaved with the realtime traffic (both reliable and unreliable).

However when using this protocol, the initial sync and asset transfers either end up being very slow when the bandwidth is conservative (the default seems to be about ~128 kB/s). Everything else is smooth.

If I up the bandwidth to something higher, like 8 MB/s, if the connection can handle it it also runs really well and transfers are super speedy. However once there are multiple people or people with slower upload/download, this ends up very quickly degrading everything.

The connection quality starts dropping to 0.5, even as low as 0.1, I assume because of a lot of dropped UDP packets, because the library is pushing them through too fast and it becomes unusable.

I've tried setting the limit just a bit higher, but even something like 512 kB/s causes problems, so we're currently stuck with the low default limit.

In our case we don't currently care about not sending some message, so if there was a limitation that bandwidth estimation only works well when the messages are not removed from the queue, that would be ok, but I understand if it's necessary to have mechanism like this in general anyway.

Currently we're staying with the old protocol as our primary one. It uses sliding window algorithm, so it scales better with the bandwidth, but it's not nearly as good as this one otherwise, we'd love to switch to it as our primary transport protocol.

I hope this info helps a bit! Thanks for all your hard work on this!

The issue names no files or tests; start by locating the bandwidth-estimation roadmap item and the current fixed-bandwidth transport setting. Review how the reported ~128 kB/s and 8 MB/s cases behave compared with the old sliding-window protocol, then define a scoped estimation change and its measurable completion criteria.