View
227
Download
0
Category
Tags:
Preview:
Citation preview
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
Recommended