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

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 22 Nov 2010 11:32:26 -0800

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.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.

- - 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).

- - 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