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

[Dr Mario Kolberg <[e-mail]>]

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.

> 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.

> 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.
>
> 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.

> 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.

> 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.

> 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.
>
> 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.

-- 
The University of Stirling is ranked in the top 50 in the world in The Times Higher Education 100 Under 50 table, which ranks the world's best 100 universities under 50 years old.
The University of Stirling is a charity registered in Scotland, 
 number SC 011159.