[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RAI] Draft on P2P architectures



Hi Dan,

thanks for your comments. Answers inline:

Dan York wrote:
Gonzolo,

On Feb 23, 2009, at 9:40 AM, Gonzalo Camarillo wrote:

the IAB has just submitted the following draft:

http://www.ietf.org/internet-drafts/draft-iab-p2p-archs-00.txt

Comments are welcome.

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