Open Stack

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.

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 <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
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/a0cc80bd/attachment.html>