Subject: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00

From: "Buford, John F (John)" <[email-masked]>
Date: Tue, 4 Sep 2012 12:05:57 -0400

Marc,

Below was one item you raised previously.

However I think this is no longer relevant to our draft, since all of our messages are being mapped to
exp_{a,b}_req, exp_{a,b}_rsp, which enables response code +1 to request code for all messages.
That is, in previous draft we introduced our own experimental message codes beyond those listed in 14.8
of RELOAD; but we aren't using that approach now that RELOAD has introduced 2 sets of experimental messages.

As far as I can tell, we don't depend upon any special request-response matching for RELOAD implementation.

Regards,
John

On 11/24/2011 10:31 PM, John Buford wrote:
> Agree with the dictionary definition suggestion.
>
> For the JoinRequest => JoinAccept,JoinReject 3-some,
> we could do JoinRequest => JoinResponse with sub-types for the response
> Accept,Reject
>
> I wasn't aware that all message routing required an encoded "+1" response.

OK, let me backtrack a little bit here.  After checking the spec, I do not think
that you have to use a ForwardingOptions for this as the nodes will be happy to
route any of your messages.  The real problem would be in the interpretation by
an implementation of this text in 5.2.1:

"Because messages may be lost in transit through the overlay, RELOAD
incorporates an end-to-end reliability mechanism.  When an
originating node transmits a request it MUST set a timer to the
current overlay-reliability-timer.  If a response has not been
received when the timer fires, the request is retransmitted with the
same transaction identifier.  The request MAY be retransmitted up to
4 times (for a total of 5 messages).  After the timer for the fifth
transmission fires, the message SHALL be considered to have failed.
Note that this retransmission procedure is not followed by
intermediate nodes.  They follow the hop-by-hop reliability procedure
described in Section 5.6.3."

The question here is how does this mechanism matches a response with a request.
My initial interpretation was that a response has 1) the same transaction_id
and 2) either message_code equals to the request message_code + 1 or to the
error value (0xffff).  So I guess that it depends on the interpretation of a
particular implementation.  In all cases, I would suggest to ask the authors of
draft-ietf-p2psip-base for a clarifications on the rules to use to match a
response with a request.  If they say that my interpretation is correct, then
you will have to use the modification that you proposed above.  If they say that
only the transaction_id is needed to match them, then your original proposal
would work.

> Thanks for suggestions.
> John

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 05 Sep 2012 07:50:20 -0700

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi John,

On 09/04/2012 09:05 AM, Buford, John F (John) wrote:
> of RELOAD; but we aren’t using that approach now that RELOAD has
> introduced 2 sets of experimental messages.
> 
> 
> 
> As far as I can tell, we don’t depend upon any special request-response 
> matching for RELOAD implementation.

Yes, but this is still not implementable.  First of all there is no
explanation on how the sub-types listed in section 15 are used.  -base does
not define the format of exp_a_req, exp_a_ans, exp_b_req or exp_b_ans, so this
spec has to provide the definitions of these requests/answers for this usage,
in which the sub-type will be defined.

Then there is "Create Tree" (section 7.2.1), where some of the text seems to
say that this is a new Request/Response (and the example seems to support
that) but the rest talks about a Store.  So is it a new request/response or is
it a Store?  Additionally, and assuming it is a Store, then the rules listing
at the end of the section do not match any existing access control policy, so
a new one would have to be defined.

And talking about example, it seems to not have been updated for the messages,
i.e. none of the JoinXXX requests are matched with JoinXXX answers.

Note that this is still not a complete review, just immediate problems that I
see preventing a review (as I do reviews by implementing I-Ds, or in this
case, evaluating what I would do to implement them).

> 
> 
> 
> Regards,
> 
> John
> 
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Hash: SHA1
> 
> 
> 
> _______________________________________________ SAM mailing list 
> [email-masked] http://www.irtf.org/mailman/listinfo/sam

- - --
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

=bIeA
- -----END PGP SIGNATURE-----

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug