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:[email protected]] >> 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: [email protected] [mailto:[email protected]] >>>> 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" <[email protected]> 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
