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. 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. 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. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
