{"id":900,"date":"2012-04-26T20:46:45","date_gmt":"2012-04-26T20:46:45","guid":{"rendered":"http:\/\/www.syslog.cl.cam.ac.uk\/?p=900"},"modified":"2012-04-27T21:49:17","modified_gmt":"2012-04-27T21:49:17","slug":"nsdi-2012-day-3","status":"publish","type":"post","link":"https:\/\/www.syslog.cl.cam.ac.uk\/2012\/04\/26\/nsdi-2012-day-3\/","title":{"rendered":"NSDI 2012 Day 3"},"content":{"rendered":"

10 New Architectures and Platforms\"jail<\/a><\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

<\/p>\n

Day 3\r\n\r\n10 New Architectures and Platforms\r\n\r\nXIA: Efficient Support for Evolvable Internetworking, CMU et al\r\n\r\nFuture Internet Project...they've been working on this for a while...I think its quite good,\r\nbut the presentation wasn't zingy enough\r\n\r\nXIA is a meta-internet protocol- actually it looks somewhat plutarch-ish (unsurprisingly). Ithink the main contribution is the DAG based addressing - this is sweet and they've done some good thinking about how to encoide a DAG efficiently.\r\nThe key motivator for DAGs was \"nested fallbacks\", but there are a lot of other benefots.\r\n\r\nDave Oran (cisco) points out the protocol still has source addresses. N.b. DAG addresses are \"loose\" in the sense there are multiple choices in routes (and non-unique return paths)  - this maps well to multipath, and is pretty nice for CCNx too.\r\n\r\nEval is about how we process DAGs efficiently (contradicting the naive assumption that expressiveness implies cost).\r\nSimulation and click based implementaiton of XIA over RouteViews data shows ok overhead in forwarding rates.\r\n\r\nMark handley asked: How will XIA avoid ending up being ossified by\r\n\"common case == fast path, everything else is slow and\/or forbidden\" mission creep?\r\n\r\nNo real answer - just hope - also XIAs three use cases for principles are pretty broad (compared with IP addresses) so maybe that's enough for another 30 years:)\r\n\r\nDesign and Implementation of a Consolidated Middlebox Architecture, Intel\r\n\r\nMeasurements show there are now typically as many modboxen as routers in a typical net.\r\nThey do useful things (performance enhancement, security, policy compliance etc).\r\nSo ISPs are forced to buy more and more piecemeal mdboxen\r\nso lets virtualise, aggregate and get statmux advantage.\r\nso need a midboxen API, and a config\/management system....\r\nand then try and collapse\/simplify\/aggregate management policy dependencies\r\n\r\neval shows lots of perf benefits (didn't do latency though)\r\nthey do isolation and are 5x better than generic VMs\r\n\r\nHe asks \"how to do re-use and isolation\"? - answer, use Mirage:)\r\n\r\nAn Operating System for the Home, IBM\r\n\r\nReally really HomeWork like (c.f. Nottingham\/Mort's project)\r\nAnalysis says reasons why home automation hasnt taken off in past are\r\ni) poor extensibility\r\nii) poor management\r\n[I agree]\r\n\r\nThe authors claim problems stem from wrong abstraction(s)\r\ntwo main existing ones are\r\n1. network of devices - interop protocols\r\n\tallows extension but makes management a nightmare\r\n2. Appliance - monolithic\r\n\tallows management, but arent extensible.\r\n\r\nThey proose a home OS (called, um, HomeOS)\r\nwhich _logically_ centralizes all devices...\r\n\r\nso should look at\r\nhttp:\/\/en.wikipedia.org\/wiki\/Andy_Stanford-Clark \t(event based)\r\nand\r\nAlertMe (cloud based)\r\n\r\nCHallenges -\r\ni) non expert users\r\nii) devevelopers confronted by heterogeneity\r\niii) new classes of devices and apps very common\r\n\r\nManagement layer is where the neat use case shows up - for example, access control model is quite subtle (read the paper)\r\n\r\nbasically apps are principles. time based roles also exist. to some extent this might be a bit like ChromeOS (and Robert Watson's ideas) - i.e. apps need resources, don't get to see other resources  (can you say \"capability\"? :-)\r\n\r\nimpl is datalog based rules...\r\n\r\napps carry \"manifests\" which can be used for testing and access control...\r\n\r\nbrave demo...worked:)\r\nsee\r\nresearch.microsoft.com\/homeos\r\n\r\neval in 12 \"real\" homes -\r\n+ve worked well - extensibility was appreciated. UIs found to be \"natural\"\r\n\r\n-ve - diagnostics hard (esp. wireless nets) - interop fragile. Not all device features visible over net<\/pre>\n

 <\/p>\n

11 Cloud Performance
\nStructured Comparative Analysis of Systems Logs to Diagnose Performance Problems, Purdue<\/p>\n

Orchestrating the Deployment of Computations in the Cloud with Conductor, MPI<\/p>\n

12 Transport - Transports of Delight<\/p>\n

me chairing session, so not liveblogging:(<\/p>\n

Fitting Square Pegs Through Round Pipes: Unordered Delivery Wire-Compatible with TCP and TLS, Yale<\/p>\n

This is about micro-TCP, which is sort of analogous to a TCPlet:) This particularlet TCPlet does out of order delivery. Very good talk - great *amusing) scene setting with 5 stages of grief from middleboxen - then introduce minion suite, which basically uses legacy protocols as building blocks for new protocols (like DCCP, STCP, XCP, BXXP etc) - minion has iCOBS, uTLS (unordered delivery on TCP and on SSL).....sweet suite:)<\/p>\n

uTCP - 2 new socket options -<\/p>\n

SO-UNORDERED_RCV...kernel delivers packets immedately (but with sequence numbers -ISN)<\/p>\n

SO_UNORDERED_SND - prioritises write()s<\/p>\n

Then uCOBS builds a message ordered delivery service on uTCP. (COBS is zero stuffing max overhead from stuart cheshire in sigcomm in the 90s)<\/p>\n

uTLS does same as uCOBS but without touching data. < 1000 lines of code...graphs (see paper) show it works.<\/p>\n

send priority stuff really is neat.<\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP, Trilogy<\/p>\n

 <\/p>\n

Note sybill attack by authors from UCL<\/em> and UCL<\/strong><\/p>\n


\n<\/strong><\/p>\n

This is the community award winning team battling their multipath way to success.<\/p>\n

Motivation - multihoming mobie devices, data center multipath, and CDN multihomed.<\/p>\n

How hard can it be - lots of detailed problems ....e.g. 6% of access nets remove unknown options, 14% on port 80!! argh! so can get asymetric state about mptcp capability... fix by inferring from data in packets...<\/p>\n

segment\/path assignment - pb. is midbox that screws with segment acks...1\/3 of access nets drop acks for \"unseen\" data....(or even kill the cx<\/p>\n

fix is to use seperate seq space on each subpath...<\/p>\n

has other advantages too(see paper)<\/p>\n

v. nice slides for clarity of explanation of protocol tricks...implemenation tricks - talk about impact of receive buffer size on mptcp on 3G+WiFi..<\/p>\n

Demo ... ... ...<\/p>\n

code at<\/p>\n

http:\/\/mptcp.info.ucl.ac.be<\/p>\n

Q&A - would data center MPTCP be different?<\/p>\n

& why do mobile multipath?<\/p>\n

1. dont have to change apps and 2. subflow seqno is really useful for fast detection of holes...so...<\/p>\n

3. what about deadlock avoidance by reserving some data in payload...(jena)<\/p>\n

yes, could, but midbox might still mess with it..<\/p>\n

4. b ford asked about fall back to TCP-standard if something changes in net...<\/p>\n

what to do with misbehaving subflow...two cases...<\/p>\n

see paper & spec...<\/p>\n

 <\/p>\n

The TCP Outcast Problem: Exposing Unfairness in Data Center Networks, Purdue<\/p>\n

 <\/p>\n

The outcast here doesn't refer to an exile, more evicted packets due to confluence of flows. This presents a rather fine solution to this effectively mis-scheduling problem.<\/p>\n

Key problem is that TCP has RTT fairness problems - known - how bad is this in data center?<\/p>\n

Answer - can be!<\/p>\n

Did initial experiment to establish the problem does happen (TCP Cubic in a many-to-one - on fattree topology (i.e. reduce) - show (nice graphic in paper)<\/p>\n

Interestingly, synchronisation between flows is not necessary for the RTT unfairness...<\/p>\n

Q: does this happen in interconnect in some multicores with TCP based IPC? (I'm guessing RTT differences are too small, but who knows? Might be larger on some baroque topologies?)<\/p>\n

 <\/p>\n

Q also - the hop dependency reminds me of the problem with multihop WiFi nets where capacity falls, but in this case, it goes the other way - actually, port blackout is like switch contention pb in knockout switches<\/p>\n

 <\/p>\n

Solution:- look at RED, ECN, SFQ etc etc - in the end, tweak routing so all flows see nearly same pathlen.<\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

10 New Architectures and Platforms      <\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[6,28,32,4,33,23,7,31,29,12],"tags":[74],"_links":{"self":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/900"}],"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\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/comments?post=900"}],"version-history":[{"count":46,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/900\/revisions"}],"predecessor-version":[{"id":974,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/900\/revisions\/974"}],"wp:attachment":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/media?parent=900"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/categories?post=900"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/tags?post=900"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}