Subject: [p2p-sip] Comments to Concepts and Terminology for P2PSIP draft

From: jani.hautakorpi at ericsson.com (Jani Hautakorpi (JO/LMF))
Date: Mon, 17 Jul 2006 14:46:09 +0300

Hi all,

I read the Concepts and Terminology for P2PSIP draft, and I though that
the draft was quite good. However, I believe that the draft could be
somewhat polished.

You can find my comments/findings from the following diff-file:
   http://users.piuha.net/jantzgu/temp/p2psip-concepts-00--diff.html

Same comments are also listed here (sorted by sections):
First page:
-  s/Byran/Bryan/
2. Definitions:
- Definition of "Overlay Network" and "P2P Network" are taken directly
   from wikipedia. Maybe a bit better definitions would be in order.
- There's no definition for "P2PSIP" itself, and I think it would be
   good to include it.
- How does a "P2PSIP Overlay User Agent differ from a traditional SIP
   UA? Is there a need to make a distinction between the two?
- The "P2P Overlay Network" is a bit ambiguous, because it is not
   defined in this draft
- s/via ,/via,/
- Is there a need to make a distinction between the "User Record" and
   "User Routing Record"?
- It is not very clear what kind of an address this User Routing Record
   contains. Does it contain an IP address, SIP URI, or some other
   address?
- The draft at its current stage talks about "Resources" and about
   "Users". I believe that it would be good to talk mainly about
   "Resources" and only mention that "User" is one form of a "Resource".
   What do you think?
3.2. Reference Model:
- I felt that the figure didn't really represent the text in the draft
   too well. I tried to draw a figure which would match the text (in my
   opinion), see the figure in the diff-file.
3.3.3. Enrolling a User and Inserting a P2PSIP Overlay User Agent:
- s/client/client or a peer/
3.3.5. Bootstrapping:
- The existence of Clients create a requirement for bootstrapping
   procedure. That is, it would be good if bootstrapping procedure would
   be able to return a Peer from a relatively large pool of online Peers.
4.10. Peer-Adjacency Through NATs:
- This could be section 4.8, because this is probably related to the
   section 4.7.
4.11. Peer and Client Enrollment Protocols:
- There is one related question: "How to do admission control in
   practice?"

It would be nice if my comments/findings would initiate some
counter-comments/discussion in this mailing list.

-- 
Regards,
Jani Hautakorpi
Ericsson Research

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 18 Jul 2006 19:08:04 -0500

> the draft was quite good. However, I believe that the draft could be
Thanks.,I agree.

> Same comments are also listed here (sorted by sections):

oops.

>   from wikipedia. Maybe a bit better definitions would be in order.

I'm game. Send text?

> - There's no definition for "P2PSIP" itself, and I think it would be

ok.

>   UA? Is there a need to make a distinction between the two?

A P2PSIP Overlay User Agent also includes a P2PSIP Overlay Peer or  
P2PSIP Overlay Client that might (assuming the client protocol is not  
plain SIP) be present in a regular SIP UA.

> - The "P2P Overlay Network" is a bit ambiguous, because it is not

Hmm. Need to delete the word "Network" in the above.

> - s/via ,/via,/

ok

> - Is there a need to make a distinction between the "User Record" and

Well, it seemed reasonable at the time. There might be USer Records  
that are not routing records. The text says:

    P2PSIP Overlay User Record: A block of data, stored in the data
       mechanism of the P2PSIP Overlay, that includes information
       relevant to a specific user.  We presume that there may be
       multiple types of user records.  Some may describe routes to a
       client at which the user is presumed reachable (a "user routing
       record", like a SIP "Contact:").  Others might store presence
       information.  The types, usages, and formats of user records  
are a
       question for future study.

So, one might envision something like a P2PSIP Overlay User Presence  
Record that contains presence, not routing information.

>   contains. Does it contain an IP address, SIP URI, or some other

We don't know yet. My presumption is that it contains a SIP route  
vector. I might be wrong.

>   "Resources" and only mention that "User" is one form of a  

I stared with that approach and got overruled b Eunsoo and others so  
I'll let them defend the choice.

The "P2PSIP Overlay Resource Enrollment" defnition is probably an  
artifact and might could just be removed if we stay with the "all  
resources are users" model.

>   opinion), see the figure in the diff-file.

You're probably right but my brain doesn't parse your figure. Curved- 
lines in ASCII art all look like naked butterfly pictures or  
something to me, but they don't look like lines.

> - s/client/client or a peer/

ok

>   be able to return a Peer from a relatively large pool of online  

That's a valid approach, but may not be the only possible one.

> - This could be section 4.8, because this is probably related to the

You mean just re-order the sections?

> - There is one related question: "How to do admission control in

Use RSVP?

> counter-comments/discussion in this mailing list.

Yes, it would.

--
Dean

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Wed, 19 Jul 2006 11:26:11 +0200

> I'll let them defend the choice.

The main difference between users and resources is that the formers have
unique identifiers (e.g. sip:alice at example.com), while the latters share
sort of "category identifiers" (e.g. urn:service:data-relay.turn).  I
think that, at least at the moment, we should keep them distinct.

> resources are users" model.

Actually the draft defines enrollment distinct for peers and resources,
not for resources and users.  Perhaps such an artifact could be
introduced, until we better understand the relationship between users
and resources.

Enrico

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 19 Jul 2006 13:15:20 -0500

> introduced, until we better understand the relationship between users

The intent of the current draft is that resources == users. i.e. they  
are synonymous terms, and all have unique identifiers within the  
overlay.

There may be a separate requirement for "classes" of resources, like  
"resources that are media relays" or "resources that are in Dallas".

Of course, this intent is subject to debate -- it should probably  
become an "open issue" in the document, unless we get a stronger  
consensus Real Soon Now.

--
Dean

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 19 Jul 2006 16:55:07 -0400

> become an "open issue" in the document, unless we get a stronger  

Below is my understanding about the terms 'resource', 'user', and
'enrollment'.

'resource' is a term used with many different meanings. Probably it has
been used different in the SIP context and P2P contexnt.
SIP UAs and media relays are resources in SIP context.
CPU time or disk storage can be a resource in P2P context.
We say a P2P network or a DHT provides resource lookup. Let say Alice
looks up Bob (actually bob at example.com)'s location. The lookup request
returns a record that contains Bob's location, i.e., IP address and port
number. Is the location record a resource as well or just a pointer to a
resource? Yes for both, I think. Or is a pointer to a resource another
type of resource itself? I think it is. If Bob looks for a message from
Alice that is stored in the P2P network,  is the message a resource? I
think it is. We can see there can be many types of resources.

But some need to have SIP URIs (or AORs) but others not. For example, a
location record does not have to have a SIP URI. It is useful to
distinguish these two categories: those identified by SIP URIs and those
not. It is useful especially when SIP URIs should be claimed only with
permission (or a right to a name) from a possibly central authority. The
process to get a right to a name is 'enrollment'. The draft calls those
with SIP URIs 'users'. In this sense, 'resource enrollment' is too
broad, I think, We should use just 'user enrollment' rather than
'resource enrollment'. For some resources like a stored message for Bob
or Bob's location record do not require enrollment. Just signature by
who generated the message or record should be enough.

Thanks.

Eunsoo

---

From: jani.hautakorpi at ericsson.com (Jani Hautakorpi (JO/LMF))
Date: Thu, 20 Jul 2006 10:57:39 +0300

Hi Dean,

> plain SIP) be present in a regular SIP UA.

Maybe I got this wrong, but I understood that an Overlay UA doesn't 
*include* an Overlay Peer. I understood it in a way that Overlay UA can 
be co-located in a same node with an Overlay Peer, and that Overlay UA 
can *use* Overlay Peer.

I'm still not convinced that we need to make a distinction between an 
Overlay UA and a regular SIP UA. I see this in a way that the Client and 
Peer protocols can be non-SIP/extended-SIP/whatever protocols, but the 
protocol between the (Overlay) UA and Client/Peer could be plain SIP. At 
least at the moment I would see this approach as an easy way to connect 
regular UAs to P2PSIP network. What do you think?

> Well, it seemed reasonable at the time. There might be USer Records that 
> are not routing records. The text says:
> 
>   ...
> 

Yes, there can be different User Records, but I'm not sure whether this 
draft should try to define them all, or should this draft define only 
"P2PSIP User Record" and let some other draft enumerate all the 
different User Record types and their structures. Any opinions?

> You're probably right but my brain doesn't parse your figure. 
> Curved-lines in ASCII art all look like naked butterfly pictures or 

The curved-lines aren't naked butterflies, they represent an edge of a 
cloud instead. But if you like the figure otherwise, I can replace ~s 
with the character of your choice. :-)

> That's a valid approach, but may not be the only possible one.

Maybe, but what I meant was that maybe something like the following 
could be appended to section 3.3.5?

   Bootstrap servers should be able to return an address of a Peer to a
   Client from a relatively large pool of Peer addresses. This is because
   otherwise load distribution would be insufficient, and some Peers
   might get overloaded.

> You mean just re-order the sections?

Yes (it doesn't really matter, this was just an observation).

>> - There is one related question: "How to do admission control in

:-) What I had in mind was that maybe something like "Do we need a 
mechanism for preventing unauthorized nodes from accessing a P2PSIP 
Overlay?" could be appended to section 4.11?

-- 
Jani

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Thu, 20 Jul 2006 18:01:20 +0200

Dean Willis wrote:
> are synonymous terms, and all have unique identifiers within the overlay.
> 

I don't have clear ideas about this.

We could define "classes" _of_ resources, in which case we then need to
have distinct policies for each class.  For example, the "list"
operation should be allowed for the "media relays" class, but not for
the "users" one.

On the other hand, we could have "classes" _as_ resources.  In this case
it would be important that, for example, only Alice was able to register
her UAs' contacts for the resource "sip:alice at example.com" (that she had
enrolled before), while anyone was able to register contacts for the
resource "media relay class".

Anyway, "being in Dallas" seems more an attribute than a class (even if
it is always possible to define such a class); just to be clear,
attribute-based search is out of scope, right?

> Of course, this intent is subject to debate -- it should probably become
> an "open issue" in the document, unless we get a stronger consensus Real
> Soon Now.

My "hum" is for "open issues" :-)

Enrico

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Thu, 20 Jul 2006 14:28:17 -0400

> be co-located in a same node with an Overlay Peer, and that Overlay UA

Below is what I understand and suggest.
There is no such thing like an Overlay UA that is not co-located with a
Client or a Peer.
If a UA exists without being coupled (i.e. not co-located) with a Client
or a Peer, it is just a plain SIP UA.
If a UA is coupled (co-located) with a Client or a Peer, it is a P2PSIP
Overlay UA.

> protocol between the (Overlay) UA and Client/Peer could be plain SIP. 

There is no protocol between an Overlay UA and a Client/Peer. There is
no need. For an Overlay UA can/will just invoke the function calls of
the API provided by the Client/Peer.

It does not make a sense to define a protocol between a plain (C/S) SIP
UA and a Client/Peer either. In a sense, they are in different
sublayers. If we want to let a C/S UA use the service of the overlay
network, the C/S UA should talk to a SIP Proxy node that is a Client or
a Peer. Apparently the protocol between the C/S SIP UA and the (P2P)SIP
Proxy is just SIP.

At
> different User Record types and their structures. Any opinions?
I agree that this draft needs to show the concept but not list all the
record types.
Even in the case, isn't it OK to mention a couple of or a few  record types?

> with the character of your choice. :-)
Somehow I don't see ~s. Where do you see them?
>   otherwise load distribution would be insufficient, and some Peers
It is a desirable characteristic for a bootstrap server.
Do we have to talk in that level in this draft?

> Overlay?" could be appended to section 4.11?
A good point.

Thanks.

Eunsoo

---

From: jani.hautakorpi at ericsson.com (Jani Hautakorpi (JO/LMF))
Date: Fri, 21 Jul 2006 14:04:57 +0300

Hi Eunsoo,

> There is no such thing like an Overlay UA that is not co-located with a

Ok, I re-read the definition of an Overlay UA, and it clearly says what 
you just said. Maybe it's a good idea after all to define the Overlay UA.

> Even in the case, isn't it OK to mention a couple of or a few  record types?

Personally I think it's a bit confusing, but I don't have any strong 
opinions about this.

> Somehow I don't see ~s. Where do you see them?

They are in the 'alternative' figure in (actually, now I can see the 
butterfly too):

> Do we have to talk in that level in this draft?

I might be a good idea to mention it, because the fact the there are 
Peers *and* Clients create this 'requirement'.

-- 
Jani

PS: I'll be on vacation for weeks 30-33.

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Fri, 21 Jul 2006 13:27:03 -0500

On Jul 20, 2006, at 2:57 AM, Jani Hautakorpi (JO/LMF) wrote:

>> P2PSIP Overlay Client that might (assuming the client protocol is  
>> not plain SIP) be present in a regular SIP UA.
>
> *include* an Overlay Peer. I understood it in a way that Overlay UA  
> can be co-located in a same node with an Overlay Peer, and that  
> Overlay UA can *use* Overlay Peer.
>
> I'm still not convinced that we need to make a distinction between  
> an Overlay UA and a regular SIP UA. I see this in a way that the  
> Client and Peer protocols can be non-SIP/extended-SIP/whatever  
> protocols, but the protocol between the (Overlay) UA and Client/ 
> Peer could be plain SIP. At least at the moment I would see this  
> approach as an easy way to connect regular UAs to P2PSIP network.  
> What do you think?
>

I think I'll go with Eunsoo's answer earlier in this thread.

>> Well, it seemed reasonable at the time. There might be USer  
>> Records that are not routing records. The text says:
>>   ...
>> So, one might envision something like a P2PSIP Overlay User  
>> Presence Record that contains presence, not routing information.
>
> Yes, there can be different User Records, but I'm not sure whether  
> this draft should try to define them all, or should this draft  
> define only "P2PSIP User Record" and let some other draft enumerate  
> all the different User Record types and their structures. Any  
> opinions?

We may well have definitions for things that are not specified in  
detail by the group --  that is, we can have definitions that are  
used to describe things that are "out of scope".

>> Curved-lines in ASCII art all look like naked butterfly pictures  
>> or something to me, but they don't look like lines.
>
> The curved-lines aren't naked butterflies, they represent an edge  
> of a cloud instead. But if you like the figure otherwise, I can  
> replace ~s with the character of your choice. :-)
>

It MIGHT be ok, but I'm really having a hard time grokking the  
presentation. Maybe a real vector-format version of the drawing would  
make more sense to me. As it is, I'm not sure you've really captured  
the NAT-traversal aspects that Philip worked into the existing  
drawing at some effort.

>   otherwise load distribution would be insufficient, and some Peers

That's one design alternative, and it has merit, but it might be  
premature to specify that sort of requirement at this stage.

> Yes (it doesn't really matter, this was just an observation).

Ok, I think we could do that.

> Overlay?" could be appended to section 4.11?

Ah! Very different from what I think when I hear "admission control",  
which is in my rather twisted world-view a QoS related question. It  
seems like a reasonable question (and the answer is probably "Duh!  
YES"). Send text, and I'll paste it into the working rev of the draft.

--
Dean