1. nTorrent: Peer-to-Peer File Sharing in Named Data Networking
NDNcomm 2017
Macrh 23 – 24
Memphis
Spyridon (Spyros) Mastorakis
University of California, Los Angeles
11/8/2018
NDNcomm 2017

2. Data-Centricity & Peer-to-Peer File Sharing
Data-centricity at different layers (application vs network) for peer-to-peer file sharing
BitTorrent (BT): peer-to-peer file sharing application in TCP/IP
Robust & efficient data distribution
Data-centricity at the application layer
Point-to-point TCP/IP packet delivery at transport & network layers
No network-layer knowledge
Named Data Networking: Data-centricity directly at network layer
How easy/difficult to design an application with similar objective?
Data-centric logic implemented at the TCP/IP application layer: peers do not care where they fetch data from + data integrity verification based on SHA1 hashes in the .torrent file
No network-layer knowledge (routing policies, distance to each peer, peer IP address)
Goal: study the impact of implementing the data-centric logic at different layers of the network architecture
Issues that TCP-IP based BitTorrent faces because of being an application layer overlay
Similarities/Differences between BitTorrent and the model of NDN
Eventually, we present the nTorrent design, a proof-of-concept NDN application to provide BitTorrent-like functions natively in NDN in a simpler way than the TCP-IP based implementation.
11/8/2018
NDNcomm 2017

3. TCP/IP Hurdles to BitTorrent
Tracker or DHT node
The ultimate goal of BT peers is to download a torrent. Given this goal, they:
Peer Discovery: The underlying TCP/IP forces BT to specific an IP address to fetch data from: peers have to discover others (their IP address): a) through a tracker, b) through a DHT, c) once they have joined a swarm, they can use some optimizations to reduce dependency on tracker or DHT, e.g., Peer Discovery Protocol (PEX)
Peer Selection: Once you discover some peers, how do you select the best ones to download data from? A number of BT implementations use download bandwidth as the metric (unaware of peer location) to decide by performing application layer measurements
Rarest Piece Prioritization: Since TCP/IP does not support data retention, peers have to download pieces in a way to benefit data replication for the swarm; they prioritize the replication of rare pieces, so that they can be downloaded in parallel from multiple peers and do not become unavailable.
Piece Integrity Verification: The TCP/IP network layer does not verify the integrity of individual packets, forcing BitTorrent to verify data integrity per piece at the application layer. If one packet in a piece is missing or fails the integrity check, the entire piece cannot be verified.
Data Sharing: No data retention by network, data sharing enforced at the application layer by explicitly managing (choking and unchoking) individual connections.
Traffic Localization: Throughout the process of data fetching and sharing, peers aim to talk to nearby peers to minimize download time, while Internet Service Providers (ISPs) aim to minimize the volume of generated inter-AS traffic. BitTorrent has no knowledge of the underlying connectivity, therefore, it can generate massive amounts of long distance and inter-AS traffic, increasing download times, network resource consumption and the costs of ISPs. Ways to deal with that: 1) external knowledge of network topology by peers or tracker 2) Path monitoring and latency measurements by peers 3) Leverage DNS service discovery to find peers within the same local network 4) ISPs deploy “local” trackers to return “local” peers All these approaches introduce components external to the protocol itself plus the last one requires modification of DNS configuration
Torrent File
Torrent File
This guy is not uploading enough. Have to “choke” him
Let’s share the piece now!
Download first from whoever has the rarest piece!
I want to download the torrent. Anybody else around????
Which peer to fetch data from?
Who is the closest one?
Are there any peers in my network?
Have to try them all!
Got a piece. Have to verify it..
11/8/2018
NDNcomm 2017

4. Common Design Elements Between BT and NDN
Say application names
Naming Data: application names in NDN are used directly by network
BitTorrent: the application names stays at the application layer
Data centric security: NDN uses signature per data packet and can use full names to optimize data integrity check to be performed by the network itself with minimal forwarder processing overhead
Efficient data retrieval: Through the stateful forwarding plane and the strategy module: 1) Prioritization of local data copies, 2) Best location that has the data in terms of data plane performance, 3) Parallel fetching and Multi-path forwarding, 4) Native data multicast and in-network caching
11/8/2018
NDNcomm 2017

5. nTorrent Design Goal: Securely retrieve a torrent. It may consist of:
one or more files
each file of a number of data packets
3 main design abstractions: 1) Torrent file, 2) File Manifest, 3) Packet in a file
Torrent File contains the full names of file manifests
File Manifest: catalog of full packet names in a file
Through website, via , via friend..
Torrent File contains the full names of file manifests
File Manifest: catalog of full packet names in a file
Full Packet Names: Integrity guaranteed by network
11/8/2018
NDNcomm 2017 5

6. Hierarchical Namespace
11/8/2018
NDNcomm 2017

7. Utilizing In-Network Caching
How to fetch data?
Peer 2
Sequentially?
Random Fashion?
Fetch packet 2
of file 1!
Fetch packet 0
of file 0!
Data for packet 10
of file 5!
Data for packet 0
of file 0
Peer 1
NFD
NFD
NFD
We do not do rarest piece first:
1) we do not know
2) does not maximize cache usage
Fetch packet 10
of file 5!
Fetch packet 0
of file 0!
Fetch data from cache for simultaneous downloads!
Unlikely to fetch
data from cache!
11/8/2018
NDNcomm 2017

8. Routing Scalability
Granularity of prefix to announce: a) torrent prefix b) file prefix c) data packet prefix Trade-off: Announcement granularity vs FIB size vs Forwarding plane accuracy
2 major decisions involved
Replace routing announcement with Routing Scalability, talk about #1 and the trade-off, then about #2 and the trade-off
More coarse grain announcements, smaller FIBs (better routing scalability), Interests may reach locations that do not have the data, more time to find and fetch data
Announcing prefixes without having downloaded all their packets, enable more parallel fetching by others, Interests may reach locations that do not have the data, more time to find and fetch data
1) this decision involves a trade-off between the accuracy of the routing and forwarding plane and the number of announced prefixes; coarse-grained announcements reduce the size of FIBs but, depending on when the announcements are made (as explained below), they might result in extended path exploration to find the data or reduced amounts of time that a peer uploads its data.
2) Since a peer can announce a prefix without having all its data (e.g., the prefix of a file in the torrent, without having all the packets in the file), this decision involves a trade-off among the required amount of path exploration to find the data, the amount of time that a peer uploads its data and the peer agility in the sense of enabling peers to download data fast from multiple sources.
11/8/2018
NDNcomm 2017

9. Routing Scalability (cont’d)
When to do the announcement:
a) when a peer starts downloading data of announced prefix
b) when a peer downloads all the data of announced prefix
c) when a peer downloads some data of announced prefix
Trade-off: Announcement timing vs Peer agility vs Forwarding plane accuracy
Announcing prefixes without having downloaded all their packets, enable more parallel fetching by others, Interests may reach locations that do not have the data, more time to find and fetch data
11/8/2018
NDNcomm 2017

10. nTorrent Implementation
Implementation (almost ready to use, have been tested and debugged on the NDN testbed):
Documentation to come soon
Implementation to be ported to ndnSIM soon
11/8/2018
NDNcomm 2017

11. Peer-to-Peer File Sharing in NDN Terms
Peer acts as producer and consumer at the same time
Peer does not have to explicitly discover others
No need for a tracker
Elimination of redundant fetching, reduction of network load and retrieval time
Peer never receives bogus data
1) a peer in NDN acts as a consumer and a producer at the same time; as a consumer, it downloads data from others, and as a producer, it uploads data to others, which requires the peer to announce the name prefixes of the data (i.e., the peer is willing to upload) to the routing system
2) Peer will express a request for data and the forwarding plane will bring this data back
3) Traffic localization and parallel downloading are done by the forwarding plane
4) NDN’s native support for multicast data delivery and in-network caching
5) Data integrity verification by forwarders because of full names
11/8/2018
NDNcomm 2017