2022-08 Limiting network bandwidth usage
In the longer term, we want the Station to be able to observe how much resources are consumed by all modules running in the Station. We also want to limit resource consumption. Ideally, we don’t want each module to implement this functionality independently but instead, have a shared control plane in the Station.
In this document, I will explore different options for observing and shaping network traffic.
Virtual networking
Create a virtual network similar to the Docker Desktop solution. Configure modules to use this virtual network for communication. Setup a gateway between this virtual network and the computer’s (host) public network, use this gateway as the place to monitor and shape network traffic.
The problems:
- On Windows, virtual networking based on the virtualization stack (Hyper-V) is not covered by the cheapest license tier Windows Home.
- On Windows and possibly other systems, defining a virtual network card, a virtual bridge, etc. requires admin permissions.
Docker docs: https://docs.docker.com/network/bridge/
OS-level network shaping & throttling
Leverage tools like trickle, wondershaper, Linux’s tc (TrafficControl), dummynet, netmap, pcap, ntop, bmon, ipfw, pf, TUN/TAP.
The problems:
- Many of these tools are OS-specific. The setup is complicated.
User-level HTTP proxy
A possibly simpler approach:
- The Station implements an HTTP proxy.
- Modules are configured to use this HTTP proxy for all network communication.
- Inside the proxy, we can observe network bandwidth consumed by the modules and throttle it down as needed.
Potentials issues:
- Performance - the code handling the proxy must have as little performance overhead as possible. Can we achieve this using Node.js, or do we need to write the proxy in Go or Rust?
- Support non-HTTP traffic (plain TCP/TLS) - can we use the HTTP verb
CONNECTfor that? See https://en.wikipedia.org/wiki/HTTP_tunnel