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

From: Michael Welzl <[email-masked]>
Date: Wed, 1 May 2013 11:37:58 +0200

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>>
>>> *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 <[email-masked] <mailto:[email-masked]>>
>>> *Cc: *sam <[email-masked] <mailto:[email-masked]>>, John Buford
>>> <[email-masked] <mailto:[email-masked]>>
>>> 
>>> 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
>> [email-masked]
>> 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 °

---

From: "Buford, John F (John)" <[email-masked]>
Date: Wed, 1 May 2013 12:39:13 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Welzl
Sent: Wednesday, May 01, 2013 5:38 AM
To: Thomas C. Schmidt; Internet Research Steering Group; [email-masked]
Subject: Re: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02

Hi,

Yes.

Cheers,
Michael

On Apr 28, 2013, at 10:00 AM, Thomas C. Schmidt <[email-masked]> wrote:

>> I just noticed that somehow, irsg and samrg were dropped from the 
>> list of recipients of this response, sorry
>> 
>> Begin forwarded message:
>> 
>>>> 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 and H. Yu. Peer-to-Peer Overlay Multicast, in: 
>>>> Encyclopedia of Wireless and Mobile Communications. 2008.
>>>> 
>>> Good!
>>>>> which is "sort of" described here... I doubt that the description 
>>>>> in the document will help most readers to really fully understand 
>>>>> 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
>>>> 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.
>>>> 
>>> 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 
>>>>> 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 
>>>>> 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.
>>>> algorithms. To avoid duplication, we have moved it from Section 8 
>>>> to the relevant subsections in Section 7.
>>> 
>>> Fine.
>>> 
>>>>> "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.
>>>>> 
>>>> sections, but we don't agree that moving it to the end will help 
>>>> the understanding of the draft.
>>> 
>>> Fine.
>>> 
>>>>> (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.
>>>>> 
>>>> 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.
>>>> 
>>> Well, even a total P2P nut like myself understands that without even 
>>> seeing P3, but whatever  :-)
>>> 
>>>>> 7) Nits:
>>>>> 
>>>>> - 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.....
>>>>>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 1 May 2013 16:58:07 +0200

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

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 1 May 2013 15:28:06 +0000

> http://www.ietf.org/iesg/informational-vs-experimental.html doesn't say anything about requiring an implementation, unless I missed it

It's not needed. Pick whatever seems most appropriate.

(The IETF rules at the URL above are a good guideline, but don't actually apply to the I*R*TF.)

Lars

---

From: John Buford <[email-masked]>
Date: Wed, 1 May 2013 11:58:53 -0400

Thanks for the pointer.   It does seem then that experimental would be more accurate.

Can we change that after the formal poll ends or should we change it now?

John

Sent from my iPad

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 1 May 2013 17:31:29 +0000

> Can we change that after the formal poll ends or should we change it now?

After is fine. The IRSG is CC'ed, so they can take the change to Experimental into account when reviewing. 

Thanks,
Lars