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

"Buford, John F (John)" <buford@avaya.com> Tue, 04 September 2012 16:05 UTC

From: "Buford, John F (John)" <buford@avaya.com>
To: "sam@irtf.org" <sam@irtf.org>
Date: Tue, 04 Sep 2012 12:05:57 -0400
Thread-Topic: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00
Thread-Index: Ac2KtufkQKfROgL4Q1ybLKQwZcdbxQ==
Message-ID: <ACCC07BD69AAD84B9383C920F3EBD20343554B0576@DC-US1MBEX5.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_ACCC07BD69AAD84B9383C920F3EBD20343554B0576DCUS1MBEX5glo_"
MIME-Version: 1.0
Cc: "marc@petit-huguenin.org" <marc@petit-huguenin.org>
Subject: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00
Precedence: list

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

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

[SAM] Review of draft-samrg-sam-baseline-protocol… Marc Petit-Huguenin
Re: [SAM] Review of draft-samrg-sam-baseline-prot… Dr Mario Kolberg
Re: [SAM] Review of draft-samrg-sam-baseline-prot… Marc Petit-Huguenin
Re: [SAM] Review of draft-samrg-sam-baseline-prot… John Buford
Re: [SAM] Review of draft-samrg-sam-baseline-prot… Marc Petit-Huguenin
Re: [SAM] Review of draft-samrg-sam-baseline-prot… John Buford
Re: [SAM] Review of draft-samrg-sam-baseline-prot… Buford, John F (John)
Re: [SAM] Review of draft-samrg-sam-baseline-prot… Marc Petit-Huguenin