Re: [P2PSIP] comments on draft-maenpaa-p2psip-self-tuning

[Jouni Mäenpää <[e-mail]>]

Hi Roni,

Thanks for your comments! See below for my answers.

> The first comment I have is related to the periodic and reactive
> stabilization.  The reload base draft is section 10.2 discuss the topic
> and mention that the current approach in the reload base draft is for
> reactive and that more input is needed. Yet section 10.7.2 describes
> periodic stabilization. I think that we need to decide on the approach
> for the base reload and if it is periodic we need to see if the text
> from the self tuning draft should fold to the base draft.

My understanding is that currently, the algorithm of the reload base
draft uses reactive stabilization for the predecessor and successor
lists, and periodic stabilization for the finger table. Our draft uses
periodic stabilization in all of the cases.

> 1.       In section 4.1 the update message includes the send-id. I am
> not sure why it is needed since the sender is attached to the receiving
> peer and I assume the receiver of the updates knows this information.
> This parameter is not part of the update message in the reload base draft.

You are right, the sender_id is not really needed. We will remove it in
the next version of the draft.

> 2.       In section 4.1 the update answer has an option to send the
> predecessor or successor lists. What is the benefit for it since the
> receiver is also part of the periodic stabilization and will need to
> send it anyhow, so this may be a duplicate of messages. I can see the
> use case for the message in the reactive stabilization case.

I guess you are saying that we could optimize (get rid of messages) by
merging the successor and predecessor stabilization procedures. The
reason we chose in the draft to send different Update requests for
predecessor stabilization and successor stabilization is that the
original Chord algorithm [1] specifies the predecessor aliveness check (
check_predecessor() ) and successor stabilization ( stabilize() )
operations separately. We are using the Update request and answer sent
by peer n to its predecessor p as part of the predecessor stabilization
procedure to implement the check_predecessor() procedure. Since the
algorithm specified in the draft uses multiple predecessor pointers
(unlike the original Chord, which maintains only one predecessor), we
extended the check_predecessor() procedure by returning the predecessor
list of peer p in the Update answer. This is done so that peer n can
stabilize its predecessor list with its predecessor.

Note that in the successor and predecessor stabilization procedures, the
Update request is empty in the sense that it does not carry any
successor or predecessor lists. The idea is that the receiver of the
Update request returns the information the sender is interested in in
the Update answer.

> 3.       I am not sure how a peer knows which topology is used in the
> overlay, is this a different overlay algorithm type that need to be
> registered in the IANA section.

Good point. It's a new overlay algorithm type. We will add the new type
to the IANA section in the next version of the draft.

> 4.       This draft defines  different parameters for update and update
> answer but uses the same message code name and I assume the same code
> value. Is that the approach and the peer knows the parameters based on
> the overlay algorithm type or should we have another code name and code
> value.

I would like to hear the opinions of the RELOAD authors on this. So far
we have been assuming that peers know the parameters based on the
overlay algorithm type.

Regards,
Jouni Mäenpää

[1] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek, M.,
Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup
Service for Internet Applications", IEEE/ACM Transactions on Networking
Volume 11, Issue 1, 17-32, Feb 2003.