Subject: [P2PSIP] more comments on RELAOD-4

From: jiangxingfeng 36340 <[email-masked]>
Date: Fri, 11 Jul 2008 15:07:19 +0800

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-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Jul 2008 00:57:58 -0700

At Fri, 11 Jul 2008 15:07:19 +0800,
>    Node ID and the resource id to be put. 

Good point. 

>    because of churn. If mismatch exists, then migrate the resource to its new 

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.

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

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

> happen when a user wants to participate in the overlay.

Pretty much, yeah. This may need some work.

> Another problem is that 

That seems like an issue outside reload.

>    the sender's identity with the help of the certificate. 

Yes it *allows* the peer responsible to verify. It's necessary but
not sufficient.

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

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

> One solution to the problem is to store the transaction ID to identify the 

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.

> username, for example, TURN service,etc. Could you please share more thoughts 

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

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Mon, 14 Jul 2008 15:05:57 +0800

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

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

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

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

>       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