On Dec 23, 2007 4:33 AM, Gonzalo Camarillo <[EMAIL PROTECTED]> wrote: > Hi Bruce, > > thanks for your comments. > > Regarding your question about Sections 3.2 and 3.3 when RELOAD is the > peer protocol and HIP BONE is used for connection management, the idea > is to use HIP, instead of RELOAD, to perform connection management. All > the other functions RELOAD typically performs are still performed by RELOAD. > > RELOAD defines the CONNECT primitive and the TUNNEL primitive. If HIP is > being used, you would use the CONNECT primitive of HIP (i.e., an I1 > packet) *instead* of the CONNECT primitive of RELOAD. The same way, you > would use the TUNNEL primitive of HIP (i.e., a HIP message) *instead* of > the TUNNEL primitive of RELOAD.
This is where I still get confused, and I think this is a pretty big architectural issue. The combination of 3.2, 3.3, and 6 still leave some questions in my mind as to exactly what is being proposed, so let me try to form up an example for discussion purposes. Suppose I have an overlay with the following connections between peers (labeled with their peerid): 1 ------ 5 ------ 10 So 1 has 5 in its routing table (and thus a direct connection) but not 10. 5 has direct connections to 1 and 10. I'm assuming recursive routing and am not being precise with a DHT algorithm for the purposes of this example. 10 is responsible for a resource, 9, that 1 wants to query for. In a non-HIP DHT implementation, 1 sends a query "to" 9. It looks up for the closest match in its routing table and discovers it is 5, then it sends the message to 5. 5 performs a similar lookup and discovers that its closest match is 10, so it forwards the query to 10. Going with the HIP-BONE, approach, as I understand the "HIP is IP and the peer protocol is OSPF" idea, I see two approaches that would meet that requirement: - the peer protocol loads enough information into the HIP layer that the HIP layer on peer 1 knows that the next hop for a message bound for "9" is 5. I will refer to this as the hip routing table approach. - the peer protocol sets the next-hop for the query to "5" based on its own routing table, and lets the HIP layer forward it. I will refer to this as the hip link layer approach. The hip routing table approach looks great from a layering perspective, but implementation looks to be very hard. Since there are multiple DHT (and unstructured overlay) algorithms with different routing rules, there would have to be a pluggable routing algorithm loaded into the HIP layer by the DHT algorithm or there needs to be an upcall from the HIP layer into the peer protocol layer to query for the next-hop for messages. In the hip link layer approach, the peer protocol layer knows that the current set of next-hop candidates are, and it runs the DHT routing algorithm in the conventional sense, telling the HIP layer what the next hop for a message is. This seems like a much simpler approach to implement, but limits the usefulness of HIP. So the first question is whether HIP-BONE is intended to specify one of these approaches, and if so, which one? I believe it's the hip routing table approach. Next, let's take the case of 3.3, "lightweight message exchange." As I understand 3.3, it should work fine in the hip routing table approach for both application and peer protocol message exchanges. In the hip link layer approach, peer protocol messages can be delivered this way, but application messages cannot (they would require a direct connection). Next, how about CONNECT messages. Suppose that now peer 1 wants to establish a direct connection to peer 10 for some reason. Your email indicates that there will be no CONNECT messages as in RELOAD, but instead there will only be I1 etc messages. Let's just assume that the peer protocol has some way of indicating that it wants to be able to send messages directly to another peer rather than over the overlay. So in the hip routing table approach, the I1 etc messages are routed via 5 using HIP to 10 and eventually a new direct connection is established. In the hip link layer approach, the peer protocol would have to insert the I1 into a peer message and forward it itself. That would work, but it's a bit cumbersome. What continues to confuse me, and what I think is the hardest architectural question here, is how the issue I mentioned above: "there would have to be a pluggable routing algorithm loaded into the HIP layer by the DHT algorithm or there needs to be an upcall from the HIP layer into the peer protocol layer to query for the next-hop for messages" is solved. Section 6 has quite a few block diagrams, but none of them seem to help me resolve this issue. I don't think I see any other alternatives, but it would be nice to see this specific issue addressed, because it would make the layering more concrete. > > Regarding when to use these primitives, you would use them in the same > way as defined by RELOAD. That is, when RELOADs tells you to use a > CONNECT primitive today, you would send an I1 message. When RELOAD tells > you to use the TUNNEL primitive today, you would use a HIP message as > well. That is, RELOAD (not HIP BONE) tells you what to do (i.e., which > primitive to use) and when to do it. > > As you can see, the only modifications to RELOAD in this context is the > substitution of these two primitives by the HIP equivalent ones. So I'm not quite sure that this is completely true. If we let the HIP layer handle the routing, then RELOAD wouldn't have to handle the hop-by-hop nature of the recursive forwarding like it does now. It doesn't change anything about the majority of the peer protocol issues, but it does change a bit in how the peer protocol's forwarding layer (in RELOAD-02's arch diagram) would work. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
