As far as I'm concerned, starting technical sessions before 9AM should be made illegal, but hey, at least we have the best paper presented in the first session! Today we have sessions about mobile, weather (in the clouds), routing and phones.<\/p>\n
<\/p>\n
<\/b>A Fistful of Bitcoins: Characterizing Payments Among Men with No Names\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko\u00c2\u00a0(UC San Diego)<\/i>, D. McCoy\u00c2\u00a0(George Mason University)<\/i>, G. Voelker and S. Savage\u00c2\u00a0(UC San Diego)<\/i><\/p>\n De-anonymizing flows of bitcoins (rather than mappings between pseudonyms and individuals).<\/p>\n Each transaction must reference a previous transaction (can only be referenced once) - will exploit that for mapping. Importantly, each received transaction should be spent all at once (although there is a 'change address' mechanism to collect excess bitcoins). Users can use arbitrarily many public keys (pseudonyms) with no real restrictions - as a result, at the moment there are some 12 million public keys in the system. So, need to cluster the IDs.<\/p>\n Heuristic to cluster pseudonyms - if two (or more) addresses are inputs to the same transaction, they are controlled by the same user\u00c2\u00a0(assume that users do not share public keys). The result - 5.5 million distinct clusters. Given the change address transactions, can further cluster pseudonyms: any change address between pseudonyms implies the same user behind both. Identifying change address transactions is hard, but doable :)<\/p>\n Funfacts:<\/p>\n To track bitcoins, can see when they \"meaningfully\" cross cluster boundaries - following \"peels\" of bitcoins.<\/p>\n Tracking stolen bitcoins! Most end up in exchanges after a few transactions. Problem for thieves: exchanges know ID of individuals...<\/p>\n Identifying drug purchases to silk road quite easy - an article in the news. (Wonder how they could get the ethics committee approval...)<\/p>\n <\/p>\n <\/b>Follow the Money: Understanding Economics of Online Aggregation and Advertising\u00c2\u00a0<\/a>(review<\/a>) (short) -\u00c2\u00a0best paper<\/strong><\/p>\n P. Gill\u00c2\u00a0(The Citizen Lab\/Stony Brook University)<\/i>, V. Erramilli\u00c2\u00a0(Telefonica Research)<\/i>, A. Chaintreau\u00c2\u00a0(Columbia University)<\/i>, B. Krishnamurthy\u00c2\u00a0(AT&T Research)<\/i>, K. Papagiannaki, and P. Rodriguez\u00c2\u00a0(Telefonica Research)<\/i><\/p>\n Focus on display advertising - $15B market in 2012<\/p>\n Little is known about the value of information advertising aggregators collect. Many tricky issues, in particular privacy - studying that can<\/p>\n Interviews with advertising professionals and came up with a revenue model: using CPM (Cost per mille) have CPM(u,p,a) = Run of network * Traffic quality multiplier * Implicit intent (u)<\/p>\n (where u - user, p - publisher, a - aggregator)<\/p>\n Implicit intent is based on the information advert aggregators collect about the user. What is intent? Based on user's browsing info as collected during their visits of websites. Each aggregator has a subset of intents as they are present only across a subset of all websites.<\/p>\n Data: network traces of 3M users and 1.5B sessions, combined with publicly available information from Alexa.<\/p>\n Results:<\/p>\n What happens when users enable one-sided privacy protection (e.g. DoNotTrack, blocking cookies)? Aggregators cannot infer intent! Mean intent values in the normal case are around 4.2 (HTTP) and 3.8 (mHTTP), but revenue can drop by a factor of 3.8. If only top 5% users block, revenues drop by 30%!<\/p>\n Q: loads of inference... how did you infer various numbers, e.g. intents?<\/p>\n A: combination of datasets and advertising knowledge<\/p>\n Q: dynamics between aggregators? Companies changing, getting bought, etc.<\/p>\n A: collapsed all aggregators into one big entity for this analysis<\/p>\n <\/p>\n <\/b>Understanding the Effectiveness of Video Ads: A Measurement Study\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n S.S. Krishnan\u00c2\u00a0(Akamai)<\/i>\u00c2\u00a0and R.K. Sitaraman\u00c2\u00a0(UMass Amherst\/Akamai)<\/i><\/p>\n The mega question: are videos sustainable, let alone profitable? Trying to do video ads, pay-per-view, subscriptions, but serving videos is costly.\u00c2\u00a0How can measure ad effectiveness? Simple metric: do people watch ad videos to completion?<\/p>\n Goal: understanding factors that could impact ad completion. Considering ad position, length, video in which it is inserted, time of day, watching habits, viewer's location\/device...<\/p>\n Data: Akamai's media analytics platform, using a plugin that runs inside the media player and is globally deployed for millions of users. 65 million users, 33 video providers and 3000 publishers, 367 million video and 257 million ad views!!<\/p>\n Viewers are more likely to complete an ad inserted in the middle of a video when they are presumably more engaged with the content than when the ad is inserted in the beginning or the end of a video.<\/p>\n Trying to answer how much does video itself matter for ad completion by looking at long-form and short-form videos. Viewers are more likely to complete an ad inserted into a longer video such as movie likely because they see more video in the content itself.<\/p>\n Folklore asserts that viewers are more likely to complete ads during relaxation time (supposedly they have more time). The data does not show a lot of difference though.<\/p>\n How much does loyalty to a website matter for ad completion? Most often measured by loyalty. Turns out, viewers who repeatedly come back to a website are more likely to watch ads to completion, presumably because they deem content on the website more valuable.<\/p>\n How do people react to pre-roll ads? People abandon the video much more often when loading of the ad is taking a long time than when there is a pre-roll ad: 45% abandoned a slow-loading video and only 13% - the ad. Explanation is that expected waiting time is of known duration and because viewers accept ads as an implicit form of payment for the content.<\/p>\n A word about techniques: can't really run controlled experiments and the data gives a lot of chance for jumping to poor conclusions (e.g. pre-roll, mid-roll and post-roll ad completion rate). Using Quasi Experiments (Krishnan, S. IMC 2012). Idea: isolate the impact of treatment and control for confounding factors by matching.<\/p>\n Q: can't properly infer post-roll watching - the muser might have got up and left.<\/p>\n A: no way of knowing that in general - assume it is the case if a the ad is played to completion.<\/p>\n Q: ranking of ads themselves?<\/p>\n A: noticed a lot of variation between ads, but haven't done in-depth analysis yet<\/p>\n <\/p>\n <\/b>Follow the Green: Growth and Dynamics in Twitter Follower Markets\u00c2\u00a0<\/a>(review<\/a>) (long),<\/p>\n G. Stringhini, G. Wang\u00c2\u00a0(UC Santa Barbara)<\/i>, M. Egele\u00c2\u00a0(CMU)<\/i>, C. Kruegel, G. Vigna, H. Zheng and B.Y. Zhao\u00c2\u00a0(UC Santa Barbara)<\/i><\/p>\n <\/p>\n Weather in the Clouds<\/strong><\/p>\n <\/b>Next Stop, the Cloud: Understanding Modern Web Service Deployment in EC2 and Azure\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n K. He, A. Fisher, L. Wang, A. Gember, A. Akella and T. Ristenpart\u00c2\u00a0(UW Madison)<\/i><\/p>\n Questions:<\/p>\n Dataset: university packet capture - deep, \u00c2\u00a0but possibly atypical. Use IDS system to get information about connections. Second: alexa subdomains dns records and mapping to IP addresses of cloud services (using public ip address ranges).<\/p>\n 94.2% domains that use cloud (40k out of 1m domains) use amazon. From the university perspective, 80% of traffic goes to EC2 and the rest to Azure. The main traffic user is dropbox (68%!), but e.g. netflix has less than 2% - this is because they deliver video content from CDNs rather than clouds.<\/p>\n Load balancers identified by CNAME records (also PaaS such as heroku - just a different CNAME pattern).<\/p>\n Loads of stats about usage statistics by types of frontends, locations (regions\/availability zones), numbers of regions used... Check paper. Summary of the seemingly important stats: most services on EC2 only use one region, but at least multiple availability zones - region failures would have high impact, but availability zones could be dealt with okish.<\/p>\n Q: infocom last year - very similar, the main difference being data from home users (50k) and their numbers are vastly different<\/p>\n A: ack<\/p>\n Q: reasons for not using multiple regions, e.g. financial?<\/p>\n A: yes, primarily - need to pay for traffic across regions, etc. Also more consistency issues across regions<\/p>\n <\/p>\n <\/b>Choreo: Network-Aware Task Placement for Cloud Applications\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n K. LaCurts, S. Deng, A. Goyal and H. Balakrishnan\u00c2\u00a0(MIT CSAIL)<\/i><\/p>\n Problem: each machine has cpu and memory capabilities and each task has those requirements - make an assignment.<\/p>\n Choreo measures network, profiles applications and places tasks. The goal is to minimize completion time of network-intensive cloud applications.<\/p>\n The motivation is large variation in pairwise VM throughputs.<\/p>\n In the paper assume that applications already know their network demands. More complicated (work under submission) analysis possible, but claims that the demands are highly predictable.<\/p>\n Use packet trains (previous work from 1986, 1993) to measure throughput - takes milliseconds. Compared against netperf, the measurements are quite close - in both cases error is within 10%. In practice, it takes ~3 minutes for a 10 machine topology. Network stability? According to their study, only 5% of paths see more than 6% error for all timescales (EC2). Comparing results between 2012 and 2013, looks like EC2 infrastructure has changed and hypothesize that aggregate traffic from a tenant is rate-limited to make bw less affected by cross traffic. Cloud nets are definitely changing...<\/p>\n There is some correlation between path length and bandwidth - if connections were affected by cross traffic, then the longer the path, the lower the observed bandwidth should be.<\/p>\n Placing tasks using greedy heuristics - example based on network, but paper considers cpu and memory as well. Optimal solution can be expressed as an integer linear program. Greedy is not always optimal, but median completion time is 13% greater than optimal.<\/p>\n Eval - data from HP cloud services data, used to simulate live traffic on EC2. Compared choreo against random placement, round-robin and a minimum number of machines placement. Two scenarios: all applications known upfront and applications arrive online.<\/p>\n For upfront known apps, up to 70% of applications have improvements (median improvement 13-18%). For online arrival, improvement for 85% of apps with median improvement of up to 53%.<\/p>\n Limitations: not meant for small apps, those that send little data or those that run for a short time.<\/p>\n Q: Assumed simple tree for bw \u00c2\u00a0measurements, how would other topologies or multipath affect them?<\/p>\n A: haven't seen any evidence of multipath, but would need to adapt the metrics. Certainly seems doable<\/p>\n Q: What if cross traffic was a bigger problem?<\/p>\n A: didn't see a lot of cross traffic, but we did simulations to check that - details in the paper.<\/p>\n Q: Is it difficult to pinpoint rate limiting? That would change many problems<\/p>\n A: the measurements suggest that strongly, but hard to say what amazon are really doing<\/p>\n <\/p>\n <\/b>Benchmarking Personal Cloud Storage\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n I. Drago\u00c2\u00a0(University of Twente)<\/i>, E. Bocchi, M. Mellia\u00c2\u00a0(Politecnico di Torino)<\/i>, H. Slatman and A. Pras\u00c2\u00a0(University of Twente)<\/i><\/p>\n <\/p>\n <\/p>\n <\/b>Measuring and Mitigating Web Performance Bottlenecks in Broadband Access Networks\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n S. Sundaresan, N. Feamster\u00c2\u00a0(Georgia Institute of Technology)<\/i>, R. Teixeira\u00c2\u00a0(CNRS\/UPMC Sorbonne Universities)<\/i>and N. Magharei\u00c2\u00a0(Cisco Systems)<\/i><\/p>\n NOT about the cloud; about web performance bottlenecks :)<\/p>\n Loads of performance optimization across all tiers: client side (caching, protocols), proxies and service providers. Last mile latency can be significant (previous work).<\/p>\n Two contributions: last-mile latency measurements and quantification of dns prefetching and tcp connection caching benefits (up to 35%).<\/p>\n Mirage indentifies latency bottlenecks by querying a url and fetching all objects. Measures time to first byte, and cycles through the list of objects linked from the page - somehow users that to estimate last mile?<\/p>\n Page load time is often bound by latency - page load time stops improving with increasing bw at 16mbps.<\/p>\n Popularity based DNS prefetching. It alone can improve page load time by up to 10%. (what about low-ttl domains?)<\/p>\n Not really feasible to keep prefetching dns names and keep tcp connections open to all popular domains... Only pre-fetch popular sites with timeout. Analyse using simulation on traces from 12 homes. Cache hits improve list size of 20 and timeout of 2 minutes: DNS hit rate improves to 19%.<\/p>\n Q: compare work with wprof from nsdi last year? Bottleneck is computation.<\/p>\n A: complimentary... will probably hit those limits anyway at some point, with improving computation speeds.<\/p>\n Q: Keeping connections on for 2 minutes is a long time for the content providers<\/p>\n A: content providers will improve infrastructure because they \"really care\"... because it has huge impact on performance<\/p>\n Routing<\/strong><\/p>\n Studying Interdomain Routing over Long Timescales\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n G. Comarela, G. Gursun and M. Crovella\u00c2\u00a0(Boston University)<\/i><\/p>\n <\/i><\/b>AS-level Topology Collection Through Looking Glass Servers\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n A. Khan\u00c2\u00a0(Seoul National University, South Korea)<\/i>, T. Kwon, H.-C. Kim\u00c2\u00a0(Sangmyung University, South Korea)<\/i>\u00c2\u00a0and Y. Choi\u00c2\u00a0(Seoul National University, South Korea)<\/i><\/p>\n <\/b>AS Relationships, Customers Cones, and Validations\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n M. Luckie, B. Huffaker, A. Dhamdhere\u00c2\u00a0(CAIDA\/UC San Diego)<\/i>, V. Giotsas\u00c2\u00a0(University College London)<\/i>\u00c2\u00a0and K. Claffy(CAIDA\/UC San Diego)<\/i><\/p>\n Fun with Phones<\/strong><\/p>\n RILAnalyzer: a Comprehensive 3G Monitor on Your Phone\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n N. Vallina-Rodriguez, A. Aucinas\u00c2\u00a0(University of Cambridge)<\/i>, M. Almeida, Y. Grunenberger, D. Papagiannaki\u00c2\u00a0(Telefonica Research)<\/i>\u00c2\u00a0and J. Crowcroft\u00c2\u00a0(University of Cambridge)\u00c2\u00a0<\/i><\/p>\n Not taking notes for own paper, but can use the opportunity to drop a link to our project's website: rilanalyzer.smart-e.org\u00c2\u00a0<\/a>\u00c2\u00a0:)<\/p>\n <\/p>\n <\/i><\/b>Signals from the Crowd: Uncovering Social Relationships through Smartphone Probes\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n M.V. Barbera, A. Epasto, A. Mei, V.C. Perta and J. Stefa\u00c2\u00a0(Sapienza University, Rome, Italy)<\/i><\/p>\n WiFi Probe Requests reveal a lot of information about the users: publish SSIDs known to devices. Funfacts from data collected during the conference and a large dataset collected over multiple events...<\/p>\n Inferring social links from their relationships with networks... Skipping the formal definition, if people share 1 or more networks, they might be connected, but not always.<\/p>\n Loads of related work in the past not even mentioned.<\/p>\n <\/p>\n <\/b>Rise of the Planet of the Apps: A Systematic Study of the Mobile App Ecosystem\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n T. Petsas, A. Papadogiannakis\u00c2\u00a0(FORTH-ICS)<\/i>, M. Polychronakis\u00c2\u00a0(Columbia University)<\/i>, E.P. Markatos\u00c2\u00a0(FORTH-ICS)<\/i>and T. Karagiannis\u00c2\u00a0(Microsoft Research)<\/i><\/p>\n A study on how distribution of downloads looks like and comparing to other domains - WWW, P2P... Infer how pricing affect popularity.<\/p>\n <\/p>\n Well.<\/p>\n <\/p>\n Analysis of the HTTPS Certificate Ecosystem\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n Z. Durumeric, J. Kasten, M. Bailey, J.A. Halderman\u00c2\u00a0(University of Michigan)<\/i><\/p>\n Loads of roots, even more intermediaries - have to establish trust.<\/p>\n How do we measure the ecosystem? Need to look at the edges. Performed 110 scans of entire IPv4 address space over 18 month period. completed 1.8 billion TLS handshakes and 42 unique certificates.<\/p>\n Active scans - need to limit scan impact. Didn't need to scan very fast - did the scans over 24 hour period, randomized and indicated the purpose of the sans over http, dns and whois honored all requests to be excluded from future scans (less than 100 networks).<\/p>\n CA stats:<\/p>\n Large attack service:<\/p>\n Lack of oversight - unmaintainable ecosystem. Policies are ignored, web browsers need co demand and coordinate change... A lot of recent work on TLS improvements, but need to make HTTPS more widespread.<\/p>\n Q: what are the incentives to lead the big technical change? How can we re-engineer the market?<\/p>\n A: the move towards more security... the end-user is never going to push for it, need a push from large companies and us as a community<\/p>\n <\/p>\n <\/b>Exploring EDNS-Client-Subnet Adopters in Your Free Time\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n F. Streibelt, J. Boettger, N. Chatzis\u00c2\u00a0(TU Berlin)<\/i>, G. Smaragdakis\u00c2\u00a0(T-Labs\/TU Berlin)<\/i>, and A. Feldmann\u00c2\u00a0(TU Berlin)<\/i><\/p>\n non-ISP resolvers are gaining momentum - users are far from resolvers and often mess up CDN assignments.<\/p>\n 13% of (top something) Alexa domains seem to support EDNS0 already.<\/p>\n Client IP in ECS cannot be checked - use that for probing (actually interesting)! Find the location of CDN caches within ISPs, observe the growth of CDNs, infer client-to-server mappings...<\/p>\n Validation against RIPE RIS.<\/p>\n Using to detect GGC (Google Global Cache edge servers) - various ISPs, very often used to serve users, usually from within an AS.<\/p>\n <\/p>\n <\/b>Mapping the Expansion of Google's Serving Infrastructure\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n M. Calder\u00c2\u00a0(USC)<\/i>, X. Fan, Z. Hu\u00c2\u00a0(USC\/ISI)<\/i>, R. Govindan\u00c2\u00a0(USC)<\/i>, J. Heidemann\u00c2\u00a0(USC\/ISI)<\/i>\u00c2\u00a0and E. Katz-Bassett\u00c2\u00a0(USC)<\/i><\/p>\n Huge Google infrastructure expansion: Google.com servers in October '12 - 200 sites in 60 countries and 100ASes (mostly google's ASes) . One year forward: 1400 sites in 130+ countries and 800ASes (mostly ISP ASes).<\/p>\n The approach relies on \"the fact that Google works hard to direct clients to nearby frontends\"<\/p>\n Same technique with EDNS as previous paper. Longitudinal study of Google infrastructure.<\/p>\n","protected":false},"excerpt":{"rendered":" As far as I’m concerned, starting technical sessions before 9AM should be made illegal, but hey, at least we have the best paper presented in the first session! Today we have sessions about mobile, weather (in the clouds), routing and phones.<\/p>\n","protected":false},"author":37,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1597"}],"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\/37"}],"replies":[{"embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/comments?post=1597"}],"version-history":[{"count":13,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1597\/revisions"}],"predecessor-version":[{"id":1610,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1597\/revisions\/1610"}],"wp:attachment":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/media?parent=1597"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/categories?post=1597"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/tags?post=1597"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n
\n
Web<\/strong><\/h2>\n
\n
\n