-----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? 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) iEYEARECAAYFAk0ri7wACgkQ9RoMZyVa61edGQCggzZ04xzB0pc2jQZrDTeAFQdP 1bYAniaPm1eH+YU3FHSv9txq7DV3IEwI =oZBv -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
