Re: [SAM] RG last call for draft-irtf-samrg-common-api-04

Matthias Waehlisch <waehlisch@ieee.org> Wed, 28 March 2012 15:57 UTC

Return-Path: <waehlisch@ieee.org>
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 898DD21F8913 for <sam@ietfa.amsl.com>; Wed, 28 Mar 2012 08:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.45
X-Spam-Level:
X-Spam-Status: No, score=-105.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 VQseZogijWVd for <sam@ietfa.amsl.com>; Wed, 28 Mar 2012 08:57:43 -0700 (PDT)
Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 874E321F8910 for <sam@irtf.org>; Wed, 28 Mar 2012 08:57:43 -0700 (PDT)
Envelope-to: sam@irtf.org
Received: from dhcp-922d.meeting.ietf.org ([130.129.10.45] helo=mw-PC.meeting.ietf.org) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from <waehlisch@ieee.org>) id 1SCvFl-0008eX-Nn; Wed, 28 Mar 2012 17:57:42 +0200
Date: Wed, 28 Mar 2012 17:57:47 +0200
From: Matthias Waehlisch <waehlisch@ieee.org>
To: John Buford <buford@samrg.org>
In-Reply-To: <00eb01ccf582$6ee3acb0$4cab0610$@org>
Message-ID: <Pine.WNT.4.64.1203281523170.34092@mw-PC>
References: <C6BFDD26-69C7-4ABF-8871-13FFA5C342A0@samrg.org> <00eb01ccf582$6ee3acb0$4cab0610$@org>
X-X-Sender: mw@mail2.rz.fhtw-berlin.de
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de)
X-HTW-DELIVERED-TO: sam@irtf.org
Cc: sam@irtf.org
Subject: Re: [SAM] RG last call for draft-irtf-samrg-common-api-04
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, 28 Mar 2012 15:57:44 -0000

Hi John,

  sorry for the late reply!

On Mon, 27 Feb 2012, John Buford wrote:

> p. 11 "Names can uniquely determine a group in a global communication
> context".
> - regarding "can", should this be "must" or "should"?
> - please add language that specifies whether group names are intended 
> to be unique (by namespace domain, by all domains, across all active 
> sessions, across all past present or future sessions, other)?
>
  OK. We will also clarify this in the Terminology section. The Group 
Name is intended to be unique by all domains.

> - is the application responsible for selecting group names and 
> determining uniqueness?
> 
  Group Names can be chosen by the end user. Determining which 
component ensure uniqueness is out of scope of the document, I would 
say.

> p. 11 "Details of service discovery are out of scope of this document" 
> - is it intended that this be 1) implementation specific detail, 2) 
> addressed in another specification, 3) use an existing service 
> discovery mechanism (if so, such as)?
> 
  It's maybe more a question to the research group. A separate document 
is not necessarily required.

> p. 12, 15
> 
>    is "sips" a possible scheme?
> 
  "sip", yes.

> p. 10 "It group communication services ..."  ?
> 
  OK, "It _provides_ group communication services ..."

> p. 19 (4.4.2) 
> - is Receive meant to be non-blocking or blocking?
>
  It's implemented as blocking.

> - Can the application receive an event when data is available to 
> receive?
> 
  That's implementation specific. The current events focus on local 
state changes.

> - How do you see an application implementing multi-resolution 
> multicast with this?
> 
  It's more the question how to apply the API for multi-resolution 
multicast? You could use the mapping of names to addresses. Considering 
a domain with lightweight devices that want data in lower quality, for 
example, the corresponding gateway could map the name to another address 
compared to a gateway serving devices with higher capabilities.

> - how is mobility across multicast domains supported, that is, if a 
> roaming client moves from an IPv4 multicast network to an overlay 
> multicast network, is 1) the transition handled by the middleware,
>   2) the transition detectable by the application through the API, 
>   3) requires the application to detect the transition and make the 
> appropriate calls to the API to reconfigure the membership and socket?
> 
  The application operates on the Group Name. The Group Name does not 
change with mobility. From this perspective, the transition should be 
handled by the middleware.

> - how is XCAST (or, generally multi-destination multicast routing) 
> supported? For example, the discussion 3.5 Name to Address Mapping 
> would seem to be effected if we want to be able to associate a group 
> name with a list of unicast addresses.
> 
  XCAST would be a separate interface (i.e., distribution technology).

  As far as I understand XCAST, the destination list is unordered. If 
this is the case, it's easy to extend the naming scheme such that the 
instantiation of the group represents a set.

> - msg assembly/disassembly handled by the middleware for messages too 
> large to send in one multicast packet?
> 
  The middleware layer should guarantee some maximal message size to the 
application developer. We will clarify this in the next version in a 
separate MTU section.



Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net