In one of the very earliest Docker issues, #37: Add ability to throttle bandwidth by container, Ken proposes that Docker should allow per-container bandwidth throttling support. I think this idea should be reconsidered.

The current state of affairs is that people who want to do this are told to use tc on the veth for a given container. I believe this to not great place to be for a few reasons:

1. tc is notoriously difficult to learn, so much so that various different suites of software have tried to paper over its rough edges. All of them are unsuited for use with docker and the large number of veths it creates.
2. tc has to be configured at container creation time. If you are deploying at scale, containers will be brought up or down constantly, which will force you, a developer or operations person, to constantly bookkeep to keep tc up to date. In practice this means you will give up. This problem is especially bad if you create many short lived containers per minute (ahem, me).
3. As the Docker-centric ecosystem expands, more and more critical ops behavior will need to apply to specific containers. Right now, cluster management is focused on the allocation and distribution of containers across physical nodes, resource allotment, and load balancing / discovery. Rate limiting and more fine-grained resource allotment (ahem, disk quota) are logical next steps, and the network throttling side of all this has been neglected.

I propose that Docker manage underlying network rules (however they are represented on the underlying system), to accept (at minimum) maximum bandwidth limits for inbound and outbound traffic, per-container. This should probably be implemented as an attribute on container creation.

THOUGHTS?