[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 °
- [SAM] Review of draft-irtf-samrg-sam-baseline-pro… Thomas C. Schmidt