Open Stack

Dear Thierry,



Thanks for your suggestion.



It is submitted as below.

http://summit.openstack.org/cfp/create


Topic

Title (Click to view/edit)

Proposer

Status

Neutron

Scaling Network Performance for Large Clouds<http://summit.openstack.org/cfp/details/270>

Tina Tsou

U Unreviewed






Thank you,

Tina





-----Original Message-----
From: Thierry Carrez [mailto:thierry at openstack.org]
Sent: Wednesday, April 09, 2014 6:36 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] Session suggestions for the Juno Design Summit now open



Tina TSOU wrote:

> Below is our proposal. Look forward to your feedback.

>

> --------------

> Description

> This session focuses on how to improve networking performance at large scale deployment.

> For example

> - having many VMs, thousands to tens of thousands, in a single data

> center

> - very heavy traffic between VMs of different physical servers

> - large quantities of OpenFlow flow tables causing slow forwarding on

> OVS and high CPU usage on hypervisor

> - VMs belong to various tenants thus requiring traffic isolation and

> security and lots of configuration on OVS mainly overlay encapsulation

> and OpenFlow tables

> - neutron server taking too long time to process requests

>

> We are introducing a solution designed for the above scenario in this area.

> The main idea is to deploy on the hypervisor a new monitor agent which will periodically check the CPU usage and network load of the NIC and inform SDN controller through plugin/API extension. If the OVS load goes very high, SDN controller can reactively off-load the traffic from OVS to TOR with minimum interruption. It means that initially, the overlay encapsulation might be done on OVS, but some feature rich TORs also provide this functionality which makes TOR capable of taking over whenever necessary. The same strategy will be applied for OpenFlow flow table. By doing this, OVS will have nothing to do other than sending the traffic to TOR. All the time-consuming jobs will be taken over by TOR dynamically. This more advanced strategy does require TOR to be feature-rich so it might cause more TCO.

>

> We believe this is worth doing for large scale deployment.

> --------------



You should file it at summit.openstack.org so that it can be considered for inclusion in the schedule.



Regards,



--

Thierry Carrez (ttx)



_______________________________________________

OpenStack-dev mailing list

OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140410/3eb75e85/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 91 bytes
Desc: image001.gif
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140410/3eb75e85/attachment.gif>