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

Matthias Waehlisch <waehlisch@ieee.org> Thu, 29 March 2012 07:14 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 C271D21E80E2 for <sam@ietfa.amsl.com>; Thu, 29 Mar 2012 00:14:28 -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 twqyCPbP1YrQ for <sam@ietfa.amsl.com>; Thu, 29 Mar 2012 00:14:25 -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 EA62E21E80FD for <sam@irtf.org>; Thu, 29 Mar 2012 00:14:24 -0700 (PDT)
Envelope-to: sam@irtf.org
Received: from mol92-4-82-227-96-34.fbx.proxad.net ([82.227.96.34] helo=mw-PC) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from <waehlisch@ieee.org>) id 1SD9Ys-00085Z-B0; Thu, 29 Mar 2012 09:14:22 +0200
Date: Thu, 29 Mar 2012 09:14:29 +0200
From: Matthias Waehlisch <waehlisch@ieee.org>
To: John Buford <buford@samrg.org>
In-Reply-To: <2178E111-A6E6-49A5-8622-033A27506409@samrg.org>
Message-ID: <Pine.WNT.4.64.1203290911040.34092@mw-PC>
References: <C6BFDD26-69C7-4ABF-8871-13FFA5C342A0@samrg.org> <00eb01ccf582$6ee3acb0$4cab0610$@org> <Pine.WNT.4.64.1203281523170.34092@mw-PC> <2178E111-A6E6-49A5-8622-033A27506409@samrg.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" <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: Thu, 29 Mar 2012 07:14:28 -0000

Hi John,

  it's no problem to use "sips", as well. The scheme parameter can be 
extended.

  We will add some clarification statements regarding XCAST in the next 
version.


Thanks
  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

On Wed, 28 Mar 2012, John Buford wrote:

> Hi Matthias,
> 
> I believe "sip" and "sips" are two different schemes, the latter using secure connection.
> 
> So it might be good to indicate whether sips can also be used.
> 
> Personally I would like to see Xcast supported in this spec, but would endorse the ID for RGLC either way.
> 
> John
> 
> Sent from my iPad
> 
> On Mar 28, 2012, at 11:57 AM, Matthias Waehlisch <waehlisch@ieee.org> wrote:
> 
> > 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
>