Re: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02

"Buford, John F (John)" <buford@avaya.com> Wed, 01 May 2013 12:40 UTC

Return-Path: <buford@avaya.com>
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 7155121F99ED; Wed, 1 May 2013 05:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
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 YrlHrxtW9JjW; Wed, 1 May 2013 05:40:04 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 33E6821F9AED; Wed, 1 May 2013 05:39:17 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah8FAJELgVGHCzI1/2dsb2JhbABSFoJQITa/F30WdIIfAQEBAQIBAQEBDwZTAwQCBQUHBAIBCA0BAwMBAQEBCh0HJwsUCQgCBAENBQgBCw6HZAYBC6NymwUXjDmBHYESDyIHBoJpYQOIXYNIkTdPhQuFHYMNgic
X-IronPort-AV: E=Sophos;i="4.87,588,1363147200"; d="scan'208";a="7510310"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 May 2013 08:39:15 -0400
Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 May 2013 08:35:52 -0400
Received: from AZ-US1EXMB02.global.avaya.com ([fe80::c01d:740:c927:8888]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Wed, 1 May 2013 08:39:13 -0400
From: "Buford, John F (John)" <buford@avaya.com>
To: Michael Welzl <michawe@ifi.uio.no>, "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>, Internet Research Steering Group <irsg@irtf.org>, "sam@irtf.org" <sam@irtf.org>
Thread-Topic: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02
Thread-Index: AQHORk+Zxp8w5MItGEyaq06L/grZRJjwRPwQ
Date: Wed, 1 May 2013 12:39:13 +0000
Message-ID: <48E0C724888CBE47A7912FCEB14DF8F406F0E2@AZ-US1EXMB02.global.avaya.com>
References: <0A9F560A-846B-40DC-83BB-DE85D7486606@ifi.uio.no> <4B1FBAB9-36C6-42B5-B976-6A156C72E432@ifi.uio.no> <517CD713.3060006@informatik.haw-hamburg.de> <0297C4A1-18B3-4485-AEF2-9D29667C3E5B@ifi.uio.no>
In-Reply-To: <0297C4A1-18B3-4485-AEF2-9D29667C3E5B@ifi.uio.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.11.85.48]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02
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, 01 May 2013 12:40:12 -0000

Michael,

Thanks for your review.

We didn't have it as experimental since it doesn't report on an implementation.

John

-----Original Message-----
From: sam-bounces@irtf.org [mailto:sam-bounces@irtf.org] On Behalf Of Michael Welzl
Sent: Wednesday, May 01, 2013 5:38 AM
To: Thomas C. Schmidt; Internet Research Steering Group; sam@irtf.org
Subject: Re: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02

Hi,

Yes.

One (non-blocking) question: why is this intended as Informational, and not Experimental? The latter would seem more appropriate to me.

Cheers,
Michael


On Apr 28, 2013, at 10:00 AM, Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de> wrote:

> Hi Michael,
> 
> this means a "ready to publish" vote?
> 
> Viele Grüße
> 
> Thomas
> 
> On 28.04.2013 07:23, Michael Welzl wrote:
>> Hi,
>> 
>> I just noticed that somehow, irsg and samrg were dropped from the 
>> list of recipients of this response, sorry
>> 
>> Begin forwarded message:
>> 
>>> *From: *Michael Welzl <michawe@ifi.uio.no 
>>> <mailto:michawe@ifi.uio.no>>
>>> *Subject: **Re: [irsg] IRSG review for
>>> draft-irtf-samrg-sam-baseline-protocol-02*
>>> *Date: *April 24, 2013 4:06:17 PM GMT+02:00
>>> *To: *Dr Mario Kolberg <mko@cs.stir.ac.uk 
>>> <mailto:mko@cs.stir.ac.uk>>
>>> *Cc: *sam <sam@irtf.org <mailto:sam@irtf.org>>, John Buford 
>>> <buford@samrg.org <mailto:buford@samrg.org>>
>>> 
>>> Hi,
>>> 
>>> In line:
>>> 
>>> 
>>> On 22. apr. 2013, at 12:36, Dr Mario Kolberg wrote:
>>> 
>>>> Hi Michael and All,
>>>> 
>>>> please find below our response to the IRSG review by Michael Welzl.
>>>> 
>>>> Best wishes,
>>>> Mario & John
>>>>> 
>>>>> General higher-level comments:
>>>>> 
>>>>> 1) I found parts of the document very hard to read, sometimes 
>>>>> wondered if this is really necessary.
>>>>> 
>>>> The document is intended for an audience which does have a 
>>>> technical background in the area of application layer multicasting 
>>>> and peer to peer overlay protocols.  We would expect readers 
>>>> unfamiliar with the area to first go to more basic material. 
>>>> Perhaps many comments in the review stem from the fact that the 
>>>> reviewer doesn't have this familiarity. To help readers to get a 
>>>> better understanding we have added references to introductory and 
>>>> background material as a starting point:
>>>> 
>>>> J. Buford, H. Yu, E. K. Lua P2P Networking and Applications. Morgan 
>>>> Kaufman 2009 (Ch 9 Peercasting and Overlay Multicasting).
>>>> M. Kolberg. Employing Multicast in P2P Networks, in: Handbook of 
>>>> Peer-to-Peer Networking. (Ed. X. Shen, H. Yu, J. Buford, M. Akon).
>>>> J. Buford and H. Yu. Peer-to-Peer Overlay Multicast, in: 
>>>> Encyclopedia of Wireless and Mobile Communications. 2008.
>>>> 
>>> Good!
>>> I would like to mention that, while I know very little about 
>>> application layer multicast, I do have some (outdated) P2P knowledge.
>>> It's not really my field, but I have done a little bit of work on it 
>>> and also taught a lecture about it a few years ago (which even 
>>> contained a brief overview of Scribe, IIRC). So that made me think, 
>>> someone like me should at least be able to make some sense of the 
>>> document - within certain limits of course, as I know nothing about 
>>> RELOAD, for example.
>>> 
>>> 
>>>>> 2) In particular, P2PCast appears to be a rather complex algorithm 
>>>>> which is "sort of" described here... I doubt that the description 
>>>>> in the document will help most readers to really fully understand 
>>>>> P2PCast, and I  wonder, is it necessary for this doc to try to 
>>>>> really explain the algorithm (when, in doing so, it can really 
>>>>> only go half-way anyway)? e.g., wouldn't it suffice to just keep 
>>>>> the "Overview" (section 9.1) but then point to [P2PCAST] for 
>>>>> further details, and just list the necessary facts? e.g., the JOIN 
>>>>> procedure
>>>>> - do we have to know all these details here, isn't it enough to e.g.
>>>>> list the reorganisation messages by name and say that they're used 
>>>>> in accordance with [P2PCAST]?
>>>> The ID is written for a technical audience which is presumed to be 
>>>> knowledgeable about RELOAD and P2P overlays and has somefamiliarity 
>>>> with multicasting at the application layer. We provide summaries of 
>>>> P2PCAST and SCRIBE since these two algorithms are well known in the 
>>>> ALM research community, and are each representative of an important 
>>>> class of ALM algorithms.  If the reader needs more background, then 
>>>> they can go to thereference papers and find it there.
>>>> 
>>>> In our opinion, the inclusion of the essential features about each 
>>>> algorithm is useful and should be in the ID.  The level of 
>>>> detaildescribes  "Scribe-like" and "P2PCast-like" algorithms, and 
>>>> not only Scribe and P2PCAST.  Since the protocol we define is 
>>>> intended to support a large variety of such algorithms.
>>>> 
>>>> This is done in other in other IDs and RFCs.   For example, please
>>>> take a look at section 10 of the RELOAD ID which gives detailed 
>>>> information about the Chord algorithm, but yet omits Chord details 
>>>> which one would find in the original papers from MIT. If your 
>>>> comments were followed, this Chord material should be removed from
>>>> RELOAD spec.      Likewise see this id produced by the PPSP WG
>>>> draft-ietf-ppsp-survey-04.  There are lots of other examples where 
>>>> important previously existing algorithms are summarized in an ID.
>>> 
>>> Well. I'm not sure if the cases you compare here really are 
>>> comparable
>>> - the Chord text in the RELOAD ID is much longer, for a (it seems to
>>> me) much simpler algorithm, and a survey is really a different case, 
>>> I think - its overall intention is different from a document like 
>>> this one. But I see your point about trying to convey the essential 
>>> features right here, and if you feel the text explains the essential 
>>> bits and is helpful, I'll trust you on this one, given my lack of 
>>> expertise in application-layer multicast.
>>> 
>>> 
>>>>> 3) Another source of confusion: the Scribe algorithm description 
>>>>> has some pseudocode that I wasn't able to parse (maybe it refers 
>>>>> to RELOAD things?) Not all functions there seem to clearly relate 
>>>>> to messages that were described earlier. Even more confusing, the 
>>>>> P2PCast algorithm description doesn't have these pseudocode 
>>>>> snippets, so the whole thing appears inconsistent. Should it be 
>>>>> everywhere? Should it be removed? If it stays, some explanations 
>>>>> are needed. It can't be up to the reader to guess what e.g.
>>>>> "invokeMessageHandler" does, right?? (section 8.7). In this 
>>>>> particular section, I would also expect the text and/or pseudocode 
>>>>> to somehow draw a relationship to "push" (listed in fig. 3), but 
>>>>> that's not there... so what is this?
>>>> 
>>>> We agree that this pseudocode is more general and applies to both 
>>>> algorithms. To avoid duplication, we have moved it from Section 8 
>>>> to the relevant subsections in Section 7.
>>> 
>>> Fine.
>>> 
>>>>> 4) Structure: even if the two algorithms are only a part of the 
>>>>> whole thing you define, the text going with them feels a bit like 
>>>>> "we've set the stage, now we apply it - the messages you heard 
>>>>> about before are used like this & that with this & that 
>>>>> algorithm". That's fine! But it also gives the reader the feeling 
>>>>> of that being "part 2", i.e. I think it should be at the end, if that makes sense.
>>>>> 
>>>> Yes the algorithms are an application of the material in earlier 
>>>> sections, but we don't agree that moving it to the end will help 
>>>> the understanding of the draft.
>>> 
>>> Fine.
>>> 
>>>>> 5) I also think that it would be better to move the examples 
>>>>> (section 12) to where you introduce the messages, the flow of 
>>>>> which they illustrate. First I have to imagine what an "INVITE" 
>>>>> message flow could look like, then I get complicated explanations 
>>>>> of how INVITE is applied in an algorithm that I can't fully 
>>>>> understand from this text anyway, and THEN I get a nice example 
>>>>> illustrating an INVITE message flow... that's not very helpful for 
>>>>> the reader I think.  e.g., when I read 7.2.3, I wondered why the 
>>>>> "peer_id" of the source peer is even needed in the struct. By 
>>>>> looking at the example, this would have become clear to me.
>>>>> 
>>>> The document is not meant to be a tutorial, hence the examples are 
>>>> not first.  The examples follow the definition of the messages 
>>>> sothat the message use is illustrated.  If we moved the examples 
>>>> first, then some other reviewer could then say . why are the 
>>>> examplesshown before the protocol messages are defined? It is not 
>>>> the purpose of the ID to bootstrap the reader into basic knowledge 
>>>> of ALM and Peer to Peer messaging.
>>>> 
>>> Fine.
>>> 
>>>>> 6) Speaking of the examples, what's the point of showing more 
>>>>> peers than you actually use in the example? Okay, I can understand 
>>>>> that perhaps you wanted to have the same number for all of them, 
>>>>> but then you could still remove P3 because it seems that you never 
>>>>> use P3 for anything in any of the examples.
>>>> 
>>>> We added these peers is to illustrate that 1) not all the peers in 
>>>> the overlay have to be part of each ALM connection, and 2) the 
>>>> overlay could have an arbitrary number of peers.
>>> 
>>> Well, even a total P2P nut like myself understands that without even 
>>> seeing P3, but whatever  :-)
>>> 
>>>>> 7) Nits:
>>>>> 
>>>>> IANA Considerations: are you sure that there is nothing? e.g., how
>>>>> would a new algorithm code be assigned?   (section 11.4)
>>>>> - btw, why is the section called "Algorithm Codes" but then the 
>>>>> text talks about "Algorithm Types" ?
>>>>> 
>>>> There are no IANA considerations since this is to be an 
>>>> informational RFC.
>>> 
>>> Ah, ok, sure -
>>> 
>>>>> 8) Some references (CASTRO2003, P2PCAST) need a space (I mean, " 
>>>>> ") after their first appearance.
>>>>> cut.....
>>>>> 
>>>> All these edits have been done and version 03 has been submitted.
>>> 
>>> Fine, thanks!
>>> 
>>> Cheers,
>>> Michael
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> SAM mailing list
>> SAM@irtf.org
>> http://www.irtf.org/mailman/listinfo/sam
>> 
> 
> --
> 
> 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 °

_______________________________________________
SAM mailing list
SAM@irtf.org
http://www.irtf.org/mailman/listinfo/sam