#opendaylight-meeting: TWS

Meeting started by colindixon at 17:03:43 UTC (full logs).

Meeting summary

  1. HP presentation on possible contributions (colindixon, 17:05:32)
    1. HP is exploring ways to help and contribute to ODL, this includes explaining their lessons from building their own controller (colindixon, 17:07:39)

  2. performance (of the controller) (colindixon, 17:08:17)
    1. HP's Openflow plugin in HP commercial controller can perform @ 3Mpps (Madhu, 17:08:57)
    2. HP's plugin supports both OF1.0 and OF1.3 (Madhu, 17:09:39)
    3. the numbers are from cbench which uses only OF1.0 (colindixon, 17:09:53)

  3. demo of the controller (colindixon, 17:10:37)
    1. controller starts in a karaf container in 3-4 seconds (impressive) (colindixon, 17:12:01)
    2. after one warm-up round of ~400k packet_in/second, we see 3.0–3.2 million packet_in/sec (colindixon, 17:12:57)

  4. performance (how they got there) (colindixon, 17:14:38)
    1. Thomas's Demo was based on a few core open flow bundles running in Karaf container (Madhu, 17:14:39)
    2. some performance from caching information at the controller so that most operations are controller-local (ODL also does this mostly) (colindixon, 17:16:25)
    3. HP capped with 1.2 million pps w/ Netty (networkstatic, 17:16:34)
    4. 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 (colindixon, 17:17:19)
    5. HP Openflow plugin uses NIO to achieve the 3Mpps. (Madhu, 17:17:29)

  5. testing (colindixon, 17:17:44)
    1. 3Mpps includes end-to-end packet processing (not just I/O) (Madhu, 17:17:49)
    2. unit tests cover 80% of the code (colindixon, 17:17:52)

  6. deep dive (colindixon, 17:18:11)
    1. the system abstraction is very much like the AD-SAL (colindixon, 17:18:45)
    2. diagram of the OpenFlow subsystem (see the slides) (colindixon, 17:19:58)
    3. they do run-to-completion packet_in handling with a system provide them with deterministic handling (ordering) (colindixon, 17:22:30)
    4. people who handle packet_ins are first advisors, then directors, then observers (colindixon, 17:22:51)
    5. question (from icbts) if they’re using the same karaf container as ODL (colindixon, 17:25:52)
    6. 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” (colindixon, 17:26:04)
    7. 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 (colindixon, 17:27:00)
    8. they currently use 16 I/O loops (that is threads), and so multiple switches can be mapped to the same I/O loop (colindixon, 17:27:26)

  7. demo number 2 (colindixon, 17:29:18)
    1. includes an application to show the topology (colindixon, 17:29:37)
    2. (aside) shows off javadoc with nice graphics and clearly some effort put into it (colindixon, 17:30:09)
    3. https://wiki.opendaylight.org/images/8/81/HP_OpenFlow.pptx (link to the slides) will also be on the wiki (colindixon, 17:30:48)
    4. runs mininet with a tiered topology with nice layout showing the thing in the browser (colindixon, 17:31:33)
    5. 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.) (colindixon, 17:32:37)
    6. shows karaf CLI commands for hosts, devices, links, paths, etc. (colindixon, 17:33:15)
    7. taking a link down shows the change in the UI in nearly real time (looks cool) (colindixon, 17:34:24)

  8. open to questions (colindixon, 17:35:55)
    1. colindixon asks if there was anything really surprising other than Netty being the performance bottleneck (other things seem mostly like good engineering) (colindixon, 17:36:27)
    2. 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 (colindixon, 17:38:22)
    3. regXboi asks what they’d be looking to contribute (colindixon, 17:38:41)
    4. 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 (colindixon, 17:39:54)
    5. question of how close people are to being able to share code (colindixon, 17:40:07)
    6. answer is that things are still in legal at the moment (colindixon, 17:40:16)
    7. jan medved asks how could we plug this into the MD-SAL in any way? (colindixon, 17:40:58)
    8. lenrow says that’s the big question we all need to think through (colindixon, 17:41:13)
    9. 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 (colindixon, 17:41:47)
    10. jan medved asks about sharding and data replication (as does alagalah_) (colindixon, 17:42:11)
    11. the Clustering support is in the Manager layer and not on the Plugin layer (Madhu, 17:44:30)
    12. 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 (Madhu, 17:45:20)
    13. Madhu asks about extensibility with a focus on OpenFlow (colindixon, 17:46:00)
    14. response is that they can do them by defining new/different messages, then provide encoders and decoders (colindixon, 17:46:30)
    15. 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 (colindixon, 17:47:13)
    16. the answer right now is no for the whole stack, but the answer seems to be yes for OpenFlow (colindixon, 17:48:12)
    17. back and forth about abstractions and low-level vs. high-level and protocol specific vs. protocol agnostic (colindixon, 17:54:48)
    18. colindixon asks what the intent is w.r.t. the community (colindixon, 17:55:09)
    19. 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 (colindixon, 17:55:29)
    20. 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 (colindixon, 17:56:12)
    21. answer is yes, they’d like that, it sounded like they would like to explore both options though (colindixon, 17:57:32)
    22. it would obviously be nice to not have even more places where the code base is forked (colindixon, 17:59:32)
    23. colindixon asks if the productization of ODL is the HP product road map (colindixon, 17:59:48)
    24. 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 (colindixon, 18:00:32)
    25. that being said, they say “it would be difficult to productize opendaylight with the current performance” (colindixon, 18:01:01)
    26. 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 (colindixon, 18:03:12)
    27. HP says they very much want to have this stuff be shared infrastructure and genuinely participate in the community (colindixon, 18:03:54)


Meeting ended at 18:03:59 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. colindixon (79)
  2. networkstatic (40)
  3. alagalah_ (21)
  4. dbainbri (10)
  5. regXboi (9)
  6. Madhu (9)
  7. rexpugh-HP (6)
  8. odl_meetbot (5)
  9. icbts (2)
  10. edwarnicke (2)
  11. rovarga (1)
  12. uchau (1)


Generated by MeetBot 0.1.4.