Subject: [P2PSIP] Terminology - no WG names

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Apr 2008 15:33:38 -0400

In writing the revised draft, I took another look at the terminology  
document. In general, I think it's a really bad idea to label terms  
with the working group name. The name will be meaningless to non-IETF  
participants, i.e., 99% of developers, and will cease to have any  
meaning once the working group fades from memory. (I don't think  
P2PSIP wants to become another DHC or AVT WG...) In addition, the  
prefix doesn't really define anything, except recursively whatever the  
working group decided to work on. Thus, a P2PSIP overlay is the  
overlay defined by the P2PSIP working group, which is...

For example, I would suggest

resource discovery overlay

for our main work item.

On a related note, I would also suggest changing 'peer ID' to 'node  
ID', since we seem to have some agreement that clients, as future  
peers, would be identified by the same construct. But saying "a client  
has a peer ID, but isn't a peer" doesn't seem to further understanding.

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

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 23 Apr 2008 15:51:17 -0400

Inline

>  resource discovery overlay

Not a bad idea, from my perspective. I think early on we did it to
distinguish what we talking about from the more general term, but
eliminating the P2PSIP labels sounds ok to me. Interested to see what
others think.

>  has a peer ID, but isn't a peer" doesn't seem to further understanding.

There was a very long discussion about peer vs. node, and the
consensus was that the literature preferred peer to node. I know way
back, in the very first P2PSIP draft submitted, I used node
everywhere, and actually preferred it to peer. When we decided to
change it, I did so in all my drafts. I actually think this is one of
those where we could argue all day back and forth about it, and the
discussion would be "Full of sound and fury, signifying nothing". I
don't really care from a technical perspective, but I'd be willing to
bet $10 we could spend many more hours debating it, and someone would
still bring it up and propose to flip it again in 6 months (and
possibly with good, reasons too -- it's just there are good arguments
on both side).

I'd vote to just recognize language is an imperfect tool to express
ideas and leave it alone.

As an aside, I would think a client having a peer-id makes perfect
sense if the reason it has it is that it could conceivably be a peer
in some context. It is is "latent" peer-ID, in that case, ready to be
used if it becomes one. I don't really see the conflict.

David (as individual)

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Wed, 23 Apr 2008 23:01:14 +0200

Hi,

>  eliminating the P2PSIP labels sounds ok to me. Interested to see what

I agree on using no P2PSIP labels and suggest that we use P2P
terminology common in the technical literature.

Thanks,
-- 
Victor Pascual Ávila

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 23 Apr 2008 17:16:02 -0400

Most of the terms were very carefully picked to match the technical
literature as much as possible. That said, the literature sometimes is
not consistent between different papers...

I agree we should try to reflect the literature, and believe that we
for the most part do in the current draft (

David (as individual)

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 23 Apr 2008 17:59:02 -0500

I suppose a good start would be to agree on some reference sources on P2P,
for example:

* Wikipedia has an excellent P2P tutorial section with well known references

http://en.wikipedia.org/wiki/Peer-to-peer

* The openDHT publications

http://opendht.org/pubs.html

Just these two sources would be a good start, though folks on the list may
well have additional sources to suggest.

What this discussions proves however is that instead every I-D in the P2PSIP
WG having its own glossary, the WG should better invite someone to write a
glossary paper on its own that can be discussed and agreed on. This was not
in the charter, but may be a good option, given the work involved.

Another option is for the terminology paper by Dean Willis et al. to be
updated with an updated and comprehensive glossary for P2P.

What do you think?

Henry

---

From: "Montpetit Marie-Jose-MGIF0300" <[email-masked]>
Date: Wed, 23 Apr 2008 19:21:32 -0400

I may be late but I agree with the proposal. The resource discovery is
essential as not all nodes are the same and some could be more
appropriate for certain task (storage vs computation vs rendering). I
also agree on node vs peer - actually some nodes could be involved in
P2P and non P2P relationships. Finally while I have no personal problem
with P2PSIP I know people who do.

/mjm 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Schulzrinne
Sent: Wednesday, April 23, 2008 3:34 PM
To: P2PSIP Mailing List
Subject: [P2PSIP] Terminology - no WG names

In writing the revised draft, I took another look at the terminology
document. In general, I think it's a really bad idea to label terms with
the working group name. The name will be meaningless to non-IETF
participants, i.e., 99% of developers, and will cease to have any
meaning once the working group fades from memory. (I don't think P2PSIP
wants to become another DHC or AVT WG...) In addition, the prefix
doesn't really define anything, except recursively whatever the working
group decided to work on. Thus, a P2PSIP overlay is the overlay defined
by the P2PSIP working group, which is...

for our main work item.

On a related note, I would also suggest changing 'peer ID' to 'node ID',
since we seem to have some agreement that clients, as future peers,
would be identified by the same construct. But saying "a client has a
peer ID, but isn't a peer" doesn't seem to further understanding.

Henning

---

From: Dan York <[email-masked]>
Date: Wed, 23 Apr 2008 21:27:01 -0400

> eliminating the P2PSIP labels sounds ok to me. Interested to see what

DY> +1  Makes sense to not have the WG label in there.
> possibly with good, reasons too -- it's just there are good arguments

DY> With P2P in general getting more attention these days, has the  
literature changed at all in relation to 'peer' vs 'node'?

DY> I would be inclined to agree with your original usage. To me,  
"node" merely indicates that a device/program/whatever is a connection  
point on a network (or network overlay), while "peer" implies a  
"relationship" between the device/program/whatever and other similar  
objects.

DY> "Node" to me does not have the relationship baggage. It just "is".

DY> However, I can also see where this could very easily go down a  
semantic rathole and be one of those things that could consume  
zillions of electrons and hours of our time debating.

DY> I agree with Henry that a centralized glossary makes sense, but  
I'm a little bit confused - isn't that what the 'concepts' document is  
supposed to be? ( http://tools.ietf.org/html/draft-ietf-p2psip-concepts-01 
  ) While Henning did not explicitly state the draft he was referring  
to, I assumed it was this one.

Regards,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

---

From: Song Haibin <[email-masked]>
Date: Thu, 24 Apr 2008 10:26:04 +0800

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Dan York
>Sent: Thursday, April 24, 2008 9:27 AM
>To: David A. Bryan
>Cc: P2PSIP Mailing List
>Subject: Re: [P2PSIP] Terminology - no WG names
>
>

[Song] +1 Agree, although I don't think "resource discovery overlay" is an
appropriate term for p2p overlay.

>zillions of electrons and hours of our time debating.

[Song] Both "peer" and "node" are okay with me.

>to, I assumed it was this one.

[Song] I think the concept and terminology draft is a centralized glossary
for the WG. If there are divergent opinions on the terminology, we should
discuss them in the mailing list or at the WG meeting, and the authors
should update the terminology draft according to the consensus.

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 23 Apr 2008 23:27:02 -0400

I also agree to dropping the WG name from the names of the terms.
Since we distinguish Peers from Clients, changing 'Peer ID' to 'Node
ID' is a good idea since it makes sense to assign an ID to a Client
and there is no reason to distinguish Client IDs and Peer IDs.

Regarding P2P glossary, I don't think the intention of the concept and
terminology draft was to write a comprehensive P2P glossary document.
The initial objective was to do a ground work to help defining the
charter and thus the authors initially tried to focus on terms and
concepts relevant to defining the charter. Now the draft should
provide an overview of the key concepts and frequently used
terminology. It is probably not easy to say when the collected
terminology is comprehensive. Maybe we can try to extend the
terminology section in the current concept and terminology draft to
cover most terms frequently used in P2P literature and draft submitted
in the WG.

Thanks.

Eunsoo

-- 
Eunsoo

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Apr 2008 05:15:01 -0400

> appropriate term for p2p overlay.

Why not? If not, please suggest a better alternative.

> should update the terminology draft according to the consensus.

That's the point of my email :-)

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Apr 2008 05:18:12 -0400

Henry,

I appreciate the pointers, but there is no agreement for many of these  
terms in the literature or the terms are very specific to either a  
particular class of resource discovery systems (such as structured/DHT  
ones) or an algorithm. I think everyone would like to use existing  
terminology as much as possible.

Henning

On Apr 23, 2008, at 6:59 PM, Henry Sinnreich wrote:

>>> On Wed, Apr 23, 2008 at 9:51 PM, David A. Bryan <[email-masked] 
>>> >
>>> wrote:

---

From: Song Haibin <[email-masked]>
Date: Thu, 24 Apr 2008 18:05:52 +0800

>From: Henning Schulzrinne [mailto:[email-masked]]
>Sent: Thursday, April 24, 2008 5:15 PM
>To: Song Haibin
>Cc: P2PSIP Mailing List
[Song] I think most p2p overlays, no matter structured or unstructured, are
used for resource discovery, e.g. file sharing, p2p VoIP and etc. I feel
that if we use the term "resource discovery overlay" for now used "P2PSIP
Overlay", we do not distinguish the application "SIP" from other
applications. I don't know if we need the term "P2PSIP Overlay", or we just
need a "P2P Overlay". For P2PSIP, we may just call it "SIP Over P2P".

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 24 Apr 2008 12:08:15 -0500

Henning,

>I think everyone would like to use existing

Can you point us to some?

Thanks, Henry

---

From: Dean Willis <[email-masked]>
Date: Thu, 24 Apr 2008 12:29:29 -0500

> updated with an updated and comprehensive glossary for P2P.

Sure -- bring vocabulary words to the list, and once we have agreement  
on what they mean, we'll stick 'em into the draft.

That might not be as easy as we think, and it's part of why everything  
currently has a "p2psip" label in front of it.

A P2PSIP overlay is not a BitTorrent overlay. For example, there's no  
concept of discretely bounded namespaces in BitTorrent.  And as far as  
I know, BitTorrent has no concept of "resource discovery" -- we use  
web sites to distribute the resource keys. But we still think of  
BitTorrent as P2P and an overlay . . .

So some of our terms are going to have names that are used in other  
literature to mean something that's not quite exactly the same thing.  
As long as we have them prefixed with "p2psip", it's clear that we're  
referring to "our" definition.

Presumably, we understand this and can drop the "p2psip" part from the  
names, but still know it is there.

But eventually some joker is going to pop up and say "You can't call  
this thing a Node, because a Node is another name for a Peer, and it's  
not a Peer, it's a Client" or some such, and I'm going to have to hit  
him with a blunt object. That's more-or-less already happened, and the  
blunt object we used was the concepts draft, with its mind-numbing  
repetition of the "p2psip" modifier.

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Apr 2008 15:59:32 -0400

That's a feature, not a bug :-) The core P2P protocol being designed  
does not depend on SIP, even though it naturally supports that  
application.

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Fri, 25 Apr 2008 00:39:24 -0400

Hi, all:

IMO, another important work is to make clear the assumptions of the future work, such as:
1. Which kinds of data will be stored in the overlay? what's the reasonable size of the data?

2. How much churn of the overlay where the peer protocol will be applied? The pratical way is to use the experimental data from the real existing system. I am not sure the resulting peer protcol could work in all cases. 

3. How much percent of the public nodes in the overlay is reasonable? 

IMHO, if we don't work it out before we come up with the protocol, I think, it's hard to get consensus on the proposal, because we have no common assumptions. 

Comments?

Regards
JiangXingFeng

> >  >>> ID', since we seem to have some agreement that clients, as 
> future>  >>> peers, would be identified by the same construct. But 
> saying "a
> >  >>> client
> >  >> possibly with good, reasons too -- it's just there are good 
> arguments>  >> on both side).
> >  >
> >  >"node" merely indicates that a device/program/whatever is a 
> connection>  >point on a network (or network overlay), while 
> "peer" implies a
> >  >"relationship" between the device/program/whatever and other 
> similar>  >objects.
> >  >
> >  >  ) While Henning did not explicitly state the draft he was 
> referring>  >to, I assumed it was this one.
> >
> >  discuss them in the mailing list or at the WG meeting, and the 
> authors>  should update the terminology draft according to the 
> consensus.>
> >
> >
> >
> >  >
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Apr 2008 03:10:21 -0400

> reasonable size of the data?

The only reasonable answers are: For the protocol: any and any. For a  
particular instance: whatever policy allows.

>
>
> 2. How much churn of the overlay where the peer protocol will be  
> applied? The pratical way is to use the experimental data from the  
> real existing system. I am not sure the resulting peer protcol could  
> work in all cases.

I don't think that is productive. We can't predict what churn is  
realistic, given that I can create networks with close to zero churn  
and networks with node lifetimes measured in seconds. As usual,  
performance and data availability will degrade as churn increases.

> 3. How much percent of the public nodes in the overlay is reasonable?

Anywhere from 0 to 100%. Again, a protocol design needs to be robust  
in these parameters; we're not designing a specific instance, but  
rather something that works across the Internet, present and future.  
Clearly, there will be configurations where nothing will work and  
things will work faster in 'nice' configurations, but that's about all  
we can say. Hopefully, our design will work as well as it can in any  
given circumstance.

>
>
> IMHO, if we don't work it out before we come up with the protocol, I  
> think, it's hard to get consensus on the proposal, because we have  
> no common assumptions.

I'm sorry to say that if this is required, we may as well fold now.