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

["John Buford" <[e-mail]>]

Yes this is a good question to bring to the P2PSIP mailing list.  I will
post it there.

Thanks,
John

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Marc
Petit-Huguenin
Sent: Friday, November 25, 2011 10:54 AM
To: John Buford
Cc: 'sam'
Subject: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00

-----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: [e-mail] [mailto:[e-mail]] 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
[e-mail]
http://www.irtf.org/mailman/listinfo/sam

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

iEYEARECAAYFAk7PuesACgkQ9RoMZyVa61eS5QCeLw+RUN9zTTCN139hgce33xln
+88An0Njb1EVqTgQNpPiPxJ4waW5gLee
=beQx
-----END PGP SIGNATURE-----
_______________________________________________
SAM mailing list
[e-mail]
http://www.irtf.org/mailman/listinfo/sam