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

Matthias Waehlisch <> Wed, 28 March 2012 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 898DD21F8913 for <>; Wed, 28 Mar 2012 08:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.45
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VQseZogijWVd for <>; Wed, 28 Mar 2012 08:57:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 874E321F8910 for <>; Wed, 28 Mar 2012 08:57:43 -0700 (PDT)
Received: from ([] by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from <>) id 1SCvFl-0008eX-Nn; Wed, 28 Mar 2012 17:57:42 +0200
Date: Wed, 28 Mar 2012 17:57:47 +0200
From: Matthias Waehlisch <>
To: John Buford <>
In-Reply-To: <00eb01ccf582$6ee3acb0$4cab0610$@org>
Message-ID: <Pine.WNT.4.64.1203281523170.34092@mw-PC>
References: <> <00eb01ccf582$6ee3acb0$4cab0610$@org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-HTW-SPAMINFO: this message was scanned by eXpurgate (
Subject: Re: [SAM] RG last call for draft-irtf-samrg-common-api-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 

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


Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. ..
:. Also: ..