Subject: [P2PSIP] I-D on P2P Status and Requirements

From: Henry Sinnreich <[email-masked]>
Date: Mon, 12 May 2008 13:32:12 -0700

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.

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

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

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.
Maybe a face to face discussion at the 72 IETF would help.

Thanks, Henry 
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 12 May 2008 16:39:03 -0700

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-masked]> wrote:

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

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

> I recommend close coordination with the P2PSIP WG.

If they have interest, sure. Although this is not aimed at the SIP specific
problem.