-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
> 
> -----Original Message-----
> From: sam-bounces@irtf.org [mailto:sam-bounces@irtf.org] On Behalf Of Marc
> Petit-Huguenin
> Sent: Thursday, November 24, 2011 11:52 AM
> To: Dr Mario Kolberg
> Cc: sam
> Subject: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00
> 
> Hi,
> 
> More comments below.
> 
> On 11/17/2011 08:29 AM, Dr Mario Kolberg wrote:
>> Dear Marc,
> 
>> many thanks for your review. See below for our responses:
> 
>> On 06/11/2011 18:11, Marc Petit-Huguenin wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Sorry for the delay in reviewing this.  I waited to base the review on an
>>> implementation, but unfortunately I never got the time to do so.  So this
> is
>>> only a partial review.
>>>
>>>
> 
> [...]
> 
>>> 3. Section 7.2.1 structure definition
>>>
>>> The Dictionary type is not defined in this spec.
>>>
>>> Also I would suggest to follow the standard convention of using lowercase
> for
>>> the character of a field.
>> Reload defines DictionaryEntry (section 6.2.3). Dictionary is a 'data
> model'
>> (section 6.2).
> 
> But Dictionary is never defined as a data structure in RELOAD, and even if
> it
> was defined as an array of DictionaryEntry, that would not match the text
> ("name-value list of properties...") - the closest structure definition that
> matches this text in RELOAD would be IceExtension.
> 
> I would suggest to explicitly define Dictionary as follow:
> 
> struct {
>   opaque name<0..2^16-1>;
>   opaque value<0..2^16-1>;
>   } DictionaryElement;
> 
> struct {
>   DictionaryElement elements<0..2^16-1>;
>   } Dictionary;
> 
>>> 4. Section 7.2.[2-5]
>>>
>>> RELOAD message are client/server based.  A request is sent and
> retransmitted
>>> until a matching response is received.  I am sure how the
>>> Join/JoinAccept/JoinConfirm/JoinDecline mechanism is working inside this
>>> framework.
>>>
>> For Join,  JoinAccept and JoinReject  are matching responses.
> 
> But this is not how the RELOAD routing works.  RELOAD says that a response
> uses
> the code value + 1 of the request, excepted for the ErrorResponse.  The
> problem
> here is that a standard implementation of RELOAD will not be able to process
> correctly theses messages.  If the goal is to change the routing algorithm,
> I
> would suggest to add a ForwardingOption to each message, with the
> FORWARD_CRITICAL flag set, so standard RELOAD implementations do not even
> try to
> route these.
> 
> [...]
> 
_______________________________________________
SAM mailing list
SAM@irtf.org
http://www.irtf.org/mailman/listinfo/sam

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk7PuesACgkQ9RoMZyVa61eS5QCeLw+RUN9zTTCN139hgce33xln
+88An0Njb1EVqTgQNpPiPxJ4waW5gLee
=beQx
-----END PGP SIGNATURE-----