Open Stack

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