[SAM] SAM RG next steps

[Nobuo Kawaguchi]

Hi John, and all,

I'm one of the SAMTK designer. So I should say my opinion.

As I already presented in IETF-69 SAM-RG, SAMTK is 
just a middleware(or toolkit) to ease a development of 
applications and multi-point protocols.
This means that, by using SAMTK, application developers can 
easily develop a multi-point comm app without considering
multi-point protocols. Also protocol researchers can 
utilize real applications just developing a protocol plug-in
for SAMTK.

We also provide a group management API in SAMTK.
We already implement a Web based centralized group management. 
But API does not limit the implementation.
(We also planning to implement a P2P/DHT based group management.)
 
As you already mentioned, API in SAMTK could be more general.
However, we do not know what kind of communication pattern 
will be suitable for multi-point group communication and 
group management.
This means, definition of "common" API is not easy.
So we start from a implementation. 
By using SAMTK as a reference, we can discuss its pros and cons.
We do not hesitate to change the API of SAMTK as a result of
discussions in SAM-RG.

SAMTK is now in beta phase. We are currently preparing English
documents. So please wait a bit.

yours, 

Nobuo Kawaguchi
Graduate School of Engineering, Nagoya Univ., Japan.
kawaguti at nagoya-u.jp


John Buford Wrotes,
> Perhaps the SAMTK designers could comment on this discussion?
> 
> On Jan 4, 2008 6:54 AM, Matthias Waehlisch <waehlisch at ieee.org> wrote:
> 
>> Hi John,
>>
>> On Thu, 3 Jan 2008, John Buford wrote:
>>
>>>> [...]
>>>>> In addition, in the P2P-SIP WG there is a proposal for a universal
>>>>> P2P overlay protocol. (universal in that it is meant to support the
>>>>> operations needed by several multi-hop structured overlays).
>>>>>
>>>>> So, the direction I have in mind for the SAM Framework involves:
>>>>> extended AMT gateways, ALM on P2P overlay, use of a universal P2P
>>>>> overlay protocol.  Then, any researcher could plug their own ALM
>>>>> algorithm into this and select their own P2P overlay algorithm as
>>>>> well. Meanwhile, the AMT integration means that native multicast and
>>>>> ALM can co-exist.
>>>>>
>>>>  What does a universal P2P overlay protocol mean in detail? Is it
>>>> similar to the common API by Dabek et al. ("Towards a Common API for
>>>> Structured Peer-to-Peer Overlays", 2003)?
>>> I recall the Dabek et al. model is mainly on the DHT level. The protocol
>>> also needs to cover overlay maintenance. It starts from the observation
>>> that many structured overlays have to send the same types of messages
>>> between peers, such as GET, PUT, JOIN, LEAVE, ROUTING-TABLE UPDATE,
>>> PROBE, etc.  But the details vary from overlay to overlay.  So the
>>> protocol covers the common message types with basic fields plus
>>> extension mechanisms.
>>>
>>  there is a detailed description for the KBR (key based routing) layer
>> and some very rough ideas for multicast (CAST).
>>
>>  The problem of the Dabek et al. model from my point of view is that it
>> intermingles semantic definitions with algorithmic logic. The CAST
>> abstraction for example provides standard group membership methods (join,
>> leave, ...) on the one hand and tree maintenace description similar to
>> SCRIBE on the other hand.
>>
>>>>  Btw: It makes sense to have an interface definition between ALM
>>>> 'stack' and application. But this should be a part of a common group
>>>> membership framework maybe borrowed from IGMP/MLD. That could be also
>>>> an outcome of SAM RG.
>>>
>>> I think there is a proposed ALM API in the RG that was discussed at
>>> IETF-69. Is this what you are thinking of?
>>>
>>  Do you mean the SAMTK? Hm, I think partly, because SAMTK is an
>> implementation as far as I understand. It can be seen as a standard stack,
>> however, it would be fine to have a document as a general ALM group
>> membership guidance. This includes definition of group management methods
>> (as done in SAMTK), a general packet format, etc. ... The SAMTK
>> definitions for example differ from the interfaces in the Dabek et al.
>> model. If we are looking on implementations in different ALM simulators we
>> will also find discrepancies, although some of them rely on the Dabek et
>> al. model.
>>
>>  Another point is the question of broadcast as a special case of
>> multicast. How should we define it: Should the application developer join
>> a special multicast group - but which one? Or should we define a separate
>> broadcast socket/interface?
>>
>>  All of these could be addressed in a common group membership description
>> for ALM. I feel a bit uncomfortable with too many approaches being around
>> on this basic topic.
>>
>> Cheers
>>  matthias
>>
>> --
>> Matthias Waehlisch
>> :. HAW Hamburg, Dept. Informatik        :. link-lab
>> :. Berliner Tor 7, 20099 Hamburg        :. Hoenower Str. 35, 10318 Berlin
>> :. Germany, mailto:waehlisch at ieee.org   :. Germany, mailto:mw at link-lab.net
>> :. http://home.fhtw-berlin.de/~mw       :. http://www.link-lab.net
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> SAM mailing list
> SAM at irtf.org
> https://www1.ietf.org/mailman/listinfo/sam