yahoo-eng-team team mailing list archive

[Miguel Angel Ajo <majopela@xxxxxxxxxx>]

Public bug reported:

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, or provide different levels of network service.

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.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: qos rfe

** Description changed:

- 
  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.
+ 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.
+ 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 
+ 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.
+ Combining egress/ingress would be achieved by including an egress
+ bandwidth limit and an ingress bandwidth limit.

** Description changed:

  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.

** Description changed:

  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.
+ provided to customers, or provide different levels of network service.
  
  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.

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1560961

Title:
  [RFE] Allow instance-ingress bandwidth limiting

Status in neutron:
  New

Bug description:
  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, or provide different levels of network service.

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1560961/+subscriptions