-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
>
> 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.
>
> 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.
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)
iEYEARECAAYFAk1SxGMACgkQ9RoMZyVa61dG/QCcC1Kl6ELen4VzE3rJGgfl0F8R
5PIAoKeX3u87MSGiUpthSqnHY/Emvrhz
=6AGB
-----END PGP SIGNATURE-----
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
