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

[Joscha Schneider <[e-mail]>]

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).
> more inline...
>
> Regards
> Joscha
>
> Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> 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
>>>
>>>
>> - --
>> 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)
>>
>> iQIcBAEBCAAGBQJRHTQcAAoJECnERZXWan7EmukP/A1P3JutcxuDooxYPFjty3ua
>> lhhbiJTd7PLEs9jsaG9hKHjuDi2qu0BNp9Ss+ki+ybtXBNKaJwkrqNqwB3R+dXpx
>> Q7zamHvCUJekNmybG2kpc5IUP2MxhDzYp3paocOdF/vdWYE+re3u9WqBN1JNuCwk
>> E6GmfEIgw28p5wKldHPCGQrRYx6QnszsQc7F3+siFrsSEzRww7ATpUXjMCVxUfWU
>> KTmBh0H+9+PhoXeH6leue2v0Y5Xb1lD8HU6WmrssWYrd9rXgc3s26kzsUrATJCKc
>> bj7M6uiKIzUDFwaj13U6bPbldVeJWd+DhWCR2k4Y3rJIfj5bdp55ApDZnF/14v91
>> i/w0hnqnuiT/KEDuW+E7jsKwXq/ILKIDZqonyFlF7KuGUT3HGi9WFkc7AnkaOi5U
>> qgsuFEYjxkUqAbTAO7nwa9YtGX0qKHhH5SkzWpITTabu48c5FKqG0vAVpGce8z3K
>> AyqtwNXAz9nIL6ZwJNg9L8tLhLBQS1lePeSiN7pog4jsKD51VaT7Y1iMysA2OqRs
>> Nw70wF7TYh4EikCHsECPQBEI/a+cJEQSro0I4kHGGttVcEdrDqM4xdfaFYN+Ag1b
>> vHEf3Zzv/x820fjbfN1eoySj/qFU7Mcuw8Rik//J63HKZbmGdbaYsdrHasgaDIqk
>> TgSsgGCf6d5FX9TFFNvd
>> =u3Pi
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> P2PSIP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/p2psip
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2psip