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

"John Buford" <> Fri, 25 November 2011 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8421F21F8B4F for <>; Fri, 25 Nov 2011 09:50:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.895
X-Spam-Status: No, score=-99.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_66=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pj7iLKL96Hn7 for <>; Fri, 25 Nov 2011 09:50:13 -0800 (PST)
Received: from ( [IPv6:2605:dc00:100:2::a8]) by (Postfix) with SMTP id 8ADD021F8B4E for <>; Fri, 25 Nov 2011 09:50:13 -0800 (PST)
Received: (qmail 21490 invoked by uid 0); 25 Nov 2011 17:50:12 -0000
Received: from unknown (HELO ( by with SMTP; 25 Nov 2011 17:50:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=tZK+T8lfFIjJ7XufZusSRxYKtXBnnC/ihVIxLyVcnlE=; b=I6WraVaEFC+memv9042sbNrLoJ8+TS/VG4qiesQkfMRagdkxrJck3cafB8MhUUbB19PGzWDc+ZcvS5GpQLENbe42CuR3tc8/rbtNYm+uV1ZxEZlWzp1Tm3hoTQFbAvJd;
Received: from [] (helo=AGILON) by with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.76) (envelope-from <>) id 1RTzud-0004TE-WD; Fri, 25 Nov 2011 10:50:12 -0700
From: "John Buford" <>
To: "'Marc Petit-Huguenin'" <>, "'John Buford'" <>
References: <> <> <> <004801ccab3b$dcb632d0$96229870$@org> <>
In-Reply-To: <>
Date: Fri, 25 Nov 2011 12:50:12 -0500
Message-ID: <00a301ccab9a$af9ff1f0$0edfd5d0$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcyrinTHhneqRlRbQpOcJ+HNdrK5CQAEB6KQ
Content-Language: en-us
X-Identified-User: {} {sentby:smtp auth authed with}
Cc: 'sam' <>
Subject: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Nov 2011 17:50:14 -0000

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


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

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
that you have to use a ForwardingOptions for this as the nodes will be happy
route any of your messages.  The real problem would be in the interpretation
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
 My initial interpretation was that a response has 1) the same
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
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,
you will have to use the modification that you proposed above.  If they say
only the transaction_id is needed to match them, then your original proposal
would work.

> Thanks for suggestions.
> John
> -----Original Message-----
> From: [] 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:
>>> Hash: SHA1
>>> Sorry for the delay in reviewing this.  I waited to base the review on
>>> implementation, but unfortunately I never got the time to do so.  So
> 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
> 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
> 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
> correctly theses messages.  If the goal is to change the routing
> 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

- -- 
Marc Petit-Huguenin
Personal email:
Professional email:
Version: GnuPG v1.4.11 (GNU/Linux)

SAM mailing list