inline On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > More questions, comments and nits: > > - - A.9. In section 5.1.2, 5th paragraph: "As an example of the second > strategy, > if node D receives a message from node C with transaction X and via list (A, > B), > it could store (X, C) in its state database and forward the message with the > via > list unchanged. When D receives the response, it consults its state database > for transaction id X, determines that the request came from C, and forwards > the > response to C." > > If I understand correctly this whole paragraph, when a message is forwarded it > keeps the same transaction_id, because if the response received by D was > using a > different transaction_id, say Y, it could not retrieve (X, C) from the state > database. Is this analysis correct?
A message should always keep the same transaction ID. The paragraph is really just trying to point out that you can keep a map of tid -> return node for your routing state. > > - - 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. > - - A.11. Looking at the examples in section 3.3, it seems that the via_list > is > updated only when the message forwarded is a request but not for responses, > but > I cannot find this anywhere in the text. So are all messages processed the > same > way when forwarded (and via updated on all types of messages) or specifically > on > requests? (by testing the last bit of message_code). > I think it's implied in 5.1 that the via list is only added to on request routing and not response, but I believe it should be made more clear. Bruce > - - A.12. Section 10.3 states that "[t]he SubjectAltName field in the > certificate > contains the following values: One or more Node-IDs...", but nowhere it is > said > how to request multiple Node-IDs. Is it an URL parameter of the POST request? > An attribute in the Certification Request object? > > > Nits > ==== > > - - Section 5.3, in the list "Security Block:" > > s/""Message Contents"/"Message Contents"/ > > - - Section 5.3.2.1 > > s/destination_value/destination_data/ > > - - Section 5.3.4 "overlay + transaction_id + MessageContents + > SignerIdentity" > > The "+" should probably be replaced with "||". > > > - -- > 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) > > iEYEARECAAYFAkzqxUgACgkQ9RoMZyVa61fLpQCglb3AQGXUnEmD6athMaIGFBAx > vLkAn2r+Gy54Z/sJHMNv/j0i4Ic4y2ZZ > =bP6t > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
