<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>