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

[Victor Grishchenko <[e-mail]>]

On 3 April 2014 20:00, Alexander Harrowell <[e-mail]> wrote:
> 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.

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.

> 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.

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.

> 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.

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

> 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).

If it works then hell yes.

> 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?"

Indeed.

-- 
Victor