Hello Henry, Thanks for your comments. I will surely try to accommodate your suggestions/comments on an upcoming version. See other comments inline....
On 5/12/08 1:32 PM, "Henry Sinnreich" <[EMAIL PROTECTED]> wrote: > The I-D ³P2P Status and Requirements² is a useful start, though it points to > many items that have to be discussed and corrected, such as: > > * This is a bandwidth view only of the (elephant) problem. The correct title > should specify this and could be for example: ³P2P Bandwidth Issues: Status > and Requirements². There are many other requirements that could be the object > of separate I-Ds, for NAT traversal, for security, for mobile clients, etc. Yes, there surely are. It depends how big of a problem people want to try to chew. For example, surely NAT traversal is a requirement. Are you suggesting we need something special for P2P or one of ICP, STUN, etc is sufficient? In the security section I tried to point out issues related to the communication between clients and the network. Of course depending on the solution we would need separate I-Ds to discuss each solution in-depth. > > * There is a huge difference between various P2P networks, such as between P2P > file sharing and video distribution, vs. P2P SIP for real time communications, > P2P for application level multicast, etc. This is pointed out in a couple of sections, more specifically in the abstract and "P2P conflicting interests" section. But the point I was trying to get across is that although the purpose of the P2P networks can be different I'm not sure if the solutions need to be. Today you have Youtube, Netflix, itunes and others all using somewhat the same HTTP methods such direct download/streaming or redirection. Are you suggesting that P2P solutions need to be different for different P2P networks? > > * Peers and clients can have network friendly behavior similar to TCP, so no > complaints about network bandwidth need to arise in the first place. Skype > network bandwidth for example compares favorably with SIP using wideband > codecs in the same class (wideband audio and conference class video). Are you talking about being friendly on the application layer? Most P2P protocols such as Bittorrent, emule, etc already use TCP for file transfer. Can you elaborate on what you mean by friendly behavior similar to TCP? > > My apology for all the other requirements I may have missed. > This I-D requires much more work. > I recommend close coordination with the P2PSIP WG. If they have interest, sure. Although this is not aimed at the SIP specific problem. > Maybe a face to face discussion at the 72 IETF would help. > > Thanks, Henry _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
