From petithug@acm.org Sun Nov 6 10:12:02 2011 Return-Path: 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 1C8E521F85A7 for ; Sun, 6 Nov 2011 10:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY22lyJ9cZc1 for ; Sun, 6 Nov 2011 10:12:01 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDF921F85A8 for ; Sun, 6 Nov 2011 10:12:01 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3813D20138 for ; Sun, 6 Nov 2011 18:02:54 +0000 (UTC) Message-ID: <4EB6CDEE.6020408@acm.org> Date: Sun, 06 Nov 2011 10:11:58 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: sam@irtf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 18:12:02 -0000 -----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. 1. Title I do not know if the rules are different for the IRTF, but shouldn't this draft been called draft-irtf-samrg-sam-baseline-protocol instead? 2. Section 7.2.1 "...peer id closest to and less than the GroupId" This idea of a Node-ID been close to another ID is specific to certain types of overlays (like the CHORD-RELOAD default), but will probably do not make sense for other types. The text either need to be modified to work with any type of overlay, or to explicitly say that this draft is only for RELOAD overlays in which this make sense. 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. 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. 5. Section 10.1. Data Model section The Data Model is probably SINGLE here. 6. Section 10.1. Access Control section The Access Control policy NODE-MATCH assumes that the Resource Name is the Node-ID of signer of the ALMtree entry. If you want to use the SessionKey as Resource Name, you probably need to define a new Access Control policy. Nits - ---- - - Section 5 s/Register Kind-ID points/Register Kind-ID codepoints/ - - Section 7.3.3 s/diffent/different/ - - Section 7.2.6 s/idenfied/identified/ - - Section 8.2 s/rendevous/rendezvous/ - - Section 8.5 s/conirm/confirm/ - -- 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) iEYEARECAAYFAk62ze0ACgkQ9RoMZyVa61cC4ACdGKlVx8bm1sQr017foMaDhyze Eg4AnR557TEUHu6CTi1qcyrRGnACiuHO =cqrN -----END PGP SIGNATURE----- From petithug@acm.org Mon Nov 14 09:33:56 2011 Return-Path: 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 ED37911E8151 for ; Mon, 14 Nov 2011 09:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhlFv-kX3oGV for ; Mon, 14 Nov 2011 09:33:52 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A8F0E11E81B8 for ; Mon, 14 Nov 2011 09:33:52 -0800 (PST) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 2C5A820371; Mon, 14 Nov 2011 17:24:11 +0000 (UTC) Message-ID: <4EC150F9.8090109@acm.org> Date: Tue, 15 Nov 2011 01:33:45 +0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: Alexander Knauf References: <20111024171352.31303.35874.idtracker@ietfa.amsl.com> <4EA5A0E1.6070105@haw-hamburg.de> In-Reply-To: <4EA5A0E1.6070105@haw-hamburg.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: sam@irtf.org, P2PSIP Mailing List Subject: Re: [SAM] [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-share-02.txt 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:33:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (CCed SAMRG mailing-list as this is where this draft will be presented - Unfortunately I will not be able to attend because of a conflict with VIPR) This version of the draft closes all my previous comments. I unfortunately did not had the time to finish my implementation of this in my RELOAD code and in Wireshark, but I will report of the status as soon as I can get this done. I support the adoption of this draft as a P2PSIP WG item. On 10/25/2011 01:31 AM, Alexander Knauf wrote: > Hi all, > > we updated our draft for Shared Resources (ShaRe) in RELOAD. Link: > > http://tools.ietf.org/html/draft-knauf-p2psip-share-02 > > regards, > > Alexander > > A new version of I-D, draft-knauf-p2psip-share-02.txt has been successfully > submitted by Alexander Knauf and posted to the IETF repository. > > Filename: draft-knauf-p2psip-share > Revision: 02 > Title: A Usage for Shared Resources in RELOAD (ShaRe) > Creation date: 2011-10-24 > WG ID: Individual Submission > Number of pages: 23 > > Abstract: > This document defines a RELOAD Usage for managing shared write access > to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic > primitive for enabling various coordination and notification schemes > among distributed peers. Access in ShaRe is controlled by a > hierarchical trust delegation scheme maintained within an access > list. A new USER-CHAIN-ACL access policy allows authorized peers to > write a Shared Resource without owning its corresponding certificate. > This specification also adds mechanisms to store Resources with a > variable name which is useful whenever peer-independent rendezvous > processes are required. > > > > > The IETF Secretariat > - -- 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) iEYEARECAAYFAk7BUPMACgkQ9RoMZyVa61d+tQCeIoXtA9D8P20lIq4BOkZocAPA a48An3EUgA8MVoRy2rH9L4ejJ65UUqNu =J8mf -----END PGP SIGNATURE----- From prvs=295436d8b=schmidt@informatik.haw-hamburg.de Thu Nov 17 03:33:31 2011 Return-Path: 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 BFCD311E80AD for ; Thu, 17 Nov 2011 03:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVEmZvb22wrp for ; Thu, 17 Nov 2011 03:33:31 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id CE65811E8089 for ; Thu, 17 Nov 2011 03:33:30 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 17 Nov 2011 12:33:27 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 64F0E102A1E0 for ; Thu, 17 Nov 2011 12:33:27 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32053-06 for ; Thu, 17 Nov 2011 12:33:23 +0100 (CET) Received: from [130.129.83.194] (dhcp-53c2.meeting.ietf.org [130.129.83.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 187A9102A1DC for ; Thu, 17 Nov 2011 12:33:22 +0100 (CET) Message-ID: <4EC4F103.4010903@informatik.haw-hamburg.de> Date: Thu, 17 Nov 2011 19:33:23 +0800 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sam Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Subject: [SAM] Slides and minutes online 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 11:33:31 -0000 Hi all, slides & minutes are online: https://datatracker.ietf.org/meeting/82/materials.html#wg-SAMRG Have a safe trip home Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409° From mko@cs.stir.ac.uk Thu Nov 17 08:30:34 2011 Return-Path: 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 4889E21F9918 for ; Thu, 17 Nov 2011 08:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVwOTRr83HgP for ; Thu, 17 Nov 2011 08:30:33 -0800 (PST) Received: from bannock.stir.ac.uk (bannock.stir.ac.uk [139.153.12.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71421F9917 for ; Thu, 17 Nov 2011 08:30:32 -0800 (PST) Received: from smtp.stir.ac.uk ([139.153.13.214]) by bannock.stir.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RR4qe-0003sy-2L; Thu, 17 Nov 2011 16:30:00 +0000 Received: from d253090.cs.stir.ac.uk ([139.153.253.90]) by smtp.stir.ac.uk with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RR4qd-0003gH-SV; Thu, 17 Nov 2011 16:29:59 +0000 Message-ID: <4EC53685.7080801@cs.stir.ac.uk> Date: Thu, 17 Nov 2011 16:29:57 +0000 From: Dr Mario Kolberg User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Marc Petit-Huguenin , sam References: <4EB6CDEE.6020408@acm.org> In-Reply-To: <4EB6CDEE.6020408@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-stir.ac.uk-MailScanner-ID: 1RR4qe-0003sy-2L X-stir.ac.uk-MailScanner: Found to be clean 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 16:30:34 -0000 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. > > > 1. Title > > I do not know if the rules are different for the IRTF, but shouldn't this draft > been called draft-irtf-samrg-sam-baseline-protocol instead? You are correct. Title will be changed. > 2. Section 7.2.1 "...peer id closest to and less than the GroupId" > > This idea of a Node-ID been close to another ID is specific to certain types of > overlays (like the CHORD-RELOAD default), but will probably do not make sense > for other types. The text either need to be modified to work with any type of > overlay, or to explicitly say that this draft is only for RELOAD overlays in > which this make sense. RELOAD spec states that they support unstructured overlays as well. It would be nice to retain that flexibility. We propose to change the text to: "The usual interpretation in a DHT based overlay of group_id is that the peer with peer id closest to and less than the group_id is the root of the tree. However, other overlay types are supported." > 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). Will change to lowercase. > 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. If JoinReject is received, then no further action occurs on this request. If JoinAccept, then JoinConfirm and JoinDecline are the possible matching responses. With these changes, then Join and JoinAccept will be treated as requests as in RELOAD which are retransmitted until either retry limit is reached or a matching response received, > 5. Section 10.1. Data Model section > > The Data Model is probably SINGLE here. > 6. Section 10.1. Access Control section > > The Access Control policy NODE-MATCH assumes that the Resource Name is the > Node-ID of signer of the ALMtree entry. If you want to use the SessionKey as > Resource Name, you probably need to define a new Access Control policy. This sections are currently removed from the draft. > > Nits > - ---- all fixed. Thanks! Regards, Mario -- The Sunday Times Scottish University of the Year 2009/2010 The University of Stirling is a charity registered in Scotland, number SC 011159. From prvs=2982c82c3=till.steinbach@informatik.haw-hamburg.de Sun Nov 20 07:42:53 2011 Return-Path: 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 ED92321F8558 for ; Sun, 20 Nov 2011 07:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3MmX0H8DjLc for ; Sun, 20 Nov 2011 07:42:52 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 36C8121F853E for ; Sun, 20 Nov 2011 07:42:51 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 20 Nov 2011 16:42:46 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 8FA34102A1FC for ; Sun, 20 Nov 2011 16:42:46 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13453-09 for ; Sun, 20 Nov 2011 16:42:46 +0100 (CET) Received: from till.fritz.box (port-33987.pppoe.wtnet.de [46.59.183.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id E1A52102A1D5 for ; Sun, 20 Nov 2011 16:42:45 +0100 (CET) From: Till Steinbach Content-Type: multipart/signed; boundary="Apple-Mail=_BBB86998-63BF-4915-BAC2-C43F036A66D2"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sun, 20 Nov 2011 16:42:45 +0100 Message-Id: <44EBEC74-E33F-43C1-8D28-97CA910E73EA@informatik.haw-hamburg.de> To: sam@irtf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Subject: [SAM] Call for Papers - 5th International Workshop on OMNeT++ in conjunction with SimuTools 2012 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 15:42:54 -0000 --Apple-Mail=_BBB86998-63BF-4915-BAC2-C43F036A66D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 [Our apologies if you receive multiple copies of this CFP] This is a friendly reminder that it is only one week away from the paper submission deadline of OMNeT++ Workshop 2012. The deadline is November = 28th, 2011. CALL FOR PAPERS ----------------------- 5th international OMNeT++ Workshop to be held in conjunction with = SIMUTools 2012, Sirmione, Italy - March 23th, 2012 OMNeT++ is a public-source, component-based, modular and = open-architecture simulation environment with strong GUI support and an embeddable = simulation kernel. It is designed to simulate discrete event systems, but the = primary application area is the simulation of communication networks. The continuing goal of this workshop is to bring together OMNeT++ = developers and their tools, applications and ideas. It provides a forum for presentations of recent developments and novel ideas in the broad area = of network simulation, with focus on OMNeT++ and on the important topics of integrating simulation models, coupling different simulation tools and providing more accurate and more efficient modeling approaches. Topics of interest include, but are not limited to: - Evaluation and validation of simulation models - Comparison with other simulation/emulation tools - Parallel simulation and simulation control - Integration of hardware-specific code - Simulation of communication networks - Cross-layer protocol design methodologies - Integration with other simulation tools - Result interpretation and analysis - Modeling techniques - Simulation in the loop - Industrial applications - Use of OMNeT++ in other domains SUBMISSION INSTRUCTIONS ------------------------------------- This year, three types of submissions are possible for the authors: - Full papers (max. 8 pages) - Short papers (max. 4 pages) - Code contributions (max. 2 pages) The first two types of submissions, full and short papers should be = prepared in ACM conference proceedings format. OMNeT++ should play a key role as = a tool to evaluate and study new systems, or to answer open research questions, or to provide novel simulation techniques. The papers that = are accepted and presented at the workshop will appear in CD proceedings, in = the ACM Digital Library (DL), and in EU-DL, along with the SimuTools 2012 proceedings. For the third type of submission, developers are encouraged to = contribute extended abstracts of up to 2 pages describing new code contributions to OMNeT++ or model frameworks. The source code and a user manual should be submitted together with the extended abstract. Code contributions = abstracts will be presented as posters at the workshop and will be made available = to all participants and on the OMNeT++ website. Please note that this type = of submission will not be included in the ACM DL, nor will it be indexed. However, if the contribution is of significant scientific value, authors = are encouraged to submit it as a short paper instead. However, the TPC will provide reviews and feedback on poster abstracts and the poster session = will be an excellent opportunity to highlight your work in the OMNeT++ = community. Detailed submission instructions, together with format files, are = available on the website: http://www.omnet-workshop.org=20 IMPORTANT DATES -------------------------- - Full paper submission: November 28th, 2011 - Notification of acceptance: January 15th, 2012 - Camera-Ready version: February 15th, 2012 - Conference: March 23th, 2012 All deadlines are 23:59 UTC ORGANIZING COMMITTEE ---------------------------------- Founding Chair: - Andras Varga, Simulcraft Inc. Workshop Co-Chairs: - Anna F=F6rster, Networking Lab/SUPSI, Switzerland - Laura Marie Feeney, SICS, Sweden TPC Co-Chairs: - Andreas Lewandowski, TU Dortmund University - Athanassios Boulis, NICTA, Australia Publicity Co-Chairs: - Christian M=FCller, TU Dortmund University - Till Steinbach, HAW Hamburg, Germany Program committee: - Alfonso Ariza, Universidad de M=E1laga, Spain - Ingmar Baumgart, Karlsruhe Institut of Technology, Germany - Athanassios Boulis, NICTA, Australia - Bart Braem, University of Antwerp, Belgium - Bogdan Ciubotaru, Dublin City University, Ireland - Laura Marie Feeney, Swedish Inst. of Computer Science, Sweden - Federico Ferrari, ETH Zurich, Switzerland - Anna F=F6rster, NetLab, SUPSI, Switzerland - Patrick Haeflinger, Alcatel-Lucent, France - Olafur Helgason, KTH - Royal Institute of Technology, Sweden - Andreas Lewandowski, TU Dortmund, Germany - Juan Carlos Maureira, University of Chile, Chile - Christian M=FCller, TU Dortmund, Germany - Dimosthenis Pediaditakis, Imperial College London, United Kingdom - Congduc Pham, University of Pau, France - German Rodriguez, IBM Zurich Research Labs, Switzerland - Silvia Santini, ETH Zurich, Switzerland - Thomas Schmidt, HAW Hamburg, Germany - Christoph Sommer, University of Innsbruck, Austria - Till Steinbach, HAW Hamburg, Germany - Yuri Tselishchev, NICTA, Australia - Klaus Wehrle, RWTH Aachen, Germany - Lars Wischhof, Audi Electronics Venture, Germany - Matthias W=E4hlisch, Freie Universit=E4t Berlin, Germany - Zarrar Yousaf, NEC Research Labs, Germany CONTACT ------------- Please send an e-mail to the organizing committee (general@omnet-workshop.org) or visit the workshop website at http://www.omnet-workshop.org/2012/ for further information. Best regards and hope to see you at the OMNeT++ Workshop in March 2012!= --Apple-Mail=_BBB86998-63BF-4915-BAC2-C43F036A66D2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGOzCCBjcw ggQfoAMCAQICAwojVDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTA0MjYwODQxMzZaFw0x MzA0MjUwODQxMzZaMIHTMRcwFQYDVQQDEw5UaWxsIFN0ZWluYmFjaDElMCMGCSqGSIb3DQEJARYW bWFpbEB0aWxsLXN0ZWluYmFjaC5kZTEqMCgGCSqGSIb3DQEJARYbdGlsbC5zdGVpbmJhY2hAaW5u b3ZhbGFuLmRlMTcwNQYJKoZIhvcNAQkBFih0aWxsLnN0ZWluYmFjaEBpbmZvcm1hdGlrLmhhdy1o YW1idXJnLmRlMSwwKgYJKoZIhvcNAQkBFh10aWxsLnN0ZWluYmFjaEBoYXctaGFtYnVyZy5kZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtIHeQ//d6SikAdHSIoUObfIXu1u81Psk2k AWHviZDl+MdisD1ZJSA5Ikti8IlRrfNXRRfKaa4tKkLEC0w+f7jQjxC7U5UNzwoRFh4GnPu2XLLm HD9GWaYNxlf90muc0hhBrM8D+WCrYCKXRxl88kzhCDPs7XluwBGBSzpRmbL7ShPiXcfWYdrDA0be 4dFOOWFT5Q3ta6/OzH/6yUdMkLvhNJ1WuyeOmODXDt7qoMpPaoMBYTUOUIyqmvQxCIRK1tXgdTgw /FvuWbJbaAarVYqnJGgqpwIUkzArztTvrbgo18+WuvRXq/Met/lMP83XuE3j/dwavB7B03EHBHFD e5cCAwEAAaOCAWswggFnMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQu b3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoD AwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2Fj ZXJ0Lm9yZzCBiAYDVR0RBIGAMH6BFm1haWxAdGlsbC1zdGVpbmJhY2guZGWBG3RpbGwuc3RlaW5i YWNoQGlubm92YWxhbi5kZYEodGlsbC5zdGVpbmJhY2hAaW5mb3JtYXRpay5oYXctaGFtYnVyZy5k ZYEddGlsbC5zdGVpbmJhY2hAaGF3LWhhbWJ1cmcuZGUwDQYJKoZIhvcNAQEFBQADggIBAKDHUThu vaEPTjCQqiaFmAHsbDTp9xSsn5nRAiJkgjXvn0G9fI/+35sR7gqICLLPXbJGozmYJVPya+4Xhoh+ Csm6nX06OFGo0PoI/RAKehbwFP6AsrZ+BAx+tI2yFofKd3ZjcddTLlZkTxebrIzneuqoOghoiYZE VyVyzdV07AED0ivRedJEvyOUmC/HX/w+XK/h4M76QkqdSpO1HYQxkpxyMbYo8z2whX1GSi3zwSZf M1dOVDjpwVkhQNw9kxbMUm5j0COLMSZlTiQaf5wsThza81WI2gGspommns/7YPXKR8lT8Vv7MpTq MkUcFcfvfeh8QzaP/BvVwaQzdMqtB9W8wtP/aXYZ7uRepByWYG/TeAItLSrWyGDu6aLDhehG3HgR p48CGLoaFT1/ppsKHvU/dj276KdaL2pA56QH6ryLdJwx8FhGIYpbFmg31TZ3SzWX2m0UBUBrSWOw ChqAyJ0cU84gR4e9e2NxAIYOOH6JaElJMVDFpqWIsryX25Lop3p/NJFhTVA7W21CoC2yzllIB06l k/BvM5/FcrW6kcBup00bA02ims6l6wYdTTjcJhnOhk9sn12pyCs9n2Ayc+4ajLaxbXHCnBfHxtHN 9fE310irK9N6rpFh71la8ucNLoOdyJ4IWNa1xK5T+6XnHv+desdXRheWAfk7IbK52VscMYIDMzCC Ay8CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQu b3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJz dXBwb3J0QGNhY2VydC5vcmcCAwojVDAJBgUrDgMCGgUAoIIBhzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTExMjAxNTQyNDZaMCMGCSqGSIb3DQEJBDEWBBSDsD43 FsAI6PPMD6Q3Zqtr6u2naDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKI1QwgZMGCyqG SIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cu Y2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKI1QwDQYJKoZIhvcNAQEBBQAEggEArcuMVepFJxFt tIqQ2Lj1E5xkSUOHmNY6IVqMA8+t6QKu4RW9S9GbCMwlqTlC9D0wbVB1nJKuAegQriU3d9T0PuTV g50C8J9Xff14ZxQq0Wr/XRCmxOB+c85RBaz1c5CJUUe5KjYm4tStP6tOxWT81hBrhEBRP8pdYVMG hBgNmtbh8i01XbAsLRFLmTbJv+2HxVzyVVR2EVUG0CP06XrobAhsuIQHMOFbeJ/11aQwmm09cuXn cy4fjVpLDc57CzFefadku0/7fHNQusZ13kICUBS/R/2laujiYKz+B7+c2vPUTmp2Mz4kIjUOEiry rWyB4gyoMe+kxRHl7U3XosX27gAAAAAAAA== --Apple-Mail=_BBB86998-63BF-4915-BAC2-C43F036A66D2-- From petithug@acm.org Thu Nov 24 08:52:51 2011 Return-Path: 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 DF74021F8BD5 for ; Thu, 24 Nov 2011 08:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7cNNJK+zvDp for ; Thu, 24 Nov 2011 08:52:51 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF5F21F8BBB for ; Thu, 24 Nov 2011 08:52:51 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 424A920142; Thu, 24 Nov 2011 16:42:17 +0000 (UTC) Message-ID: <4ECE764E.1040202@acm.org> Date: Thu, 24 Nov 2011 08:52:30 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16 MIME-Version: 1.0 To: Dr Mario Kolberg References: <4EB6CDEE.6020408@acm.org> <4EC53685.7080801@cs.stir.ac.uk> In-Reply-To: <4EC53685.7080801@cs.stir.ac.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: sam 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 16:52:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. [...] - -- 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) iEYEARECAAYFAk7Odk0ACgkQ9RoMZyVa61dp0wCdF2Znb/RGGPDTBOKxYWqT+U+e H4EAnjP8q8J9yjFCwdaMPy+XVHVuIzUJ =S1qj -----END PGP SIGNATURE----- From buford@samrg.org Thu Nov 24 22:31:35 2011 Return-Path: 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 0180D1F0C4B for ; Thu, 24 Nov 2011 22:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.895 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLDjLsel-UH4 for ; Thu, 24 Nov 2011 22:31:30 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 3FE131F0C34 for ; Thu, 24 Nov 2011 22:31:30 -0800 (PST) Received: (qmail 13474 invoked by uid 0); 25 Nov 2011 06:31:28 -0000 Received: from unknown (HELO host181.hostmonster.com) (74.220.207.181) by oproxy3.bluehost.com with SMTP; 25 Nov 2011 06:31:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samrg.org; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=Ucn2e2jGOIjUGYWWawlZ1CirQYePdO5bb8oiXK77FPc=; b=e2vyCbLKtoVjesDA+Qn9HHZOU4T/nsj/BXWZ0WffFFkP8L/CA1tbgwRuZTIeUt6YN8wblPav/gJnPaNcn9ePXlz8FJ21HnYRmWl6Kv5q8kck4BEWV6Dk5JihiRQEMBbJ; Received: from [216.80.63.2] (helo=AGILON) by host181.hostmonster.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.76) (envelope-from ) id 1RTpJn-0005rX-M8; Thu, 24 Nov 2011 23:31:27 -0700 From: "John Buford" To: "'Marc Petit-Huguenin'" , "'Dr Mario Kolberg'" References: <4EB6CDEE.6020408@acm.org> <4EC53685.7080801@cs.stir.ac.uk> <4ECE764E.1040202@acm.org> In-Reply-To: <4ECE764E.1040202@acm.org> Date: Fri, 25 Nov 2011 01:31:26 -0500 Message-ID: <004801ccab3b$dcb632d0$96229870$@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: AcyqyZAe3RR+wvP+TECADdcYNyrI5QABqbLg Content-Language: en-us X-Identified-User: {2055:host181.hostmonster.com:samrgorg:samrg.org} {sentby:smtp auth 216.80.63.2 authed with buford@samrg.org} Cc: 'sam' 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 06:31:35 -0000 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. 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. [...] - -- 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) iEYEARECAAYFAk7Odk0ACgkQ9RoMZyVa61dp0wCdF2Znb/RGGPDTBOKxYWqT+U+e H4EAnjP8q8J9yjFCwdaMPy+XVHVuIzUJ =S1qj -----END PGP SIGNATURE----- _______________________________________________ SAM mailing list SAM@irtf.org http://www.irtf.org/mailman/listinfo/sam From petithug@acm.org Fri Nov 25 07:53:57 2011 Return-Path: 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 B654A21F8B82 for ; Fri, 25 Nov 2011 07:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.303 X-Spam-Level: X-Spam-Status: No, score=-102.303 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIsqDHebaIt8 for ; Fri, 25 Nov 2011 07:53:57 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id ACE9B21F8B7B for ; Fri, 25 Nov 2011 07:53:56 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 0989720143; Fri, 25 Nov 2011 15:43:33 +0000 (UTC) Message-ID: <4ECFBA0F.8080703@acm.org> Date: Fri, 25 Nov 2011 07:53:51 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16 MIME-Version: 1.0 To: John Buford References: <4EB6CDEE.6020408@acm.org> <4EC53685.7080801@cs.stir.ac.uk> <4ECE764E.1040202@acm.org> <004801ccab3b$dcb632d0$96229870$@org> In-Reply-To: <004801ccab3b$dcb632d0$96229870$@org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'sam' 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 15:53:57 -0000 -----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----- From buford@samrg.org Fri Nov 25 09:50:14 2011 Return-Path: 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 8421F21F8B4F for ; Fri, 25 Nov 2011 09:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.895 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj7iLKL96Hn7 for ; Fri, 25 Nov 2011 09:50:13 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (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 host181.hostmonster.com) (74.220.207.181) by oproxy8.bluehost.com with SMTP; 25 Nov 2011 17:50:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samrg.org; 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 [216.80.63.2] (helo=AGILON) by host181.hostmonster.com 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: <4EB6CDEE.6020408@acm.org> <4EC53685.7080801@cs.stir.ac.uk> <4ECE764E.1040202@acm.org> <004801ccab3b$dcb632d0$96229870$@org> <4ECFBA0F.8080703@acm.org> In-Reply-To: <4ECFBA0F.8080703@acm.org> 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: {2055:host181.hostmonster.com:samrgorg:samrg.org} {sentby:smtp auth 216.80.63.2 authed with buford@samrg.org} Cc: 'sam' 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" 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. Thanks, John -----Original Message----- From: sam-bounces@irtf.org [mailto:sam-bounces@irtf.org] 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: 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----- _______________________________________________ SAM mailing list SAM@irtf.org http://www.irtf.org/mailman/listinfo/sam