Last day of IMC 2013 - starting with network scaling and their analysis at scale and will have some rather funky if not weird papers later today.<\/p>\n
<\/p>\n
Missed the beginning of the session and not taking notes for the rest of the session, but here is the list together with links to the pdfs<\/p>\n
<\/b>Indexing Millions of Packets per Second using GPUs\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n F. Fusco\u00c2\u00a0(ETH Zurich)<\/i>, M. Vlachos\u00c2\u00a0(IBM Research Zurich)<\/i>, X. Dimitropoulos\u00c2\u00a0(ETH Zurich)<\/i>\u00c2\u00a0and L. Deri\u00c2\u00a0(ntop)<\/i><\/p>\n <\/b>On the Benefits of Using a Large IXP as an Internet Vantage Point\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n N. Chatzis\u00c2\u00a0(TU Berlin)<\/i>, G. Smaragdakis\u00c2\u00a0(T-Labs\/TU Berlin)<\/i>, J. Boettger, T. Krenc, and A. Feldmann\u00c2\u00a0(TU Berlin)<\/i><\/p>\n <\/b>Growth Analysis of a Large ISP\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n A. Ferguson, J. Place and R. Fonseca\u00c2\u00a0(Brown University)<\/i><\/p>\n <\/b>Understanding the Super-sized Traffic of the Super Bowl\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n J. Erman and K.K. Ramakrishnan\u00c2\u00a0(AT&T Research)<\/i><\/p>\n <\/b>Appraising the Delay Accuracy in Browser-based Network Measurement\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n W. Li, R. Mok, R. Chang and W. Fok\u00c2\u00a0(The Hong Kong Polytechnic University)<\/i><\/p>\n How much accuracy is there in browser-based measurement results?<\/p>\n Used 10 techniques (protocols - http, websocket, etc.) and different browser-os combinations.<\/p>\n Cause object reuse by immediately rerunning experiment (not convinced how that interacts with the different components...). Not sure I buy their methodology - the numbers might be interested, but 1ms - 10ms latency of JS alone and 10-200ms of flash for example do not seem to be plausible, possibly because of the methodology. Need to take a look at the paper.<\/p>\n <\/b>Network Fingerprinting: TTL-based Router Signatures\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n Y. Vanaubel\u00c2\u00a0(Universit\u00c3\u00a9 de Li\u00c3\u00a8ge)<\/i>, J.-J. Pansiot, P. Merindol\u00c2\u00a0(Universit\u00c3\u00a9 de Strasbourg)<\/i>\u00c2\u00a0and B. Donnet\u00c2\u00a0(Universit\u00c3\u00a9 de Li\u00c3\u00a8ge)<\/i><\/p>\n Grouping network devices into disjoint classes. Using TTL for fingerprinting.<\/p>\n TTL should be initialised to 64, but in reality not the case (hardware, OS, protocol, type of message...). Use ICMP messages: time-exceeded, echo-reply and destination-unreachable messages and TTLs of 32, 64, 128 and 255. Inferred TTL is then the smallest initial TTL for which returned TTL is smaller than sent...<\/p>\n Only used <time-exceeded, echo-reply> initial TTL as a signature. Turns out to be specific to hardware vendor, can deduce more info about hardware in the network based on the simple signatures...<\/p>\n Q: why do you need to infer TTLs in the orders of 2? are there any weird ttls that people use?<\/p>\n A: (shortened answer) we did not think about this<\/p>\n Comment from twittersphere: traceroute -D on FreeBSD\/OSX...<\/p>\n <\/b>Peeking Behind the NAT: An Empirical Study of Home Networks\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n S. Grover, M.S. Park, S. Sundaresan, S. Burnett, H. Kim, B. Ravi and N. Feamster\u00c2\u00a0(Georgia Institute of Technology)<\/i><\/p>\n Poses that design studies rely exclusively on human subject interviews. Suggests measuring from the gateway.<\/p>\n Want to answer: how frequently home networks disconnect? are there connectivity patterns and how crowded is the wifi? do users saturate their links, does usage depend on devices?<\/p>\n Part 1: user behaviour can \u00c2\u00a0affect connectivity.<\/p>\n Part 2: Connectivity patterns over wifi<\/p>\n Strong diurnal patterns... some stats about large numbers of APs seen...<\/p>\n Part 3: usage patterns<\/p>\n Do users saturate their links? bw is often 100mbps, but half the houses saturate less than 50% of the link. (related to wifi link capacity being smaller than access link capacity?). Most of the traffic is due to one bandwidth-hungry device even in household with 3+ devices.<\/p>\n More popular content is served over long-lived connections - interesting note, sadly didn't go into more detail.<\/p>\n Different types of devices have different most popular domains (more detail in paper) - propose that could be used for device fingerprinting.<\/p>\n <\/b>Identifiability of Link Metrics Based on End-to-End Path Measurements\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n L. Ma\u00c2\u00a0(Imperial College, London, UK)<\/i>, T. He\u00c2\u00a0(IBM T.J. Watson Research, Yorktown, NY, USA)<\/i>, K.K. Leung\u00c2\u00a0(Imperial College, London, UK)<\/i>, A. Swami\u00c2\u00a0(Army Research Laboratory, Adelphi, MD, USA)<\/i>\u00c2\u00a0and D. Towsley\u00c2\u00a0(UMass Amherst)<\/i><\/p>\n <\/b>Profiling High-School Students with Facebook: How Online Privacy Laws Can Actually Increase Minors' Risk\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n R. Dey, Y. Ding and K.W. Ross\u00c2\u00a0(Polytechnic Institute of New York University)<\/i><\/p>\n Question: is it possible to automatically build detailed profiles (names, addresses, gender, etc.) of most of the teenagers in a target high school?<\/p>\n By default fb profiles for minors expose much less information publicly. Still contains name, gender, networks and profile photo. FB will not even allow showing more information publicly. Chellenge: for a give high school, how do we find the students in facebook and build profiles? Minors are not searchable by school and expose little information.<\/p>\n Clustering idea: kids often have many friends from the same high school and the same graduating year. In addition, children lie about their age - get around the restrictions and circumvent all the special privacy policies. Previous research: almost 44% percent of kids lie (Sorbone?) and 1 of 5 in UK.<\/p>\n I don't really feel like summarising the method they used to find minors on fb publicly...<\/p>\n Scary thing is that they contacted fb and google+ about the issues and potential measures, but they did not really do anything.<\/p>\n <\/p>\n <\/b>Demystifying Porn 2.0: A Look into a Major Adult Video Streaming Website\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n G. Tyson\u00c2\u00a0(Queen Mary, University of London)<\/i>, Y. El-khatib\u00c2\u00a0(Lancaster University)<\/i>, N. Sastry\u00c2\u00a0(King's College London)<\/i>\u00c2\u00a0and S. Uhlig\u00c2\u00a0(Queen Mary, University of London)<\/i><\/p>\n Well, read the paper.. :)<\/p>\n Comparison with youtube interesting though: much fewer uploads, but each video gets viewed much more - on average over 10k views. Need fresh content - people don't watch content twice and don't share content...<\/p>\n Content is being vetted - only 18% seem to become live (only 10% of content seems to be removed afterwards). Users are not very choosy - content differentiation is tough. Furthermore, popularity trends are largely dictated by browsing order (least effort). People browse by category - the more categories a video is tagged in, the more viewing grows...<\/p>\n A lot of implications for delivery, caching and UI design.<\/p>\n Q: costs are high... how do these websites make any money?<\/p>\n A: advertising based. Commercial content providers using that as a distribution channels...<\/p>\n Q: what kind of content distribution did you find? No externalities increasing video viewing, how does that compare to youtube?<\/p>\n A: still skewed, but less than youtube. Very little content curation in ones like youtube... The skew is created by social sharing. Vetting becomes the information bottleneck and another part is UI content.<\/p>\n Q: (comment): recent article shows that sandwitches receive good sales from these adverts..<\/p>\n <\/p>\n <\/b>From Paris to Tokyo: On the Suitability of Ping to Measure Latency\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n C. Pelsser\u00c2\u00a0(Internet Initiative Japan)<\/i>, L. Cittadini\u00c2\u00a0(Roma Tre University)<\/i>, S. Vissicchio\u00c2\u00a0(Universit\u00c3\u00a9 Catholique de Louvain)<\/i>\u00c2\u00a0and R. Bush\u00c2\u00a0(Internet Initiative Japan)<\/i><\/p>\n short answer - not suitable for RTT distributions. OK for min\/max RTT, but not suitable for jitter. everything that uses ping to measure latency (unless detecting min\/max) should be re-evaluated.<\/p>\n <\/b>A Comparison of Syslog and IS-IS for Monitoring Link State\u00c2\u00a0<\/a>(review<\/a>) (short)<\/p>\n D. Turner, K. Levchenko, S. Savage and A.C. Snoeren\u00c2\u00a0(UC San Diego)<\/i><\/p>\n Syslog has been popular for network reliability measurements. Not the gold standard though - the gold standard is IGP routing messages...<\/p>\n Question: how accurate is syslog compared to IS-IS data?<\/p>\n Can syslog be used as a drop in replacement for IS-IS data? short answer is no - 18% for DL and 15% UL syslog messages are never received by either end; syslog misses ~1k hours of downtime; 20% of syslog failures are false positives.<\/p>\n Data collection: CENIC network, 13 months of data.<\/p>\n <\/p>\n <\/b>Scap: Stream-Oriented Network Traffic Capture and Analysis for High-Speed Networks\u00c2\u00a0<\/a>(review<\/a>)(long)<\/p>\n A. Papadogiannakis\u00c2\u00a0(FORTH-ICS)<\/i>, M. Polychronakis\u00c2\u00a0(Columbia University)<\/i>\u00c2\u00a0and E.P. Markatos\u00c2\u00a0(FORTH-ICS)<\/i><\/p>\n <\/p>\n <\/b>A Measurement-based Study of Multipath TCP performance over Wireless Networks\u00c2\u00a0<\/a>(review<\/a>) (long)<\/p>\n Y.-C. Chen, Y.-S. Lim\u00c2\u00a0(UMass Amherst)<\/i>, R.J. Gibbens\u00c2\u00a0(University of Cambridge)<\/i>, E.M. Nahum\u00c2\u00a0(IBM Research)<\/i>, R. Khalili\u00c2\u00a0(Deutsche Telekom)<\/i>\u00c2\u00a0and D. Towsley\u00c2\u00a0(UMass Amherst)<\/i><\/p>\n Experiment setup: apache with one interface as a server and WiFi + 4G\/3G cellular client (multiple nets in US). Presenting the case of 2-flow MPTCP with AT&T LTE.\u00c2\u00a0Measure download time, RTT, loss rate and out-of-order delay.<\/p>\n Loads of pair-by-pair comparisons - difficult to summarise, but worth taking a look at the paper. Overall - in many cases end up with performance degradation with MPTCP on cellular networks and energy consumption is problematic because of two radios active simultaneously.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Last day of IMC 2013 – starting with network scaling and their analysis at scale and will have some rather funky if not weird papers later today.<\/p>\n","protected":false},"author":37,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[6,91,23],"tags":[],"_links":{"self":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1612"}],"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=1612"}],"version-history":[{"count":8,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1612\/revisions"}],"predecessor-version":[{"id":1620,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1612\/revisions\/1620"}],"wp:attachment":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/media?parent=1612"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/categories?post=1612"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/tags?post=1612"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Detective Stories<\/strong><\/h2>\n
\n
Intriguing Results<\/strong><\/h2>\n
Paths and Flows<\/strong><\/h2>\n