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

["Huangyihong (Rachel)" <[e-mail]>]

Hi Alex,

Please see some of my opinions inline.

BR,
Rachel

> -----Original Message-----
> From: ppsp [mailto:[e-mail]] On Behalf Of Alexander Harrowell
> Sent: Friday, April 04, 2014 12:00 AM
> To: [e-mail]
> Subject: [ppsp] Alternative tracker proposals; multicast-DNS
> 
> 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
> 
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.
> 
> 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.

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ppsp