Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer InternetTelephony

From: matthewsp at avaya.com (Matthews, Philip (Philip))
Date: Fri Oct 28 18:35:50 2005

[I am posting this to the P2P-SIP mailing list only (and not SIPPING),
since it is my belief that that list provides the most appropriate
discussion forum.]

I think this is a great start on the requirements discussion.
My thanks to the authors for producing this.

Here are some quick comments. Hope to generate some more in-depth
comments next week.

> 4.3.  DHT Changeability
>    The protocol(s) for maintaining the peer-to-peer network SHOULD be
>    flexible to accommodate different DHT algorithms.

I totally agree with this. From my limited investigation of the DHT
world,
I see things just changing too fast to have any hope that today's DHT
will
still be tomorrow's DHT of choice.

> 4.5.  NAT and Firewall Traversal
>    R1.  The peer-to-peer system SHOULD distribute the functionality of
>    NAT and firewall traversal servers to the end-points.

I don't see why this must be a requirement. Your other requirements talk
about being flexible on where services are located (i.e. centralized or
distributed). Given this flexibility, which I agree with, why require
that
a certain service be distributed? Why not leave the choice up to the
builder of
the particular P2P overlay network? If that builder wants to provide a
centralized NAT and Firewall Traversal scheme, why not let him?

As I see it, a centralized service is one that is located on just a
small number
of peers, while a distributed service is one that is located on a large
number
of peers. The same lookup scheme could be used for both, so an arbitrary
peer doesn't
really need to know whether a service is centralized or distributed. So
why say that
a certain service must be distributed?

On the other hand, I would agree that the design should SUPPORT making
the NAT and
Firewall Traversal distributable, but I think you have already covered
that in 4.1.

> 5.4.1.  Centralized Lookup
>    Value-added services such as reliable voicemail storage can be
>    provided by a central authority in a P2P network.  The system
SHOULD
>    allow the peers to efficiently locate the centralized service
>    providers or resources.

This is just a minor comment. The first sentence seems to imply that
voicemail
is preferably implemented as a centralized service. I disagree with that
implication, and suggest that the first sentence be reworded or simply
removed.

I DO agree with the requirement in the second sentence.

> 6.1.  Support for different DHTs
>    Any protocol specification SHOULD be able to incorporate different
>    DHT algorithms based on the P2P service provider requirements.

Isn't this the same as requirement 4.3??

- Philip Matthews
  Nimcat Networks (now a part of Avaya)

PS. Please note that my e-mail address has recently changed to
       [email-masked]
    Mail sent to my old address ([email-masked]) will
    be forwarded for a period, but will eventually be returned.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Salman Abdul Baset
Sent: October 28, 2005 13:16
To: [email-masked]
Cc: [email-masked]
Subject: [p2p-sip] Draft: Requirements for SIP-based Peer-to-Peer
InternetTelephony

We have attempted to compile the requirements for SIP-based peer-to-peer
Internet telephony in a draft. It is available at:
http://www1.cs.columbia.edu/~salman/drafts/draft-baset-sipping-p2preq-00
.txt

Title: Requirements for SIP-based Peer-to-Peer Internet Telephony
Abstract:
This document defines requirements for designing peer-to-peer voice,
text, and real-time multimedia communication system protocols.

Comments are requested.

Regards,
Salman, Henning, Eunsoo, Kishore
_______________________________________________
p2p-sip mailing list
[email-masked]
http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip

---

From: salman at cs.columbia.edu (Salman Abdul Baset)
Date: Sun Oct 30 01:14:06 2005

> centralized NAT and Firewall Traversal scheme, why not let him?

I agree that the choice should be left to the bundler of the P2P overlay
network for deciding which services should be centralized and which should
be distributed. However, at some point the P2P bundler will need to decide
whether the overlay network it is building has degenerated into a typical
SIP-based network and still being marketed as P2P:)

> Firewall Traversal distributable, but I think you have already covered

We think that distributed NAT and firewall traversal is one of the key
motivations to build a P2P overlay, so we decided to keep it as a seperate
requirement. There are two requirements in this section. I think one
option is to delete R1 and keep R2 which says:

"A peer with NAT and firewall traversal capabilities SHOULD be selected
such that it does not introduce significant delay between the
communicating peers."

The other option is to include this section as a subsection of 4.1.

> I DO agree with the requirement in the second sentence.

The sentence says '...reliable voicemail storage can be provided...'. I
guess the 'can' should be changed to 'might'.

> Isn't this the same as requirement 4.3??

We wanted to emphasize that a 'P2P Protocol Spec' must support multiple
DHTs. Since this requirement fell under 'Architecture' and 'Protocol Spec
Requirements', we decided to keep it in both. I think cross-referencing
the sections will be helpful.

regards,
--
Salman Baset

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Mon Oct 31 17:09:18 2005

First off, good requirements set. Thanks for putting them together. Couple of
comemnts on the draft.

1. I would suggest including the <draft-ford-behave-app-01.txt> draft as a
reference in the context of firewall/NAT traversal. The recommendation in the
draft about how P2P apps could adapt to traverse NATs would be directly
relevant here. Also talked in the draft are security concerns with P2P NAT
traversal.

2. Usage Scenarios - Please expand on section 7.1 with a diagram - specifically
descrbing a P2P SIP setup as opposed to a traditional SIP. What
servers/services are prevalent in traditional SIP setup vs a P2P SIP setup.

Additional comments in line below.

regards,
suresh

> > centralized NAT and Firewall Traversal scheme, why not let him?

[suresh] I too disagree with the requirement, but for a different reason. I
beleve, the requirement is that P2P nodes should be able to traverese the
FW/NAT devices enroute. Why should the functionality of NAT/firewall traversal
servers be distributed to the end-points? And, why is this a requirement?

I do not see why services required for P2P shoudl be mandated as part of P2P
end nodes.

> SIP-based network and still being marketed as P2P:)

[suresh] I think, it woudl be a good idea to draw a picture to contrast between
a traditional SIP network and a P2P SIP network. Endpoint Identity and location
of P2P nodes (and the associated service) is the key distinction, in my
opinion. 

> requirement. 

[suresh] I agree, NAT and firewall traveral is a key requirement for P2P
overlay.

>              There are two requirements in this section. I think one

[suresh] The above requirement is disctinct from R1, in my opinion. I woudl not
suggest eliminating R1. R2 above is similar to Req-3 in
<draft-ford-behave-app-01.txt>, which talks about design guidelines for P2P
applications in the context of NAT traversal.  

> The other option is to include this section as a subsection of 4.1.

[suresh] Please see my comment earlier about rewording R1.

> guess the 'can' should be changed to 'might'.

[suresh] That sounds good.

> the sections will be helpful.

regards,
suresh

---

From: dhara at research.avayalabs.com (K. Kishore Dhara)
Date: Sun Nov 6 10:32:03 2005

Philip,

Thanks for your comments.  My comments inline.

>Firewall Traversal distributable, but I think you have already covered
I agree with you that the general requirement 4.1 should subsume 4.3 R1.

>implication, and suggest that the first sentence be reworded or simply
You are right, we don't mean to imply that voicemail is preferred as a 
centralized service.  Sure, we will reword it to avoid ambiguity.

>Isn't this the same as requirement 4.3??
As I see it, 4.3 is a general requirement on the P2P protocol 
maintenance to accommodate different DHT algorithms and 6.1 is the 
specific ability of  the protocol to incorporate requirements (?) of P2P 
service providers, which might include things other than the  
maintenance of P2P structure.  I agree with you that the section 
headings for 4.3 and 6.1 are misleading.

Thanks.

Regards,
-- Kishore