[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [P2PSIP] New version of draft-ietf-p2psip-base
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
Song Haibin wrote:
>> -----Original Message-----
>> From: Cullen Jennings [mailto:fluffy at cisco.com]
>> Sent: Monday, October 26, 2009 11:46 PM
>> To: Song Haibin
>> Cc: P2PSIP WG
>> Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base
>>
>>
>> On Oct 26, 2009, at 3:32 , Song Haibin wrote:
>>
>>> 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?
>> 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.
>>
>
>>> 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.
>> 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.
>>
>>> 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.
>> 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.
>>
>>> 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.
>> 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
>>
>>> 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.
>> 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.
>>
>>> Thanks!
>>> Haibin
>> Thanks for reviewing it - much appreciated.
>>
>> Cullen <in my individual contributor role>
>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: p2psip-bounces at ietf.org [mailto:p2psip-bounces at ietf.org]
>>>> 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
>>>>
>>>>
>>>> On 10/23/09 2:38 PM, "Cullen Jennings" <fluffy at cisco.com> wrote:
>>>>
>>>>> 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>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> P2PSIP mailing list
>>>>> P2PSIP at ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>>
>>>> _______________________________________________
>>>> P2PSIP mailing list
>>>> P2PSIP at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>>
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP at ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip