openstack team mailing list archive

[andi abes <andi.abes@xxxxxxxxx>]

Caitlin, I'm curious what were the use cases and concerns in DCB?
If my memory serves me right (from rate limiting at L2 level) the main
issues are guaranteeing QoS, effective bandwidth usage, fair
allocation of memory buffer space. All of those goals damaged pretty
badly if congestion occurs and any of the resources are exhausted
(leading to indiscriminate packet loss, for lack of any other
recourse).

The use cases, at least the way as I conceive them for OS are very
different. They're not intended to resolve resource constraints as a
primary goal (though, that's definitely a secondary goal).  As an
example - issuing lots of Nova API calls is by itself not the problem
- executing the downstream effects of what those requests trigger is
whats being protected (access to DB, spawning VM's, Rabbit MQ message
rates etc).

For Swift, where pure bandwidth is a primary concern, and the primary
resource being consumed - I imagine you're right. Some L2/L3 traffic
shaping (and monitoring) would be advisable - but that's not to say
that's the only resource. e.g. creating and deleting containers
repeatedly will consume relatively little bandwidth, but will exert
quite a lot of resource consumption on the back end. Rate limiting
these API calls is probably prudent at the API layer.





On Fri, Mar 30, 2012 at 1:56 PM, Jay Pipes <jaypipes@xxxxxxxxx> wrote:
> You make some good points about what is the appropriate level in the stack
> to do rate shaping, but I would just like to have a configurable, manageable
> and monitorable ratelimit/quota solution that doesn't seem like a giant hack
> :)
>
> Baby steps.
>
> -jay
>
>
> On 03/30/2012 01:23 PM, Caitlin Bestler wrote:
>>
>> Throughout the discussion on distributed rate limiting I’ve had the
>> annoying feeling that I’ve heard this joke before.
>>
>> Basically, are we looking for our keys under the street lamp because the
>> light is good rather than looking for them
>> where they were lost?
>>
>> Has anyone studied the effectiveness of rate limitations implemented at
>> this layer. From my experience with rate
>>
>> shaping discussions in IEEE 802.1 Data Center Bridging group I am
>> concerned that the response time working this
>>
>> far up the stack will preclude effective rate shaping.
>>
>> Of course, if someone has studied this and shown it to be effective then
>> this would be great news. The light is
>>
>> Better under the street lamp.
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp