17:03:43 <colindixon> #startmeeting TWS
17:03:43 <odl_meetbot> Meeting started Mon Jun 30 17:03:43 2014 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:03:43 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:43 <odl_meetbot> The meeting name has been set to 'tws'
17:05:32 <colindixon> #topic HP presentation on possible contributions
17:05:59 <colindixon> #chair Madhu
17:05:59 <odl_meetbot> Current chairs: Madhu colindixon
17:06:01 <colindixon> #chair networkstatic
17:06:01 <odl_meetbot> Current chairs: Madhu colindixon networkstatic
17:06:20 <networkstatic> ahh, ty col
17:06:46 <colindixon> anyone who wants to can start a line with #info to have it show up in the logs, same with #link
17:06:55 <colindixon> only chairs can #topic or #agreed
17:07:39 <colindixon> #info HP is exploring ways to help and contribute to ODL, this includes explaining their lessons from building their own controller
17:08:14 <regXboi> is there a link for the slides for those of us only on the phone?
17:08:17 <colindixon> #topic performance (of the controller)
17:08:23 <colindixon> regXboi: working on it, how’s that coming networkstatic ?
17:08:57 <Madhu> #info HP's Openflow plugin in HP commercial controller can perform @ 3Mpps
17:08:57 <networkstatic> navigating stupid wiki
17:09:06 <colindixon> thanks Madhu
17:09:39 <Madhu> #info HP's plugin supports both OF1.0 and OF1.3
17:09:53 <colindixon> #info the numbers are from cbench which uses only OF1.0
17:10:37 <colindixon> #topic demo of the controller
17:12:01 <colindixon> #info controller starts in a karaf container in 3-4 seconds (impressive)
17:12:57 <colindixon> #info after one warm-up round of ~400k packet_in/second, we see 3.0–3.2 million packet_in/sec
17:13:27 <networkstatic> regXboi https://www.dropbox.com/s/zlu9uwd7pqfdjhx/HP%20OpenFlow.pptx
17:13:34 <networkstatic> dont pound yet
17:13:39 <networkstatic> still getting it on wiki
17:13:40 <colindixon> I’ll post it if you want
17:13:48 <networkstatic> i think i broke the stupid accordian
17:13:49 <networkstatic> lol
17:14:38 <colindixon> #topic performance (how they got there)
17:14:39 <Madhu> #info Thomas's Demo was based on a few core open flow bundles running in Karaf container
17:16:25 <colindixon> #info some performance from caching information at the controller so that most operations are controller-local (ODL also does this mostly)
17:16:34 <networkstatic> #info HP capped with 1.2 million pps w/ Netty
17:16:53 <networkstatic> NIO?
17:17:16 <networkstatic> nice
17:17:19 <colindixon> #Info started with Netty for for I/O, but found it limited them to 1.2 million packet_in/second, seemed to be because netty failed to pack multiple messages into a frame
17:17:29 <Madhu> #info HP Openflow plugin uses NIO to achieve the 3Mpps.
17:17:44 <colindixon> #topic testing
17:17:49 <Madhu> #info 3Mpps includes end-to-end packet processing (not just I/O)
17:17:52 <colindixon> #info unit tests cover 80% of the code
17:18:01 <colindixon> sorry Madhu :p
17:18:11 <colindixon> #topic deep dive
17:18:15 <Madhu> colindixon: np. am trying to cover the missing pieces :)
17:18:21 <colindixon> yup
17:18:45 <colindixon> #info the system abstraction is very much like the AD-SAL
17:19:58 <colindixon> #info diagram of the OpenFlow subsystem (see the slides)
17:20:09 <dbainbri> clarification please, it was commented that they are using a stack similar to AD-SAL. This says to me that this demo is not using AD-SAL nor MD-SAL, so what components of ODL are being used? Or is this essentially just sharing the OSGi controller?
17:20:35 <colindixon> dbainbri: HP’s own controller
17:20:38 <colindixon> not based on ODL
17:20:44 <dbainbri> ah, thx.
17:21:03 <regXboi> so the proposal is to contribute what exactly then?
17:21:15 <colindixon> regXboi: that’s a really good question
17:21:35 <regXboi> well, I'm going to ask it :)
17:22:30 <colindixon> #info they do run-to-completion packet_in handling with a system provide them with deterministic handling (ordering)
17:22:51 <colindixon> #info people who handle packet_ins are first advisors, then directors, then observers
17:24:44 <icbts> I’m wondering if their Karaf container is the same as the one we have at ODL?
17:25:21 <regXboi> icbts: good question
17:25:28 <colindixon> ask if you want to
17:25:29 <uchau> we are using a standalone karaf container, but have prototyped and been able to run in the karaf container that is being put into the controller
17:25:52 <colindixon> #info question (from icbts) if they’re using the same karaf container as ODL
17:25:53 <icbts> uchau: Thanks — we’ve been building ODL to use Karaf
17:26:04 <colindixon> #info answer uchau “we are using a standalone karaf container, but have prototyped and been able to run in the karaf container that is being put into the controller”
17:27:00 <colindixon> #info advisors see the packet_in before any action is taken and can provide metadata that helps, directors actually take action on packets, observers can see the actions taken and make notes for the future
17:27:26 <colindixon> #info they currently use 16 I/O loops (that is threads), and so multiple switches can be mapped to the same I/O loop
17:28:26 <alagalah_> how is mobility handled ?
17:28:40 <rexpugh-HP> clarify? mobility?
17:28:42 <colindixon> alagalah_: can you define mobility?
17:28:55 <alagalah_> App moves.... what happens ?
17:29:18 <colindixon> #topic demo number 2
17:29:23 <alagalah_> ( and I have a bandaged finger so dont expect fast typing)
17:29:37 <colindixon> #info includes an application to show the topology
17:30:09 <colindixon> #info (aside) shows off javadoc with nice graphics and clearly some effort put into it
17:30:17 <networkstatic> colindixon https://wiki.opendaylight.org/images/8/81/HP_OpenFlow.pptx
17:30:48 <colindixon> #link https://wiki.opendaylight.org/images/8/81/HP_OpenFlow.pptx (link to the slides) will also be on the wiki
17:30:52 <colindixon> networkstatic: thanks!
17:31:04 <alagalah_> This is pretty cool actually
17:31:25 <networkstatic> alagalah_ beating Netty is interesting
17:31:33 <colindixon> #info runs mininet with a tiered topology with nice layout showing the thing in the browser
17:31:37 <alagalah_> networkstatic: lolz
17:31:45 <rexpugh-HP> Sorry keith not ignoring your question... by App, you mean consumer of the Network service API (Java or REST?)
17:32:21 <alagalah_> rexpugh-HP: yes I mean consumer
17:32:27 <networkstatic> remind me, did BSN use Netty for socket abstraction or did they end up with NIO also?
17:32:37 <colindixon> #info shows the path in the web UI and demonstrates multipathing (shortest path based on hop-count, can also do paths to avoid obstacles, provide waypoints, link weighting, etc.)
17:33:15 <colindixon> #info shows karaf CLI commands for hosts, devices, links, paths, etc.
17:33:47 <alagalah_> rexpugh-HP: specifically either (which is a tautology)
17:34:08 <alagalah_> rexpugh-HP: but this is cool
17:34:24 <colindixon> #info taking a link down shows the change in the UI in nearly real time (looks cool)
17:34:56 <rexpugh-HP> App mobility opens a different discussion around how we hooked the "controller" to cluster peers using message bus technology. HP product uses modified hazelcast for state sync etc
17:35:25 <rexpugh-HP> didnt want to bring that up in this forum
17:35:45 <networkstatic> dont say motherhood and apple pie, we say that too much
17:35:55 <colindixon> #topic open to questions
17:35:55 <networkstatic> makes me hungry too
17:36:25 <networkstatic> What is the performance comparison?
17:36:27 <colindixon> #info colindixon asks if there was anything really surprising other than Netty being the performance bottleneck (other things seem mostly like good engineering)
17:36:31 <networkstatic> MD/AS
17:36:37 <networkstatic> er MD/HP_AD
17:36:53 <alagalah_> rexpugh-HP: motherhood and apple pie .. there... I went there... and yes I am hungry
17:36:56 <colindixon> networkstatic: ~16,000 ops/second last I checked on Jan’s laptop I think in a vm
17:37:15 <alagalah_> rexpugh-HP: :)
17:38:22 <colindixon> #Info it’s a combination of things, in particular they note get the factoring of functionality layered in the right places to keep things from causing other bottlenecks
17:38:34 <rexpugh-HP> thanks keith... I will bring dessert next time
17:38:41 <colindixon> #info regXboi asks what they’d be looking to contribute
17:38:57 <alagalah_> colindixon: I think that was networkstatic
17:39:32 <dbainbri> so, to play devil's advocate, if an OF plugin contribution won't actually improve overall performance, because of the upper layers, what are we looking to gain?
17:39:41 <dbainbri> we == ODL
17:39:54 <colindixon> #info answer is that at a minimum, they’d want to to contribute the OF controller (the part that talks to switches) and the I/O loop, but would also like to contribute more because it might not improve performance without also reworking some of the upper layers
17:40:05 <networkstatic> dbainbri what if you dont use it?
17:40:07 <colindixon> #info question of how close people are to being able to share code
17:40:15 <alagalah_> networkstatic: good point
17:40:16 <colindixon> #info answer is that things are still in legal at the moment
17:40:28 <regXboi> yep... it's a third SAL
17:40:41 <alagalah_> regXboi: yay
17:40:43 <dbainbri> regXboi: that is what i was concerned about
17:40:58 <colindixon> #info jan medved asks how could we plug this into the MD-SAL in any way?
17:41:13 <networkstatic> not like we dont already have two conrtollers already
17:41:13 <colindixon> #info lenrow says that’s the big question we all need to think through
17:41:16 <networkstatic> why not
17:41:20 <alagalah_> Can we talk about sharding ?
17:41:29 <networkstatic> use karaf, build whatever alacart
17:41:31 <alagalah_> Or replication
17:41:33 <networkstatic> we are there anyways
17:41:46 <dbainbri> networkstatic: don't understand your point, what if you don't use it? we have an OF plugin today. this contribution may be more performant than this plugin, but it sounds like the real performance is outside that device comms bit.
17:41:47 <colindixon> #info some comments (from networkstatic and regXboi, but I agree) that this looks like it would be a third SAL, i.e., almost a third controller
17:41:49 <networkstatic> grab your bundles, build the controller to build your app
17:42:11 <colindixon> #info jan medved asks about sharding and data replication (as does alagalah_)
17:42:12 <alagalah_> colindixon: +1
17:42:24 <networkstatic> dbainbri sorry, meaning, if you dont need the nuclear submarine. we use topology and OF13
17:42:27 <networkstatic> thats it
17:42:50 <networkstatic> so seeing 16k flowmods p/sec vs a very streamlined OF implementation
17:42:56 <networkstatic> why not
17:43:02 <alagalah_> networkstatic: +1
17:43:02 <regXboi> is it me or does this sounds like this is self sharded
17:43:04 <networkstatic> competition is good imo
17:43:11 <networkstatic> keep peeps on their toes
17:43:13 <alagalah_> regXboi: WTF does that mean
17:43:16 <colindixon> regXboi: I’m not really following this
17:43:18 <networkstatic> lol
17:43:26 <dbainbri> but we don't get the demonstrated through put unless we have the contributed plugin as well as the upper layers used.
17:43:44 <colindixon> Madhu: can you summarize that if you understood it?
17:43:56 <Madhu> colindixon: yes
17:44:00 <networkstatic> yeah, i heard that too dbainbri until we see code hard to say.
17:44:03 <alagalah_> regXboi: Dude... wtf does "self clustering" mean? you flummaxed me
17:44:13 <dbainbri> agree competition is good, but it gets harder and harder to define what ODL is.
17:44:15 <regXboi> what I heard in that conversation about remote processing is that the implementation is already doing sharding
17:44:17 <colindixon> Madhu: and I can summarize flexibility
17:44:29 <regXboi> or its equiv to keep requests local whenever possible
17:44:30 <Madhu> #info the Clustering support is in the Manager layer and not on the Plugin layer
17:44:34 <networkstatic> dbainbri i think a pretty tight package went over the cliff 6 months ago
17:44:45 <dbainbri> networkstatic: lol
17:44:49 <networkstatic> hehe
17:45:10 <networkstatic> i just want to see nerd rage wars really
17:45:13 <networkstatic> thats all
17:45:18 <regXboi> umm... I don't think the upper IO is the important thing here, I think its the lower level API that are important
17:45:20 <Madhu> #info this is AD-SAL clustering design as well. where the plugin layer performs all the local I/O processing while the NSF / Manager layer manages the clustering data-store across controllers
17:45:46 <dbainbri> i just fear the customer support call. well i started with the ODL bundle you gave me then swapped out X, Y, and Z. not it isn't working. Please fix it vendor.
17:46:00 <colindixon> #info Madhu asks about extensibility with a focus on OpenFlow
17:46:30 <colindixon> #info response is that they can do them by defining new/different messages, then provide encoders and decoders
17:46:40 <alagalah_> networkstatic: This convo requires beer
17:47:05 <networkstatic> +1 edwarnicke extensions
17:47:08 <alagalah_> networkstatic: but it ia too early
17:47:13 <colindixon> #info edwarnicke asks if they can do “side wise augmentation”, that is you can provide a new action at the bottom and consume it at the top without modifying the middle
17:47:15 <networkstatic> w/o changing the plguin
17:48:12 <colindixon> #info the answer right now is no for the whole stack, but the answer seems to be yes for OpenFlow
17:49:56 <colindixon> protocol agnostic loosely means “doesn’t use OF in class names” in my experience (in both ODL and this)
17:50:13 <edwarnicke> colindixon: We've *tried* to do better than that in ODL
17:50:18 <edwarnicke> And sometimes succeeded
17:50:31 <colindixon> edwarnicke: I know, it’s hard, it was mostly innocent snark
17:50:36 <colindixon> though there’s a grain of truth in it
17:53:06 <rexpugh-HP> We can share javadocs today.
17:53:49 <rovarga> that would be excellent. one thing I wonder is how you identify links for example :)
17:54:48 <colindixon> #info back and forth about abstractions and low-level vs. high-level and protocol specific vs. protocol agnostic
17:55:09 <colindixon> #info colindixon asks what the intent is w.r.t. the community
17:55:29 <colindixon> #info response is that they want to help shepherd the code in and get help from the community, but that they intend to have developers to help support
17:56:12 <colindixon> #info jan medved asks if HP would be willing to help the current openflow plugin in ODL, instead of of (or maybe in addition to) a separate implementation
17:57:32 <colindixon> #info answer is yes, they’d like that, it sounded like they would like to explore both options though
17:59:32 <colindixon> #info it would obviously be nice to not have even more places where the code base is forked
17:59:48 <colindixon> #info colindixon asks if the productization of ODL is the HP product road map
18:00:32 <colindixon> #info answer is that they’re not really willing to make a statement about product strategy in that way, but that they don’t intend to just dump code and walk
18:01:01 <colindixon> #info that being said, they say “it would be difficult to productize opendaylight with the current performance”
18:02:21 <networkstatic> top of the hour
18:02:23 <networkstatic> lets wrap
18:03:12 <colindixon> #info their code is already shipping and so they need to avoid regressing, so they would need at least the performance to come into line; the APIs and abstractions are somewhat more negotiable and would be nice to collaborate on
18:03:54 <colindixon> #info HP says they very much want to have this stuff be shared infrastructure and genuinely participate in the community
18:03:59 <colindixon> #endmeeting