Open Stack

Hello,

In regards to the issue of policing in a LAN kind of environment, would it
make sense to add additional capability for per destination policing?
This would be pretty useful use case.


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
>



-- 
Vinay Bannai
Email: vbannai at gmail.com
Google Voice: 415 938 7576
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130404/34f130a1/attachment.html>