Subject: [ppsp] Alternative tracker proposals; multicast-DNS

From: Alexander Harrowell <[email-masked]>
Date: Thu, 3 Apr 2014 17:00:28 +0100

An issue that came up at the London meeting was that some participants
(especially Dave Cottenhuber) are not convinced by the tracker
protocol, and propose instead to discover chunks through DNS
resolution.

Criticisms of the tracker are, as far as I know, as follows:

1) The tracker is a single point of failure, which is undesirable

2) The tracker protocol requires it to track quite a variety of
metrics and to make decisions. As a result, it is quite complex, which
affects its scalability.

3) The tracker is also vulnerable to surveillance and to censorship,
which violates "encrypt all the things". Historically, P2P
distribution has very often been broken by actors filtering,
exploiting, or suing the tracker.

4) It is only weakly localised, so the problem that peer selection
might pick peers on the other side of an ISP's most expensive link
exists.

UK ISPs had this problem when p2p filesharing was popular in the
mid-2000s - they typically had to backhaul traffic from local
concentrators over L2TP connections leased from BT to their
facilities. P2P in this context typically required inter-peer
communication to cross the expensive L2TP link twice. A similar issue
was that Australian ISPs experienced the problem that peers might
select high-reputation peers in, say, North America or Europe, so
traffic would transit the high cost, high latency transpacific link.

We could summarise these as three issues: scalability,
decentralisation, and localisation.

A further issue is that since the 2000s "glory years" of P2P, many
more applications have essentially been port-multiplexed into TCP/80
or 443 by being delivered on the WWW. A very valuable use case would
therefore be the distribution of web content, essentially using the
PPSP swarm as a globally distributed cache. The effort to get support
for ppsp:// URIs into Firefox is a case in point. I am not sure how
well the
current proposals support this.

DNS is scalable, globally distributed, and importantly, it is
relatively easy for users to change their DNS servers. Further, I
think it would be easier to protect relatively small and transactional
interactions with DNS against malicious interference. Existing IETF
work like DNSSEC provides for the security of DNS information although
of course it needs more deployment.

I would like to introduce an idea which contributes to scalability, to
decentralisation, and to localisation. This would be to take up the
idea of DNS-based content identification, using something like the
Naming Things with Hashes proposal, and to add a multicast-DNS layer,
so peers would initially request content from machines on their
multicast domain, and then begin serving it to others.

If it was not found locally, the peer would fall back to DNS recursive
resolution, and then failing that to the anycast root. This would
require that peers be able to register proactively in DNS.

This provides for traffic localisation, reduced load on DNS, a simpler
tracker, and perhaps also greater resistance to censorship, as a
"border firewall" model would not prevent content distribution when at
least one peer behind the firewall had managed to access the censored
material (eg by a VPN, TOR etc or physical media).

It's also relatively close to Van Jacobsen's notion of content-centred
networking, in that the question you ask the mDNS and DNS is not "what
IP address does this name match?" but "where is the nearest source for
content matching this hash?"

Thoughts?

Alex Harrowell

---

From: Victor Grishchenko <[email-masked]>
Date: Fri, 4 Apr 2014 16:01:21 +0400

> protocol, and propose instead to discover chunks through DNS

In the early days of the Swift project, Maciej Wojciechowski was
proposing something of the sort, but we didn't investigate it
thoroughly. There are definitely some issues with response caching and
such, so some experimentation is needed.

> well the current proposals support this.

Indeed, one idea behind swift was to reduce P2P transfer warmup cycles
to make a BitTorrent-like protocol applicable to smaller content, like
Web pages.
Then, BitTorrent-like HTTP trackers are not a viable option because it
takes too much time/traffic to find content/peers. Some DNS magic may
do the trick indeed.

> require that peers be able to register proactively in DNS.

I am not sufficiently familiar with the current state of DNS *cast to
say something definite.

> material (eg by a VPN, TOR etc or physical media).

If it works then hell yes.

> content matching this hash?"

Indeed.

-- 
Victor

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 8 Apr 2014 05:59:32 +0000

Hi Alex,

Please see some of my opinions inline.

BR,
Rachel

> -----Original Message-----
> From: ppsp [mailto:[email-masked]] On Behalf Of Alexander Harrowell
> Sent: Friday, April 04, 2014 12:00 AM
> To: [email-masked]
> Subject: [ppsp] Alternative tracker proposals; multicast-DNS
> 
> (especially Dave Cottenhuber) are not convinced by the tracker protocol, and
> propose instead to discover chunks through DNS resolution.
> 
The tracker is a logical element. It could be a centralized single device in some cases. But in other cases, it may be a distributed implementation, logically behaving as a single entity. It can even be implemented as a cloud service/system. 

> 2) The tracker protocol requires it to track quite a variety of metrics and to
> make decisions. As a result, it is quite complex, which affects its scalability.
> 

The tracker protocol "transports" the metrics, does not take decisions. The Tracker entity may use some of the metrics to make decisions, typically to respond with a selected list of peers in a swarm, suitable for the requesting peer. That peer selection mechanism of the Tracker may use strong localization criteria, which is out of the scope of the current tracker protocol. We have base tracker protocol and extended tracker protocol, to satisfy different requirements. The base tracker protocol only track elementary information like ip address while leave more rich information tracking to the extended tracker protocol, which exactly reflects the scalability.  

> 3) The tracker is also vulnerable to surveillance and to censorship, which
> violates "encrypt all the things". Historically, P2P distribution has very often
> been broken by actors filtering, exploiting, or suing the tracker.

It is not required for the Tracker entity to possess specific information about a content. A content being "streamed", may be just identified at the Tracker level by an ID. The Tracker only manages which peers are "streaming" that content ID. For tracker protocol itself, some mechanisms like authentication between tracker and peers, content integrity protection against polluting peers/trackers have been considered.

> 
> 4) It is only weakly localised, so the problem that peer selection might pick
> peers on the other side of an ISP's most expensive link exists.

It's about the peer selection criteria, not quite related to the tracker protocol itself.

> 
> UK ISPs had this problem when p2p filesharing was popular in the mid-2000s -
> they typically had to backhaul traffic from local concentrators over L2TP
> connections leased from BT to their facilities. P2P in this context typically
> required inter-peer communication to cross the expensive L2TP link twice. A
> similar issue was that Australian ISPs experienced the problem that peers
> might select high-reputation peers in, say, North America or Europe, so traffic
> would transit the high cost, high latency transpacific link.
> 
> We could summarise these as three issues: scalability, decentralisation, and
> localisation.
> 
> A further issue is that since the 2000s "glory years" of P2P, many more
> applications have essentially been port-multiplexed into TCP/80 or 443 by being
> delivered on the WWW. A very valuable use case would therefore be the
> distribution of web content, essentially using the PPSP swarm as a globally
> distributed cache. The effort to get support for ppsp:// URIs into Firefox is a
> case in point. I am not sure how well the current proposals support this.
> 
> DNS is scalable, globally distributed, and importantly, it is relatively easy for
> users to change their DNS servers. Further, I think it would be easier to protect
> relatively small and transactional interactions with DNS against malicious
> interference. Existing IETF work like DNSSEC provides for the security of DNS
> information although of course it needs more deployment.
> 
> decentralisation, and to localisation. This would be to take up the idea of
> DNS-based content identification, using something like the Naming Things with
> Hashes proposal, and to add a multicast-DNS layer, so peers would initially
> request content from machines on their multicast domain, and then begin
> serving it to others.
> 
> If it was not found locally, the peer would fall back to DNS recursive resolution,
> and then failing that to the anycast root. This would require that peers be able
> to register proactively in DNS.

The tracker protocol is about the message exchanging between peers and tracker. The message signaling among multiple or hierarchical trackers in distributed tracker implementations is out of the scope of current tracker protocol and for further discussion. But it seems DNS like mechanism could be considered.

> 
> This provides for traffic localisation, reduced load on DNS, a simpler tracker,
> and perhaps also greater resistance to censorship, as a "border firewall" model
> would not prevent content distribution when at least one peer behind the
> firewall had managed to access the censored material (eg by a VPN, TOR etc or
> physical media).
> 
> It's also relatively close to Van Jacobsen's notion of content-centred networking,
> in that the question you ask the mDNS and DNS is not "what IP address does
> this name match?" but "where is the nearest source for content matching this
> hash?"
> 
> Thoughts?
> 
> Alex Harrowell
> 
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp