Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This new version addresses all my comments, and is really better at explaining
how Redir works.

Thanks.

On 02/23/2013 12:59 AM, Jouni Mäenpää wrote:
> Hi,
> 
> The comments below have now been addressed in version -08 of the draft. The
> changes in the new version include:
> 
> - The temporary local caching mechanism for RedirServiceProvider records
> fetched during a service lookup operation that is described below was added
> to the draft - The text was clarified further - New examples were added to
> clarify how ReDiR tree nodes are numbered and how intervals are assigned to
> tree nodes
> 
> Regards, Jouni
> 
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Jouni Mäenpää Sent: 18.
> helmikuuta 2013 21:25 To: Joscha Schneider Cc:
> [e-mail]; [e-mail] Subject: Re: [P2PSIP] WGLC
> for draft-ietf-p2psip-service-discovery-06
> 
> Hi Joscha,
> 
> Thanks for the comments! Answering the first comment inline, need some more
> time to check the second comment.
> 
> Regards, Jouni
> 
> -----Original Message----- From: Joscha Schneider
> [mailto:[e-mail]] Sent: 18. helmikuuta 2013 13:21 To:
> Jouni Mäenpää Cc: Marc Petit-Huguenin; [e-mail];
> [e-mail] Subject: Re: [P2PSIP] WGLC for
> draft-ietf-p2psip-service-discovery-06
> 
> two comments inline
> 
> regards joscha
> 
> 
> Am 16.02.2013 18:55, schrieb Jouni Mäenpää:
>> Hi Marc and Joscha,
>> 
>> Thanks for the comments! Answers inline.
>> 
>> Regards, Jouni
>> 
>> -----Original Message----- From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Joscha Schneider Sent: 15.
>> helmikuuta 2013 12:30 To: Marc Petit-Huguenin Cc:
>> [e-mail]; [e-mail] Subject: Re: [P2PSIP] WGLC
>> for draft-ietf-p2psip-service-discovery-06
>> 
>> I can confirm that the draft might need some improvements to make the
>> implementation easier. I did a basic implementation but I'm not quite
>> sure that I handled everything correct.
>> 
>> [Jouni]: I'll try to improve the text in the next version of the draft.
>> 
>> Especially the definition of the successor seams a bit unclear for me. A
>> simple example: Only a single service provider with Node-ID 2 provides a
>> service. Node with ID 7 performs a lookup... How should it be handled? I
>> implemented it as follows: in case a lookup reveals only a single service
>> provider it must be the direct successor.
>> 
>> [Jouni]: What would happen in this case is that the upward walk of the
>> service lookup reaches the root level because no successor can be found
>> from the lower levels in the tree. In my implementation, when this
>> happens, I'm selecting either the closest successor at the root level or,
>> if there is no successor, select one of the available service providers
>> randomly (or pick the only service provider if there is only one like you
>> are doing in your implementation). Anyway, I'll add text to clarify this
>> to the next version of the draft.
>> 
>> Further notice, due to the periodically triggered re-registration the
>> consistency of the ReDiR tree can not be always ensured. Theoretically
>> this can lead to failed lookup processes. This derives from the fact that
>> each new service provider registration might affect the re-registration
>> of the former service providers which again might affect the
>> re-registrations of other service providers.
>> 
>> [Jouni]: Not sure about this. I could be wrong, but why would the
>> re-registration of a service provider affect the re-registrations of
>> other service providers? I mean, when a service provider X re-registers
>> or registers, it simply stores its own record at different levels in the
>> ReDiR tree as a part of the upward and downward walks. This
>> re-registration process does not influence the (re-)registrations of
>> other service providers. Or did I understand your comment incorrectly?
> 
>> I'll try to make an example: Two service provider are even in Level 4 in
>> the same interval. First service prover (X) stops registration downwalk
>> at level 2 because it's the only one. Second service provider (Y) goes
>> down to level 3 to finish its downwalk. X starts re-registration. Now the
>> downwalk need to go down to level 4 as level 2 and 3 are shared Y.
> Now Y starts re-registration. Goes down to level 5 as level 3 and 4 are
> shared now. X re-registers again. goes down to level 5. Finally both
> service providers have found the leaves and the tree is consistent. In
> between, service lookups might go down to a level at which no service
> provider information is stored (yet).
> 
> [Jouni]: Ok, I think you're right, that can happen. How often do you think
> it would occur? The default branching factor of the ReDiR tree is 10. I
> guess that the Node-IDs of the service providers that are (re-)registering
> at the same time would need to be very close to each other in order for the
> service providers to end up into the same interval at two levels of the
> tree (with the default branching factor of 10, level 2 has 1000 intervals,
> level 3 10000, level 5, 100000, etc.).
> 
> I guess there might also be other similar situations, though, such as when
> a RedirServiceProvider record expires within a given interval at some level
> just before a service lookup for which that record is the closest successor
> reaches that level and interval, and before the re-registration stores a
> new RedirServiceProvider record in that interval. This situation should be
> quite rare, though.
> 
> One potential strategy for dealing with the situations above is to fail the
> service lookup procedure and retry it - if the temporary inconsistency has
> been fixed by a re-registration between the old and new service lookup, the
> new service lookup will succeed.
> 
> Another strategy that we are using in our ReDiR implementation is that we
> are temporarily (for the duration of a service lookup) caching/storing the
> RedirServiceProvider entries fetched during that specific service lookup at
> the peer that is carrying out the service lookup. Thus, if for whatever
> reason the service lookup would happen to go down to a level at which no
> service provider information is stored, the peer that is carrying out the
> search can go through the locally cached RedirServiceProvider entries to
> find the closest successor of the search key from among the cached entries.
> This strategy would allow one to recover from the scenarios described
> above. Do you think it would help if we described this strategy in the
> draft? Do you have some other potential solutions in mind?
> 
>> more inline...
>> 
>> Regards Joscha
>> 
>> Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin:
> I did a review of this draft, and I have some concerns.
> 
> First of all some parts of the I-D are verbatim copy of the text in the
> original paper.  Is that OK?
>>> [Jouni]: I guess the main reason for that is that ReDiR is pretty
>>> complex to describe. So we took a safe bet and tried to reuse some of
>>> the text (the algorithm description) from the paper. But since there
>>> are also comments that the text is difficult to follow, I'll make an
>>> attempt to reformulate it in the next version of the draft.
>>> 
> Probably because some of the text comes from a research paper, it was very
> difficult to understand fro me, and I am not sure that I yet understood
> everything - I still have to write an implementation of this, and
> unfortunately to not have enough time to do so before the end of the WGLC.
> On the other hand, I know that RELOAD.NET has an implementation, so I guess
> it is implementable.
>>> [Jouni]: I have also implemented the draft and think I got the
>>> implementation right. So if you have any further questions about things
>>> that are unclear, let me know and I can check the code to see how that
>>> specific thing was implemented (and clarify the same issue in the draft
>>> if necessary).
>>> 
> But I was not able to make sense of something in the example in section 7: 
> Why is the 4th peer added to level 0? Bullet 4 in Section 4.3 says "Node N
> MUST continue [repeating steps 2 and 3] until it reaches either the root or
> a level a which n.id is not the lowest or highest Node-ID in the interval
> I(level, n.id)".  In this case 4 is not the lowest or highest Node-ID in
> the interval (lowest is 2, highest is 7), so why is it added to this node?
>>> I think the example is simply following the rules. At level 1 peer 4 is
>>> the lowest. So go up and fetch and store.
>>> 
>>> [Jouni]: That's correct. Node 4 starts from the starting level, which
>>> is level 2. It stores its record on level 2. Since Node-ID 4 is the
>>> lowest (only) Node-ID in its interval, the upward walk continues to
>>> level 1. At level 1, Node-ID 4 is also the lowest Node-ID in its
>>> interval and thus the upward walk continues all the way to the root
>>> level. Node 4 stores its record in that level. Since Node-ID is neither
>>> the lowest nor highest Node-ID, the upward walk stops at level 0
>>> (although it would stop anyway at level 0 since it is of course not
>>> possible to go further up in the tree).
>>> 
> But if i reveal correct that fact caused a few headaches for me too. Why
> does the store does not depend on the information that was fetched before?
>>> [Jouni]: That is how it goes - if there has been a decision that the
>>> upward walk shall continue to the next level, a record is stored at
>>> that level 'automatically', regardless of the contents of the tree
>>> node. The contents of the tree node (i.e., whether n.id is sandwiched
>>> or not) will influence the decision on whether to stop the upward walk
>>> or continue it. The idea in the upward and downward walks is to ensure
>>> that the tree is populated densely enough so that service lookups will
>>> finish without requiring too many Fetch operations.
>> But does this make sense? If I recall correct the registration
>> information of node 3 and 4 in Level 0 in the draft example will never be
>> used in lookup processes. As far as I understood at most two service
>> provider entries are needed (lowest and highest) in each tree node to
>> make the algorithm work. All sandwiched service provider information is
>> not needed. Most of them will also expire and not be renewed in the
>> re-registration process in case other service providers have registered
>> in the meantime. I think this 'automatic' store process makes the tree
>> just a bit more wired and the algorithm mode difficult to understand. Or
>> do you see a resonable reason for this behaviour that I don't see.
> BTW a similar example for the service lookup would be useful.
>>> [Jouni]: Ok, I'll add an example in the next version of the draft.
>>> 
> More comments:
> 
> - Section 3, 3 paragraph: "contains a list of Node-IDs"
> 
> Technically each node is a Dictionary whose keys are Node-IDs and values
> contain a list of Destinations.
>>> [Jouni]: Ok, I'll modify this in the next version of the draft.
>>> 
> - Section 4.1
> 
> s/detination_list/destination_list/
>>> [Jouni]: Ok, will change this one also in the next version of the
>>> draft.
>>> 
> - Section 4.1
> 
> namespace is an opaque value but the charset and conversion between 
> character string and byte string for the namespace is not defined.
>>> confirm
>>> 
>>> [Jouni]: Would specifying that it is an opaque UTF-8 encoded string be
>>> enough?
>>> 
> - Section 8
> 
> The document says that the redir namespace is added to the 
> <mandatory-extension> element, meaning that all nodes MUST understand 
> ReDIR, but isn't that against one of the goal of ReDIR, which is that by
> using standard Store/Fetch, only a node wishing to store or fetch has to
> implement ReDIR?
>>> I think at least the RedirServiceProvider Data Structure must be
>>> supported. And also the Access Control Rules. But the algorithm might
>>> not be mandatory  needed.
>>> 
>>> The RedirServiceProvider Data Structure does not need to be understood
>>> by the peer storing it, but you are right about the Access Control
>>> rule.  My own draft about storing the Access Control rule solves this
>>> problem but, even if it is accepted as WG item, we do not want to add a
>>> normative reference to it.
>>> 
>>> So I withdraw what I said - redir needs to be a a mandatory extension
>>> at least until new access control policies no longer have to be
>>> hardcoded.
>>> 
>>> [Jouni]: Ok, so if I understood correctly, it is ok to leave the text
>>> as it is.
>>> 
> - Section 10.3
> 
> I think that we need a bit more explanation on what the turn-server and
> voice-mail service providers are.
>>> [Jouni]: I could remove the voice-mail service provider from the next
>>> version of the draft as I don't have a good explanation for that. For
>>> turn-server I will add some text.
>>> 
> On 01/31/2013 03:11 PM, Carlos Jesús Bernardos Cano wrote:
>>>>> Hi,
>>>>> 
>>>>> Hereby we are issuing a WGLC for
>>>>> draft-ietf-p2psip-service-discovery-06.
>>>>> 
>>>>> The WGLC will be open till the 15th of February. We kindly ask the
>>>>>  WG to review the document and provide comments.
>>>>> 
>>>>> If you have no comments and think the document is ready to be 
>>>>> submitted to IESG, please do send a note stating that to the WG
>>>>> ML.
>>>>> 
>>>>> Additional information about the document is below:
>>>>> 
>>>>> Title           : Service Discovery Usage for REsource LOcation
>>>>> And Discovery (RELOAD) Author(s)       : Jouni Maenpaa Gonzalo
>>>>> Camarillo Filename        :
>>>>> draft-ietf-p2psip-service-discovery-06.txt Pages : 15 Date
>>>>> : 2012-10-01
>>>>> 
>>>>> Abstract: REsource LOcation and Discovery (RELOAD) does not define
>>>>> a generic service discovery mechanism as part of the base
>>>>> protocol. This document defines how the Recursive Distributed
>>>>> Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can
>>>>> be applied to RELOAD overlays to provide a generic service
>>>>> discovery mechanism.
>>>>> 
>>>>> 
>>>>> The IETF datatracker status page for this draft is: 
>>>>> https://datatracker.ietf.org/doc/draft-ietf-p2psip-service-discovery
>>>>>
>>>>>
>>>>> 
There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-ietf-p2psip-service-discovery-06
>>>>> 
>>>>> 
>>> _______________________________________________ P2PSIP mailing list 
>>> [e-mail] https://www.ietf.org/mailman/listinfo/p2psip
>> _______________________________________________ P2PSIP mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/p2psip
> 
> _______________________________________________ P2PSIP mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/p2psip 
> _______________________________________________ P2PSIP mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/p2psip
> 

- -- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJRLRPDAAoJECnERZXWan7ESQAQAKp49csNIYytMJ9NdACdQBTW
S6MXxhymlmDWOjsj6OjYUKb1NOFbT5pbs4sM5eJ22v+DyTWOoQ/YWu+hnShPL9zV
pfOgn66TzL2KsAI0xkKB7QhyYIUmH9ODrf3NPcs8u3FUw4exXGInh9Y96hq0pMfD
KeH/UTVOQ4W2O860xpogWaoGOJ89fhqRT9B4HD36uw97MD/hh5KbZ9i7/RhxhtKa
G0ayNXzyxziql3LRMBe8ty31+/T4/L6JK9TJVLrK1xnEg2yRmQslbFgVeNQhd3U6
uEIPKuDJRP04IKQ3OwLTvmteg3q16GJLMDsTFcD6C0i02701BNwP5WI2XuFXQBEp
JoPtFnAvLS8KrdjgpIO4cXXYfTbjcskRh9261M58iv7o9WGQEefsk/rvp4oVY+xd
Cb+j6uN4dI3DDU7oiYd6yyCNnHrLqgEXZ/PtkhgBhvGmvE50/bHmGbPZjRmYr8JC
8CyUbsmDx66N9BPt9MBH0zQtI+RtWhIzdFYgYSFeyywWrVfAAuXxcuhOPpqq1R3J
pec45/i8XM4nIwL9HudFnNDpL+LU7CWkR08JTpjJb3ObPE5PlKF7hyXe0Q74MSJl
a5skclkWEqoqqjIIz76Cua87B0MlE2sOW6wDfeB9sIlDt1hgaDQyX9pkQrUwbvJ8
TUSqWkHed1zr3ImnQxu3
=Q3Od
-----END PGP SIGNATURE-----