[SAM] Review of draft-irtf-samrg-sam-baseline-protocol

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Sat, 26 January 2013 23:39 UTC

Return-Path: <prvs=7310067af=schmidt@informatik.haw-hamburg.de>
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 997EC21F8940 for <sam@ietfa.amsl.com>; Sat, 26 Jan 2013 15:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.55
X-Spam-Level:
X-Spam-Status: No, score=-98.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6, MANGLED_LIST=2.3, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIId+howTO2r for <sam@ietfa.amsl.com>; Sat, 26 Jan 2013 15:39:06 -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 37B3621F893E for <sam@irtf.org>; Sat, 26 Jan 2013 15:39:05 -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; 27 Jan 2013 00:39:03 +0100
Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id EB2E91066AE3; Sun, 27 Jan 2013 00:39:03 +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 20881-05; Sun, 27 Jan 2013 00:39:03 +0100 (CET)
Received: from [192.168.178.33] (g231104150.adsl.alicedsl.de [92.231.104.150]) (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 2610E1066AE2; Sun, 27 Jan 2013 00:39:03 +0100 (CET)
Message-ID: <51046914.8030700@informatik.haw-hamburg.de>
Date: Sun, 27 Jan 2013 00:39:00 +0100
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Buford <buford@samrg.org>, Dr Mario Kolberg <mko@cs.stir.ac.uk>
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
Cc: sam <sam@irtf.org>
Subject: [SAM] Review of draft-irtf-samrg-sam-baseline-protocol
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: Sat, 26 Jan 2013 23:39:07 -0000

Dear John and Mario,

finally I can contribute my review to your draft.

In general, this document is interesting and in good shape. I found a 
number of editorial and presentation issues, though:

General issues:

  * s/a ALM/an ALM/
  * Please provide captions to figures
  * Please reference figures unambiguously by numbers, not by positions 
(e.g., "figure above/below")
  * As this document is intended to be informational, normative 
references are inappropriate, I believe. Rather change all references to 
informational ...

Detailed comments:

[Section 1, 1st enumeration:] s/trees connect nodes over global 
internet/trees connect nodes over the global Internet

[Section 1, 2nd enumeration:] epending on initial application parameters 
or application class*es*

[Section 2.3] additional roles such as connection relays, super nodes, 
NAT traversal *assistance*

[Section 3.3] "We use RELOAD [I-D.ietf-p2psip-base] as the distibuted 
hash table (DHT)" ... I would RELOAD not coin a DHT, rather a generic 
P2P overlay protocol ...

[Section 4, 2nd point of 1st enumeration:] ... store diagnostic 
information about the operation of tree*s* ...
	in addition: s/lost packet rate/packet loss rate

[Section 5, 4th point of 1st enumeration:] Defines the Resource Name 
used to hash to the Resource ID *that determines* where the kind is stored

[Section 6, 4th para:] s/Its main advantage is use of the overlay 
routing mechanism for routing both control and data messages./Its main 
advantage is use of the overlay for routing both control and data messages.

[Section 6, enumeration point 5, "ASM tree":] This describes a specific 
bidirectional flooding mechanism on shared trees. Is this intended as 
such? This should be clarified ...

[Section 7 - in general:] This section explains the protocol handshakes, 
but does not display any sequence diagrams. Corresponding diagrams are 
in Section 12 - please reference or move ...

[Section 7.1, 1st para:] Refers to 
"I-D.irtf-sam-h]ybrid-overlay-framework" in a somewhat vague manner - 
maybe the key argument should be inlined to make the document more 
consistent?

[Section 7.1, 2nd para:] mentiones "SAM requirements draft" without 
referencing.

[Section 7.1, Dictionary data structure:] The Dictionary data structure 
displayed in this draft differs from the RELOAD Dictionary data 
structure - is this intended? Is this useful?

[Section 7.2.1, 1st para:] "...  of group_id is that the peer with peer 
id closest to and less than the group_id is the root of the tree." -> 
this seems very specific to CORD, is this intended as such? Maybe a more 
generic formulation is useful?

[Section 7.2.1, 3rd para:] This paragraph is very hard to parse ... 
please explain more carefully what "create tree" does.

[Section 7.2.3, 1st para:] "If successful, the peer_id is notified ..." 
-> peer_id is a number, who is notified?

[Section 7.2.3, 2nd para:] "RELOAD is a client server protocol" - you 
mean to say "RELOAD is a request-response protocol" ?

[Section 7.2.6, 1st para:] "the negotiation of options between the two 
peers." - I haven't seen any explanation of this negotiation mechanism ??

In general: The use, syntax and semantic of options might be worth to 
specify/illustrate, at least in the specific example sections (Scribe, 
P2PCast) ... (I suppose, options are always algorithm-specific).

[Section 7.2.17, "max_tree_data":] this is a global quantity commonly 
unavailable to any P2P overlay node ... I wonder what this is based on? 
Is this an optional value supplied if known?

[Section 7.2.19, "PushResponse:] Who sends this - the neighboring peer 
or the receiver to the sender?

[Section 9:] A message table as supplied in Section 8 should be helpful.

[Section 9.3, 1st para after enumeration:] "P2Pcast uses defined 
messages ..." This para is fairly unclear to me - clarify?

[Section 16:] This seems to contradict Section 14??

It would be good to provide a polished update prior to moving this ID ...

Best regards,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Scienc"es                   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 °