Skip to Content
[CAIDA - Center for Applied Internet Data Analysis logo]
Center for Applied Internet Data Analysis
6th NDN Retreat 2016

The NDN-NP Project will host the 6th NDN Retreat March 20-23, 2016, on the campus of the University of California at San Diego in La Jolla, CA.

|   6th NDN Retreat    Participants   |
|   NDN Hackathon Page   |
Date: March 20-23, 2016
Place: Auditorium B210E/B211E Meeting Room,
San Diego Supercomputer Center, UC San Diego Campus, La Jolla, CA

6th NDN Retreat 2016

We are pleased to announce the NDN 2016 Retreat: an opportunity to discuss the application environments, the NDN software platform and testbed, and focus on some specific areas such as security. This year's meeting will be 4 days long, allowing for more time for sharing and collaboration.

The retreat will be hosted by UC San Diego in the fourth week of March 2016. Sunday and Monday morning are for software development efforts (hacking, getting NDN software installed on laptops, testing software, etc).

The primary goals of the retreat are:

  • Gain new insights and ideas for NDN trust and security mechanism in the context of the network environments
  • Find new design directions for the pilot applications in the proposed network environments
  • See active involvement by all attendees

We wish to focus our interactions and discussions on making problems of security within the targeted NDN-NP application environments concrete and to find and flesh out application specific security problems. We hope to focus on student interaction and new ideas related to NDN NP applications in a retreat-style setting.

The NDN project uses current and future applications to drive the development and deployment of the architecture and its supporting modules, to test prototype implementations, and to encourage an iterative cycle of hands-on experimentation, evaluation, and design. So, we particularly encourage attendees to prepare in advance of the retreat: install all prerequisites for developing and running NDN applications.


March 20 (Sunday)

  • 09:00 - 10:00 Breakfast
  • 10:00 - 19:00 Hackathon Track: Hack
    • NDN Hackathon participants: Find detailed information at the 2nd NDN Hackathon page
  • 12:30 - 13:30 Lunch
  • 16:00 - 19:00 Non-Hacking Track: Office hours for setting up NDN
  • 19:00 - 20:00 dinner on-site

March 21 (Monday)

  • 08:00 - 09:00 Breakfast
  • 09:00 - 17:30 Hackathon Track: Hack
    • NDN Hackathon participants: Find detailed information at the 2nd NDN Hackathon page
  • 12:00 - 14:00 Non-Hacking Track: Office hours for setting up NDN
  • 12:30 - 13:30 Lunch
  • 14:00 - 17:00 Non-Hacking Track: PI Meeting (in SDSC Room E-145)
  • 17:30 - 18:30 Hackathon Track: Presentations
  • 19:00 Reception on-site / Announcements / Opening of retreat

March 22 (Tuesday)

  • 08:00 - 09:00 Breakfast
  • 09:00 - 09:15 Welcome, purpose, lightning introductions
  • 09:15 - 09:30 Warmup brainstorm
  • 09:30 - 09:50 10-minute plenary intro to topics/netenv status
  • 09:50 - 11:40 Parallel working sessions
    • 1A) Patrick Crowley (Washington University in St. Louis), Networks of Diverse & Intermittent Links
      • Overview and Goal: Many interesting "connectivity scenarios" consist of devices with variable connectivity, both with other devices and with well-connected fixed infrastructure. For example, many military and so-called Internet-of-Things environments are characterized as networks of diverse and intermittent links. The goal of this discussion group is to explore how NDN can be used to provide effective & secure connectivity in such environments. The desired outcome is to identify common interests among NDN team members for pursuing research in this area.
      • Recommended reading:
      • Summary of breakout:
        • The group discussion focused on a) building shared consensus that the NDN project should aim to provide substantial improvements rather than incremental ones and b) discussing how NDN holds such promise for connectivity scenarios characterized by networks of diverse, intermittent links. Following framing and general discussion, the group broke up into smaller groups of 2-6 people and discussed the following themes and topics.
          1. Dissident information sharing: rural wireless mesh networks, banned books, etc.
          2. Distinguishing betweeen retry and retransmit in vehicular networks in particular; reacting to net changes that are too fast to see at client
          3. Distinguishing between link failure & packet loss in strategy layer
          4. Disambiguating responsibilities between applications and forwarding strategy
          5. Populating the toolbox for information flows (sync + processing steps, duty cycling v. intermittent,architectural perspectives on accommodating multi-TB information flows)
          6. General purpose mechanism for link constraints; how to notify the consumer/application
          7. The death of SDN: co-design of applications & strategy for scenarios with diverse intermittent links
          8. Seeding and distributing coordinates in Hyperbolic routing: qualitatively better than link-state routing
    • 1B) Alex Afanasyev (UCLA), Autoconfiguration
      • Overview and Goal: We need to return to a realistic scenario of NDN connectivity for Open mHealth, and break down all of the missing "autoconfiguration" pieces, clarify the design direction, and create a plan to implement. By the end of NP, we should be able to install a binary and get local and testbed connectivity anywhere in the world, provide apps with acceptable publishing prefixes, and have a working approach to publisher mobility that builds on these basic capabilities. This is the notion that in order to be successful in short- and medium-term pilots, NDN has to be best-in-class in terms of ease of use as a middleware stack and solve these problems in a way that points to future viability.
      • Recommended reading:
  • 11:40 - 12:30 Recap on working sessions
  • 12:30 - 13:10 Working Lunch
    • Hackathon Organizing Committee, NDN Hackathon Recap
    • John DeHart (Washington University), NDN Testbed Status
    • Jeff Burke (UCLA REMAP), Preliminary results of NDN developer survey
    • Begin plenary intro to breakout topics
  • 13:10 - 13:40 15-minute plenary intro to breakout topics
  • 13:40 - 14:00 Plenary discussion
  • 14:00 - 16:00 Parallel breakout sessions
    • 2A) Alex Halderman (University of Michigan) and Yingdi Yu (UCLA), Security for NP Environments
      • Overview and goals: For the NP environments, we'd like to see 1) response to existing approach for NAC and schematized trust as applied to NDNFit, which has not been presented in too much detail to a broader group; 2) ideas on how to simplify the terminology and approach and make it more accessible to developers; 3) design direction on open challenges for NDNFit, especially for NAC; 4) Discussion of our team's take on the demand for "encryption everywhere"
      • Recommended reading:
        • Y. Yu, A. Afanasyev, L. Zhang. Name-Based Access Control. NDN, Technical Report NDN-0034 Revision 2, January 11, 2016.
        • Schematizing Trust in Named Data Networking by by Yingdi Yu, kc claffy, Alexander Afanasyev, Van Jacobson, David Clark, and Lixia Zhang. ACM Conference on Information-Centric Networking (ICN), September 2015.
        • NDNFit slides (link coming soon)
        • EBAMS slides (link coming soon)
    • 2B) Beichuan Zhang (University of Arizona), NFD Congestion Control & Throughput/Performance
      • Overview and goal: This session will cover focus on two NFD-related topics: 1) Congestion control. For NDN-RTC, we would like to see an analysis of the initial/hackathon approach to congestion control and a plan to get it integrated and tested. If possible, we would add like to add a review of the limitations/issues with current forwarding strategies that we are seeing with NDN-RTC. 2) Performance. We will consider how to improve performance based on the needs of the Climate / HEP group and vehicular networking team.
      • Recommended reading:
    • 2C-a) Edmund Yeh (Northeastern University), Congestion in theory: Congestion Control, Caching, and Forwarding in NDN
      • Summary of breakout:
        • During the breakout session on congestion control, the VIP framework for joint caching, forwarding, and congestion control was presented. A good discussion followed and a number of issues were raised. The group was interested in how the algorithm would handle (a) unknown bandwidth, (b) unknown data packet size, (c) packet losses, PIT timeout, and retransmissions. Within sensing applications, it was asked how the algorithm might be jointly designed with the name space, so that approximations of the requested data could be returned according to application needs. Along these lines, it was asked how adaptive-rate video could be handled using the algorithm, given that video is usually not scalably coded. With respect to congestion control within the VIP framework, it was asked how user-specific congestion control and content-specific congestion control might be suitably combined, so that both fairness and content popularity are adequately reflected.
    • 2C-b) Klaus Schneider (University of Arizona), Congestion in practice: NDN Congestion Control: Motivation, Assumptions, and Early Design
      • Summary of breakout:
        • Our congestion control scheme was designed bottom-up by considering the differences between the NDN architecture and the current Internet. Instead of applying a theoretical framework, we try to design a practical scheme that can be implemented in NFD by the end of this year. In contrast to other CCN/NDN congestion control designs (including the one of Dr. Yeh), our approach does not assume a-priori knowledge of link bandwidth or data chunk size. Thus, it also works in scenarios such as wireless links, IP-overlay links and NDN/IP dual stack deployments. It uses congestion detection based on router queue sizes, explicit congestion notification, window adaptation at the consumer, and multipath forwarding. The specifics of the design can be found at:
        • Big picture ideas:
          1. There is currently no implementation of congestion control in NDN at all.
          2. Congestion control becomes more complicated than in TCP/IP, because of ubiquitous caching, multicast (PIT aggregation), and multipath forwarding.
          3. There is still disagreement about the assumptions you can make about the network (flow identification possible?, known bandwidth, known data chunk size)
          4. These different assumptions lead to vastly different design.
  • 16:00 - 16:30 Recap on breakout sessions
  • 16:30 - 16:45 Break
  • 16:45 - 17:30 Lightning Talks
  • 17:30 - 18:00 Plenary recap and discussion of progress
  • 18:00 Dinner/ Poster session / Demos

March 23 (Wednesday)

  • 08:00 - 09:00 Breakfast
  • 09:00 - 10:45 Roundtable plenary: What I learned from yesterday
  • 10:45 - 11:00 Break
  • 11:00 - 11:30 Plenary breakout introductions
  • 11:30 - 12:00 Parallel IoT breakout sessions
    • Breakout goals:
      1. Re-articulate the problem in terms of the specific use case.
      2. Come up with a solution, in keeping with proposed NDN design principles, that could be built in 6 months, with what we know now.
      3. Frame your solution in terms of the key concepts for IoT on NDN.
      4. Describe the solution in terms of the use case.
      5. Describe and address important security considerations.
      6. List critical dependencies (which may not exist) for your solution.
      7. Based on the limitations of your solution, articulate a small number of specific research areas for a 1-2 year timeframe.
    • 3A) Wentao Shang (UCLA), Pub-sub communication in IoT environment
      • Summary of breakout:
        • traditional way of achieving pub-sub communication in NDN is to set up outstanding Interests before the data is generated. This approach has one limitation: if the subscribers (i.e., consumers) move, or the network topology changes, the pre-established PIT entires will be useless. The subscribers may need to re-express Interests at a smaller interval than the Interest lifetime. The exact frequency depends on the frequency of network topology changes.
        • this group came up with a scalable and reliable pub-sub system design for IoT, using repos as message brokers to coordinate publishers and subscribers running on constrained nodes:
          1. publishers push data to one of the pub-sub repos, using any push mechanism available
          2. subscribers and pub-sub repos run partial sync to retrieve latest update of new data
          3. pub-sub repos run classic sync protocol (e.g., ChronoSync) to synchronize the complete data set
        • long-term research question: can forwarding strategy help with the issues of network topology changes? E.g., one simple strategy is that when a forwarder detects a face is down, it may retransmit the Interests that have been forwarded to the dead face over an alternative path. This allows the forwarders to adapt to network changes without waiting for the end nodes to retransmit.
    • 3B) Joshua Polterock (CAIDA/UC San Diego), Sync: Efficient Multi-party Communication
      • Summary of breakout:
        • Context: We used smart home - energy sharing amongst neighbors Use case: shared battery status/life of neighbors (good sync scenario)
        • Potential solution: Use of sync between gateways; sensors connect to a controller/gateway with more resources.
        • Concerns about maintaining sync digest tree and constrained devices would require lots of memory.
        • Run sync across the neighborhood, Would not run sync in the house.
        • Use of a hierarchical namespace for in-home and neighborhood with different groups of peers.
        • Two broadcast channels: one for the house and one for the neighborhood.
        • Sync running neighborhood wide on its own prefix. likely derived by existing geographic designations.
        • Security concerns. Does it matter that the fridge knows about the laundry machine? Coordinating sync namespace without someone spoofing it.
        • Autoconfig of device names critical to improve, also naming templates
        • Six month development dependency: solving security problems and possibly naming problems.
        • Development dependency for 1-2 year time frame, improve sync protocol to work with network partitions and intermittent connectivity.
        • In a disconnected environment, block chain might work.
        • research proposal: sync based on block chains. Bitcoin-style journaling
    • 3C) Beichuan Zhang (University of Arizona), Gateway approach
    • 3D) Yingdi Yu (UCLA), Multiple hierarchies
    • 3E) Christos Papadopoulos (Colorado State University), Routing in infrastructureless environs
    • 3F) Alex Afanasyev (UCLA), Challenges of constrained devices
    • 3G) Klaus Schneider (University of Arizona), Push-style communication
      • Summary of breakout:
        • Problem statement: How can we achieve efficient push without extra RTTs in IoT?
        • We use two approaches:
          1. Put the payload in the data packet + pre-configure the PIT to accept unsolicited data.* This has the benefit that we can put large amounts of data into the packet payload. However, the sender will get no acknowledgment that the data packet was received. Thus, this approach is only useful for cases where no acknowledgments are needed, like periodic status updates.
          2. *Put payload in the interest name.* This allows to use the data packet as an acknowledgment. However, it is hard to put large amounts of data (like 1MB) into the interest name.
  • 12:00 Plenary reporting and discussion of breakouts
  • 13:00 Introductions for next breakout session
  • 13:00 Working Lunch
  • 13:30 - 13:50 Introductions by new consortium members
  • 14:00 Post-lunch breakout sessions
    • 4A) Lucia D'Acunto (TNO), System Design
    • 4B) Junxiao Shi (University of Arizona), IoT link layer issues
      • Summary of breakout:
        • Questions (detailed in slides): Energy efficiency, Efficient forwarding over layer 2, Fragmentation, Retransmission.
    • 4C) Yingdi Yu (UCLA), Security
      • Summary of breakout:
        • Theme: Confidentiality, privacy. Name encryption
        • Big picture ideas:
          1. continue NAC design, encryption-based access control.
          2. clarify the question about granularity of content key, and workflow flow of E-KEY/D-KEY distribution. Alex Halderman suggested generating content key deterministically, to avoid unnecessary encryption key retrieval.
          3. Discuss scenarios with different confidentiality needs (1) ephemeral end to end communication, (provide TLS equivalent? how to make easy to use?) (2) long lived asynchonrous communication (data delivery model). need to elucidate efficiency/trust tradeoff
          4. Name encryption. Undermines point of architecture. But name reveals too much information. Discussion of Onion approaches for obscurity, e.g., routable prefix is plain text, suffix encrypted, suffix may reveal the routing information for next hop. Is one proxy enough? Tradeoffs of hop-by-hop interest encryption between caching efficiency.

            Data producer can produce data with plain text name (which carries needed application semantics), and encapsulate. signature on encapsulation? who will verify?

    • 4D) Lixia Zhang (UCLA) and Alex Afanasyev (UCLA), Autoconfig
  • 16:00 Official end of retreat
  • 16:00 - 18:00 NDN PI meeting

Local Arrangements / Getting to UC San Diego

For the hackathon and the retreat, attendees are expected to make their own hotel reservations and transportation arrangements from their hotels to the venue. For CAIDA's list of local hotels including shuttle availability, see the updated Local Hotels list (PDF). The Estancia La Jolla (~$222 per night), adjacent to UCSD campus, is within relative walking distance to SDSC. Contact the hotels directly for hotel shuttle schedules (if available) to the San Diego Supercomputer Center (SDSC).

This hackathon/retreat is being held in the SDSC East Auditorium (Room B210E/B211E) that faces Hopkins Drive.
(For those GPS-enabled attendees, the GPS coordinates near the SDSC Auditorium is WGS84: 32°53'03.77"N, 117°14'20.31"W)

General driving directions to SDSC are located on the CAIDA Contact and Visitor Info page.

  • Shuttle to Hotels: SuperShuttle can be arranged to shuttle to UC San Diego campus or your hotel.
  • Taxis: San Diego Taxi Information maintains a list of taxis with rates and additional information. Uber is also well established in San Diego and now has access to service San Diego's airport. GPSes will need to go to the intersection of Hopkins Drive and Voigt Lane. The nearest street address is 10100 Hopkins Drive, La Jolla, CA 92093.
  • Car: Rental available at the airport near the baggage claim areas of Terminals 1 and 2. To park on campus, see Parking on Campus section, below.
  • Parking on campus
    The most convenient parking is in the Hopkins parking structure at Hopkins Dr and Voigt Dr, just south of SDSC.

    Parking Permits: Parking permits are required to park on UC San Diego Campus except on weekends.

    • Hackathon attendees (Sunday and Monday): Park in any lettered space (A,B,S,V/VP) unless otherwise indicated. Since parking is free on Day 1/Sunday but required for the rest of the event, please ask registration/checkin for parking permits for the following days.
    • Retreat-only attendees (Tuesday and Wednesday): attendees: If you're not attending the hackathon, on arrival to campus on the morning of Day 3 (Wednesday) from 8am-9am, check in with a CAIDA staff member at the driveway loop in front of the SDSC building on Hopkins Drive. Tell them that you are here for NDN, and we will give you a parking permit for the day, and then point you to the Hopkins Parking Structure for parking. If no one is there, park in the 5 minute zone, head into the Auditorium to get a permit first. Otherwise, parking permits are sold at the kiosks in the structure for $16/day.

    Parking permits for subsequent days will be provided at the end of Day 1 and day 3, be sure to check in with registration for them.

    After picking up your parking permit, it is recommended you go to the Hopkins Parking Structure next to SDSC and park on the lower levels. Walk back to the street-side of the parking garage (Level 2), and along the street to the SDSC East building. The auditorium is on the left just before the stairs, labeled Auditorium or B210E/B211E Meeting Room.

    Hackathon attendees: Note that the SDSC building will be locked on Sunday except the auditorium. Those coming from the west/Ridgewalk entrance will have to Walk around the building to the auditorium on the east, street-side entrance.

For transportation concerns, general questions and help before the workshop, contact Cindy Wong at <cindy at>.

General UC San Diego Maps and general UC San Diego Visitor Parking information are useful resources for navigating on campus.

  Last Modified: Mon Oct-3-2016 14:31:15 PDT
  Page URL: