1. In section 1.2.3, The Storage component is responsible for processing data
storage and retrieval messages from other peers.
it is not accurate, the Storage component may processing data storage and
retrieval messages from itself. It depends on the relationship between the
Node ID and the resource id to be put.
2. In section 1.2.3 However, the exact mapping between these is
determined by the overlay algorithm used by the overlay, therefore
the Storage component always the queries the topology plugin to
determine where a particular resource should be stored.
Maybe the Storage componet SHOULD periodically detect whether mismatch
exists
because of churn. If mismatch exists, then migrate the resource to its new
responsible peer.
3. It seems that RELOAD-4 could not support unstructured P2P algorithms well.
For example, unstructured P2P algorithms has no concept of Node ID. So how to
use messages, such as "Connect" in these kind of algorithms? Could you please
give more insight into this? thanks!
4. For the architecture figure, I have a suggestion. In my mind, routing table
and <key, value> pair table are the two important database for overlay's
functioning well. What about add them into the figure and locate them into
appropriate layer or component? althgouth it could got from the text.
5. In RELOAD-4, a small number of bootstrap nodes with unrestrictive
connections, i,e, having public address and no firewall. How could the nodes
get
the set of the bootstrap nodes? just through enrollment procedure which only
happen when a user wants to participate in the overlay. Another problem is that
accuracy of the information of the boostrap nodes are very important. Will the
bootstrap nodes be provided by the overlay operators just like what Skype does?
6. In section 4.1.1, The digital signature over the data serves two
purposes. First, it
allows the peer responsible for storing the data to verify that this
Store is authorized.
I don't think digital signature provide authorization function, it only
check
whether the data is really from the request originator. It is used to prove
the sender's identity with the help of the certificate.
7. RELOAD-4 currently support TLS/DTLS. Why is other protocol such as SCTP out
of considerations? Although I am not familiar with the SCTP, but it seems it
has
some interesting feartures which help the P2PSIP overlay:
.multihome
.stream concept which make no intervention between messages. Essentially,
messages in
P2P overlay have nothing to do with each other.
I also know there is some trouble in traversing NAT/firewall while SCTP is
taken. I'd like to hear more comments from the authors?
8. In section 6.4.1.2, RELOAD introduces reliablity for unreliable transports.
In my mind, the reliability also helps in the case where reliable transports
are
used. For example, if the sending peer does not receive ACK within reasonable
period, it could conclude the receiving peer may be offline. Then it could
reschedule the routing decision to choose another neighbor to improve the
success rate of the request. what do you think of it?
9. As for generation in STORE request, there may be some error. When the
responsible peer receives a STORE reqeust, it MUST make sure the generation in
the request is larger than one stored. Is my understaning right? If it is
right,
I have a question here.
For example, peer A sends a STORE request in which generation counter is 10.
Finally, peer B is the destination of the STORE request and the stored
generation is 10. Then peer B process the STORE request, and increase the
stored
generation to 11 and sends a respons to peer A. Unfortunatelly, the response
did
not go back to peer A successful for various reasons. So Peer A retransmit the
request again and the generation is still 10. In the end, peer B will think it
is a replay request, and give a error response to peer A. Peer A later get the
error response, but the STORE actually succeeded.
One solution to the problem is to store the transaction ID to identify the
retransmission request.
10.In section 13 Enrollment and Bootstrap. I think the description in the
section is useful. But I don't think the procedure should be standardized.
11. In section 15.5.1. Authorization, RELOAD tries to use certificate to let
only node in the certification to put the resource which is got by hashing the
username. What if the user want to put resource which is not stored under the
username, for example, TURN service,etc. Could you please share more thoughts
with me in this regard?
******************************************************************************************
This email and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed above.
Any use of the information contained herein in any way (including, but not
limited to, total or partial disclosure, reproduction, or dissemination) by
persons other than the intended recipient(s) is prohibited. If you receive this
e-mail in error, please notify the sender by phone or em
ail immediately and delete it!
*****************************************************************************************
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
