Marc, I think there's an underlying issue here of whether it's important to - use the same "physical" connection between two physical nodes that are both acting as multiple virtual nodes for all pairs of connectivity between them AND - differentiate on the receipt of a message what pair of virtual nodes A'->B' the original sender believed the message was going between.
I'm not immediately convinced that this is a useful property for the routing system, as if each physical node is merging the virtual nodes' routing tables and forwarding to the closest match, I don't think it's necessary for reliable routing. However, if you have a pointer to a description of why this would be useful, I'd be very interested in reading it. With that said, my current opinion is that what you want to accomplish can and should be accomplished through a new routing algorithm. However, I think we should move to incorporate the new SignerIdentity into the base draft and probably handle the IceExtension as a new draft. But both should probably get a thread of their own so they have more eyes. More comments inline On Wed, Feb 9, 2011 at 11:44 AM, Marc Petit-Huguenin <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/08/2011 06:25 PM, Bruce Lowekamp wrote: >> On Mon, Jan 10, 2011 at 5:44 PM, Marc Petit-Huguenin <[email protected]> >> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Thanks for your responses. see below for more comments. >>> >>> On 01/07/2011 02:24 PM, Bruce Lowekamp wrote: >>>> inline >>>> >>>> On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin <[email protected]> >>>> wrote: >>>> More questions, comments and nits: >>>> >>> >>> [...] >>> >>>> >>>> - A.10. It seems that this version of RELOAD lacks the support of virtual >>>> servers (see draft-harjula-p2psip-loadbalancing-survey), more precisely a >>>> way to >>>> share connections between two virtual servers on the same physical server >>>> (see >>>> Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, >>>> Wide-area cooperative storage with CFS: "Use of virtual servers could >>>> potentially increase the number of hops in a Chord lookup. CFS avoids this >>>> expense by allowing virtual servers on the same physical server to examine >>>> each >>>> others' tables: the fact that these virtual servers can take short-cuts >>>> through >>>> each others' routing table exactly compensates for the increases number of >>>> servers."). Because the certificates contains a list of Node-IDs, it is >>>> not >>>> possible to know on a hop by hop basis what are the source and destination >>>> NodeIds of a specific message. Section 3 of >>>> draft-rosenberg-dispatch-vipr-reload-usage seems to acknowledge that by >>>> adding a >>>> PeerID Shim to exchange the source and destination peerIDs (aka Node-IDs). >>>> >>>> Because of this, it is probably a good idea to add in p2psip-base the >>>> possibility to know the source Node-ID and destination Node-ID of a >>>> message. >>>> One way to do that would have be to have the sender of a message add its >>>> own >>>> Node-ID in the via_list, and the Node-ID of the destination in the >>>> destination_list before sending a message (similar to what SIP is doing), >>>> but I >>>> guess that it is too late for such a modification. >>>> >>>> >>>>> I totally agree that vnodes should share routing state. But it's not >>>>> clear to me what benefit would be obtained by making that sort of a >>>>> protocol change. >>>> >>>>> * on request routing, a message should normally have exactly one >>>>> destination node-id. The only reason to have more would be that the >>>>> request sender has some particular reason to want to source-route the >>>>> request. >>>>> * on response sending, with recursive response you simply want to >>>>> reverse the initial request routing. If there was an advantage to >>>>> "short-cutting" between v-nodes, it would have been done on the >>>>> request routing. If you're not doing recursive response routing, >>>>> then this case is the same as request routing. >>> >>> Let's forget for now the solution I proposed. Do you agree that Section 3 >>> of >>> draft-rosenberg-dispatch-vipr-reload-usage exposes a problem that would be >>> worth >>> been solved in p2psip-base? >> >> I think we're merging two separate issues here: >> >> - how do you differentiate the sender of an end-to-end-message >> - how do you identify the multiple Node-IDs of an adjacent node >> >> For the first, I think SignerIdentity is the logical place. Using >> hash_alg, certificate_hash, and Node-ID would be sufficient. > > I agree, with one caveat: If the sender of the message is also an adjacent > node, and the extension described below is not implemented, then { hash_alg, > certificate_hash, Node-ID } does not permit to differentiate the sender if > there > is multiple Node-IDs in the certificate. This is because the Via is added by > the receiving node instead of the sending node. > Again, I think a new SignerIdentity would be sufficient for identifying the originator of the message. You're right that it doesn't identify the virtual node acting in this case. >> >> For adjacent nodes, I would rather encode it using an IceExtension in >> the Attach sequence that's already flowing than use a shim approach, >> particularly because it avoids issues with datagram protocols. > > OK. I still think that having 1) each node adding the Via before sending > (instead of by the receiving node), 2) all nodes adding the next hop on top of > the destination_list before forwarding and 3) the receiving node dropping the > first node in the destination_list before applying the routing algorithm would > have been a better solution. > This strikes me as a major change, but if you want to start a separate thread on it, we could see if others feel the same way. I think this routing algorithm is only required if we want the property above. No objections to your defining a routing algorithm extension that has this property, of course. >> >> I have mixed feelings on whether either of these should be in the base >> protocol. I really think that SignerIdentity should handle that case. >> But I think the support for multiple NodeIDs over a connection adds a >> lot of complexity and might be better as an extension. > > Well, I am willing to write immediately the I-D for such extension (because my > implementation is using multiple Node-IDs per certificate), so let me know if > this is the way to go. > Probably best to start a separate thread, but I'd be happy to see a draft proposing the IceExtension. Bruce > Thanks. > > - -- > Marc Petit-Huguenin > Personal email: [email protected] > Professional email: [email protected] > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk1SxGMACgkQ9RoMZyVa61dG/QCcC1Kl6ELen4VzE3rJGgfl0F8R > 5PIAoKeX3u87MSGiUpthSqnHY/Emvrhz > =6AGB > -----END PGP SIGNATURE----- > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
