1 / 13

Community-Driven Internet Measurement: An Innovative Approach to Collaborative Data Gathering

This paper explores a novel community-oriented framework for Internet measurement through a decentralized architecture. It addresses the challenges of high entry barriers in the field, promoting inclusivity and participation. By leveraging existing infrastructure like Distributed Hash Tables (DHT), the proposed platform lowers the maintenance load while providing essential measurement functionalities. The framework facilitates interaction among measurement requesters and providers, enhances community engagement, and fosters trust through cryptographic verification of requests. It aims to democratize access to Internet measurements.

nerys
Download Presentation

Community-Driven Internet Measurement: An Innovative Approach to Collaborative Data Gathering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On Community-Oriented Internet Measurement Mark Allman ICSI Lann Martin, Michael Rabinovich EECS Dept., CWRU Kenneth Atchinson Baldwin-Wallace College

  2. Internet Measurements • A great need • Never-ending • Active community • High barrier of entry into the field • Requires deep expertise • Needs professional contacts • Involves significant effort • A frequent result: • General inferences from small-scale studies

  3. Existing Infrastructures • Research infrastructures • IDMaps, NIMI, Skitter, Ark, RouteView, … • Lots of functionality for large maintenance costs • Commercial platforms • Keynote, Gomez • P2P platforms • DipZoom • Still the core to maintain • GIGRIB • User-based platforms • NetDimes, traceroute@home • Specific experiments, not general measurement enablers

  4. OpenMeas • Remove dedicated infrastructure • No dedicated infrastructure! • All functionality at the end-hosts • An existing DHT as the glue • Benefits • Nothing to maintain • Community orientation • Lowering the “barrier of entry” to the measurements studies • But limited functionality • No find-grained time coordination • Best effort DHT

  5. Architecture Overview • Requirements for DHT • Get/put interface • Put(key, value, ttl) • Get(key) • OpenDHT fits the bill • Measurement requesters • Deposit requests • Poll for results • Measurement providers • Poll for requests • Deposit results • Watchers (in particular long-term data repositories) • Poll for results

  6. Main Tasks • Identifying MPs to request measurements from • Requesting measurements • Processing measurements and reporting results • Retrieving requested measurements • Retrieving watched measurements

  7. Identifying MPs AllMPs Extra info MeasType <MPRespQueue> <MPReqQueue> • MP registration (done by MP) • Put(“AllMP”, “ping-0.45b reqQ5 respQ5 extra-info”) • Finding an MP (done by client - requester or watcher) • Get(“AllMPs”) • Select MPs, i.e., (<MPReqQueue>, <MPRespQueue>) <MPReqQueue> <MPRespQueue> Extra request attributes StartTime <RespQueueKey> Req-string MPID <MeasUID> <RespQueue> MPID <MeasUID> <MeasUID> MPID MeasurementResults

  8. Requesting Measurements AllMPs Extra info MeasType <MPRespQueue> <MPReqQueue> • Create a request record for selected MP (done by requester) • Put(“reqQ5”, “184866301 clientResults_31 -c 100 www.icir.org”) <MPReqQueue> <MPRespQueue> Extra request attributes StartTime <RespQueueKey> Req-string MPID <MeasUID> <RespQueue> MPID <MeasUID> <MeasUID> MPID MeasurementResults

  9. Processing Measurements (done by MP) AllMPs Extra info MeasType <MPRespQueue> <MPReqQueue> • Retrieving requests • Get(reqQ5) • Identifying new requests in table reqQ5 • Generating a unique measurement ID “U” • Putting results into DHT • Put(U, result) • Put(“respQ5”, U) • Put(“clientResults_135”, U) <MPReqQueue> <MPRespQueue> Extra request attributes StartTime <RespQueueKey> Req-string MPID <MeasUID> <RespQueue> MPID <MeasUID> <MeasUID> MPID MeasurementResults

  10. Retrieving Results AllMPs Extra info MeasType <MPRespQueue> <MPReqQueue> • Periodically retrieve own results table • Get(“clientResults_135”) • Identify new result UIDs • Retrieve results • Get(U) <MPReqQueue> <MPRespQueue> Extra request attributes StartTime <RespQueueKey> Req-string MPID <MeasUID> <RespQueue> MPID <MeasUID> <MeasUID> MPID MeasurementResults By requester: By watcher: • Similar but with “resQ5” table.

  11. Security • Threats: • DoS against an MP • Reflected DoS against measurement target • Attacker identity laundering • Mitigation • MP’s best-effort processing • In particular, rate limiting • Protects against MP-targeted DoS • Measurement target-keyed DHT tables recording measurement rate • Protects against a reflected DoS attack • Community orientation • Building web-of-trust of requesters • Crypto-signing measurement requests • Honoring requests from requesters with proper web-of-trust credentials

  12. Primitives • MP Registration • Removing duplicates from DHT tables • Fragmentation and reassembly of data due to DHT table size limitations • Assessing trust • Etc.

  13. Summary • We propose a new measurement platform • Open • Community-oriented • Light-weight - infrastructure-less! • Utilizes an existing substrate (DHT) • Incrementally growing (or shrinking…) • We built a small prototype • Provides a generic client • An MP offering traceroutes

More Related