Open Stack

Inline...

On Fri, Apr 5, 2013 at 12:43 AM, Gary Kotton <gkotton at redhat.com> wrote:

>  On 04/05/2013 06:54 AM, Sumit Naiksatam wrote:
>
> 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
>
>
> Nice write up.
> Maybe category should be policy?
>
> In addition to this do we want to consider guaranteed bandwidth for
> tenants? From what I understand you are suggesting a limited bandwidth.
>
> Sumit: Agree. These were just a couple of example metrics to convey the
idea.


>  It would be nice to discuss this in more detail at the summit.
>
> Thanks
> Gary
>
>
>  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> 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]
>> 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
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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/b8ff2237/attachment.html>