Subject: Re: [RAI] Draft on P2P architectures

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 17 Apr 2009 11:14:53 +0300

Hi Dan,

thanks for your comments. Answers inline:

Dan Wing wrote:
>> the IAB has just submitted the following draft:
>>
>> http://www.ietf.org/internet-drafts/draft-iab-p2p-archs-00.txt
>>
>> Comments are welcome.
> 
> Please add Gnutella, BitTorrent, and Skype to section 2.  I
> noticed BitTorrent isn't mentioned in the document at all.

I have added BitTorrent to Section 2. However, I would not like to have 
too many examples in that section. Since Skype and Gnutella were already 
mentioned somewhere else in the document, I have not added new 
subsections with them in Section 2.

> You might also mention Octoshape's don't-look-under-the-covers P2P video
> streaming application,
> http://arstechnica.com/web/news/2009/02/cnn-p2p-video-streaming-tech-raises-qu
> estions.ars
> 

I have added references to Octoshape.

> 
> end of Section 5.3,
>      traditional SIP, which relays on a rendezvous server infrastructure.
>                             ^^^^^^
>                             relies

Fixed.

> Section 6,
>    we have discussed a number of
>    perfectly legitimate applications that have been implemented using
>    P2P.
> 
> I would drop "perfectly" from that sentence.  (Same phrase is in Section 1).
> (Are there imperfectly legitimate applications?)

I would like to stress the fact that there are *fully* legitimate. If 
you have a suggestion to give more emphasis to the sentence without 
using "perfectly", let me know.

> To your list of legitimate uses of p2p technology in Section 6, you might also
> consider adding the "unofficial release" by Nine Inch Nails of 400Gb of
> time-synchronized multiple-camera HD video footage from three concerts using
> BitTorrent, http://forum.nin.com/bb/read.php?52,378166.  The trackers are on
> nin.com's own website.

Since this is yet another example of content distribution using 
bittorrent, I do not think we need to add it to the document... but 
thanks for the reference anyway. It is interesting!

Thanks for your comments,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 17 Apr 2009 12:37:11 +0300

Hi Dan,

Dan York wrote:
> Gonzolo,
> 
> On Feb 23, 2009, at 9:40 AM, Gonzalo Camarillo wrote:
> 
> Overall I think this is a useful document to help people understand what 
> is going on with P2P architectures.  A couple of comments:
> 
> - I'll second Dan Wing's comment that the draft should include some 
> mention of Bittorrent, given the wide usage of that P2P protocol.   Many 
> sites have info about torrent usage - some good pointers off of the 
> Wikipedia page: http://en.wikipedia.org/wiki/BitTorrent_(protocol)  A 
> mention (and links) would be good if for no other reason than to point 
> people interested in learning more about P2P architectures to the wealth 
> of info out there about torrent-based networks.

I have added references to BitTorrent now.

> - In section 2, it would seem to me beneficial to provide some further 
> examples of applying the P2P definition beyond simply DNS, SIP and 
> P2PSIP.  I realize that the authors may be trying to constrain 
> discussion to items directly handled by the IETF, but there are 
> significant P2P deployments out there on the Internet (Bittorrent being 
> one of them, but there are many others) that could be interesting to 
> discuss in the document to help readers understand how the P2P 
> definition can relate to deployed P2P systems.

I have added a subsection in Section 2 about BitTorrent.

> - When providing guidance on whether a P2P architecture is appropriate, 
> it may be useful to encourage developers to think about the *type* of 
> endpoints that will most likely be part of their network.  I believe it 
> was Xiao Lin in the P2PSIP mailing list who suggested that there were 
> three types of endpoints to consider: fixed (e.g desktop computers), 
> mobile (e.g. mobile phones) and mixed (e.g. laptops).  Fixed endpoints 
> or laptops may be good candidates for *peers* in a P2P environment, 
> whereas mobile handsets may not be. (But they could be as "clients", see 
> next bullet.)

The reason why mobile handsets may not be a good candidate for peers is 
that they have limited battery life... and that point was already 
discussed in the document (in Section 7 when talking about energy 
consumption).

> - The mobility discussion in the P2PSIP mailing list has highlighted 
> that there may be some P2P environments where some nodes connect to the 
> P2P overlay to access services but do not participate as full peers, 
> perhaps because they don't have the processing capabilities or perhaps 
> because they are too mobile and would create too much churn in the 
> overlay with their movement.  They are simply "clients" of the P2P 
> network.  It may be useful to mention this concept in this draft.

I have introduced this concept in Section 2 now.

> - For the security section, I know there are several Internet-Drafts out 
> there that get into P2P security issues and it may be useful to point to 
> those drafts from this document.  One of them that I know of (because I 
> am involved with it) is for P2PSIP and is at: 
> http://tools.ietf.org/html/draft-matuszewski-p2psip-security-requirements.  
> (The draft is currently being refactored to align with the newest main 
> P2PSIP specification and to split some pieces out into a separate 
> document, but the content there may still be of interest.)

I have had a look at a few drafts that deal with P2P issues. However, I 
have tried to minimize references to work in progress (especially to 
individual contributions). The only draft that is currently referenced 
is ICE.

> - Also, the security section mentions does not mention (that I could 
> see) that dealing with some of these security issues is precisely why 
> some P2P networks will implement centralized enrollment/authentication 
> servers (which were mentioned briefly back at the beginning of section 
> 3).  If you look at Skype, for example, they maintain tight centralized 
> control over joining the P2P overlay through their enrollment servers. 
> You have to have a valid Skype username and password in order for Skype 
> to connect to the P2P cloud.

This is mentioned in the Security Considerations section in the context 
of the Sibil attack.

> Again, I think a document like this is quite a useful contribution to 
> the interest out there in P2P architectures and I thank the IAB for 
> putting it together.

Thanks for your comments. I will be submitting a new revision of the 
document including them shortly.

Cheers,

Gonzalo

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Apr 2009 10:25:37 -0700

Thanks for incorporating those changes,
-d

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Friday, April 17, 2009 1:15 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [RAI] Draft on P2P architectures
> 
> Hi Dan,
>

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 23 Apr 2009 21:12:55 +0200

Hi Gonzalo,

the draft seems in pretty good shape and I think it should be published
as soon as possible to the benefit of the whole community. However, I'm
not sure I totally agree with the last sentence of the newly added
section 2.4, "Applying the P2P Definition to BitTorrent":

   Note, however, that a particular swarm where most endpoints were
   seeders could not be strictly considered a P2P system because most
   endpoints would only be providing services, not requesting them.

In the common case a seeder is a peer that has completed the download,
but still has not uploaded enough to reach a decent share ratio. So, the
fact that a swarm has a majority of seeders is more likely to indicate
that consumption of resources is significantly faster than provision
(either because of asymmetry in uplink and downlink bandwidth, or simply
because offer exceeds demand) and not necessarily that the peers are
providing the service without getting anything back -- they have already
got it.

Enrico

Gonzalo Camarillo wrote:
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai