Let’s ChronoSync: Decentralized Dataset State Synchronization in Named Data Networking

Zhenkai ZhuAlexander 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

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

• 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

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

Caches

Data

NameSelectors (opt)Nonce

Interest packet

NameContentSignature

Data packet

6

What is group text chat application?

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

8

Knowledge about the chat room messages

New data item changes state digest

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

Sync Interest

Sync Data

/broadcast/ChronoSync/lunch/4b01...

/broadcast/ChronoSync/lunch/4b01...

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

Chat message Interest

Sync Data

/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

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

14

Synchronization delay (no network failures)

15

Synchronization delay in lossy environments

16

Resilience to network failures

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.

18

Questions