Inline...<br><br><div class="gmail_quote">On Fri, Apr 5, 2013 at 12:43 AM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    On 04/05/2013 06:54 AM, Sumit Naiksatam wrote:
    <blockquote type="cite">Hi Sridar and Team,
      <div><br>
      </div>
      <div>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:</div>
      <div><a href="https://docs.google.com/document/d/1qeoOAVXjbizwcF3lK7QFtT6NGn8WNzQbW98WSOIOi0g/edit" target="_blank">https://docs.google.com/document/d/1qeoOAVXjbizwcF3lK7QFtT6NGn8WNzQbW98WSOIOi0g/edit</a></div>
    </blockquote>
    <br>
    Nice write up.<br>
    Maybe category should be policy?<br>
    <br>
    In addition to this do we want to consider guaranteed bandwidth for
    tenants? From what I understand you are suggesting a limited
    bandwidth. <br>
    <br></div></blockquote><div>Sumit: Agree. These were just a couple of example metrics to convey the idea.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div bgcolor="#FFFFFF" text="#000000">
    It would be nice to discuss this in more detail at the summit.<br>
    <br>
    Thanks<br>
    Gary<br>
    <br>
    <blockquote type="cite">
      <div><br>
      </div>
      <div>I imagined it might be relevant to this discussion and might
        help your proposal.</div>
      <div><br>
      </div>
      <div>Thanks,<br>
        ~Sumit. </div>
      <div><br>
        <div class="gmail_quote">On Wed, Apr 3, 2013 at 10:59 AM, Sridar
          Kandaswamy (skandasw) <span dir="ltr"><<a href="mailto:skandasw@cisco.com" target="_blank">skandasw@cisco.com</a>></span> wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All:<br>
            <br>
            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.<br>
            <br>
            Thanks<br>
            <br>
            Sridar<br>
            <br>
            -----Original Message-----<br>
            From: Sridar Kandaswamy (skandasw)<br>
            Sent: Friday, March 29, 2013 12:28 PM<br>
            To: OpenStack Development Mailing List<br>
            Subject: RE: [openstack-dev] [Quantum] Summit Sessions<br>
            <br>
            Hi All:<br>
            <br>
            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.<br>
            <br>
            Would it make sense for a solution  that can  address:<br>
            <br>
               1) Multiple types of actions (marking, rate-limit (we can
            get more fancy with multi queue scheduling)<br>
                    depending on  the capabilities of the underlying
            datapath.<br>
               2) A notion of classifiers, that can segment the traffic
            on a port  (based on the usual  suspects such as the<br>
                    5 tuple with masking to aggregate a block, incoming
            DSCP, and possibly other fields)<br>
            <br>
            Thus, the  policy involves two components - the classifier
            and the action on the traffic matching the classifier.<br>
            <br>
            So the policy applied on a port could represent a logic as
            below:<br>
            <br>
                if traffic_class == video:<br>
                    mark_dscp(AF3)<br>
                if traffic_class == voip:<br>
                    mark_dscp(EF)<br>
                if traffic_class == generic_user:<br>
                    if bandwidth > 100000:<br>
                        apply_rate-limit()<br>
                if traffic_class == nomatch:<br>
                    do_some_default_action()<br>
            <br>
            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.<br>
            <br>
                if True:<br>
                    if bandwidth > 100000:<br>
                        apply_rate-limit()<br>
            <br>
            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.<br>
            <br>
            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.<br>
            <br>
            Thanks<br>
            <br>
            Sridar<br>
--------------------------------------------------------------------------------------------------------------------------------------<br>
            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):<br>
            <br>
            The Classifier (this is optional - needed only if we want to
            have different actions on different classes of traffic.<br>
            <br>
            quantum classifier-create  [-h]<br>
                                       [--request-format {json,xml}]<br>
                                       [--tenant-id TENANT_ID]<br>
                                       [--src-ip <ip/mask><br>
                                       [--dst-ip <ip/mask><br>
                                       [--src-port <port-range><br>
                                       [--dst-port <port-range><br>
                                       [--dscp DSCP]<br>
                                       [--other-things-to-be-added
            <value>]<br>
                                       NAME<br>
            <br>
            Action specifier:<br>
            <br>
            quantum traffic-policy-rule-create [-h]<br>
                                               [--request-format
            {json,xml}]<br>
                                               [--tenant-id TENANT_ID]<br>
                                               [--classifier
            <classifier-name>]<br>
                                               [--direction
            [ingress|egress]<br>
                                               [--action
            <mark-dscp=<val>><br>
                                               NAME<br>
            <br>
            --action can take on appropriate action keys and desired
            value such as:<br>
            <rate-limit=100000> etc.<br>
            <br>
            <br>
            We can also aggregate multiple rules in to a single block
            which can make them more manageable.<br>
            <br>
            -----Original Message-----<br>
            From: Nachi Ueno [mailto:<a href="mailto:nachi@nttmcl.com" target="_blank">nachi@nttmcl.com</a>]<br>
            Sent: Thursday, March 28, 2013 5:15 PM<br>
            To: OpenStack Development Mailing List<br>
            Subject: Re: [openstack-dev] [Quantum] Summit Sessions<br>
            <br>
            Hi Henry<br>
            <br>
            Thanks! Sounds great<br>
            <br>
            2013/3/28 Henry Gessau <<a href="mailto:gessau@cisco.com" target="_blank">gessau@cisco.com</a>>:<br>
            > Hi Nachi,<br>
            ><br>
            > Thanks for bringing this to my attention. My initial
            reaction is that,<br>
            > yes, it should be covered by QoS. I will refer to it in
            my write-up<br>
            > for the QoS proposal, and keep in touch with you for a
            potential merge.<br>
            ><br>
            > -- Henry<br>
            ><br>
            > On Wed, Mar 27, at 7:56 pm, Nachi Ueno <<a href="mailto:nachi@nttmcl.com" target="_blank">nachi@nttmcl.com</a>>
            wrote:<br>
            ><br>
            >> Hi<br>
            >><br>
            >> I'm also planning to implement related feature in
            H.<br>
            >> BP<br>
            >> <a href="https://blueprints.launchpad.net/quantum/+spec/quantum-basic-traffic-" target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-basic-traffic-</a><br>
            >> control-on-external-gateway<br>
            >><br>
            >> Basically, I wanna stop exhaust of external network
            connection by one<br>
            >> tenant<br>
            >><br>
            >> May be we can merge our proposals.<br>
            >> Your qos api is per port based one?<br>
            >><br>
            >> Regards<br>
            >> Nachi<br>
            >><br>
            >> 2013/3/27 Henry Gessau <<a href="mailto:gessau@cisco.com" target="_blank">gessau@cisco.com</a>>:<br>
            >>> I will be adding some more details to the
            proposal soon.<br>
            >>><br>
            >>> -- Henry<br>
            >>><br>
            >>> On Wed, Mar 27, at 10:50 am, gong yong sheng
            <<a href="mailto:gongysh@linux.vnet.ibm.com" target="_blank">gongysh@linux.vnet.ibm.com</a>>
            wrote:<br>
            >>><br>
            >>>> It will help if u can have some design
            before summit discuss.<br>
            >>>> On 03/27/2013 10:33 PM, Sean M. Collins
            wrote:<br>
            >>>>> I'd like to get the QoS API proposal in
            as well.<br>
            >>>>><br>
            >>>>> <a href="http://summit.openstack.org/cfp/details/160" target="_blank">http://summit.openstack.org/cfp/details/160</a><br>
            >>>>><br>
            >>>>> I am currently working with Comcast,
            and this is a must-have<br>
            >>>>> feature in Quantum.<br>
            >>>>><br>
            >>>>><br>
            >>>>><br>
            >>>>>
            _______________________________________________<br>
            >>>>> OpenStack-dev mailing list<br>
            >>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
            >>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
            >>>><br>
            >>>><br>
            >>>><br>
            >>>>
            _______________________________________________<br>
            >>>> OpenStack-dev mailing list<br>
            >>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
            >>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
            >>>><br>
            >>><br>
            >>> _______________________________________________<br>
            >>> OpenStack-dev mailing list<br>
            >>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
            >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
            >><br>
            >> _______________________________________________<br>
            >> OpenStack-dev mailing list<br>
            >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
            >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
            >><br>
            ><br>
            > _______________________________________________<br>
            > OpenStack-dev mailing list<br>
            > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
            > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
            <br>
            _______________________________________________<br>
            OpenStack-dev mailing list<br>
            <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
            <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
            <br>
            _______________________________________________<br>
            OpenStack-dev mailing list<br>
            <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
            <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br>