{"id":1296,"date":"2013-08-15T01:10:47","date_gmt":"2013-08-15T01:10:47","guid":{"rendered":"http:\/\/www.syslog.cl.cam.ac.uk\/?p=1296"},"modified":"2013-08-15T10:10:42","modified_gmt":"2013-08-15T10:10:42","slug":"liveblog-from-sigcomm13-day-3","status":"publish","type":"post","link":"https:\/\/www.syslog.cl.cam.ac.uk\/2013\/08\/15\/liveblog-from-sigcomm13-day-3\/","title":{"rendered":"Liveblog from SIGCOMM13 \u00e2\u20ac\u201c Day 3"},"content":{"rendered":"<p>I'm back again, liveblogging from SIGCOMM13. Yesterdays blog was in fact not clyoned out of existence, but a very successful poster session kept me busy until after busses had started leaving for banquet. As a result of the successful poster session I've been here since 7am....<\/p>\n<p><!--more--><\/p>\n<p><img decoding=\"async\" title=\"More...\" alt=\"\" src=\"http:\/\/www.syslog.cl.cam.ac.uk\/wp-includes\/js\/tinymce\/plugins\/wordpress\/img\/trans.gif\" \/><\/p>\n<h1>Privacy<\/h1>\n<h2>Mosaic: Quantifying Privacy Leakage in Mobile Networks<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p279.pdf<\/p>\n<ul>\n<li>How much information can be obtained by obtaining packet traces for a given user.<\/li>\n<li>This work focuses on mobile because there is more private information and IPs change more frequently.<\/li>\n<li>Lots of services use key\/value pairs with user IDs.<\/li>\n<li>We use OSN IDs as anchors, but their coverage of the sessions is too small about 2%<\/li>\n<li>Traffic attribution markers. Group sessions into blocks using IPs. \u00c2\u00a0We know that OSN IDs will be shared.<\/li>\n<li>Using the same traffic markers and OSN IDs we can track users.<\/li>\n<li>What if there are no traffic markers?<\/li>\n<li>Users can be classified by their favourite DNS searches.<\/li>\n<li>Traffic attribution evaluation<\/li>\n<li>Compare to RADIUS sessions (ground truth)<\/li>\n<li>Accuracy is quite good.<\/li>\n<li>Mosaic of a real user:\n<ul>\n<li>12 classes eg location, device, traffic, e-commerce etc.<\/li>\n<\/ul>\n<\/li>\n<li>Leakage:\n<ul>\n<li>OSN profiles provide static user information (education, interests)<\/li>\n<li>Network analyse give real-time activities\/locations.<\/li>\n<li>Both complete\/corroborate each other<\/li>\n<\/ul>\n<\/li>\n<li>How to prevent this?\n<ul>\n<li>Traffic markers should be limited\/encrypted<\/li>\n<li>Third party services should be strongly regulated<\/li>\n<li>OSN public profiles should be carefully obfuscated.<\/li>\n<li>HTTPS isn't really helping this as traffic markers are not encrypted.<\/li>\n<li><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h2>Expressive Privacy Control with Pseudonyms<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p291.pdf<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Tracking is pervasive.\u00c2\u00a0<\/span><\/li>\n<li>Cons:\n<ul>\n<li>Lack of privacy<\/li>\n<\/ul>\n<\/li>\n<li>Pros\n<ul>\n<li>Personalisation<\/li>\n<li>Revenue<\/li>\n<li>Security<\/li>\n<\/ul>\n<\/li>\n<li>Goal is to give users control over how they are tracked<\/li>\n<li>We do not argue for removing the ability to be tracked, just to add more control<\/li>\n<li>Current defences eg:\n<ul>\n<li>Cookie blocking<\/li>\n<li>Do not track etc<\/li>\n<li>Proxies<\/li>\n<li>Tor<\/li>\n<\/ul>\n<\/li>\n<li>Problem: These mechanisms are course grained.<\/li>\n<li>We use pseudonyms as a way to obfuscate users privacy demands.<\/li>\n<li>Many IP address for an end-host.<\/li>\n<li>We use IPv6 - even a small network has more addresses than the entire IPv4 block.<\/li>\n<li>IPv6 uses top half of address for WAN, lower half for LAN ==&gt; We can do whatever we want with the LAN address<\/li>\n<li>Split LAN address into subnet, host and pseudonym, this is then encrypted to form an encrypted ID.<\/li>\n<li>Web browsers extended use JS to request pseudonym IDs.<\/li>\n<li>Policies are quite expressive from 1 pseudonym to every request with a new one.<\/li>\n<li>Per request needs less than 10 bits.<\/li>\n<\/ul>\n<p><strong>Questions:<\/strong><\/p>\n<p>Q: Breaks some functionality, how would it work if people respected do not track; A: It would be ideal, but no guarantee, so this is more explicit for users to control.<\/p>\n<p>Q: [ can't hear] PLEASE SPEAK UP!!!! A:<\/p>\n<p>&nbsp;<\/p>\n<h2>Towards Ef\u00ef\u00ac\u0081cient Traf\u00ef\u00ac\u0081c-analysis Resistant\u00c2\u00a0Anonymity Networks<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p303.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">How to defend ourselves from mass\u00c2\u00a0surveillance.\u00c2\u00a0<\/span><\/li>\n<li>The problem of IP anonymity:\n<ul>\n<li>Man in the middle can inspect IPs to know where data goes.<\/li>\n<li>Proxies can be be required to take logs and reveal users<\/li>\n<li>Tor, decentralised - Onion routing. Bitwise deniability does not protect against traffic analysis.<\/li>\n<\/ul>\n<\/li>\n<li>Goal - K-anonymity (indistinguishable amongst k clients)<\/li>\n<li>Threat model:\n<ul>\n<li>Global passive attacks, can snoop all traffic.<\/li>\n<li>Active attack - Can alter traffic eg add watermarks.<\/li>\n<\/ul>\n<\/li>\n<li>Strawman\n<ul>\n<li>Pad flows \u00c2\u00a0- Defats analysis, but has too high overhead.<\/li>\n<\/ul>\n<\/li>\n<li>Use a variable, uniform rate at the to pad at the core.<\/li>\n<li>Use ksets to pad at the edge.<\/li>\n<li>Evaluation:\n<ul>\n<li>Trace driver simulations. 100,000 bit-torrent users.<\/li>\n<li>Models\n<ul>\n<li>constant rate onion V2<\/li>\n<li>Boardacst: P5, DC-Nets<\/li>\n<li>P2P: Tarzan<\/li>\n<li>Aqua<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Overhead?\n<ul>\n<li>In the median case, Aqua uses 30% overhead vs 80% for other models.<\/li>\n<li>Throttling is low.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>Question:<\/strong><\/p>\n<p>Q: Why use bittorrent over Tor? A: Tor is slow because of an incentives mismatched.<\/p>\n<p>Q: You assume that messages are large: A:[Didn't understand]<\/p>\n<p>Q: Expect aqua to have a lot of providers, how does it compare to DCent A: Uses broadcast so bandwidth \u00c2\u00a0usage is much higher.<\/p>\n<p>&nbsp;<\/p>\n<h2>SplitX: High-Performance Private Analytics<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p315.pdf<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Data analytics is important and useful.<\/span><\/li>\n<li><span style=\"line-height: 13px;\">Data exposure is becoming a concern. <\/span><\/li>\n<li><span style=\"line-height: 13px;\">Fast analytics of user\u00c2\u00a0controlled\u00c2\u00a0and distributed data. <\/span><\/li>\n<li><span style=\"line-height: 13px;\">Previous work - Servers aggregate data wihout seeing individual data.\u00c2\u00a0<\/span><\/li>\n<li>Previous systems\n<ul>\n<li>scale poorly, because they require public key operations<\/li>\n<li>Malicious users can poison the results.<\/li>\n<\/ul>\n<\/li>\n<li>Components and assumptions\n<ul>\n<li>Analysis (potentially malicious)<\/li>\n<li>Clients (have data, potentially malicious)<\/li>\n<li>Servers, are honest but curious. Will follow the protocol, but can exploit extra information if found.<\/li>\n<\/ul>\n<\/li>\n<li>High to achieve high performance?\n<ul>\n<li>Don't use public key<\/li>\n<li>split messages and use xor<\/li>\n<\/ul>\n<\/li>\n<li>Each message is sent to a separate mixer.<\/li>\n<li>Clients cannot arbitrarily alter data.<\/li>\n<li>We bucket results. ! answer per bucket.<\/li>\n<li>Pub\/Sub for queries.<\/li>\n<li>System is 2-3 orders of magnitude than current systems.<\/li>\n<li>Implementation is a chome plugin + jetty.<\/li>\n<li>400 clients. More details in the paper.<\/li>\n<\/ul>\n<p><strong>Questions:<\/strong><\/p>\n<p><b><br \/>\n<\/b>Q: What is the long term business model? A: \u00c2\u00a0data analytics is important but so is privacy. So maybe the incentives are well aligned.<\/p>\n<p>Q: How much performance burden does each split add? A: Xor is very efficient. So it's doesn't cost that much.<\/p>\n<p>&nbsp;<\/p>\n<h1>Applications and Resource Allocation<\/h1>\n<h2>Participatory Networking<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p327.pdf<\/p>\n<ul>\n<li>Applications have preferences for the network, but we need to share access to SDN style resources.<\/li>\n<li>We provide an end user API\/syscalls<\/li>\n<\/ul>\n<ol>\n<ol>\n<li>Requests<\/li>\n<li>Hints<\/li>\n<li>Queries<\/li>\n<\/ol>\n<\/ol>\n<ul>\n<li>Challenges:\n<ul>\n<li>How to resolve conflicting requests? [ed: wrong]\n<ul>\n<li>Expose shares - Flow groups, principals, privileges.<\/li>\n<li>Sub shares - Kind of like capabilities. can be delegated<\/li>\n<li>Oversubscription is allowed, but policy is enforced dynamically.<\/li>\n<\/ul>\n<\/li>\n<li>How to resolve conflicts\n<ul>\n<li>Policy trees. Hierarchal flow tables. [HFT]<\/li>\n<li>Uses three combination operators to resolve conflict.<\/li>\n<li>Requires associativity and default \"don't care\"<\/li>\n<li>+D In node<\/li>\n<li>+S sibiling<\/li>\n<li>+P Parent-sibiling<\/li>\n<li>HFT doesn't care so long as requirements are met.<\/li>\n<li>Compiler linearises the tree into openflow rules.\n<ol>\n<li>Generate the entire network flow table<\/li>\n<li>Break the table up using network information to distribute it.<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<\/li>\n<li>Adapted to 4 applications, Haddoop, Zookper, [2 others]<\/li>\n<li>Hadoop case:\n<ul>\n<li>3 sort jobs,<\/li>\n<li>2 priorities.<\/li>\n<\/ul>\n<\/li>\n<li>PANE allows users to talk back to the control plane<\/li>\n<li>So far bandwidth, access control and priority explored.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><strong>Question<\/strong><\/p>\n<p>Q: Why do these applications need to be able to control the network? A: We don't trust the VMs?<\/p>\n<p>Q: Isn't it bad bad to mix data\/control planes. Security? A: We have a restricted API.<\/p>\n<p>Q: Other resources? A: Latency? Latency is hard. Maybe we consider switch hops as a proxy for latency.<\/p>\n<p>Q: Scaling? A: Relates to the number of rules.<\/p>\n<p>Q: [Can't hear] SPEAK UP!!! How would we integrate something like Sinbad? A: Good question, extensions needed.<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<h2>Developing a Predictive Model of\u00c2\u00a0Quality of Experience for Internet Video<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p339.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Quality\u00c2\u00a0of experience is tied into the value chain of content providers.\u00c2\u00a0<\/span><\/li>\n<li>If users are satisfied then they they will watch more.<\/li>\n<li>The relationship between quality and and revenue is not well understood.<\/li>\n<li>QoE both subjective and objective. Validated by comparison to subjective.<\/li>\n<li>Subjective is not representative of \"in-the-wild\" settings.<\/li>\n<li>Objective does not capture buffering, switching etc.<\/li>\n<li>Subjective replaced with Engagement -\n<ul>\n<li>How many videos does the user watch as a fraction<\/li>\n<\/ul>\n<\/li>\n<li>Objective replaced with \"qaulity\" measures.\n<ul>\n<li>Join time<\/li>\n<li>Buffering<\/li>\n<li>Bit-rate of the session<\/li>\n<\/ul>\n<\/li>\n<li>Which one to use? We need a model!<\/li>\n<li>Challenges:\n<ul>\n<li>Relationship between metics and engagement.\n<ul>\n<li>Non monotonic relationship between bitrate and engagement.<\/li>\n<\/ul>\n<\/li>\n<li>Quality metrics are not independent.<\/li>\n<li>Confounding factors\n<ul>\n<li>Two types of video - live, and VOD - different viewing patterns.\n<ul>\n<li>live people don't watch to completion whereas VOD this is mostly the case.<\/li>\n<\/ul>\n<\/li>\n<li>Quality metrics - different buffers sizes for live and VOD<\/li>\n<li>Quality - users on wireless more willing to wait ==&gt; higher engagement<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li>Cast this as a machine learning problem.<\/li>\n<li>Choice of ML is important. 40% only.<\/li>\n<li>But can get better if we can add extra confounding factor information.<\/li>\n<li>Final model is a collection of decision trees with 70% accuracy.<\/li>\n<li>Evaluated model against baseline, optimised and QoE =&gt; 100% than baseline, 20% better engagement.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p><strong>Questions<\/strong><\/p>\n<p>Q: Your evaluation has no error bars. How significant is it? A: We did multiple runs.<\/p>\n<p>Q: But there are no error bars. A: um.....<\/p>\n<p>&nbsp;<\/p>\n<h2>ElasticSwitch: Practical Work-Conserving Bandwidth\u00c2\u00a0Guarantees for Cloud Computing<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p351.pdf<\/p>\n<ul>\n<li>\u00c2\u00a0Desire work conserving bandwidth guarantees\n<ul>\n<li>Use the hose model.<\/li>\n<\/ul>\n<\/li>\n<li>Desire work conserving allocation. Tenants can use spare capacity.<\/li>\n<li>\u00c2\u00a0Desire the network to be practical.\n<ul>\n<li>Commodity devices.<\/li>\n<li>Topology independent<\/li>\n<li>Scaleable.<\/li>\n<\/ul>\n<\/li>\n<li>Elastic switch runs in a hypervisor<\/li>\n<li>Two components: Guaranteed partitioning, rate limiting<\/li>\n<\/ul>\n<h1>Data Center Networks 2<\/h1>\n<h2>zUpdate: Updating Data Center Networks with Zero Loss<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p411.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Network updates are hard. Planning stages are hard. Performance hotspots and it's a very laborious process.\u00c2\u00a0<\/span><\/li>\n<li>Applications want low latency updates with no packet drops.<\/li>\n<li>Congestion free updates are hard, and require a multi-step plan.<\/li>\n<li>Example, a CLOS network with ECMP.<\/li>\n<li>Problem how to transition between two congestion free network topologies?<\/li>\n<li>Can't update both switches at the same time.<\/li>\n<li>So we need to introduce an intermediate stages that are also congestion free.<\/li>\n<li>zUpdate takes a traffic distribution and calculates a congestion free plan.<\/li>\n<li>uses a two phase commit.<\/li>\n<li>Is the computation time for the plan too long? Do we have enough rules in the switch?<\/li>\n<li>We only implement tuning for critical flows.<\/li>\n<li>Flows on bottleneck links are the critical flows.<\/li>\n<li>Testbed - 22, 10G switches, open flow 1.0<\/li>\n<li>\"large\" simulation with \"production\" traces.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>\u00c2\u00a0Got Loss? Get zOVN!<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p423.pdf<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Two types of networks networks \u00c2\u00a0physical networks, and application level \u00c2\u00a0virtual networks.\u00c2\u00a0<\/span><\/li>\n<li>Why don't we use ethernet pause frames?<\/li>\n<li>Contribution: Loss identification and characterisation, Introduce a zero loss network with flow control.<\/li>\n<li>3 virtual machines on a single physical machine with a vswitch.<\/li>\n<li>Two merging to one. \u00c2\u00a0Packets lots in the vswitch and end host. \u00c2\u00a0Not an artefact of just one VM or vswitch impl.<\/li>\n<li>Architecture:\n<ul>\n<li>Extended the socket interface with a lossless option.<\/li>\n<li>Modified the device driver the the ability to pause and resume the queue.<\/li>\n<li>Inside the vswitch. If the transmission port is full, then issue pause to the receiver queue.<\/li>\n<\/ul>\n<\/li>\n<li>Eval: partition aggregate\n<ul>\n<li>4 rack servers with 16 physical cores + HyperThreading<\/li>\n<li>Intel 10G adapters.<\/li>\n<li>1G control network.<\/li>\n<li>Virtual network flow control improves mean flow completion time.<\/li>\n<li>Simulation confirms findings from prototype.<\/li>\n<li>For optimal performance use both physical and virtual flow control.<\/li>\n<\/ul>\n<\/li>\n<li>Reviewers questions:\n<ul>\n<li>If we have faster networks or CPUs does this solve the problem? No.<\/li>\n<li><strong>Lossless links - Order of magnitude better completion time in reduction in Partition\/Aggregate jobs.<\/strong><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h2>pFabric: Minimal Near-Optimal Datacenter Transport<\/h2>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p435.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>DC \u00c2\u00a0look more like interconnect inside a switch.<\/li>\n<li>In response to a single query 100s of services are started<\/li>\n<li>What really matters is getting messages through network. Message latency matters.<\/li>\n<li>Need to schedule flows so that large flow so that they get high throughput<\/li>\n<li>Need to schedule short flows to to get short delays<\/li>\n<li>Existing work: Uses rate cnntorl HUL, DCTCP, D2TCP, D3, PDQ<\/li>\n<li>The problem is it's constrained, doesn't take into account the the size of the flows.<\/li>\n<li>Other work calculates the rate of the flow and assigns it to the flows. But switches need to cooperate.<\/li>\n<li>Prior work vastly improved performance, but it's still complex.<\/li>\n<li>PFbric in one slide.\n<ul>\n<li>Every flow has a single prioority number, prio= remaining flow size.<\/li>\n<li>Small buffers.<\/li>\n<li>Send highest priority, drop low priority<\/li>\n<li>host just send aggressively.<\/li>\n<\/ul>\n<\/li>\n<li>DC fabric is basically just a big switch.<\/li>\n<li>Need to decide which packets will get through.<\/li>\n<li><strong>Need to schedule flows over a giant switch<\/strong><\/li>\n<li>Always subject ingress\/egress constraints.<\/li>\n<li>Ideal flow scheduling is NP-Hard<\/li>\n<li>Simple greedy algo is within factor of 2 of ideal.<\/li>\n<li>Can't implement it. Requires a central scheduler that has global knowledge.<\/li>\n<li>Key insight -\n<ul>\n<li>Decouple flow scheduling from rate control.<\/li>\n<li>Implement flow scheduling via local mechanisms<\/li>\n<li>End hosts do flow control.<\/li>\n<\/ul>\n<\/li>\n<li>Priority scheduling, whenever you have a packet, send it first.<\/li>\n<li>If the buffer is full, always drop the lowest priority.<\/li>\n<li>Buffers in pFabric is very small. Never need more than 2x BDP per port.\n<ul>\n<li>10-30x smaller than a regular switch.<\/li>\n<\/ul>\n<\/li>\n<li>Pirority mechanisms need to find the min\/max of~ 600 numbers<\/li>\n<li>Binary tree takes about 10ns, budget is about 51ns.<\/li>\n<li>With a priority shecuudling\/dropping mechanism, queue build up doesn't matter.<\/li>\n<li>Only task for rate control, is to make sure that elephant flows don't have congestion collapse.<\/li>\n<li>Need minimal rate control to make sure that loss inside of the spine doesn't waste bandwidth.<\/li>\n<li>Implement a minimal version of TCP\n<ul>\n<li>State at line rate.<\/li>\n<li>No retransmission timeout estimation<\/li>\n<li>Reduce window size upon packet loss<\/li>\n<\/ul>\n<\/li>\n<li>\u00c2\u00a0Key invariant for ideal scheduling: If at any point in time, the highest priority packet is at the switch, \u00c2\u00a0should be avialble.<\/li>\n<li>Eval: Ns2 simulation.\n<ul>\n<li>144 port leaf-spine network.<\/li>\n<li>Parameters from other empirical work.<\/li>\n<\/ul>\n<\/li>\n<li>pFabric is with 20% of the ideal. ==&gt; and the ideal is REALLY ideal.<\/li>\n<li>at the average and at the 99% almost no jitter.<\/li>\n<li>pFabric, simple yet near optimal.<\/li>\n<li>Needs new switches and minor host changes.<\/li>\n<li>How much can you get with existing switches?<\/li>\n<\/ul>\n<p><strong>Question:<\/strong><\/p>\n<p>Q: Doesn't consider topology. How sensitive are the results to packet spray. A: Near optimal.<\/p>\n<p>Q: How do you define the priority? Esp for streaming. A: In a lot of applications you know the size. Some applications you don't. Need to to separate pfabric into a class of it's own.<\/p>\n<p>Q: \u00c2\u00a0You priority mechanisms mean that you get very different performance at the beginning and the end. \u00c2\u00a0A: Yes that's hard.<\/p>\n<p>Q: Can you do this hybrid, do you need new hardware A: Run something like this in \u00c2\u00a0each slice.<\/p>\n<p>Q: With a large frames, you wont be able to take more than 2 priorities at a time. A: Our eval, only 1500, probably need more slack for jumbo frames. But not much.<\/p>\n<p>Q: Do you care about fairness. A: no? Can make it more fair. Fairness is something we can get off.<\/p>\n<p>Q: Do you deal with reordering A: This is the simple version.<\/p>\n<p>&nbsp;<\/p>\n<h1>Integrating Microsecond Circuit Switching\u00c2\u00a0into the Data Center<\/h1>\n<p>http:\/\/conferences.sigcomm.org\/sigcomm\/2013\/papers\/sigcomm\/p447.pdf<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\">Datacenter's\u00c2\u00a0rely on scale.\u00c2\u00a0<\/span><\/li>\n<li>Underlying network must scale as well.<\/li>\n<li>Providing bandwidth involves a lot of fibber optics.<\/li>\n<li>Core network is a big source of cost, lots of transceivers.<\/li>\n<li>Probably need about 5 core transceivers per host.<\/li>\n<li>Effective switch radix is probably going up with speed and redundancy<\/li>\n<li>A few ideas looking replacing circuit switches.<\/li>\n<li>Fundamental connection between speed of circuit switches and how quickly the traffic can change.<\/li>\n<li>Need faster circuit switching.<\/li>\n<li>Morida - Circuit switching to the core.<\/li>\n<li>Contribution:\n<ul>\n<li>100us vs 100ms<\/li>\n<li>25us vs 25ms<\/li>\n<\/ul>\n<\/li>\n<li>Traffic matrix. Need to connect input to outputs. While the circuit switch is changing can't do anything. \"Night time\", while it's running \"day-time\"<\/li>\n<li>Pipeline observe, compute, reconfigure.<\/li>\n<li>Assuming we can make configuration and computation fast.<\/li>\n<li>Goal to use a collection of traffic matrixes flows.<\/li>\n<li>Use a set of permutation matrixes that compute to the final traffic matrixes.<\/li>\n<li>Fast OCS requires a fast control plane.<\/li>\n<li>Traffic matrix scheduling - Decompose it into a future schedule.<\/li>\n<li>Prototype:<\/li>\n<li>Previous tech uses \u00c2\u00a03D mems technology. Quite high port counts, but slow ~25ms<\/li>\n<li>\u00c2\u00a0We use 2d mems, mirrors are either on or off. \u00c2\u00a0Fast 2us, \u00c2\u00a0low port count 2-8 ports.<\/li>\n<li>Key challenge is how to build a scalable network.<\/li>\n<li>Build a physical ring, with a different wavelength for each port. Each port connects to a TOR switch.<\/li>\n<li>Need to modify the TOR: 1 queue per destination, DMA schedule and up\/down events.<\/li>\n<li>We didn't have a TOR, so we used linux hosts with a kernel module. Also needed and out of band control plane.<\/li>\n<li>Eval.<\/li>\n<li>How fast can we run this prototype. Lots of layers that we need to configure. Mean time of about 11us.<\/li>\n<li>Needed a guard time to get an idea for our circuit lengths. About 20ms.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h1>Closing Remarks<\/h1>\n<ul>\n<li>Student Research Competition (SRC):\n<ul>\n<li>1'st round Poster\/Demo to a SIG conference (SIGCOMM)<\/li>\n<li>2'nd round presentation (this morning at 7:30)<\/li>\n<li>6 winners advance to grand final. Me!<\/li>\n<\/ul>\n<\/li>\n<li>Keshav\n<ul>\n<li>Nothing happens on it's own, every thing happens because people make it happen.<\/li>\n<li>100,000's hours put in to make this happen.<\/li>\n<li>Remarkable show. Look forward to seeing everyone in Chicago!<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>I&#8217;m back again, liveblogging from SIGCOMM13. Yesterdays blog was in fact not clyoned out of existence, but a very successful poster session kept me busy until after busses had started leaving for banquet. As a result of the successful poster session I&#8217;ve been here since 7am&#8230;.<\/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":[79,86],"_links":{"self":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1296"}],"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=1296"}],"version-history":[{"count":16,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1296\/revisions"}],"predecessor-version":[{"id":1298,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1296\/revisions\/1298"}],"wp:attachment":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/media?parent=1296"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/categories?post=1296"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/tags?post=1296"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}