<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 04/05/2013 06:54 AM, Sumit Naiksatam wrote:
<blockquote
cite="mid:CAMWrLviqha43YeF-KdcxGcXwin5T++EF11bGTOf8rdAcEDQa-g@mail.gmail.com"
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 moz-do-not-send="true"
href="https://docs.google.com/document/d/1qeoOAVXjbizwcF3lK7QFtT6NGn8WNzQbW98WSOIOi0g/edit">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>
It would be nice to discuss this in more detail at the summit.<br>
<br>
Thanks<br>
Gary<br>
<br>
<blockquote
cite="mid:CAMWrLviqha43YeF-KdcxGcXwin5T++EF11bGTOf8rdAcEDQa-g@mail.gmail.com"
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
moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:nachi@nttmcl.com">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 moz-do-not-send="true"
href="mailto:gessau@cisco.com">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
moz-do-not-send="true" href="mailto:nachi@nttmcl.com">nachi@nttmcl.com</a>>
wrote:<br>
><br>
>> Hi<br>
>><br>
>> I'm also planning to implement related feature in
H.<br>
>> BP<br>
>> <a moz-do-not-send="true"
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
moz-do-not-send="true" href="mailto:gessau@cisco.com">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 moz-do-not-send="true"
href="mailto:gongysh@linux.vnet.ibm.com">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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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 class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>