1. Let’s ChronoSync: Decentralized Dataset State Synchronization in Named Data Networking Zhenkai Zhu Alexander Afanasyev (presenter) Tuesday, October 8, 2013

2. Introduction Many Internet applications are collaborative by nature –group text chat –file sharing –audio/video conferencing Key piece in these applications –distributed state synchronization chat room messages files and folders in the shared folder voice/video streams from each participant 2

3. Distributed state synchronization in today’s Internet Centralized –simple implementation direct match with point-to-point model of IP –centralized control –single point of failure –delivery model mismatch application-level multicast 3 Peer-to-peer –decentralized control –no single point of failure, but –delivery model mismatch application-level multicast –underlying and p2p topology mismatch

4. Can we synchronize state in a true peer- to-peer way in NDN? Keep peer-to-peer decentralization –no single point of failure Utilize data-centric architecture to support distributed applications –network-supported multicast –network-supported efficient data distribution Design general-purpose ChronoSync protocol –group text chat as a driving example 4

5. NDN overview Named Data Networking (NDN) separates –objective of retrieving –specifics of how to do it Interest names exactly what to fetch –matching (secured) Data is retrieved by the network –from caches, in-network storage, or data producers 5 Interest In- network storage Cache s Data Name Selectors (opt) Nonce Name Selectors (opt) Nonce Interest packet Name Content Signature Name Content Signature Data packet

6. What is group text chat application? 6 Synchronization of distributed chat room dataset (set of sequences of chat messages) among the participants Sequence of Alice’s messages Sequence of Ted’s messages Sequence of Bob’s messages

7. Two separate tasks Synchronize knowledge about the dataset (dataset state) –who is in the chat room –how many messages each user generated –Sync Interest/Data Fetch missing data in the dataset –fetch chat messages all, recent, latest –Chat message Interest/Data 7

8. Knowledge about the chat room messages 8 New data item changes state digest

9. ChronoSync naming conventions NDN the same for –application –transport –network layers NDN names should be expressive to provide functions for all layers 3-tier structure of ChronoSync names –for network layer broadcast- or uni- routable prefix –for transport layer application de-multiplexor (demux) –for application layer application-specific data descriptor 9

10. How to get state knowledge updates? Request chat room state that are “newer” that the state digest 10 Sync Interest Sync Data /broadcast /ChronoSync/lunch /4b01... /broadcast /ChronoSync/lunch /4b01... /broadcast /ChronoSync/lunch /4b01... /broadcast /ChronoSync/lunch /4b01... The same question is asked by everybody leverage NDN caching and Interest aggregation The same question is asked by everybody leverage NDN caching and Interest aggregation

11. How to fetch chat messages? Request missing Data pieces directly from the producer –what to request known from Sync Data reply 11 Chat message Interest Sync Data /alice /ChronoSync/lunch /17 /alice /ChronoSync/lunch /17 /alice /ChronoSync/lunch /17 /alice /ChronoSync/lunch /17 The same question is asked by everybody

12. NDN effects Interests are forwarded towards places where Data could be –Data is always returned over shortest paths After request, Data is cached in NDN –retransmitted requests (after loss or disconnection) don’t go down to the Data producer 12

13. Evaluations Goals: examine baseline ChronoSync performance and performance under adverse conditions –packet loss –link failures Methodology –simulation based on ndnSIM –centralized IP based design for baseline comparison –Topology 52 nodes, 84 links, 100 Mbps Rocketfuel-inferred link delays –Traffic 1000 messages in the chat room –All nodes participate in the chat room 13

14. Synchronization delay (no network failures) 14

15. Synchronization delay in lossy environments 15

16. Resilience to network failures 16 When server is not isolated, almost everybody is still able to communicate When server gets isolated, almost nobody is able to communicate

17. Conclusions: ChronoSync is Robust through decentralization –avoids single point of failure –relies on build-in NDN’s flexible Interest forwarding strategy Efficient with data distribution –relies on build-in NDN’s multicast Secured –relies on build-in NDN’s security Building block to support distributed applications –ChronoChat, ChronoShare (file sharing), routing, etc. 17

18. Questions 18

19. Broadcast in large networks Broadcast directly in large networks is costly A broadcast overlay can dramatically reduce the cost 19

20. How to infer changes when sync Interest arrives? The same state digest –states are equal Different state digests –previously observed digest use digest log –otherwise wait (Sync Interest with “unknown” digest may have arrived before Sync Data is fetched) use exclude filter (there could be multiple different Sync Data that correspond to the same state digest) explicitly ask for the state corresponding to the unknown digest (recovery) 20 Digest log recent history of state digest changes state digest vs. actual state changes Digest log recent history of state digest changes state digest vs. actual state changes

21. ChronoSync states Stable state –everyone has the same knowledge –identical outstanding sync Interests –new knowledge efficiently disseminated among participants Simultaneous data generation –multiple different Sync Data with identical digest –exclude filter to fetch all Network partitions –knowledge in disconnected network parts diverges –a set reconciliation to restore stable state 21 4b01..