{"id":1313,"date":"2013-08-16T00:54:24","date_gmt":"2013-08-16T00:54:24","guid":{"rendered":"http:\/\/www.syslog.cl.cam.ac.uk\/?p=1313"},"modified":"2013-08-16T08:57:47","modified_gmt":"2013-08-16T08:57:47","slug":"liveblog-from-sicomm13-hotsdn-workshop","status":"publish","type":"post","link":"https:\/\/www.syslog.cl.cam.ac.uk\/2013\/08\/16\/liveblog-from-sicomm13-hotsdn-workshop\/","title":{"rendered":"Liveblog from SICOMM13 &#8211; HotSDN Workshop"},"content":{"rendered":"<p>Once again collocated with SIGCOMM is the HotSDN conference. I'm here live blogging the proceedings, SDN controllers permitting....<\/p>\n<p><!--more--><\/p>\n<h1>Session 1 - Controller Architecture<\/h1>\n<h2>The Beacon OpenFlow Controller<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p13.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p13.pdf<\/a><\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>Back in the day, the state of the art was NOX\n<ul>\n<li>Python - inconsistent API<\/li>\n<li>C++ - STL (strange errors), Linux<\/li>\n<\/ul>\n<\/li>\n<li>Decided to build a controller\n<ul>\n<li>Decided to use Java because it's fast and cross platform.<\/li>\n<li>Decided against C# because it's not x-platform<\/li>\n<li>Decided against python because it's single threaded? [ed huh?]<\/li>\n<\/ul>\n<\/li>\n<li><strong>SDN controller ~= operating system [ed: interesting insight]\u00c2\u00a0<\/strong><\/li>\n<li>Beacon:\n<ul>\n<li>Core module, with lots of modules above it.<\/li>\n<li>Single threaded, 1 thread per core. 1 thread per switch.<\/li>\n<\/ul>\n<\/li>\n<li>Beacon scales up to about 13M repossess per second on 12 cores, much better than anyone else.<\/li>\n<li>Floodlight is an open source version of Beacon.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>Questions:<\/strong><\/p>\n<p>Q: Why is it fast? A: Limited by programming languages, and I\/O interfaces.<\/p>\n<p>Q: The metric you're using, what does it tell you about apps? A: It's the lowest bar. This is the overhead that your controller is running.<\/p>\n<p>&nbsp;<\/p>\n<h2>Exploiting Locality in Distributed SDN Control<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/www.syslog.cl.cam.ac.uk\/wp-admin\/post.php?post=1313&amp;action=edit&amp;message=6\">http:\/\/www.syslog.cl.cam.ac.uk\/wp-admin\/post.php?post=1313&amp;action=edit&amp;message=6<\/a><\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Controllers don't dictate the network, you have a distributed system.\u00c2\u00a0<\/span><\/li>\n<li>2 Dimensions -\n<ul>\n<li>There is a spectrum. Fully centralised through to totally distributed.<\/li>\n<li>Visibility of the network from fully \u00c2\u00a0centralised to totally distributed.<\/li>\n<\/ul>\n<\/li>\n<li>How to control a network if we have a local view only?<\/li>\n<li>Local view means we can scale easily.<\/li>\n<li>Applications\n<ul>\n<li>Load balancing == Link assignment \"semi-matching problem\"<\/li>\n<li>Loop free forwarding == Spanning tree<\/li>\n<\/ul>\n<\/li>\n<li>Both tasks are trivial if you have a global view, not trivial with a local view.<\/li>\n<li>Local control - we try to minimise interactions between controllers.<\/li>\n<li>Take home 1 - Go for local approximations - Semi-matching is global, but you can do it almost optimally.<\/li>\n<li>Take home 2 - Verification is easier than computation - verification can be made local<\/li>\n<li>Take home 3 - Not purely local, pre-processing can help.<\/li>\n<li>Take home &gt; 3 - Make sure that your controller graph has a low degree.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>\u00c2\u00a0Towards an Elastic Distributed SDN Controller<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p7.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p7.pdf<\/a><\/p>\n<ul>\n<li>We'd like a distributed control plane, but we don't want to overload controllers.<\/li>\n<li>So, we want dynamic load distribution, and elastic control expansion\/shrinking.<\/li>\n<li>This requires, load estimation at the controllers, and a switch migration protocol.<\/li>\n<li>This paper focuses on a switch migration protocol.<\/li>\n<li>Naive switch migration - Master + State. Migration = Switch master and slave.<\/li>\n<li>Pretty simple, just send a change role message.<\/li>\n<li>But, you can drop packets if you switch half way through message exchanges.<\/li>\n<li>4-Phase migration protocol.\n<ol>\n<li>Change from slave to equal both now receive messages, but only one responds.<\/li>\n<li>New master adds a dummy entry and removes it. This creates a message that is sent to both controllers. Sync point.<\/li>\n<li>\u00c2\u00a0Old master flushes out any old messages.<\/li>\n<li>Equal now switches to master.<\/li>\n<\/ol>\n<\/li>\n<li>Evaluated with mininet<\/li>\n<li>Cannot generate enough traffic on a single host to test this.<\/li>\n<li>So we enhanced minimnet to be distributed emulated network using GRE tunnels.<\/li>\n<\/ul>\n<h2>Cementing High Availability in OpenFlow with RuleBricks<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p139.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p139.pdf<\/a><\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">We need to plan for failure in our SDN networks.\u00c2\u00a0<\/span><\/li>\n<li>How can high availability policies be added o openflow's forwarding rules?<\/li>\n<li>We wan't a backup plan in case something fails.<\/li>\n<li>Exploits two features\n<ul>\n<li>Hierarchal structure of wildcards<\/li>\n<li>Precedence rules extraction<\/li>\n<\/ul>\n<\/li>\n<li>If you look at matching as blocks (bricks) instead of a a binary tree - each brick reprsents some part of the matching space.<\/li>\n<li>We colour the bricks depending on which flows they belong to.\n<ol>\n<li>Dropping bricks down as new replicas come online.<\/li>\n<li>Insert - slide a brick in underneath other bricks.<\/li>\n<li>Reduce transforms - Fragment, defragment, duplicate.<\/li>\n<\/ol>\n<\/li>\n<li>Built a greed algo that frags\/defrags bricks.<\/li>\n<li>1. Fragement 2. Deduplicate 3. defrag.<\/li>\n<li>What can you do with it?<\/li>\n<li>Eg:<\/li>\n<li>1 brick to cover the entire space.<\/li>\n<li>Add a replica, another rule for the whole space, plus an active rule.<\/li>\n<li>Implemented rule bricks in python.\n<ul>\n<li>how does it affect the rule list size? Not too bad.<\/li>\n<\/ul>\n<\/li>\n<li>\u00c2\u00a0Take away, failure is elasticity's evil twin.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>Questions<\/strong><\/p>\n<p>Q: Do you end up with a mess in the end? Fragmentation A: We don't just drop from the top. The reduction operations help to defragment. No proof of optimality \u00c2\u00a0(yet).<\/p>\n<p>Q: How do you detect failure? A: We don't.<\/p>\n<p>Q: How do you detect host failure? A: \u00c2\u00a0We assume that you're running in a VM.<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<h1>Session 2 - Testing, Simulation, and Debugging<\/h1>\n<h2>Leveraging SDN Layering to Systematically Troubleshoot Networks<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p37.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p37.pdf<\/a><\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>How do you automate troubleshooting?<\/li>\n<li>Requirements:\n<ol>\n<li>Know the intended policy<\/li>\n<li>Check behaviour against policy<\/li>\n<\/ol>\n<\/li>\n<li>Requirements in in a traditional network are hard.<\/li>\n<li>But in SDN??<\/li>\n<li>Key insight: Modularity allows us to check the behaviour of any given layer. Any bug will manifest as a mistranslation between layers.<\/li>\n<li>Allows a systematic approach.<\/li>\n<li>Eg:\n<ul>\n<li>Two hosts can't communicate.<\/li>\n<li>Check the policy to make sure the sorting policy is ok. (Anteater)<\/li>\n<li>Use \"soft\" to figure out if switches are implementing rules correctly. Then we know there is a firmware bug.<\/li>\n<\/ul>\n<\/li>\n<li><span style=\"font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; line-height: 18px;\">\u00c2\u00a0So, what has changed?\u00c2\u00a0<\/span>\n<ul>\n<li>We no longer need to understand all of the protocols and all of their interactions. Tools can do that for us.<\/li>\n<li>Automated troubleshooting appears to be possible.<\/li>\n<\/ul>\n<\/li>\n<li>Thinking about troubleshooting in terms of tools and layers.<\/li>\n<li>Plenty of opportunities left.<\/li>\n<\/ul>\n<h2><\/h2>\n<h2>High-Fidelity Switch Models for\u00c2\u00a0Software-De\u00ef\u00ac\u0081ned Network Emulation<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p43.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p43.pdf<\/a><\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>Suppose you want to buy an SDN switch? Which one do you want to buy?<\/li>\n<li>\u00c2\u00a0Different switches have different performances.<\/li>\n<li>How do you predict the performance of 1000 switches given just 1.<\/li>\n<li>Emulators\/simulators are great, but they aren't good enough, for control plane.<\/li>\n<li>open vswitch doesn't model the data plane.<\/li>\n<li>We want an emulator. But what are the differences?<\/li>\n<li>Flow table size. Flow table management policy, different switches, different CPUs<\/li>\n<li>Just going to model switch CPU speed for this talk.<\/li>\n<li>In a flow setup stage, the flow is handled by the CPU. Which may be wimpy.<\/li>\n<li>Ingress, egress delays matter.<\/li>\n<li>Measure ingress\/egress \u00c2\u00a0delay.<\/li>\n<li>OVS is really fast. Ingress\/egress delay is almost zero - So we can slow down OVS to make it the same as a real switch.<\/li>\n<li>Emulated performance is a pretty reasonable approximation.<\/li>\n<li>Not quite the same because we only capture ingress\/egress delays.<\/li>\n<\/ul>\n<h2><\/h2>\n<h2>Fast, Accurate Simulation for SDN Prototyping<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p31.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p31.pdf<\/a><\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Prototyping and debugging SDN is hard.\u00c2\u00a0<\/span><\/li>\n<li>The main challenge is the S. Writing good software is hard.<\/li>\n<li>Goal develop an SDN simulation capability that complements existing development and debugging tools.<\/li>\n<li>fs - Accurate to 1 second time scales. FS-SDN uses the POX controller.<\/li>\n<li>Monkey patching to get POX and FS to talk to each other.<\/li>\n<li>Results: Significant speed up. 900 second experiments down to 6 - 72 seconds.<\/li>\n<li>Code available on github<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>EtherPIPE: an Ethernet character device for network\u00c2\u00a0scripting<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p61.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p61.pdf<\/a><\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">We provide a character device, that allows packets to be written and read<\/span><\/li>\n<li>Two interfaces, ascii and binary formats.<\/li>\n<li>Can use standard linux text tools for creating and capturing packets.<\/li>\n<li>\"optimized\" interface with binary tools.<\/li>\n<li>Uses LatticeECP3 FPGA NIC.<\/li>\n<li>1.4M pps with character packets at 1G == line rate.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h1>Session 3 - \u00c2\u00a0Improved Abstractions and State Management<\/h1>\n<h2>Protocol-Oblivious Forwarding: Unleash the Power\u00c2\u00a0of SDN through a Future-Proof Forwarding Plane<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p127.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p127.pdf<\/a><\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">We want to make switches oblivious to the SDN protocol used.\u00c2\u00a0<\/span><\/li>\n<li>SDN should operate like a PC. With generic instructions.<\/li>\n<li>It can be done efficiently with microcode.<\/li>\n<li>We built a prototype.<\/li>\n<li>We need to standardise the instruction set.<\/li>\n<\/ul>\n<p>Question: How do you handle diversity in the instruction sets. Vendors always add proprietary extensions!<\/p>\n<h2>Incremental Consistent Updates<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p49.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p49.pdf<\/a><\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">How do you update \u00c2\u00a0policy in the\u00c2\u00a0controllers\u00c2\u00a0consistently.\u00c2\u00a0<\/span><\/li>\n<li>Past work: Packet sees either old policy or new policy, so you keep both.<\/li>\n<li>But this takes 100% overhead and rule space is expensive. Can you do an incremental update?<\/li>\n<li>Trade space for time.<\/li>\n<li>Update the policy slice by slice.<\/li>\n<li>How do you compute a slice?<\/li>\n<li>Compute using symbolic execution.<\/li>\n<li>Update slices like garbage collection. Use reference counting to make sure that packets see only \u00c2\u00a01 rule.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>HotSwap: Correct and Ef\u00ef\u00ac\u0081cient Controller\u00c2\u00a0Upgrades for Software-De\u00ef\u00ac\u0081ned Networks<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p133.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p133.pdf<\/a><\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">How do you upgrade your SDN controllers, which is destruction free and correct.\u00c2\u00a0<\/span><\/li>\n<li>SDN controllers must be upgraded to:\n<ul>\n<li>fix bugs<\/li>\n<li>new services<\/li>\n<li>improve performance.<\/li>\n<\/ul>\n<\/li>\n<li>Releases to popular openflow controllers (3-33) patches 1000's<\/li>\n<li>We upgrade controllers by rebooting.\n<ul>\n<li>Network failure<\/li>\n<li>rule timeout<\/li>\n<li>packet failure<\/li>\n<\/ul>\n<\/li>\n<li>New controller, wipes out the forwarding table, so there are no remaining rules.<\/li>\n<li>Is it\u00c2\u00a0<em>really<\/em> a problem?<\/li>\n<li>Simulated using mini-net. Up to 83% of packets lost.<\/li>\n<li>Consider - a controller running a statefull firewall.\n<ul>\n<li>When a controller starts. \u00c2\u00a0You can block allowed traffic, or allow forbidding traffic.<\/li>\n<\/ul>\n<\/li>\n<li>HotSwap is a hypervisor - warms up the upgraded controller before handing over to it.\n<ol>\n<li>Record stage. - Abstract view of network state<\/li>\n<li>Replay - plays the network events over to the new controller.<\/li>\n<li>Compute the delta between the rules.<\/li>\n<li>Push the rules out.<\/li>\n<li>Return to 1<\/li>\n<\/ol>\n<\/li>\n<li>Challenges:\n<ul>\n<li>Scalability - Recording everything doesn't scale, but, we only need some subset of the events.<\/li>\n<li>Correctness - We want version 2 of the rules to behave as if it had always been 1 rule.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>\u00c2\u00a0CAP for Networks<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p91.pdf<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">\u00c2\u00a0CAP theorem, correctness or availability, can't have both.\u00c2\u00a0<\/span><\/li>\n<li>eg SQL servers correctness, KVS, \u00c2\u00a0availability.<\/li>\n<li>What about networks? With the move to SDN, we wanted richer functions.<\/li>\n<li>Control plane partitions no longer imply data plane partitions.<\/li>\n<li>Data plane connected --&gt; Delivers packets, but not necessarily correct.<\/li>\n<li>Can one can provide correct isolation and availability in the presence of link failures.<\/li>\n<li>Only consider, \u00c2\u00a0out of band control networks.<\/li>\n<li>You cannot, in general, provide both isolation and availability in the presence of failure.<\/li>\n<li>You must pick one or the other.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<h1>Session 4 - Theoretical Foundations<\/h1>\n<h2>Software Transactional Networking:\u00c2\u00a0Concurrent and Consistent Policy Composition<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p1.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p1.pdf<\/a><\/p>\n<ul>\n<li>How does the design of the distributed control plane affect replication?<\/li>\n<li>Can we realise the benefits of software transactional memory (STM) in the network? \"Software Transactional Networking\" (STN)<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>FatTire: Declarative Fault Tolerance\u00c2\u00a0for Software-De\u00ef\u00ac\u0081ned Networks<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p109.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p109.pdf<\/a><\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">OpenFlow 1.1+ -&gt; Fast failure\u00c2\u00a0<\/span><\/li>\n<li>Frenetic provides a declarative language for expressing forwarding policies.<\/li>\n<li>But doesn't know how to cope if there is a failure because it's hop-by-hop<\/li>\n<li>FatTire -&gt; Lifts the abstraction up from hop-by-hop to full path forwarding.<\/li>\n<li>Write programs in terms of regular expressions<\/li>\n<li>Use annotations to define fault-tolerance conditions.<\/li>\n<li>Combine policies with intersections and unions.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>Resource\/Accuracy Tradeoffs in Software-De\u00ef\u00ac\u0081ned\u00c2\u00a0Measurement<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p73.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p73.pdf<\/a><\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>Lots of good reasons to do measurement\n<ul>\n<li><span style=\"line-height: 13px;\">Management policies often want measurement.\u00c2\u00a0<\/span><\/li>\n<li>Accounting for pricing also wants it<\/li>\n<li>As does troubleshooting<\/li>\n<\/ul>\n<\/li>\n<li>Would like to use SDN to do measurement.<\/li>\n<li>Limited resources CPU\/memory in switches.<\/li>\n<li>Limited control network bandwidth.<\/li>\n<li>Different primitives used in switches.<\/li>\n<li>Different measurements require different resources.<\/li>\n<li>Eg: Monitor 10.0.0.1\/24, when traffic exceeds a threshold, figure out where it's from.<\/li>\n<li>Use sketches from hash based counters.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>Towards Secure and Dependable Software-De\u00ef\u00ac\u0081ned\u00c2\u00a0Networks<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p55.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p55.pdf<\/a><\/p>\n<ul>\n<li>\u00c2\u00a0SDN allows us to program the network. Cool!<\/li>\n<li>But bad guys can do it too.<\/li>\n<li>Threats?<\/li>\n<li>7 new threat vectors.<\/li>\n<li>Tools we can use:\n<ul>\n<li>Replication<\/li>\n<li>Self-Healing<\/li>\n<li>Diversity -&gt; Making it hard to find vulnerability.<\/li>\n<li>Autonomic trust between controllers and devices, and between apps and controllers.<\/li>\n<li>Security domains (eg rings on OSs, eg FortNox)<\/li>\n<\/ul>\n<\/li>\n<li>Use a collection of different controllers, with a common API. Diversity is strength.<\/li>\n<li>Main message: SDN increases the threat surface.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>Question<\/strong><\/p>\n<p>Q: IOS already has attack vectors. Multi-chassis machines already have controlers. Where is the new attack vector: A: ??<\/p>\n<p>&nbsp;<\/p>\n<h2>A Balance of Power:\u00c2\u00a0Expressive, Analyzable Controller Programming<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p79.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p79.pdf<\/a><\/p>\n<ul>\n<li>When you program the switch you can use any language.<\/li>\n<li>But the data plane expects open flow.<\/li>\n<li>Programming in OpenFlow is a pain.<\/li>\n<li>So, we can use higher level languages. (Frenetic, Pyretic etc)<\/li>\n<li>Abstractions aren't quite right.\n<ul>\n<li>Want a hash table, or a set or a graph.<\/li>\n<\/ul>\n<\/li>\n<li>In reality, these high level languages are wrong. Half for the controller, half for the control.<\/li>\n<li>When you use a bug finding tool, it find bug in the flow tables, but you want to relate that back to the control plane programming language.<\/li>\n<li>Missing: Platform for programming and verification of control and data plane.<\/li>\n<li>FlowLog: A limited and restricted language. Unified for doing both control and data plane code.<\/li>\n<li>Based on prolog: No recursion support. No arithmetic.<\/li>\n<li>Cannot express shorted path algo in FlowLog.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>OF.CPP: Consistent Packet Processing for OpenFlow<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p97.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p97.pdf<\/a><\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">I'm not really following this talk.\u00c2\u00a0<\/span><\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<h1>Session 5 -\u00c2\u00a0Dataplane and Wireless Techniques<\/h1>\n<h2>FlowTags: Enforcing Network-Wide Policies in the\u00c2\u00a0Presence of Dynamic Middlebox Actions<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p19.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p19.pdf<\/a><\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Add flow tags to packets to bridge gaps across middle boxes.\u00c2\u00a0<\/span><\/li>\n<li>Middle boxes produce and consume tags<\/li>\n<li>FlowTags make flow context visible.<\/li>\n<li>Minimal modifications to middle boxes.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>SoftRAN: Software De\u00ef\u00ac\u0081ned Radio Access Network<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p25.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p25.pdf<\/a><\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Radio access network, high capacity wireless connectivity.\u00c2\u00a0<\/span><\/li>\n<li>Increasing demand for wireless resources.<\/li>\n<li>solution: dense deployment, but it's possible for base stations to cross paths.<\/li>\n<li>In dense deployments higher frequency of handovers.<\/li>\n<li>We need tightly co-ordinated management.<\/li>\n<li>Currently limited coordination between base stations.<\/li>\n<li>SofRAN - Big BaseStation Abstraction.\n<ul>\n<li>Abstract capacity as a single large 3d capcity structure.<\/li>\n<li>Logically centralised management.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h2><\/h2>\n<h2>The FlowAdapter: Enable Flexible Multi-Table Processing\u00c2\u00a0on Legacy Hardware<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p85.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p85.pdf<\/a><\/p>\n<ul>\n<li>\u00c2\u00a0Goal is to address the mismatch between the controllers.<\/li>\n<li>I can't follow this talk, and I don't understand the abstract. :-(<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>Cheap Silicon: a Myth or Reality? \u00c2\u00a0Picking the Right Data Plane\u00c2\u00a0Hardware for Software Defined Networking<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p103.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p103.pdf<\/a><\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Traditional landscape, if we reduce programability, we\u00c2\u00a0increase\u00c2\u00a0performance.\u00c2\u00a0<\/span>\n<ul>\n<li>NPUS !4-5W \/ 10G<\/li>\n<li>CPUS ~25W \/ 10G<\/li>\n<li>Switches ~0.5W \/ 10G<\/li>\n<\/ul>\n<\/li>\n<li>But this is not apples to apples.<\/li>\n<li>We implement a switching load. (on paper)<\/li>\n<li>CPU Packets per second per watt isn't that bad when we compare now. And maximum packet rate is quite good.<\/li>\n<li>Performance depends mostly on the use case.<\/li>\n<li>NPU is probably the right model. Proof by prototyping.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>Open Transport Switch - A Software De\u00ef\u00ac\u0081ned Networking\u00c2\u00a0Architecture for Transport Networks<\/h2>\n<p><a title=\"paper\" href=\"http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p115.pdf\">http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/hotsdn\/p115.pdf<\/a><\/p>\n<ul>\n<li>\u00c2\u00a0What about the WAN?<\/li>\n<li>There's a lot of complexity in the wAN.<\/li>\n<li>Circuit oriented.<\/li>\n<li>Static pipes\/configuration<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Once again collocated with SIGCOMM is the HotSDN conference. I&#8217;m here live blogging the proceedings, SDN controllers permitting&#8230;.<\/p>\n","protected":false},"author":34,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[6,28,23],"tags":[88,79,86],"_links":{"self":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1313"}],"collection":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/users\/34"}],"replies":[{"embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/comments?post=1313"}],"version-history":[{"count":29,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1313\/revisions"}],"predecessor-version":[{"id":1315,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1313\/revisions\/1315"}],"wp:attachment":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/media?parent=1313"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/categories?post=1313"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/tags?post=1313"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}