[openstack-dev] [Quantum] Summit Sessions
Sridar Kandaswamy (skandasw)
skandasw at cisco.com
Fri Mar 29 19:28:24 UTC 2013
Hi All:
While rate limiting is an important aspect of QoS (Nachi - ur BP proposal and something that Henry is exploring), my
colleague Dan Florea and I have been looking at some requirements for DSCP marking for end to end QoS . We would
like to bring the different aspects under a single framework for Traffic Policies. We had some inputs from key partners
as well, so we wanted to get it out to the community for some early feedback.
Would it make sense for a solution that can address:
1) Multiple types of actions (marking, rate-limit (we can get more fancy with multi queue scheduling)
depending on the capabilities of the underlying datapath.
2) A notion of classifiers, that can segment the traffic on a port (based on the usual suspects such as the
5 tuple with masking to aggregate a block, incoming DSCP, and possibly other fields)
Thus, the policy involves two components - the classifier and the action on the traffic
matching the classifier.
So the policy applied on a port could represent a logic as below:
if traffic_class == video:
mark_dscp(AF3)
if traffic_class == voip:
mark_dscp(EF)
if traffic_class == generic_user:
if bandwidth > 100000:
apply_rate-limit()
if traffic_class == nomatch:
do_some_default_action()
For the case where we want the action to be applied on all traffic on a port - not specifying
a classifier can default the action on all traffic.
if True:
if bandwidth > 100000:
apply_rate-limit()
There is precedence for such a model in the switching world and this will look a lot like
Quantum security groups with more options on it.
Pls provide ur feedback and would also like to have an opportunity to continue the discussion
at the Summit. If there is common ground we can collaborate on a BP.
Thanks
Sridar
--------------------------------------------------------------------------------------------------------------------------------------
A very high level stab and sense of what the CLI's could look like (this is just to give an
idea of some of the fields):
The Classifier (this is optional - needed only if we want to have different actions on
different classes of traffic.
quantum classifier-create [-h]
[--request-format {json,xml}]
[--tenant-id TENANT_ID]
[--src-ip <ip/mask>
[--dst-ip <ip/mask>
[--src-port <port-range>
[--dst-port <port-range>
[--dscp DSCP]
[--other-things-to-be-added <value>]
NAME
Action specifier:
quantum traffic-policy-rule-create [-h]
[--request-format {json,xml}]
[--tenant-id TENANT_ID]
[--classifier <classifier-name>]
[--direction [ingress|egress]
[--action <mark-dscp=<val>>
NAME
--action can take on appropriate action keys and desired value such as:
<rate-limit=100000> etc.
We can also aggregate multiple rules in to a single block which can make them more
manageable.
-----Original Message-----
From: Nachi Ueno [mailto:nachi at nttmcl.com]
Sent: Thursday, March 28, 2013 5:15 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Quantum] Summit Sessions
Hi Henry
Thanks! Sounds great
2013/3/28 Henry Gessau <gessau at cisco.com>:
> Hi Nachi,
>
> Thanks for bringing this to my attention. My initial reaction is that,
> yes, it should be covered by QoS. I will refer to it in my write-up
> for the QoS proposal, and keep in touch with you for a potential merge.
>
> -- Henry
>
> On Wed, Mar 27, at 7:56 pm, Nachi Ueno <nachi at nttmcl.com> wrote:
>
>> Hi
>>
>> I'm also planning to implement related feature in H.
>> BP
>> https://blueprints.launchpad.net/quantum/+spec/quantum-basic-traffic-
>> control-on-external-gateway
>>
>> Basically, I wanna stop exhaust of external network connection by one
>> tenant
>>
>> May be we can merge our proposals.
>> Your qos api is per port based one?
>>
>> Regards
>> Nachi
>>
>> 2013/3/27 Henry Gessau <gessau at cisco.com>:
>>> I will be adding some more details to the proposal soon.
>>>
>>> -- Henry
>>>
>>> On Wed, Mar 27, at 10:50 am, gong yong sheng <gongysh at linux.vnet.ibm.com> wrote:
>>>
>>>> It will help if u can have some design before summit discuss.
>>>> On 03/27/2013 10:33 PM, Sean M. Collins wrote:
>>>>> I'd like to get the QoS API proposal in as well.
>>>>>
>>>>> http://summit.openstack.org/cfp/details/160
>>>>>
>>>>> I am currently working with Comcast, and this is a must-have
>>>>> feature in Quantum.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list