-----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. > 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.
I spent more time on this problem(s) (the fact that the information on a specific subject are scattered all over the I-D does not help, for sure), and I am now less sure that there is a need for this changes. Let's take the issues one by one: 1. Connections sharing: I am still running some simulations and so far I do not have an definitive answer, so let forget about this for now. Hopefully it could be done as an extension, as you suggested. 2. Knowing the Node-ID of the sender of an end-to-end message, when multiple Node-IDs are used in the certificate: - - If the message is a request and traversed at least one peer, then the sender Node-ID will be the first Node-ID in the via list. - - If the message is a request that was sent over a direct connection, then the sender Node-ID is the Node-ID associated with the connection - see (3). - - If the message is an answer, then the sender Node-ID is the same Node-ID that was used to send the matching request. An implementation had to store it for the end-to-end retransmission, so it is retrievable from the transaction-id. 3. Knowing the Node-ID of the sender of a message on a direct connection, when multiple Node-IDs are used in the certificate: - - Because direct connections are established by Attach, the Node-ID of the sender of a message on a direct connection is also the Node-ID of the sender of the Attach message (request or answer) that was used to establish the direct connection - see (2). Now there is one case that does not work: a client with a certificate with multiple Node-IDs. Because a client connects directly to a bootstrap peer (without Attach), the bootstrap node has no way to know which Node-ID to choose on the certificate. When the Attach to the admitting peer will be sent by the client, the bootstrap peer will not be able to know what Node-ID to add in the via list, and so will not be able to route back the answer. And neither a new SignerIdentity or IceExtension can help in this case. So because it is not possible to join an overlay with a certificate containing multiple Node-IDs, the only way it could work would be to join with a certificate containing one Node-ID then after the Attach to the admitting peer switch to a certificate with multiple Node-IDs. Was that the intent? - -- 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.11 (GNU/Linux) iEYEARECAAYFAk1gWAAACgkQ9RoMZyVa61fFXwCfegOrqYADs9809eM+N0y5muMA gRUAn2x4ZThclCBYbEZ4aMMmrM4p+3PO =gCJY -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
