Subject: [p2p-sip] work items we agreed on and not agreed on

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Wed, 14 Jun 2006 13:30:15 -0400

Eunsoo:

Thanks for the excellent summary.

Can we poll on this in this mailing list for the following topic before
the Dallas meeting, and present this result in the BoF to have the final
rough consensus?

<THINGS WE DID NOT MAKE A ROUGH CONSENSUS ON YET>

* P2PSIP Overlay Peer Protocol
      - GET,PUT,JOIN,LEAVE
      - Selection of the P2P algorithm (or DHT)

There are three positions about this.
       - We should select at least a DHT algorithm and design the Peer
Protocol for v1.0.
       - We should do it but postpone it after v1.0. (A variation of
this position suggests that, for v1.0, we assume multicast/broadcast
among Peers.)
       - We should not do this at all.

Best regards,
Radhika

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Eunsoo Shim
Sent: Wednesday, June 14, 2006 12:14 PM
To: P2P-SIP
Subject: [p2p-sip] work items we agreed on and not agreed on

As repeatedly stressed, we should focus on creating the WG and thus on
work items for the first charter.

There was a discussion about whether an IETF WG should design a system
or a set of tools. Jon Peterson suggested that the proposed P2PSIP WG
should focus on tools. I believe his view is widely accepted in the
group and I also agree with him. Eventually the IETF produces protocols
and developers and vendors use the protocols to design and build systems
.

We were requested to present our architecture(s) to explain what we are
going to do in the BOF in Dallas. But I believe the intention is to
explain what kind of tools we are going to produce using the
architectures but not to limit the architectures or systems that can use
the tools.

Maybe not fast as we have hoped, but I believe we have made meaningful
progresses. Below is my summary of our status in terms of consensus on
work items. There are other things like what protocol we will use for a
certain thing but we are not required to agree on those things or more
details of the tools/work items at this stage.

<THING WE MADE A ROUGH CONSENSUS ON>

We would build the following tools:
* P2PSIP Overlay Client Protocol
    - GET and PUT request/reply
* Types and formats of data to be stored and shared on the P2PSIP
Overlay Network for P2PSIP
    - There should be associated descriptions of how SIP can use the
defined data.
* Mechanism(s) to locate proximate STUN servers (TURN relay in a
different language)

For NAT Traversal, we agreed that NAT traversal should be considered
from the beginning and that STUN/TURN/ICE should and could be used for
P2PSIP but we would talk to the relevant WGs if we need anything new in
STUN/TURN/ICE.

For security, we agreed that the P2PSIP Overlay Network will typically
consist of users not trusted by each other and thus there should be
security mechanisms built into the protocols for P2PSIP.

For basic call setup, we agreed that the UAC retrieves the
location/contact/route information of the UAS from the P2PSIP Overlay
Network using the GET procedure and establishes the call following
RFC3261.

<THINGS WE DID NOT MAKE A ROUGH CONSENSUS ON YET>

* P2PSIP Overlay Peer Protocol
      - GET,PUT,JOIN,LEAVE
      - Selection of the P2P algorithm (or DHT)

There are three positions about this.
       - We should select at least a DHT algorithm and design the Peer
Protocol for v1.0.
       - We should do it but postpone it after v1.0. (A variation of
this position suggests that, for v1.0, we assume multicast/broadcast
among Peers.)
       - We should not do this at all.

Does this summary concur with what you think?

Thanks.

Eunsoo

_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 14 Jun 2006 23:12:10 -0700

>       - Selection of the P2P algorithm (or DHT)

[pp]: These two items should not be mutual dependent, as long as the
primitives (GET,PUT,...) are well abstracted to fit 2+ popular DHTs.

>        - We should select at least a DHT algorithm and design the Peer

[pp]: This option feels like WakeField's knuckle ball bobbled behind the
catcher, which strikes out those unlucky dogs who happen to have chosen
another DHT, and leaves their third-base runners in a dilemma of diving home
or not.

> this position suggests that, for v1.0, we assume multicast/broadcast

[pp]: Avaya and eBay cannot be happier with this option :)

>        - We should not do this at all.

[pp]: My ballot would favor this option if I'm allowed to vote. Though
well-abstracted primitives may not necessarily realize direct
interoperability between nodes of different DHTs, they hopefully can
facilitate interoperability between nodes of the same DHT types, as long as
DHT-dependency is avoided throughout the P2PSIP journey. That would be a
great boon to those unlucky dogs who choose the wrong side for different
technical belief but still care about protocol standardization. After all,
reflexly we all speak the same language -- SIP.

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 15 Jun 2006 16:52:10 -0400

> primitives (GET,PUT,...) are well abstracted to fit 2+ popular DHTs.
What do you mean by 'primitives'?
If they are API, I think we can define the API fairly independent of
underling DHTs.
The recent draft by Kundan and Henning (
http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-00.txt )
presents the point well.
If they are protocol (message formats and procedures), it was pointed
out that even GET and PUT procedures were likely to affected by the
underling DHTs. For example, replication is likely to depend on the DHT.
That's why GET and PUT were not separated from JOIN and LEAVE which are
obviously dependent on the underling DHT.

> DHT-dependency is avoided throughout the P2PSIP journey. 

Again I think we need to clarify what you mean by 'primitivies'.
Sharing the API does not enable interoperability.
We need interoperability in the level of message formats and procedures.
To specify the message formats and procedures, it is unavoidable to pick
a DHT algorithm.

Note: we are not talking about interoperation between different DHTs but
 just between nodes supporting the same DHT.

That would be a

Thanks.

Eunsoo

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Fri, 16 Jun 2006 08:35:19 -0700

> obviously dependent on the underling DHT.

[pp]: Sorry if I misuse it. By "primitives" I mean basic overlay operations
of "generic" DHTs, not of a specific DHT.

> To specify the message formats and procedures, it is unavoidable to pick

[pp]: Right. The primitives are not API but are procedures and messages of a
generalized protocol (eg. XML/RPC based) that lies above popular DHTs to
tunnel between P2PSIP nodes of *same DHT types*.

Regretfully I'm not sure at all whether such a "dream protocol" is possible.
If it is concluded as mirage, I agree a decisive ball is unavoidably
necessary for things here to move on (but also unavoidably callous for those
unlucky dogs to leave).

>  just between nodes supporting the same DHT.

[pp]: Well believed and appreciated for quite some time.

---

From: bryan at ethernot.org (David A. Bryan)
Date: Fri, 16 Jun 2006 11:38:50 -0400

I agree with Eunsoo's last couple of points here. My thought is that
if we do not select some sort of DHT, we can't (at least easily) have
nodes from different vendors working together, which personally I view
as the main reason to standardize things. Perhaps we could find
someway to allow nodes to use different DHTs and yet allow them to
fully interoperate, but I certainly can't imagine how.

The purpose of standardization is to allow things from different
vendors/open source implementations to interoperate in such a way that
they can at least communicate and (hopefully) that components from
different vendors can be combined in a deployment. It seems to me that
if we have a "standard" where each implementation meets it but uses a
different DHT and is thus an island, that isn't a "standard", it is a
blessing from the IETF on a proprietary technology or something, which
I don't think is really what we are here for.

If we don't standardize *how* the p2p nodes interact with each other,
it seems we are simply building islands. We can do that by having each
faction write a BCP in SIPPING about how each DHT works and be done
with it...no working group needed. I don't think that is really what
we had in mind. I would think we may standardize a small but greater
than 1 number of DHTs mind you, although I think we would have to see
compelling distinctions between the DHTs to want to do that, not the
sort of fractional speedups and nearly imperceptible algorithmic
tweaks that differentiate most of the DHTs today from one another.

My 2 cents.

David Bryan

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 20 Jun 2006 17:50:45 -0400

Sorry to be slow in replying. See below...

> [pp]: Avaya and eBay cannot be happier with this option :)

Well, I have not consulted with my fellow Avaya employees on this,
but I, for one, would like to see the peer-to-peer protocol standardized
as part of the initial charter.

- Philip