The current implementation of bandwidth limiting rules only supports egress bandwidth
limiting.
Use cases
========
There are cases where ingress bandwidth limiting is more important than egress limiting,
for example when the workload of the cloud is mostly a consumer of data (crawlers,
datamining, etc), and administrators need to ensure other workloads won't be affected.
Other example are CSPs which need to plan & allocate the bandwidth provided to
customers.
API/Model impact
===============
The BandwidthLimiting rules will be added a direction field (egress/ingress),
which by default will be egress to match the current behaviour and, therefore
be backward compatible.
Combining egress/ingress would be achieved by including an egress bandwidth limit
and an ingress bandwidth limit.
The current implementation of bandwidth limiting rules only supports egress bandwidth
limiting.
Use cases
========
There are cases where ingress bandwidth limiting is more important than egress limiting,
for example when the workload of the cloud is mostly a consumer of data (crawlers,
datamining, etc), and administrators need to ensure other workloads won't be affected.
Other example are CSPs which need to plan & allocate the bandwidth provided to
customers.
API/Model impact
===============
The BandwidthLimiting rules will be added a direction field (egress/ingress),
which by default will be egress to match the current behaviour and, therefore
be backward compatible.
Combining egress/ingress would be achieved by including an egress bandwidth limit
and an ingress bandwidth limit.