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

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 14 Feb 2013 10:59:42 -0800

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?

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.

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?

BTW a similar example for the service lookup would be useful.

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.

- - Section 4.1

s/detination_list/destination_list/

- - 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.

- - 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?

- - Section 10.3

I think that we need a bit more explanation on what the turn-server and
voice-mail service providers are.

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: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Joscha Schneider <[email-masked]>
Date: Fri, 15 Feb 2013 11:29:31 +0100

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.

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.

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.

more inline...

Regards
Joscha

Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
I think the example is simply following the rules. At level 1 peer 4 is 
the lowest. So go up and fetch and store.
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?

> string and byte string for the namespace is not defined.
confirm
> standard Store/Fetch, only a node wishing to store or fetch has to implement
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.
> -----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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 15 Feb 2013 08:51:05 -0800

One comment below.

On 02/15/2013 02:29 AM, Joscha Schneider wrote:
> implementation easier. I did a basic implementation but I'm not quite sure
> that I handled everything correct.
> 
> 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.
> 
> 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.
> 
> 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.
> 

[...]

> - Section 8
> <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?
>> 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.

- -- 
Marc Petit-Huguenin

---

From: Jouni Mäenpää <[email-masked]>
Date: Sat, 16 Feb 2013 17:55:53 +0000

Hi Marc and Joscha,

Thanks for the comments! Answers inline.

Regards,
Jouni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joscha Schneider
Sent: 15. helmikuuta 2013 12:30
To: Marc Petit-Huguenin
Cc: [email-masked]; [email-masked]
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?

more inline...

Regards
Joscha

Am 14.02.2013 19:59, schrieb Marc Petit-Huguenin:
> 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).

> 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.

> 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.

> 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.

> 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?

> 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.

>> 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.
>>
>> 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.
>>
>>

---

From: Joscha Schneider <[email-masked]>
Date: Mon, 18 Feb 2013 12:21:13 +0100

two comments inline

regards
joscha

> [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-…
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]: 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 th…
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.

---

From: Jouni Mäenpää <[email-masked]>
Date: Mon, 18 Feb 2013 19:24:39 +0000

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:[email-masked]] 
Sent: 18. helmikuuta 2013 13:21
To: Jouni Mäenpää
Cc: Marc Petit-Huguenin; [email-masked]; [email-masked]
Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06

two comments inline

regards
joscha

> 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?

>> 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?
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.
>>> The WGLC will be open till the 15th of February. We kindly ask the 
>>> WG to review the document and provide comments.
>>>
>>> (ReDiR) service discovery mechanism used in OpenDHT can be applied 
>>> to RELOAD overlays to provide a generic service discovery mechanism.
>>>
>>>

---

From: Jouni Mäenpää <[email-masked]>
Date: Sat, 23 Feb 2013 08:59:59 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Jouni Mäenpää
Sent: 18. helmikuuta 2013 21:25
To: Joscha Schneider
Cc: [email-masked]; [email-masked]
Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06

Hi Joscha,

Regards,
Jouni

-----Original Message-----
From: Joscha Schneider [mailto:[email-masked]]
Sent: 18. helmikuuta 2013 13:21
To: Jouni Mäenpää
Cc: Marc Petit-Huguenin; [email-masked]; [email-masked]
Subject: Re: [P2PSIP] WGLC for draft-ietf-p2psip-service-discovery-06

two comments inline

regards
joscha

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 26 Feb 2013 11:58:03 -0800

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:
> - 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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Jouni Mäenpää Sent: 18.
> helmikuuta 2013 21:25 To: Joscha Schneider Cc:
> [email-masked]; [email-masked] Subject: Re: [P2PSIP] WGLC
> for draft-ietf-p2psip-service-discovery-06
> 
> Hi Joscha,
> 
> Regards, Jouni
> -----Original Message----- From: Joscha Schneider
> [mailto:[email-masked]] Sent: 18. helmikuuta 2013 13:21 To:
> Jouni Mäenpää Cc: Marc Petit-Huguenin; [email-masked];
> [email-masked] Subject: Re: [P2PSIP] WGLC for
> draft-ietf-p2psip-service-discovery-06
> 
> two comments inline
> 
> regards joscha
> 
> 
>> Regards, Jouni
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Joscha Schneider Sent: 15.
>> helmikuuta 2013 12:30 To: Marc Petit-Huguenin Cc:
>> [email-masked]; [email-masked] Subject: Re: [P2PSIP] WGLC
>> for draft-ietf-p2psip-service-discovery-06
>> 
>> implementation easier. I did a basic implementation but I'm not quite
>> sure that I handled everything correct.
>> 
>> [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.
>> 
>> 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?
> 
>> 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.
> [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
>> 
>>> [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.
>>> 
> 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).
>>> 
> 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?
>>> [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).
>>> 
>>> [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.
>> 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
> - Section 3, 3 paragraph: "contains a list of Node-IDs"
> 
> - Section 4.1
> - Section 4.1
>>> 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.
>>> 
> - Section 10.3
>>> [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.
>>> 
>>>>> 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.
>>>>> 
>>>>> 
There's also a htmlized version available at:
>>> _______________________________________________ P2PSIP mailing list 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/p2psip
>> _______________________________________________ P2PSIP mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/p2psip
> 
> _______________________________________________ P2PSIP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/p2psip 
> _______________________________________________ P2PSIP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/p2psip
> 

- -- 
Marc Petit-Huguenin