Open Stack

Hi Sumit:

Thanks for the input. Yes the thought is to look at it from a provider perspective to manage traffic behavior of instances. I took a quick look at ur doc now, Henry is looking at some of the aspects with queuing disciplines - we were leaning towards a Queue object which defines the scheduling characteristics to be attached on the policy. Lets discuss more perhaps before and during the summit.

Edgar and Plumgrid folks also have shown interest in the proposal.

Thanks

Sridar

From: Sumit Naiksatam [mailto:sumitnaiksatam at gmail.com]
Sent: Thursday, April 04, 2013 8:55 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Traffic/QoS policy framework; was - RE: [Quantum] Summit Sessions

Hi Sridar and Team,

Thanks for sharing and bringing this topic up for discussion. I would expect that the QoS abstraction exposed to the end user (for consumption) is different from the abstraction used by the admin/provider (for configuration). The details you have captured below seem to fall into the later category. Am I understanding it correctly? To elaborate a little more on this, I repurposed a document I had written earlier and have posted it here:
https://docs.google.com/document/d/1qeoOAVXjbizwcF3lK7QFtT6NGn8WNzQbW98WSOIOi0g/edit

I imagined it might be relevant to this discussion and might help your proposal.

Thanks,
~Sumit.

On Wed, Apr 3, 2013 at 10:59 AM, Sridar Kandaswamy (skandasw) <skandasw at cisco.com<mailto:skandasw at cisco.com>> wrote:
Hi All:

Resending.  Would others  have interest in the area of Traffic/QoS policies ?  We can try to have some discussions prior to the summit and meet up at the summit to converge towards a proposal. Henry is looking at some possibilities for queuing disciplines to add to the notes below so we can converge. We would definitely like to get a sense of what others would be interested in as well and get more folks involved.

Thanks

Sridar

-----Original Message-----
From: Sridar Kandaswamy (skandasw)
Sent: Friday, March 29, 2013 12:28 PM
To: OpenStack Development Mailing List
Subject: RE: [openstack-dev] [Quantum] Summit Sessions

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<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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130405/feec2afe/attachment.html>