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

Marc Petit-Huguenin <petithug@acm.org> Wed, 05 September 2012 14:50 UTC

Return-Path: <petithug@acm.org>
X-Original-To: sam@ietfa.amsl.com
Delivered-To: sam@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D1D21F8621 for <sam@ietfa.amsl.com>; Wed, 5 Sep 2012 07:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.79
X-Spam-Level:
X-Spam-Status: No, score=-101.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001, SARE_RMML_Stock1=0.21, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdjZmtMxaoAk for <sam@ietfa.amsl.com>; Wed, 5 Sep 2012 07:50:24 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD6921F84E1 for <sam@irtf.org>; Wed, 5 Sep 2012 07:50:24 -0700 (PDT)
Received: from [IPv6:2001:5c0:1515:1100:213:d4ff:fe04:3e08] (unknown [IPv6:2001:5c0:1515:1100:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id D03C520E87; Wed, 5 Sep 2012 14:50:22 +0000 (UTC)
Message-ID: <504766AC.6070207@acm.org>
Date: Wed, 05 Sep 2012 07:50:20 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6
MIME-Version: 1.0
To: "Buford, John F (John)" <buford@avaya.com>
References: <ACCC07BD69AAD84B9383C920F3EBD20343554B0576@DC-US1MBEX5.global.avaya.com>
In-Reply-To: <ACCC07BD69AAD84B9383C920F3EBD20343554B0576@DC-US1MBEX5.global.avaya.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: "sam@irtf.org" <sam@irtf.org>
Subject: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00
X-BeenThere: sam@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" <sam.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/sam>, <mailto:sam-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/sam>
List-Post: <mailto:sam@irtf.org>
List-Help: <mailto:sam-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/sam>, <mailto:sam-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Sep 2012 14:50:25 -0000

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

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

Hi John,

On 09/04/2012 09:05 AM, Buford, John F (John) wrote:
> 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.

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
> 
> 
> 
> 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 mailing list 
> SAM@irtf.org http://www.irtf.org/mailman/listinfo/sam


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

iQIcBAEBCAAGBQJQR2Z0AAoJECnERZXWan7EBKwQAIPRqRRb5NvSGYFJ88PDBOkf
jEVbaoTGnYAvCyjogNEvqP14zZnac0yTj6PFLYtbunFxQgmUlDd0TaFWcouEOw6I
T1O4pqcezyXIvr11CkQxb+78q9V8W3ZcJD51GQIW1WAwaQGrXzP4Zqf+9ilvPv1r
LfxViHhqTy9xY2Ba+1q8Wnwh5xciOG9RV50tCvJp9qIyaUEMTvqzL0ioGAf5t2XD
4JzrGRQfw6w8BNX1hh5+6lGY1WvFNqLQpqxuihUr3HkyMy6lzSy0LGRsWwJaXARh
+Zt4piQA1ABX3VTCTQa4RiAnZ4YlCdSSWXuCVnvQT/OGGhy62HIsCWXT+Crl3i0Y
zhybYPj8e2oaEvzPDPTmHoVUG2uuCDUftExfHnzHOPNZiQltbjE2t9iIokmS6aHq
dbj+N1dVcv0T9xcgaVdXkoJKWp4Xs0kmV0IqcTsYJc8VbHLgCrSRgx1YcabXtwe0
+3hY+BxbbHLf05rV6h7OoymHtaAq8FbtL+lsQzlocun/4RUoS4FG5CITQUEFGIS2
11gSMe3JSAuhG2h5Bz7pYZ+9cHKyEw54b9TUZTsu0yiobjMpVYC9D4usIOKbIwUB
vDNCisn+DCezVmkwHhkPVkFmI1MjzvbRgDyokih+GZm69j9NLUGthBDI1hbf1nVJ
wzN4kOYAVNFyCLzdPwbR
=bIeA
- -----END PGP SIGNATURE-----

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

iQIcBAEBCAAGBQJQR2aqAAoJECnERZXWan7ErYIP/AqS7mgihFyyUDHmiA/9LAmr
pA1f6zVF4tQFvBvo6WGUJT5uruIV46ZLadOzRZjVrLrC9u7y+fnb+QbaghbvfLFx
UDF3HK8P1Z8NJcH2yLsxw4nH4asm0uvrSxWpB09AOMkIlmoTNG+uyk8JPu6grtHZ
hSzPp5qpoywrvHhbvHBag8jrQqvAKXKdjU1Vt8Cb7y8rbwfWna/IpkH9xPMf3GTA
9SFC/g0PAh80cajjWxBBBhpTKIutMeTYPS27KauuTLoQFYc1cUr0XJtBfo/g/8pm
qFIDFjTCMQJKI8HhVhZh8f8yzs40CHr7yrHNCP9QUCoIBvaA2Ipo7vlYoUyEh4GH
joxSfL1zSUUXIrJ9DHxgaQWXc85vbtRNfT7Lqp7VbVx2N5KEjxQgfoON5Czm3dBc
EQXXTkuVWXBfdSrJpjlBoxQzAfQMv+Th1VIn52HmZrvj90DbZgeyCp6pJSJeKLK1
y/6+DEacHDi6h8p/WCRIUblD8g6cYBlc6JJhuDjrfR41Op20Ut+ZndkdSPzOK6Sp
pqdWtrFa008OLEBk3sBh+fDv/aGC4geGiS5zSrVjIivY+fkMlwpO0/l4GDbzfJ30
mrRx3aEkgOeOIQNwsxk0l4lzXmfPA276AAirePFZadRgS3ZeMMz5LjWsGAlvgBJ4
OzhtfiLu0f0laYisCXv4
=rkIT
-----END PGP SIGNATURE-----