<div dir="ltr">On Wed, Feb 20, 2013 at 2:44 PM, Rossella Sblendido <span dir="ltr"><<a href="mailto:rossella@midokura.com" target="_blank">rossella@midokura.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Hi Guillermo,<br>
      <br>
      thanks for the write up. <br>
      I just have one question, how would you implement in the rest api
      the operation of associating a queue to a vport? I imagine you'd
      do a PUT of the DtoPort with the filder ID set. Is that correct?</div></div></blockquote><div><br></div><div style>Hi Rossella,</div><div style><br></div><div style>Actually what I propose is never associating a queue with a vport. When a QOS (with a queue id) rule matches a packet, that implicitly means "the vport where this packet ingressed the virtual topology needs an instance of this queue if it didn't have it already". Queues would be created dynamically as QOS actions are found as a result of a simulation.</div>
<div style><br></div><div style>Cheers,</div><div style>G</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"><div><span class="HOEnZb"><font color="#888888"><br>

      <br>
      Rossella</font></span><div><div class="h5"><br>
      <br>
      On 2/19/13 7:00 PM, Guillermo Ontañón wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      <div dir="ltr">Hi devs,
        <div><br>
        </div>
        <div>Below is my draft spec for Midonet's rate-limiting feature,
          looking forward to discussing it:</div>
        <div><br>
        </div>
        <div>
          <div><font face="courier new, monospace">Feature Description</font></div>
          <div><font face="courier new, monospace">-------------------</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Add a rate-limiting
              feature targetted at cloud service providers, who</font></div>
          <div><font face="courier new, monospace">may want to limit the
              bandwidth available to their tenants in various</font></div>
          <div><font face="courier new, monospace">ways.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Use cases</font></div>
          <div><font face="courier new, monospace">---------</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">There are three use
              cases, with varying degrees of importance/</font></div>
          <div><font face="courier new, monospace">usefulness, that
              Midonet could support:</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Use case 1: Limit the
              uplink egress bandwitdh</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Two reasons why this
              may make sense for a cloud service provider:</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">* Pricing options
              based on uplink speed. </font></div>
          <div><font face="courier new, monospace">* Resource sharing.
              The uplink is a shared resource and likely</font></div>
          <div><font face="courier new, monospace">  oversubscribed,
              rate limiting provides a limit into how much a given</font></div>
          <div><font face="courier new, monospace">  subscriber can
              affect resource allocation to the rest of subscribers.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Use case 2: Limit
              east-west traffic</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Though much less
              important than use case #1. The motivations are</font></div>
          <div><font face="courier new, monospace">similar.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Use case 3. Limit the
              global egress bandwidth for a VM</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Reasons for doing
              this:</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">* Having a global
              bandwidth limit for the VM makes it less necessary to</font></div>
          <div><font face="courier new, monospace">  explicitly support
              the 'east-west' use case. If that's the case,</font></div>
          <div><font face="courier new, monospace">  east-west bandwidth
              for a VM would be the global limit minus its</font></div>
          <div><font face="courier new, monospace">  current uplink
              usage.</font></div>
          <div><font face="courier new, monospace">* Fair sharing of the
              network link in a host among all guests. Note</font></div>
          <div><font face="courier new, monospace">  that, this is not
              real or perfect 'sharing' if the limits of the local</font></div>
          <div><font face="courier new, monospace">  VMs aren't somehow
              balanced to fully utilize the host's link.</font></div>
          <div><font face="courier new, monospace">* Limiting the
              guest's bandwidth to ensure services running on the host</font></div>
          <div><font face="courier new, monospace">  have guaranteed
              bandwidth. </font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Design/implementation
              implications of use cases</font></div>
          <div><font face="courier new, monospace">-----------------------------------------------</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Use cases #1 and #2
              clearly require that traffic be mapped to a rate</font></div>
          <div><font face="courier new, monospace">limiting queue on a
              per-flow basis. With the difference that use case #1</font></div>
          <div><font face="courier new, monospace">could have simpler
              design/implementations because all the rate-limited</font></div>
          <div><font face="courier new, monospace">traffic goes through
              a few edge nodes. We will call this flow-based</font></div>
          <div><font face="courier new, monospace">rate-limiting.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Use case #3 is very
              clearly the simplest from all points of view,</font></div>
          <div><font face="courier new, monospace">blindly rate limiting
              all traffic that ingresses the virtual topology</font></div>
          <div><font face="courier new, monospace">from a given VM
              vport. We will call this port-based rate-limiting.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Use cases #1 and #2
              also pose the question of whether the rate-limiting</font></div>
          <div><font face="courier new, monospace">is applied to each VM
              (or rather, vport) independently or it can be</font></div>
          <div><font face="courier new, monospace">applied to each
              tenant or arbitrary group of VMs as a whole.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">The latter, together
              with flow-based limiting, is a full generalisation</font></div>
          <div><font face="courier new, monospace">of the problem
              because it requires a distributed rate-limiting queue (on</font></div>
          <div><font face="courier new, monospace">top of the per-flow
              classification).  This is, for the time being, out</font></div>
          <div><font face="courier new, monospace">of the scope for this
              feature.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Furthermore, in a
              vport-local scenario, rate-limiting may be applied on</font></div>
          <div><font face="courier new, monospace">the ingress vport, on
              egress, or both.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Features supported in
              the Quantum NVP QoS feature</font></div>
          <div><font face="courier new, monospace">-------------------------------------------------</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">The NVP QoS feature
              for Quantum [0] is in code-review [1] state. It</font></div>
          <div><font face="courier new, monospace">offers:</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">  * Putting a
              rate-limiting queue in a VMs vport (no flow matching, not</font></div>
          <div><font face="courier new, monospace">    a distributed
              queue).</font></div>
          <div><font face="courier new, monospace">  * The settings for
              port's queue may be chosen individually or inherit</font></div>
          <div><font face="courier new, monospace">    from the queue
              set for the 'network'. So an admin may just configure</font></div>
          <div><font face="courier new, monospace">    one queue and
              have a whole set of VMs use those settings.</font></div>
          <div><font face="courier new, monospace">  * A rate-limiting
              queue can set:</font></div>
          <div><font face="courier new, monospace">    * max bandwidth
              rate</font></div>
          <div><font face="courier new, monospace">    * min bandwidth
              rate ???</font></div>
          <div><font face="courier new, monospace">    * qos_marking
              (unclear what it does, could it mark the packet for</font></div>
          <div><font face="courier new, monospace">      the kernel to
              custom further qos/processing on the packet?)</font></div>
          <div><font face="courier new, monospace">    * dscp (unclear
              too)</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Proposed Rate
              Limiting feature for Midonet Diyari 13.06</font></div>
          <div><font face="courier new, monospace">-------------------------------------------------------</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Midonet will support
              ingress vport-local flow-based rate-limiting.</font></div>
          <div><font face="courier new, monospace">Meaning that:</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">  * Queues are local
              to a vport and applied on ingress only, a flow may</font></div>
          <div><font face="courier new, monospace">    only traverse one
              queue.</font></div>
          <div><font face="courier new, monospace">  * Flows are
              assigned to queues independently.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Therefore, all of the
              use cases discussed above would be covered,</font></div>
          <div><font face="courier new, monospace">although in a
              non-distributed manner.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Flow classification
              will use the existing chains/rules infrastructure.</font></div>
          <div><font face="courier new, monospace">Only one extension is
              needed: a new QOS action for rules. Upon matching</font></div>
          <div><font face="courier new, monospace">on a rule with a QOS
              action, Chain.apply() will:</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">  * Is the flow
              already marked for QOS by an eearlier rule?</font></div>
          <div><font face="courier new, monospace">    - Yes -> do
              nothing.</font></div>
          <div><font face="courier new, monospace">    - No  -> mark
              the flow with the queue id given by the rule</font></div>
          <div><font face="courier new, monospace">  * Continue
              processing on the next rule (this is a non-terminating</font></div>
          <div><font face="courier new, monospace">    rule)</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">QOS rules will have a
              queueId UUID attribute. Queue objects need not</font></div>
          <div><font face="courier new, monospace">exist per-vport,
              their configuration will be used to create a queue</font></div>
          <div><font face="courier new, monospace">when traffic
              ingressing a vport is marked with a given queue id, but a</font></div>
          <div><font face="courier new, monospace">queue object is not
              bound to a vport it can be reused by rules</font></div>
          <div><font face="courier new, monospace">regardless of ingress
              port.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Necessary REST API
              changes</font></div>
          <div><font face="courier new, monospace">--------------------------</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">Changes in RuleDto:</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">  * 'flowAction' will
              get a new allowed value: 'queue'.</font></div>
          <div><font face="courier new, monospace">  * New field:
              queueId. It MUST have a value if flowAction is 'queue',</font></div>
          <div><font face="courier new, monospace">    and that value
              must be id of a valid QueueDto object.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">A new QueueDto is
              created, with fields:</font></div>
          <div><font face="courier new, monospace">  * id</font></div>
          <div><font face="courier new, monospace">  * maxRateKbps
              Maximum ingress (into the virtual topology - egress from</font></div>
          <div><font face="courier new, monospace">    the pov of the
              VM) bandwidth.</font></div>
          <div><font face="courier new, monospace">  * qosMark
              (to-be-discussed) - this would mark the packet for
              matching</font></div>
          <div><font face="courier new, monospace">    in processing by
              the linux qos stack, letting admins setup more</font></div>
          <div><font face="courier new, monospace">    sophisticated QoS
              behaviour. This would use OVS skb-mark action.</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">A new top-level URL
              for the QueueDto:</font></div>
          <div><font face="courier new, monospace"><br>
            </font></div>
          <div><font face="courier new, monospace">  * /queues/ -
              ApplicationDto would get a new getQueues() method.</font></div>
          <div><font face="courier new, monospace">  *
              /queues/:queue_id/ (URL for a Queue - POST, DELETE, GET)</font></div>
          <div><br>
          </div>
          <div><br clear="all">
            <div><br>
            </div>
            Regards,</div>
          <div><br>
            <div dir="ltr">-- Guillermo Ontañón</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">-- Guillermo Ontañón</div>
</div></div>