Open Stack

> On May 14, 2015 9:26 PM, "Gal Sagie" <gal.sagie at gmail.com<mailto:gal.sagie at gmail.com>> wrote:
> Hello Ryan,
>
> We have proposed a spec to liberty to add rate limit functionality to security groups [1].
> We see two big use cases for it, one as you mentioned is DDoS for east-west and another
> is brute force prevention (for example port scanning).
>
> We are re-writing the spec as an extension to the current API, we also have a proposal
> to enhance the Security Group / FWaaS implementation in order to make it easily extendible by such
> new classes of security rules.
>
> We are planning to discuss all of that in the SG/FWaaS future directions session [2].
> I or Lionel will update you as soon as we have the fixed spec for review, and feel free to come to the discussion
> as we are more then welcoming everyone to help this effort.
>
> Gal.
>
> [1] https://review.openstack.org/#/c/151247/
> [2] https://etherpad.openstack.org/p/YVR-neutron-sg-fwaas-future-direction

Isn't there already described a way to rate-limit instances (overall) by 
putting qdiscs onto their tap devices?

Having looked only briefly at the spec, I would say you want to have the 
option to "MARK" that traffic which is EDN enabled the rate limiting 
might have otherwise dropped.

The extant mechanism I mentioned uses HTB in one direction (instance 
inbound/tap outbound) and a policing filter in the other.  I've used it 
(as a mostly end user) and have noticed that as described, one can 
introduce non-trivial bufferbloat inbound to the instance.

And I've always wished (as in if wishes were horses) that the instance 
outbound throttle were actually implemented in a way where it becomes 
immediately apparent to the instance by causing the tx queue in the 
instance to build-up.  That wouldn't be something on a tap device though.

Does there need to be both a packet and bit rate limit?  I've some 
experience with bit rate limits and have seen otherwise rather throttled 
(bitrate) instances cause non-trivial problems with a network node.

rick jones