Subject: [P2PSIP] New version of draft-ietf-p2psip-base

From: Cullen Jennings <[email-masked]>
Date: Fri, 23 Oct 2009 12:38:38 -0600

We just submitted a new version of the base draft at

http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt

(there is a new version of the sip-usage as well).

The major changes are mostly a very long and excruciating editorial  
pass to try and improve the grammar.

At this point, I don't know of any significant issues that need to be  
resolved. I think the draft is ready for WGLC.

I'm sure that during WGLC some major issues will come up, some  
important decisions will be made about what needs to be mandatory and  
such, and we will find several small inconsistencies and typos in the  
draft as well as things that need a clearer explanation. This will  
take some time and I expect multiple more revisions for this draft  
before it is published, however, I do think this is the right time to  
start WGLC. Lets get the issues on the table and then we can start  
resolving them.

Thanks,
Cullen <in my individual contributor role>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 23 Oct 2009 14:54:57 -0400

<as chair>
If you think the draft is missing something big, or has some other serious
shortcoming that makes it inappropriate to hold a WGLC, please speak up now.
We'll give everyone a few days to look over this version, and then decide if
we will start it.

If you had signed up to review NOW would be the time to do it, on this
version.  That was NOW, and not "soon", please.

Brian

On 10/23/09 2:38 PM, "Cullen Jennings" <[email-masked]> wrote:

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

---

From: Song Haibin <[email-masked]>
Date: Mon, 26 Oct 2009 10:32:16 +0800

Hi,

I have not finished the review, but I have several questions on this
document.

1).  I am not sure how the TRUN usage defined in this document will work
well. Who will be responsible for calculating the turnDensity and how? How
to update the TURN server information in the overlay when some TURN servers
leave the overlay suddenly, to aovid getting the "old" information?

2). In section 4.1.1 "Storage Permissions" said "RELOAD addresses this issue
by only allowing any given node to store data at
   a small number of locations in the overlay, with those locations being
determined by the node's certificate." This rule will limit the applications
that the protocol could support. E.g, for streaming or file-sharing
applications, it is very practical to put the resource providers' address
information under the same Resource ID which is the hash of the content
name, despite the node ID or username information contained in the
certificate of the resource provider.

3). How do you prevent "via list" being modified by the intermediate peers?
This is very important because it is related to whether you can get a right
returen path for your response.

4). In section 5.4.2.4.2., RouteQuery response should at least include a
next hop peer infomation if you want to use this message for the iterative
routing. 

5). I'm not sure about the necessity of access control policies in section
6.3. I think it will make sense only when these access control policies are
generic to all usages that will be built on top of RELOAD. Other than that,
I would suggest to remove this section and define these policies in each
usage document. Comment 2 is also related to this topic.

Thanks!
Haibin

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Brian Rosen
>Sent: Saturday, October 24, 2009 2:55 AM
>To: Cullen Jennings; P2PSIP WG
>Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base
>
><as chair>
>If you think the draft is missing something big, or has some 
>other serious shortcoming that makes it inappropriate to hold 
>a WGLC, please speak up now.
>We'll give everyone a few days to look over this version, and 
>then decide if we will start it.
>
>If you had signed up to review NOW would be the time to do it, 
>on this version.  That was NOW, and not "soon", please.
>
>Brian
>
>

---

From: jc <[email-masked]>
Date: Mon, 26 Oct 2009 01:14:30 -0400

> certificate of the resource provider.

This is how the BitTorrent DHT works and it's sloppy and insecure. To  
solve this problem you could create an extension such as Multicast  
groups in Overlay networks.

I've implemented the following algorithm, it works and is fairly  
heavily tested.

http://dks.sics.se/pub/mcastposter.pdf

Julian

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Oct 2009 16:46:03 +0100

On Oct 26, 2009, at 3:32 , Song Haibin wrote:

> well. Who will be responsible for calculating the turnDensity and how?

The idea was to specify the minimal simple thing and allow for much  
more advanced things to be developed in the future. Right now, the  
operator of the DHT would specify the turnDensity - they could  
presumable measure by probing the overlay. Keep in mind the two  
interesting values for overlays are no one is a TURN server and  
everyone is a TURN server.

> How
> leave the overlay suddenly, to avoid getting the "old" information?

The data times out and goes away and and this is part of the reason  
for finding a bunch.

> certificate of the resource provider.

Sure, but without this rules peers are would have to store an  
unlimited amount of data on behalf of others. A key premise of this  
work since before the WG was charter was that the protocol should be  
possible to use in a way where one could deploy a overlay for some  
application usage and not have it become used for file sharing. Note  
that if the overlay wants to allow kinds that have no authorization  
rules and allow anyone to write anywhere, there is nothing the spec  
that forbids that. It's up to the usage. So if someone wants to make a  
file-sharing usage, well storing the whole file in the DHT is probably  
not the best design but one could certainly make a usage that did  
exactly that.

> returen path for your response.

Well we can't really secure this in any practical way, or more  
importantly, we can  prevent the intermediate peers from misrouting  
the request. The misroute of the response is no more serious than the  
misroute of the request. It's a pretty fundamental limitation of an  
overlay system like this. However, the overlay security of the system  
does not depend on stopping this. This can be used to DOS the systems  
but not much else. Keep in mind, the same is true of IP that is  
running over.

> next hop peer infomation if you want to use this message for the  

Agree this is needed but it is somewhat DHT specific. I forget the  
details but I think it was Salman who pointed out that for some  
unstructured overlays, you would need something other than the next  
hop. Because of that, we made the answer DHT specific. For the Chord  
DHT specified here, 100% agree with you we need the next hop and the  
message to return that is defined in Section 9.8

> usage document. Comment 2 is also related to this topic.

Clearly many usage documents can share many of the basic policies so I  
think it make more sense to define at least the ones needed for the  
charter of this WG in the base draft.

> Haibin

Thanks for reviewing it - much appreciated.

---

From: Song Haibin <[email-masked]>
Date: Tue, 27 Oct 2009 17:37:22 +0800

>From: Cullen Jennings [mailto:[email-masked]] 
>Sent: Monday, October 26, 2009 11:46 PM
>To: Song Haibin
>Cc: P2PSIP WG
>> 1).  I am not sure how the TRUN usage defined in this document will 
>> work well. Who will be responsible for calculating the 
>turnDensity and 
>> how?
>
>The idea was to specify the minimal simple thing and allow for 
>much more advanced things to be developed in the future. Right 
>now, the operator of the DHT would specify the turnDensity - 
>they could presumable measure by probing the overlay. Keep in 
>mind the two interesting values for overlays are no one is a 
>TURN server and everyone is a TURN server.
>

In that case, the turnDensity is really dynamic, especially in an overlay
with high churn rate and there are few TURN servers in the overlay. A TURN
server has to register its information to the overlay with different times
when the turnDensity changes. Does it need to delete some copies of its
information or register more copies when the turnDensity changes? I don't
think this discovery mechanism in the document is mature to implement.

Haibin

>> How
>> to update the TURN server information in the overlay when some TURN 
>> servers leave the overlay suddenly, to avoid getting the "old" 
>> information?
>
>The data times out and goes away and and this is part of the 
>reason for finding a bunch.
>

>> 3). How do you prevent "via list" being modified by the 
>intermediate  
>> peers?

---

From: Jouni Mäenpää <[email-masked]>
Date: Tue, 27 Oct 2009 12:33:06 +0200

Hi Haibin,

> In that case, the turnDensity is really dynamic, especially in an
> overlay with high churn rate and there are few TURN servers in the
> overlay. A TURN server has to register its information to the overlay
> with different times when the turnDensity changes. Does it need to
> delete some copies of its information or register more copies when the
> turnDensity changes? I don't think this discovery mechanism in the
> document is mature to implement.

In the following draft that we submitted last week:

http://www.ietf.org/id/draft-maenpaa-p2psip-service-discovery-00.txt

we are proposing a generic service discovery mechanism for RELOAD. As
indicated in the RELOAD base draft, RELOAD currently defines a
TURN-specific service discovery mechanism, but is lacking a generic
mechanism for service discovery. So if you are interested in an
alternative, more generic service discovery mechanism, you could have a
look at our draft.

Regards,
Jouni