-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/13/2011 05:04 PM, Bruce Lowekamp wrote: > 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.
OK, fair enough. > However, I think we should move to incorporate the new SignerIdentity > into the base draft and probably handle the IceExtension as a new > draft. OK, I'll write the I-D before the cut-off, and will implement it. Thanks. > 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: > 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) iEYEARECAAYFAk1YlL4ACgkQ9RoMZyVa61dKzwCfXRdXpdciAOD9e34qyEmpuofv +VQAoKbsdbCju6vadmAcdNvUVNTlFy77 =Qayk -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
