On Jan 10, 2008 3:17 AM, Pekka Nikander <[EMAIL PROTECTED]> wrote: > Hi Bruce, > > > - 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 only difference that I can see between the previous one and this > one is that here there are no explicit routing table. Hence, instead > of doing the typical thing routers do, i.e., to compute a forwarding > table from the routing table as a "batch job" the forwarding decision > is performed "lazily" on demand. > > > The hip routing table approach looks great from a layering > > perspective, but implementation looks to be very hard. > > Why? Do you allude that the various overlay routing protocols are > sufficiently different from the IP routing protocols so that one > cannot compute a forwarding table? Or is there some other > implementation problem that you are thinking about? >
The issue I'm concerned about here is that different DHTs use completely different routing algorithms. For example, for Chord you forward the message to the peer with the closest ID that is < the target, but with Kademlia, you do a prefix match and calculate distances with xor. I'm sure it's possible to come up with a safe language or something that could be used to describe how to make routing decisions, but it's certainly non-trivial. I think in a later message I sent yesterday, I looked a bit more at the layering and believe that it's not a layering violation, but an interface that is needed between the two adjacent layers. > > > 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). > > I don't quite understand what you are saying. Would you please clarify? > As I thought of the "hip link layer" approach, it was somewhat limited in what it could do independently without the request of the peer protocol. > > 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. > > Well, depending on many factors, it may be only a subset of the HIP > base exchange messages that would be routed over the overlay (through > node 5); some of them (like perhaps R2) could perhaps be sent > directly, at least in some cases. So, there is some flexibility > here, but at least I don't quite understand the situation in cases > where both 1 and 10 are behind NATs. > As long as they are both reachable in the overlay, both peers behind nats isn't a problem as long as the ice message exchanges are carried over the overlay. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
