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

Michael Welzl <michawe@ifi.uio.no> Wed, 01 May 2013 14:58 UTC

Return-Path: <michawe@ifi.uio.no>
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 0B78121F991A; Wed, 1 May 2013 07:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102
X-Spam-Level:
X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 jDodAVw6jZKi; Wed, 1 May 2013 07:58:14 -0700 (PDT)
Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 34F8221F98B3; Wed, 1 May 2013 07:58:13 -0700 (PDT)
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from <michawe@ifi.uio.no>) id 1UXYTz-0002mI-1f; Wed, 01 May 2013 16:58:11 +0200
Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.103]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1UXYTx-0001u5-QZ; Wed, 01 May 2013 16:58:11 +0200
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <48E0C724888CBE47A7912FCEB14DF8F406F0E2@AZ-US1EXMB02.global.avaya.com>
Date: Wed, 1 May 2013 16:58:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1599A8CE-8979-426D-A208-44D8C6288687@ifi.uio.no>
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> <48E0C724888CBE47A7912FCEB14DF8F406F0E2@AZ-US1EXMB02.global.avaya.com>
To: "Buford, John F (John)" <buford@avaya.com>
X-Mailer: Apple Mail (2.1503)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 4 sum rcpts/h 9 sum msgs/h 4 total rcpts 4052 max rcpts/h 40 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 3EB6FD00B1E06DE56E19B3C359CC5760BA09D387
X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 498 max/h 8 blacklist 0 greylist 0 ratelimit 0
Cc: "sam@irtf.org" <sam@irtf.org>, Internet Research Steering Group <irsg@irtf.org>
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 14:58:19 -0000

Not sure that's needed?!
http://www.ietf.org/iesg/informational-vs-experimental.html doesn't say anything about requiring an implementation, unless I missed it

Cheers,
Michael


On May 1, 2013, at 2:39 PM, "Buford, John F (John)" <buford@avaya.com> wrote:

> 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