{"id":1253,"date":"2013-08-13T01:00:41","date_gmt":"2013-08-13T01:00:41","guid":{"rendered":"http:\/\/www.syslog.cl.cam.ac.uk\/?p=1253"},"modified":"2013-08-13T09:55:36","modified_gmt":"2013-08-13T09:55:36","slug":"liveblog-from-sigcomm13-day-1","status":"publish","type":"post","link":"https:\/\/www.syslog.cl.cam.ac.uk\/2013\/08\/13\/liveblog-from-sigcomm13-day-1\/","title":{"rendered":"Liveblog from SIGCOMM13 &#8211; Day 1"},"content":{"rendered":"<p>Greetings from SIGCOMM 2013, Hong Kong. I'll be live blogging as much of the event as I can, battery life permitting.<\/p>\n<p><!--more--><\/p>\n<h2>Introduction<\/h2>\n<ul>\n<li>Warning - There may be a typhoon, stay tuned for further updates....<\/li>\n<\/ul>\n<h3>PC Chairs Note<\/h3>\n<ul>\n<li><span style=\"line-height: 13px;\">Inspired by last year, broadened the scope by adding more topics to the CFP and targeting 40 papers for acceptance.\u00c2\u00a0<\/span><\/li>\n<li>First round papers got &gt;200 papers. All got three reviews.<\/li>\n<li>96 to second round<\/li>\n<li>80 papers made it to PC meeting.<\/li>\n<li>Highest acceptance rate ever, about 16%, almost 1\/6.<\/li>\n<\/ul>\n<h3>Best Paper<\/h3>\n<ul>\n<li><span style=\"line-height: 13px;\"><strong>Ambient Backscatter: Wireless Communication Out of Thin Air<\/strong> - Both the best paper and best student paper!\u00c2\u00a0<\/span><\/li>\n<li>Really cool idea. Communication using ambient RF as it's power source. Strong eval.<\/li>\n<\/ul>\n<h3>SIGCOMM Chair (Keshav)<\/h3>\n<ul>\n<li><span style=\"line-height: 13px;\">A new way to asses papers, coming up at community feedback session<\/span><\/li>\n<\/ul>\n<h3>Awards<\/h3>\n<ul>\n<li><span style=\"line-height: 13px;\">Test of time award:<strong> PlanetLab: an overlay testbed for broad-coverage service<\/strong>s, <strong>A Delay-Tolerant Network Architecture for Challenged Internets delay tolerant network architecture\u00c2\u00a0<\/strong><\/span><\/li>\n<li>SIGCOMM Dissertation Award: Shyamnath Gollakota (MIT)<\/li>\n<li>SIGCOMM award: Larry Peterson - For ground breaking advances in how networking and distributed systems research is conducted.<\/li>\n<\/ul>\n<h2>\u00c2\u00a0Kenote: Zen and the Art of Network Architecture (Larry Perterson)<\/h2>\n<ul>\n<li><span style=\"line-height: 13px;\">Zen and the Art of Motorcycle Maintenance: Rejected by 121 publishers (world record)<\/span><\/li>\n<li>Classic vs Romantic perspectives: Science vs Art<\/li>\n<li>Classic view, systems of subsystems. Romantic view, \"I just like to ride my bike\"<\/li>\n<li>Quality unifies both classic and romantic views. Whole is greater than the sum of its parts.<\/li>\n<li>Buddhism: Life = suffering = GENI (test bed)<\/li>\n<li>Duality - Networking vs Distributed Systems - Made GENI very hard to deal with.<\/li>\n<li>The middle way: Involves balancing requirements, not about optimising any one dimension.<\/li>\n<li>Path to Enlightenment:\n<ul>\n<li>Inspiration - Some new idea<\/li>\n<li>Analysis - Simulation, back of the envelope - Does this make sense?<\/li>\n<li>Controlled Lab Experiments - Implementation reality - Can it be built?<\/li>\n<li>Deployment Studies - Traffic and user reality<\/li>\n<li>Pilot Demonstrations - Customer reality<\/li>\n<li>Commercial Adoption - Market reality<\/li>\n<li>Change the market<\/li>\n<\/ul>\n<\/li>\n<li>PlanetLabs &amp; CoBlitz - 12 year time frame. \u00c2\u00a0CoBlitz is a CDN system.\n<ul>\n<li>Change the market: Operators now all have their own CDN systems.<\/li>\n<\/ul>\n<\/li>\n<li>The path to enlightenment:\n<ul>\n<li>See reality clearly - Assumptions hide the truth.<\/li>\n<li>Users reveal the truth faster than any other way<\/li>\n<\/ul>\n<\/li>\n<li>Architectures tell engineers what they can't do, but engineers don't read architecture documents.<\/li>\n<li>Lessons on architectures:\n<ul>\n<li>Part analysis, part intuition - whole is greater than sum of the parts<\/li>\n<li>Unify abstractions - duality is an opportunity<\/li>\n<\/ul>\n<\/li>\n<li>Putting Lessons to Action\n<ul>\n<li>SDN vs NFV (network function virtualisation) vs Distributed Applications<\/li>\n<li>Lines are quite blued. Distinctions without a difference.\n<ul>\n<li>Is a proxy an application or controller?<\/li>\n<li>Is a scalable controller that uses NoSQL an app or a controller?<\/li>\n<li>Is a firewall in the data plane or in the control plane?<\/li>\n<\/ul>\n<\/li>\n<li>Topology - We all have a network graph in our heads.\n<ul>\n<li>Network people like interesting topologies, but applications like a bit switch. Everything to everything.<\/li>\n<li>Basic model: Application is a function that sits on top of the network switch<\/li>\n<li>There are Topology optimisations -\n<ul>\n<li>cut-through - don't bother sending data up to the application<\/li>\n<li>Inline - put the function in the network and don't bother sending to the \"application\"<\/li>\n<\/ul>\n<\/li>\n<li>Really - Cut-through = SDN, inline = NFV.<\/li>\n<\/ul>\n<\/li>\n<li>Model all network functions as \"scalable services\"<\/li>\n<li>Use SDN to bootstrap a virtualization \u00c2\u00a0layer - supports cut-through optimisation<\/li>\n<li>NFV - tool to decide where to put functions.<\/li>\n<\/ul>\n<\/li>\n<li>XaaS - Everything-as-a-Service\n<ul>\n<li>Service as a unifying abstraction.<\/li>\n<li>Unifies across resources (Compute, Network, Storage)<\/li>\n<li>Unifies across the network (DC, Access, WAN)<\/li>\n<li>Unifies across service levels (IaaS, PaaS, SaaS)<\/li>\n<\/ul>\n<\/li>\n<li>Conclusions\n<ul>\n<li>I'm indebted to lots and lots of people including the NSF.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>Questions:<\/strong><\/p>\n<p>Q: What about hardware? A: This model applies as well. Keep it simple, keep it fast and keep the interfaces static.<\/p>\n<p>Q: PlanetLabs: Haven't we been doing OpenCloud all along: A: Network virtualisation is coming up to speed with server virtualisation.<\/p>\n<p>Q: What about publishing: A: Operational experience should be a SIGCOMM category.<\/p>\n<p>Q: What about incentives. Aren't there conflicting requirements encryption vs storage. A: Hard problem, don't have a good answer.<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<h1>Session 1 - SDN<\/h1>\n<h2>B4: Experience with a Globally-Deployed\u00c2\u00a0Software De\u00ef\u00ac\u0081ned WAN<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p3.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>We want to run our networks at 100% utilisation. But then we need to deal with loss. OK.<\/li>\n<li>We are willing to tolerate small amounts of low-bandwidth, if it means we can get higher aggregate bandwidth.<\/li>\n<li>Design principles\n<ul>\n<li>Separate forwarding and hardware from control<\/li>\n<li>Manage network as a single fabric<\/li>\n<li>Use application specific knowledge.<\/li>\n<\/ul>\n<\/li>\n<li>Hybrid SDN Deployment\n<ul>\n<li>Quagga used to implement IBGP\/ISIS to remote sites, slow transition from traditional switches.<\/li>\n<li>\u00c2\u00a0At first we have done a huge amount of work, to just replicate functionality.<\/li>\n<li>Now we can introduce new functionality. eg Traffic Engineering<\/li>\n<\/ul>\n<\/li>\n<li>Traffic engineering server takes demand, topology, application priority and creates a traffic matrix to be programmed into switches.<\/li>\n<li>\n<ul>\n<li>Basically max-min over flow-groups. Flow groups have priorities. Different paths are used to satisfy TE requirements<\/li>\n<li>We don't have to use the shortest path!<\/li>\n<li>15% increase in BW.But...<\/li>\n<li>The real benefit is in failure scenarios. We don't have to run backup links at low utilisation because we know what will happen in a failure.<\/li>\n<\/ul>\n<\/li>\n<li>Challenges\n<ul>\n<li>No time. SDN is not a pancea.<\/li>\n<\/ul>\n<\/li>\n<li>Benefits of SDN\n<ul>\n<li>Leverage commodity forwarding hardware<\/li>\n<li>Control software innovation decoupled from hardware.<\/li>\n<li>Global network optimization<\/li>\n<li><strong>Manage the network as a single fabric rather than a collection.<\/strong>\u00c2\u00a0Really matters at scale<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Questions:<\/p>\n<p>Q: Why use legacy protocols, (IBGP etc) A: Backwards compat\/failure. But as we gain experience, less so<\/p>\n<p>&nbsp;<\/p>\n<h2>Achieving High Utilization with Software-Driven Wan<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p15.pdf<\/p>\n<ul>\n<li>MS, Google, Amazon etc - Large inter-DC WAN, very expensive.<\/li>\n<li>2 key problems \u00c2\u00a01) Poor efficiency 30-50% 2) poor sharing<\/li>\n<li>Why?<\/li>\n<li>Cause of inefficiency -\n<ul>\n<li>Lack of coordination<\/li>\n<li>Greedy resource allocation. Shortest path. Suboptimal.<\/li>\n<li>Poor sharing. \u00c2\u00a0Services compete with each other. Greedy.<\/li>\n<\/ul>\n<\/li>\n<li>SWAN - Software driven WAN<\/li>\n<li>Traffic demands forwarded to controller, rate allocations are sent back. Controller sets up switch planes.<\/li>\n<li>Challenges: scalability, congestion free data plane, small amounts of switch memory.<\/li>\n<li>#1 Computing allocations is hard. Max-Min takes minutes. So instead, we approximate the max-min.\n<ul>\n<li>Only 4% of flows deviated mored than 5% from their fair allocations.<\/li>\n<\/ul>\n<\/li>\n<li>#2: Congestion free updates are hard.\n<ul>\n<li>Leave a small amount of \"scratch\" capacity at each link.<\/li>\n<li>With slack between 0-50% always exists a congestion free update.<\/li>\n<li>LP based solution to find the update steps.<\/li>\n<li>Use slack for background traffic so utilisation is still 100%, but congestion is possible.<\/li>\n<\/ul>\n<\/li>\n<li>#3: Switch memory is limited\n<ul>\n<li>50 sites = 2,500 pairs<\/li>\n<li>3 priority classes<\/li>\n<li>==&gt; &gt;20K rules needed. Switches only have a few thousand rules.<\/li>\n<li>Solution: Dynamic path selection.<\/li>\n<li>Working path set &lt;&lt; total needed paths.<\/li>\n<\/ul>\n<\/li>\n<li>Summary of workflow\n<ul>\n<li>Compute resource allocation<\/li>\n<li>Compute rule update plan<\/li>\n<li>Compute Congestion free updte plan<\/li>\n<li>Notify services<\/li>\n<li>Deploy<\/li>\n<li>Notify applications.<\/li>\n<\/ul>\n<\/li>\n<li>\u00c2\u00a0Compared to optimal, SWAN achieves 98% util.<\/li>\n<\/ul>\n<p><strong>Questions:<br \/>\n<\/strong><\/p>\n<p>Q: Can you compare MSR approaches to congestion free updates A: different situations, inter-DC vs intra DC<\/p>\n<p>Q: Is there a concern with how long the update takes. A: Update order is arbitrary.<\/p>\n<p>Q: Why do you want to achieve high util: A: We want to be able to support more traffic. Saving money.<\/p>\n<p>&nbsp;<\/p>\n<h2>SIMPLE-fying Middlebox Policy Enforcement Using SDN<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p27.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Middlebox management is hard. \u00c2\u00a0Can SDN simplify\u00c2\u00a0middle<\/span><span style=\"line-height: 13px;\">box\u00c2\u00a0management?\u00c2\u00a0<\/span><\/li>\n<li>Middlebox functions are beyond L2\/L3 tasks.<\/li>\n<li>We want to do this without modifying middlebox or SDN hardware.<\/li>\n<li>Problem: Enforcing specific policies using SDN<\/li>\n<li>Challenges:\n<ul>\n<li>Policy composition - traditional composition may introduce loops.<\/li>\n<li>Resource constraints -&gt; need space to allocate resources in both switches and middleboxes<\/li>\n<li>Dynamic modifications -&gt; Correctness<\/li>\n<\/ul>\n<\/li>\n<li>Design:\n<ul>\n<li>Rule generator handles policy composition.<\/li>\n<li>Resources Manager - Split into online and offline stages. Offline stage assumes that some network attributes (eg topology) don't change rapidly.<\/li>\n<li>Modifications Handler - Payload similarity used to track packets as they are modified.<\/li>\n<\/ul>\n<\/li>\n<li>Evaluation\n<ul>\n<li>4-7x better load balancing. Close to optimal.<\/li>\n<li>LP solver takes 1s for 252 node topology<\/li>\n<li>95% accuracy for inferring flows.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>Questions<\/strong><\/p>\n<p>Q: Want to maintain legacy? A: Yes. We want to be backwards compatible.<\/p>\n<p>Q:Why bother with middle boxes, just use SDN. A: We think there are significant barriers to modifying middle boxes.<\/p>\n<p>Q:How do you do the tags A: We use \"spare bits\" in the IP header.<\/p>\n<p>Q: Why are middleboxes special? A: Don;t understand the question.<\/p>\n<p>Q: 95% accuracy. What happens in the 5% A: It is true. It's a problem.<\/p>\n<p>&nbsp;<\/p>\n<h1>Session 2 - Wireless<\/h1>\n<h2>Ambient Backscatter: Wireless Communication Out of Thin Air (best paper)<\/h2>\n<ul>\n<li>Want to build a device that that can interact without power.<\/li>\n<li>Idea: leverage background wireless signals to power the device.<\/li>\n<li>About 10uw available, but orders of magnitude lower than power needed to \u00c2\u00a0power an RF device.<\/li>\n<li>Idea: use background signals and reflect or absorb them.<\/li>\n<li>Challenges:\n<ul>\n<li>#1 Extracting backscattered signals<\/li>\n<li>#2 Decoding on a battery free device<\/li>\n<li>#3 Designing a distributed MAC protocol for battery free devices.<\/li>\n<\/ul>\n<\/li>\n<li>#1 Extracting - Run a low-pass filter over the signal and detect the change in average signal strength.<\/li>\n<li>#2 Decoding - Using an RC circuit you build a moving average filter.<\/li>\n<li>#3 MAC layer - Uses CSMA. Use bit transitions as a proxy for energy change.<\/li>\n<li>Can do 10Kbps at a range of about 12 inches with zero bits. Can do 100bps at a range of 3.5feet.<\/li>\n<li>Demo - Tags can be used to self identify misplaced items.<\/li>\n<\/ul>\n<p><strong>Questions:<\/strong><\/p>\n<p>Q: How far can you scale A: Right now about 2.5 feet. Expect to be able to scale to 10mbps at 10 feet.<\/p>\n<p>Q: Aerial are large. Can it be smaller. A: Yes, probably can shrink to the size of an RFID<\/p>\n<p>Q: Have you looked at the the asymmetric case? A: \u00c2\u00a0Yes, maybe like an RFID without the broadcast mechanism.<\/p>\n<p>Q: What about gigahertz. A: Power extraction is possible.<\/p>\n<p>&nbsp;<\/p>\n<h2>Dude, Where\u00e2\u20ac\u2122s My Card? RFID Positioning That Works with\u00c2\u00a0Multipath and Non-Line of Sight<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p51.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">RFID's are pretty cheap now. ABout 5c<\/span><\/li>\n<li>Reader range is about 15m.<\/li>\n<li>What if we can do location within 10-15cm. \u00c2\u00a0Can eliminate queues at shops. Can track items at home. Like \"I forgot my laptop charger\"<\/li>\n<li>Current accuracy is about 1m.<\/li>\n<li>Why not? Main challenge is multi path effects.<\/li>\n<li>PinIt - 10-15cm RFID in multi path environments.\n<ul>\n<li>Focuses on proximity to reference devices.<\/li>\n<li>Exploits multi-path -Similar peaks in the profiles of close items have similar peaks. Dissimilar peaks in the profiles of items are far from each other.<\/li>\n<\/ul>\n<\/li>\n<li>How to find the proximity from multi-path signals\n<ul>\n<li>Naive approach - Correlation. - Doesn't work.<\/li>\n<li>Borrow an idea from speech recognition. DTW (Dynamic time warping). How do I modify the the one signal to arive at the other signal.<\/li>\n<\/ul>\n<\/li>\n<li>200 RFIDs deployed in MIT library.<\/li>\n<li>Can pin the book to within 4cm of the nearest locator.<\/li>\n<\/ul>\n<h2>Dhwani: Secure Peer-to-Peer Acoustic NFC<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p63.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">NFC principle is trust by proximity. <\/span><\/li>\n<li><span style=\"line-height: 13px;\">Penetration is low. 12% in the US<\/span><\/li>\n<li><span style=\"line-height: 13px;\">NFC does not define security. Assumes that security is inherent to \u00c2\u00a0range.\u00c2\u00a0<\/span><\/li>\n<li>Dhwani\n<ul>\n<li>Uses phones speaker and microphone to do acoustic coupling.<\/li>\n<\/ul>\n<\/li>\n<li>Challenge #1 - Frequency Selectivity\n<ul>\n<li>Imperfect electromechanical conversion.<\/li>\n<li>Non-uniform frequency response.<\/li>\n<\/ul>\n<\/li>\n<li>Challenge #2 - Ringing and rise time\n<ul>\n<li>ABout 2ms rise time to detect a signal.<\/li>\n<\/ul>\n<\/li>\n<li>Challenge #3 - Ambient noise\n<ul>\n<li>Measured in a cafe.<\/li>\n<\/ul>\n<\/li>\n<li>Software define acoustic radio\n<ul>\n<li>Carrier-less design<\/li>\n<li>128 sub-carriers each 171hz<\/li>\n<li>4ms cycle prefic (challenge 2)<\/li>\n<li>operating bandiwdth 1KHz<\/li>\n<li>Communication at 4kpbs<\/li>\n<\/ul>\n<\/li>\n<li>JamSecure\n<ul>\n<li>Receiver sends a jamming signal, but can cancel out the signal (mostly)<\/li>\n<li>Key Challenge - Self Interference Cancellation<\/li>\n<li>Frequency selective comes mostly from sender receiver physical characteristics - precomputed and mixed.<\/li>\n<li>Need to compensate<\/li>\n<\/ul>\n<\/li>\n<li>Limitations\n<ul>\n<li>DOS - also eavesdropper can emit a jamming signal, but no info is lost<\/li>\n<li>Directed antenna - hard as the direction area is about 10cm<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>See Through Walls with Wi-Fi!<\/h2>\n<p>http:\/\/www.syslog.cl.cam.ac.uk\/2013\/08\/13\/liveblog-from-sigcomm13-day-1\/<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Wifi travels through walls.\u00c2\u00a0<\/span><\/li>\n<li>If there's a person behind the wall, a reflection will come back.<\/li>\n<li>But ... reflection directly from the wall is 10,000x higher than reflection behind the wall.<\/li>\n<li>Wi-Vi - Low power, eliminates refection.<\/li>\n<li>Transmit two waves that cancel each other when they reflect off static objects but cancel out when they reach dynamic objects.<\/li>\n<li style=\"text-align: left;\">Use 3 antennas - Two transmitting one receiving.<\/li>\n<li style=\"text-align: left;\">Send cancelling signals.<\/li>\n<li style=\"text-align: left;\">Using an antenna array to detect motion - however, no antnena array.<\/li>\n<li style=\"text-align: left;\">Instead - Use the idea that the object is moving to emulate an antenna array. (<strong>cool<\/strong>)<\/li>\n<li style=\"text-align: left;\">Can detect gestures with movement.<\/li>\n<li style=\"text-align: left;\">Classification algo developed to detect the number of people behind a wall. Pretty good up to about 3 people.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h1>Best of CCR 1<\/h1>\n<h3>What We Talk About When We Talk About Cloud Network Performance<\/h3>\n<p>http:\/\/www.sigcomm.org\/sites\/default\/files\/ccr\/papers\/2012\/October\/2378956-2378964.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">We want network guarantees<\/span><\/li>\n<li>\"Just give me enough bandwidth\" - Not enough. How\/where\/when do you measure it is bandwidth enough?<\/li>\n<li>We should talk about cloud performance and latency measurements.<\/li>\n<li>Customers want:\n<ul>\n<li>Predictable high bandwidth<\/li>\n<li>Predictable low latency<\/li>\n<li>Predictable low loss<\/li>\n<li>Predictable low cost<\/li>\n<li>Simple, flexible interface<\/li>\n<\/ul>\n<\/li>\n<li>Providers\n<ul>\n<li>Want happy customers<\/li>\n<li>Efficient implementation<\/li>\n<li>High utilization<\/li>\n<\/ul>\n<\/li>\n<li>High bandwidth:\n<ul>\n<li>Where do you measure bandwidth?<\/li>\n<li>The hose model - there's one big virtual switch with bandwidth guarantees\n<ul>\n<li>You'll likely over provision<\/li>\n<li>Simple abstract<\/li>\n<li>Matches real world \"basically top of rack switch\"<\/li>\n<li>Only two parameters<\/li>\n<\/ul>\n<\/li>\n<li>The pipe model - Bandwidth guarantees between pairs of VM's.\n<ul>\n<li>\u00c2\u00a0N^2 parameters to understand it. Hard for customers to understand.<\/li>\n<\/ul>\n<\/li>\n<li>Bandwidth requirements change over time.<\/li>\n<li>What are we measuring:\n<ul>\n<li>Mean bandwidth over a given period P<\/li>\n<li>Peak bandwidth<\/li>\n<li>Latency<\/li>\n<li>Tail latency (99.999%)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li><strong>Summary one size does not fit all.<\/strong><\/li>\n<\/ul>\n<\/li>\n<li>Cloud networking is a business\n<ul>\n<li>Does fairness matter? - It's one way to allocate resources, in the absence of other mechanisms it's ok.<\/li>\n<li>Map-reduce likes fairness, but not everything.<\/li>\n<\/ul>\n<\/li>\n<li>Implementation issues:\n<ul>\n<li>Hose model guarantees in an oversubscribed network<\/li>\n<li>scalable pipe-model guarantees<\/li>\n<li>Hose model gurantees + fiar work conserving.<\/li>\n<\/ul>\n<\/li>\n<li>Summary\n<ul>\n<li>Evidence suggests that we have not entirely converged, technologists need to talk to business people.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h1>Session 4: Fast and Scalable Network Design<\/h1>\n<p>&nbsp;<\/p>\n<h2>Maple: Simplifying SDN Programming\u00c2\u00a0Using Algorithmic Policies<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p87.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">SDN promises to make\u00c2\u00a0network\u00c2\u00a0management simpler with\u00c2\u00a0controller\u00c2\u00a0software.\u00c2\u00a0<\/span><\/li>\n<li>Openflow is a key building block, but also a source of complexity<\/li>\n<li>onPacketIn(p)\n<ol>\n<li>Figure out what to do with the packet<\/li>\n<li>Program the OF hardware for subsequent packets.<\/li>\n<\/ol>\n<\/li>\n<li>Programmers are motivated by performance to use wildcard rules, but it's easy to get these wrong.<\/li>\n<li>We desire the ability to automate the the generation of rules.<\/li>\n<li>Algorithmic policy -&gt; Specified in a general purpose language such as Java\/Python\/Haskell<\/li>\n<li>But, we ned to generate rules.<\/li>\n<li>Maple : New technique: Runtime tracing.<\/li>\n<li>Trace of the execution is taken as the packet moves through the rule to generate a trace tree.<\/li>\n<li>Maple then compiles the trace tree into a flow table.<\/li>\n<li>Trace tree method converts arbitrary algorithmic policies into correct forwarding entires with wildcards used properly.<\/li>\n<li>Implemented in Haskell<\/li>\n<li>To evaluate - implementing ACLs using maple.<\/li>\n<li>Evaluate using class bench of 1000 and 2000 filters.<\/li>\n<li>Maple is reasonably efficient in terms of table entries and priorities used.<\/li>\n<\/ul>\n<p>Q: Modularity is a good thing. How can they interact? A: Maple is oblivious. If it had more insight it could be better.<\/p>\n<p>Q: Hardware does not all support proprieties. How do you cope? A: Don't understand [ed: language barriers]. We assume that priorities work.<\/p>\n<p>&nbsp;<\/p>\n<h2>Forwarding Metamorphosis: Fast Programmable\u00c2\u00a0Match-Action Processing in Hardware for SDN<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p99.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Would like to be able to software upgrade your switch with software.\u00c2\u00a0<\/span><\/li>\n<li>Fixed function switches uses a collection of stages with fixed functions and algos.<\/li>\n<li>May want to be able to extend. But how?<\/li>\n<li>SDN accentuates the need for flexibility.<\/li>\n<li>What alternatives\n<ul>\n<li>100x too slow, expensive<\/li>\n<li>10x too slow, expensive<\/li>\n<li>10x too slow, expensive<\/li>\n<\/ul>\n<\/li>\n<li>How \u00c2\u00a0do I design a flexible switch chip.\n<ul>\n<li>Big chip<\/li>\n<li>High frequency<\/li>\n<li>wiring intensive<\/li>\n<li>many crossbars<\/li>\n<li>lots of TCAM<\/li>\n<li>interaction between physical design and architecture<\/li>\n<\/ul>\n<\/li>\n<li>RMT switch model.\n<ul>\n<li>parse graph - parses headers<\/li>\n<li>table graph - looks up stuff<\/li>\n<li>eg if you add a field, you add it to the parser, and then you put it in the table<\/li>\n<li>But the parse and table graph doesnt tell you how to build the switch.<\/li>\n<\/ul>\n<\/li>\n<li>For a flexible switch we need lots of CPUs in a pipeline<\/li>\n<li>But memory bandwidth is a problem. So we replicate the CPUs.<\/li>\n<li>Cost?\n<ul>\n<li>Many functions are the same. I\/O, data buffer, queuing etc.<\/li>\n<li>\u00c2\u00a0Make extra functions optional: statistics<\/li>\n<li>Memory dominates the area: RMT must use memory bit efficiently.<\/li>\n<li>Overall a 15% area increase.<\/li>\n<li>Overall a 12.4% power increase.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>Questions:<\/strong><\/p>\n<p>Q: When can I buy one. A: It's a research product, can't comment on product releases.<\/p>\n<p>Q: You're arguing for homogenous CPUS, most people are talking about heterogeneous cores. A: Very different architecture.<\/p>\n<p>Q: What about the compiler? A: We haven't produced either the chip or the compiler.<\/p>\n<p>&nbsp;<\/p>\n<h2>Compressing IP Forwarding Tables:\u00c2\u00a0Towards Entropy Bounds and Beyond<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p111.pdf<\/p>\n<ul>\n<li>Not going to talk about the paper, talking about compressed data structures instead.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Greetings from SIGCOMM 2013, Hong Kong. I&#8217;ll be live blogging as much of the event as I can, battery life permitting.<\/p>\n","protected":false},"author":34,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[6,23],"tags":[],"_links":{"self":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1253"}],"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=1253"}],"version-history":[{"count":33,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1253\/revisions"}],"predecessor-version":[{"id":1255,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1253\/revisions\/1255"}],"wp:attachment":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/media?parent=1253"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/categories?post=1253"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/tags?post=1253"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}