Day 3 10 New Architectures and Platforms XIA: Efficient Support for Evolvable Internetworking, CMU et al Future Internet Project...they've been working on this for a while...I think its quite good, but the presentation wasn't zingy enough XIA 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. The key motivator for DAGs was "nested fallbacks", but there are a lot of other benefots. Dave 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. Eval is about how we process DAGs efficiently (contradicting the naive assumption that expressiveness implies cost). Simulation and click based implementaiton of XIA over RouteViews data shows ok overhead in forwarding rates. Mark handley asked: How will XIA avoid ending up being ossified by "common case == fast path, everything else is slow and/or forbidden" mission creep? No 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:) Design and Implementation of a Consolidated Middlebox Architecture, Intel Measurements show there are now typically as many modboxen as routers in a typical net. They do useful things (performance enhancement, security, policy compliance etc). So ISPs are forced to buy more and more piecemeal mdboxen so lets virtualise, aggregate and get statmux advantage. so need a midboxen API, and a config/management system.... and then try and collapse/simplify/aggregate management policy dependencies eval shows lots of perf benefits (didn't do latency though) they do isolation and are 5x better than generic VMs He asks "how to do re-use and isolation"? - answer, use Mirage:) An Operating System for the Home, IBM Really really HomeWork like (c.f. Nottingham/Mort's project) Analysis says reasons why home automation hasnt taken off in past are i) poor extensibility ii) poor management [I agree] The authors claim problems stem from wrong abstraction(s) two main existing ones are 1. network of devices - interop protocols allows extension but makes management a nightmare 2. Appliance - monolithic allows management, but arent extensible. They proose a home OS (called, um, HomeOS) which _logically_ centralizes all devices... so should look at http://en.wikipedia.org/wiki/Andy_Stanford-Clark (event based) and AlertMe (cloud based) CHallenges - i) non expert users ii) devevelopers confronted by heterogeneity iii) new classes of devices and apps very common Management layer is where the neat use case shows up - for example, access control model is quite subtle (read the paper) basically 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"? :-) impl is datalog based rules... apps carry "manifests" which can be used for testing and access control... brave demo...worked:) see research.microsoft.com/homeos eval in 12 "real" homes - +ve worked well - extensibility was appreciated. UIs found to be "natural" -ve - diagnostics hard (esp. wireless nets) - interop fragile. Not all device features visible over net
11 Cloud Performance
Structured Comparative Analysis of Systems Logs to Diagnose Performance Problems, Purdue
Orchestrating the Deployment of Computations in the Cloud with Conductor, MPI
12 Transport - Transports of Delight
me chairing session, so not liveblogging:(
Fitting Square Pegs Through Round Pipes: Unordered Delivery Wire-Compatible with TCP and TLS, Yale
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:)
uTCP - 2 new socket options -
SO-UNORDERED_RCV...kernel delivers packets immedately (but with sequence numbers -ISN)
SO_UNORDERED_SND - prioritises write()s
Then uCOBS builds a message ordered delivery service on uTCP. (COBS is zero stuffing max overhead from stuart cheshire in sigcomm in the 90s)
uTLS does same as uCOBS but without touching data. < 1000 lines of code...graphs (see paper) show it works.
send priority stuff really is neat.
How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP, Trilogy
Note sybill attack by authors from UCL and UCL
This is the community award winning team battling their multipath way to success.
Motivation - multihoming mobie devices, data center multipath, and CDN multihomed.
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...
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
fix is to use seperate seq space on each subpath...
has other advantages too(see paper)
v. nice slides for clarity of explanation of protocol tricks...implemenation tricks - talk about impact of receive buffer size on mptcp on 3G+WiFi..
Demo ... ... ...
Q&A - would data center MPTCP be different?
& why do mobile multipath?
1. dont have to change apps and 2. subflow seqno is really useful for fast detection of holes...so...
3. what about deadlock avoidance by reserving some data in payload...(jena)
yes, could, but midbox might still mess with it..
4. b ford asked about fall back to TCP-standard if something changes in net...
what to do with misbehaving subflow...two cases...
see paper & spec...
The TCP Outcast Problem: Exposing Unfairness in Data Center Networks, Purdue
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.
Key problem is that TCP has RTT fairness problems - known - how bad is this in data center?
Answer - can be!
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)
Interestingly, synchronisation between flows is not necessary for the RTT unfairness...
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?)
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
Solution:- look at RED, ECN, SFQ etc etc - in the end, tweak routing so all flows see nearly same pathlen.