Subject: [SAM] draft-kolberg-sam-baseline-protocol-00

From: Gustavo Carneiro <[email-masked]>
Date: Wed, 7 Apr 2010 18:54:10 +0100

Hi,

I am trying to understand
draft-kolberg-sam-baseline-protocol-00<http://tools.ietf.org/html/draft-kolberg-sam-baseline-protocol-00>

<http://tools.ietf.org/html/draft-kolberg-sam-baseline-protocol-00>One thing
that confuses me is in Sec. 5.  Group Management API.  First it says,

While native multicast is bound to IP addresses, ALM uses arbitrary strings
> as multicast names, which will be mapped to the overlay identifier space.

The aim of this API is to implement group-oriented data
> communication independent of the underlying distribution technologies.

But then the API described is based on Address types, which are described
as:

Address is any address structure suitable with respect to the technology
> available at the host. This may be an IPv4 or an IPv6 address, or any
> overlay identifier.

So it seems that the Group Management API does not work with high-level
abstract identifiers, it already works with transport-specific identifiers.
 This is contrary to what was show in the  presentation
http://www.ietf.org/proceedings/10mar/slides/SAMRG-1.pdf

In page 11 of the slides:
             Sec 5. Group Management API
• API between Application and Group stack
• init(out Handle s)
    – This call creates a multicast socket that is bound to some virtual
multicast
       interface and provides a corresponding handle to the application
programmer,
       which will be used for subsequent communication.
• join(in Handle s, in URL g)
    – This operation initiates a group subscription for the name g,
including the
       corresponding tree access.

Here we see a different API, where URLs are used instead of identifiers.

Another not so clear item is how the API in Sec. 5 articulates with Sec. 6.
 Sec.6 starts like this:

In this document we define messages for hybrid overlay multicast
> tree creation...

I get the feeling this used to be a separate draft that was converted to a
section of another draft.  I suppose that the Protocol described is
triggered by API calls of the Sec. 5 API, but I get the feeling I am
guessing what should be explicitly stated in the document.  In that
sense, draft-waehlisch-sam-common-api-02 (Fig. 2) is clearer.

And what is exactly the relationship
between draft-waehlisch-sam-common-api-02
and draft-kolberg-sam-baseline-protocol-00.  They were published almost at
the same time (for the meeting?); are they competing proposals?

Thanks,
-- 
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert

---

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 7 Apr 2010 20:48:45 -0700 (Pazifik Sommerzeit)

Hi Gustavo,

  many thanks for your valuable feedback!

  Please see my reply inline.

On Wed, 7 Apr 2010, Gustavo Carneiro wrote:

> I am trying to understand draft-kolberg-sam-baseline-protocol-00
> 
> One thing that confuses me is in Sec. 5.  Group Management API.  
> First it says,
> 
> While native multicast is bound to IP addresses, ALM uses arbitrary 
> strings as multicast names, which will be mapped to the overlay 
> identifier space.
> 
> The aim of this API is to implement group-oriented data communication 
> independent of the underlying distribution technologies.
> 
> Address is any address structure suitable with respect to the 
> technology available at the host. This may be an IPv4 or an IPv6 
> address, or any overlay identifier.
> 
> So it seems that the Group Management API does not work with 
> high-level abstract identifiers, it already works with 
> transport-specific identifiers. 
>
  Yes, this is misleading presented in the current version. We updated 
this to mention explicit naming using the URI scheme with respect to 
draft-waehlisch-sam-common-api. However, this update has not been 
published yet, as we want to add some further extensions in the 
draft-kolberg-sam-baseline-protocol.

[...]

> And what is exactly the relationship between 
> draft-waehlisch-sam-common-api-02 and 
> draft-kolberg-sam-baseline-protocol-00.  They were published almost at 
  No, they are not competing proposals. From the perspective of 
draft-waehlisch-sam-common-api the baseline protocol is a special use 
case for the common API. In contrast, from the perspective of 
draft-kolberg-sam-baseline-protocol the common API fills the gap to 
develop hybrid group communication applications.

Thanks
  matthias

-- 
Matthias Waehlisch
.  FU Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: Dr Mario Kolberg <[email-masked]>
Date: Thu, 08 Apr 2010 10:38:53 +0100

Dear Gustavo,

many thanks for your comments.

> Another not so clear item is how the API in Sec. 5 articulates with Sec. 
> 6.  Sec.6 starts like this:
> 
> I get the feeling this used to be a separate draft that was converted to 
> a section of another draft.  I suppose that the Protocol described is 

Yes section 5 is the API to the application, whereas section 6 describes 
the API between nodes. And yes this draft is based on a number of 
previous drafts. The aim is to align them and to form a base document 
for the WG. I accept there is still some work to be done.

Mario

-- 
The Sunday Times Scottish University of the Year 2009/2010
The University of Stirling is a charity registered in Scotland, 
 number SC 011159.

---

From: Gustavo Carneiro <[email-masked]>
Date: Thu, 8 Apr 2010 13:36:55 +0100

On Thu, Apr 8, 2010 at 10:38 AM, Dr Mario Kolberg <[email-masked]> wrote:

>> guessing what should be explicitly stated in the document.  In that sense,
>> draft-waehlisch-sam-common-api-02 (Fig. 2) is clearer.
>>
>
> the API between nodes. And yes this draft is based on a number of previous
> drafts. The aim is to align them and to form a base document for the WG. I
> accept there is still some work to be done.
>

OK, that is understandable in the first versions.

Still I was wondering if the plan is for the sam-common-api will continue to
evolve alongside sam-baseline-protocol, or whether it will be merged
into sam-baseline-protocol.

Many thanks for your answers (Matthias as well).

Regards,

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 8 Apr 2010 14:38:06 -0700 (Pazifik Sommerzeit)

Hi Gustavo,

On Thu, 8 Apr 2010, Gustavo Carneiro wrote:

> Still I was wondering if the plan is for the sam-common-api will 
> continue to evolve alongside sam-baseline-protocol, or whether it will 
> be merged into sam-baseline-protocol.
> 
  we also working on an update of the common API draft. The common API 
described in draft-waehlisch is not bound to the baseline protocol.

Best regards
  matthias

---

From: "John Buford" <[email-masked]>
Date: Thu, 8 Apr 2010 20:32:54 -0400

I think that the API ID could be adopted as an RG work item by itself, and
the section in the baseline document could focus on how the API works
specifically with the RELOAD extensions we are describing.

John

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gustavo Carneiro
Sent: Thursday, April 08, 2010 8:37 AM
To: [email-masked]
Subject: Re: [SAM] draft-kolberg-sam-baseline-protocol-00

Dear Gustavo,

Yes section 5 is the API to the application, whereas section 6 describes the
API between nodes. And yes this draft is based on a number of previous
drafts. The aim is to align them and to form a base document for the WG. I
accept there is still some work to be done.

Still I was wondering if the plan is for the sam-common-api will continue to
evolve alongside sam-baseline-protocol, or whether it will be merged into
sam-baseline-protocol.

Regards,