> > 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.
> > > > 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. I don't think enrollment is the better place to distribute the information of the bootstrap peers, because only when the node registers with the system, it contacts with the enrollment server. In other cases, we need a more formal method to get the information. > > > 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. I mean the bootstrap method in peer protocol should maintain a set of available bootstrap nodes which could be used to help other nodes join the system. Often, peer's behavior is autonomous and may leave the system without notification. So how does the RELOAD guarantee at least one peer in the set is available. On the other hand, I am very interested in how the RELOAD determine which kind of nods could be candidate bootstrap nodes, I,e, public address and no firewall? > > > > > 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. I am interested in and could contribute more in the topic. > > > 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... Right. So do you think it is a open issue for the peer protocol design? > > > > 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. How could RELOAD achieve that? Keep state under the transaction-id? It seems not a good method. >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. If my understanding is right, does that mean all other resource or resource-id should have some relation with information in certificate to ensure the current authorization mechanism? For example, if the TURN service discovery does not follow current method in RELOAD-4, the authorization may not hold. Right? Regards JiangXingFeng _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
