At Fri, 11 Jul 2008 15:07:19 +0800,
jiangxingfeng 36340 wrote:
>
> 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.
Good point.
> 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.
We envision the topology plugin sending instructions to the storage
component, since it's the part that knows. However, obviously you
could design the software either way. It doesn't affect the wire
protocol.
> 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!
The current document is intended to be a compromise: i.e., to leave a
potential hole for unstructured overlay networks, but not to
actually describe how they would work. Some extensions might
be required in the future to actually support them.
> 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.
I tend to think the diagram is sort of at the conceptual limit as-is.
> 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.
Pretty much, yeah. This may need some work.
> 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?
That seems like an issue outside reload.
> 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.
Yes it *allows* the peer responsible to verify. It's necessary but
not sufficient.
> 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?
There's no technical reason that SCTP couldn't be supported, but
since TCP and UDP are the dominant protocols people use
(for the NAT/firewall issues you cite, among others), we decided
to start with those. SCTP can be used with TLS/DTLS.
> 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?
I think this depends on what you think a reasonable time is. The
current specification doesn't have any set time to give up
(though imitating TCP here is probably appropriate), so we
should decide if it's going to be a lot faster than TCP,
otherwise there's no advantage...
> 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.
In general, peers need to ensure similar responses to retransmitted
transaction ids. This is an issue that we know isn't completely
described in RELOAD-04.
> 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 section doesn't say that it uses the "user name", it says
"based on the user's certificate information." Which information
depends on the kind and each kind has to specify it. Section 9
specifies the relevant values for the TURN Service:
Access Control If certificate-based access control is being used,
stored data of kind TURN-SERVICE MUST be authenticated by a
certificate which contains a peer-id which when hashed with the
iteration counter produces the resource-id being stored at.
-Ekr
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
