[ppsp] Alternative tracker proposals; multicast-DNS

[Alexander Harrowell <[e-mail]>]

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