Subject: Re: [P2PSIP] draft-ietf-p2psip-base-12 (2)

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 7 Jan 2011 17:24:25 -0500

inline

On Mon, Nov 22, 2010 at 2:32 PM, Marc Petit-Huguenin <[email-masked]> 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-masked]
> Professional email: [email-masked]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 10 Jan 2011 14:44:14 -0800

Thanks for your responses. see below for more comments.

> More questions, comments and nits:

[...]

> 
> - A.10. It seems that this version of RELOAD lacks the support of virtual

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Jan 2011 15:42:59 +0200

On Nov 22, 2010, at 11:32 AM, Marc Petit-Huguenin wrote:
> ]

I don't think I understand your point about destination node-ids. They will
be in the destination list, no? I agree about source.

We would also need to add text about populating the routing table with
"accidental" adjacencies. I.e., if you connect to node 1234 and it gives you
a cert for 1234 and 5678 you need to automatically add that as a routing
adjacency.

> An attribute in the Certification Request object?

Good question. This is an issue that's simply not addressed in the draft., but presumably
we'll need to do something like this, yeah. My taste would be for it to be a URL in the POSt.

> The "+" should probably be replaced with "||".

Done.

-Ekr

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 21 Jan 2011 10:16:16 -0800

On 01/07/2011 02:24 PM, Bruce Lowekamp wrote:
> - A.9. In section 5.1.2, 5th paragraph: "As an example of the second strategy,

In fact this is implied by the fact that the Signature in the SecurityBlock
covers transaction_id.  Sorry for that.

- -- 
Marc Petit-Huguenin