Subject: RE: [SAM] SAMTK @irtf69

From: "Lim Boon Ping" <[email-masked]>
Date: Mon, 17 Sep 2007 11:02:50 +0800

Dear all,

Many Application Layer Multicast protocols have been developed in the past.
Some of which are ALMI, Narada, NICE, YOID, HMTP, Bayeux, SCRIBE, Borg. These
protocols, combined with individual ALM application (such as ESM, SRMS) were
built on top of ALM application or leverages on existing overlay
infrastructure (eg. Tapestry, Pastry), providing a common set of
functionalities, which include; 
*	 topology construction (at initial stage),
*	 topology re-construction (upon membership change), 
*	 topology refinement (upon network condition or performance metrics
change),
*	 topology distribution (for centralized approach), 
*	 topology lookup (upon data delivery/relay), and
*	 content distribution.

Despite sharing a set of similar functionalities, these protocols have been
separately developed and integrated into network simulator or individual
application for performance benchmarking and deployment test. Lack of common
set of wrapper API leads to redundant application layer development, thus
diluting effort on underlying ALM protocol enhancement and integration on a
common application platform.  

We think it is necessary to provide a set of wrapper API for ALM topology
management and network layer transparent content distribution as a common
platform for ALM application development and testing. This will allow
researchers to focus on ALM topology protocol enhancement which is the key
component of ALM technology.

What do you think?

Best Regards,
Boon Ping

-----Original Message-----
From: Nobuo Kawaguchi [mailto:[email-masked]] 
Sent: Friday, August 17, 2007 6:00 PM
To: Lim Boon Ping
Cc: [email-masked]; Nobuo Kawaguchi
Subject: Re: [SAM] SAMTK @irtf69

Dear Lim Boon Ping,

Thank you for having interest of SAMTK.
We are currently under alpha-development phase.

However, most of development efforts of SAMTK are 
held for protocol abstraction and group-management.
So topology management is not currently implemented.
(It is open for plug-in developers)

However, current plug-in interface is very simple.
If you have any comments, please let me know.

(Below is a part of current plug-in interface implementation )
---
    qint64 writeDatagram ( const char * data, qint64 size, SAMGroupAddress
*g=NULL);
    bool start(ushort selfport);
    qint64 readDatagram ( char * data, qint64 maxSize, QHostAddress
*address=0, quint16 *port = 0);
    bool hasPendingDatagrams () const;
    qint64 pendingDatagramSize ();   
    void close();
    bool setGroup(SAMGroupAddress *group);
    bool addMember(const SAMGroupMember &member);
    bool deleteMember(const SAMGroupMember &member);
---
SAMGroupAddress is a class for group of node addresses obtained 
from group management module.

Most of interface design is derived from Qt QUDPSocket.

I'm not sure it is enough to implement other ALM/OM protocols.
However, we are willing to support plug-in development on SAMTK.

yours,

Nobuo Kawaguchi

Lim Boon Ping wrote:
> Hi all,
> 
>  
> 
> We have recently explored into SAM-RG activities through the mailing list
and
> meeting materials, and are keen to understand more on SAM-RG latest
technical
> priority and research focus. 
> 
>  
> 
> We are particularly interested to understand more on SAMTK by Mr.
Kawaguchi,
> specifically on SAMTK integration with Topology Management module.
> 
> I have read the presentation material in
> http://samrg.org/about/meetings/ietf69/SAMTK-kawaguchi-ierf69.ppt, and
would
> hope if Mr. Kawaguchi or the RG members could clarify some of the
questions.
> 
>  
> What the scope of Topology management is as indicated in Slide 6? How do
you
> envision ALM/OM/hybrid protocols (given as a Plugin) seamlessly integrating
> with SAMTK's Group Membership/Traffic management module? There are a few
> dynamic topology management protocol discussed in the previous meetings,
such
> as Dynamic Mesh-based overlay multicast protocol (DMMP) and Hybrid Shared
> Tree, could these protocol/mechanism easily being integrated/ported into
> SAMTK? What're the standard input/output parameters would be provided by
> SAMTK to/from the topology management plugin? 
>  
> Quite a number SAM applications have been developed using SAMTK, is there
any
> plan to integrate dynamic topology management plugin (eg. dynamic ALM
> topology construction/update/route convergence), and perform experiment
trial
> on PlanetLab (or others large scale research test bed)? 
>  
> This work seems to be a good effort to spearhead a Standard Framework for
> rapid SAM application development/deployment. How is this effort being
> envisioned by other members in the RG? 
>  
> 
> Hope to hear your thought on this soon! 
> 
>  
> 
>  
> 
> Yours truly,
> 
> Boon Ping
> 
> Panasonic Kuala Lumpur Lab
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> SAM mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sam

_______________________________________________
SAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sam

---

From: "Jun Lei" <[email-masked]>
Date: Mon, 17 Sep 2007 10:54:56 +0200

Dear Lim,

Please see inline.

Best Regards

Jun Lei

*******************************************************************

Research Assistant

Address:
Georg-August-Universitaet Goettingen
Institut fuer Informatik
Telematics Group
Lotzestrasse 16-18
37083 Goettingen

Fax: +49 (551) 39-1 44 03
Tel: +49 (551) 39-1 35 78

Email: [email-masked]

******************************************************************
----- Original Message ----- 
From: "Lim Boon Ping" <[email-masked]>
To: <[email-masked]>; "Nobuo Kawaguchi" <[email-masked]>
Sent: Monday, September 17, 2007 5:02 AM
Subject: RE: [SAM] SAMTK @irtf69

Dear all,

Some of which are ALMI, Narada, NICE, YOID, HMTP, Bayeux, SCRIBE, Borg. 
These

What do you think?

[Jun] My 2 cents. It is a very good idea to provide a common API for the ALM 
topology management since it will save the time and energy for the 
researchers to start from very basic step. Besides, how the preliminary 
structure for the topology management and data distribution will be included 
in the API will be another question. Since the topology construction may 
have different mechanisms to construct the overlay and topology may also be 
different, it would be nice to aggregate some of the general methods and 
leave the specific ones untouched.

Anyway, I would keep my eyes on it.

Cheers

Jun

Best Regards,
Boon Ping

-----Original Message-----
From: Nobuo Kawaguchi [mailto:[email-masked]]
Sent: Friday, August 17, 2007 6:00 PM
To: Lim Boon Ping
Cc: [email-masked]; Nobuo Kawaguchi
Subject: Re: [SAM] SAMTK @irtf69

Dear Lim Boon Ping,

yours,

Nobuo Kawaguchi

and
technical
Kawaguchi,
would
questions.
you
such
any
trial

---

From: Stig Venaas <[email-masked]>
Date: Mon, 17 Sep 2007 11:22:59 +0200

> Dear Lim,
[...]
> [Jun] My 2 cents. It is a very good idea to provide a common API for the
> ALM topology management since it will save the time and energy for the
> structure for the topology management and data distribution will be
> included in the API will be another question. Since the topology
> construction may have different mechanisms to construct the overlay and
> topology may also be different, it would be nice to aggregate some of
> the general methods and leave the specific ones untouched.

I would like to take this a step further. I would have liked one common
API not only for ALM, but that also can make use of native multicast
whenever possible. It is not easy, but I would like application
developers to have an easy way of using multicast where native multicast
should be the preferred way (at least IMO), and make use of ALM if that
is not available.

Stig

---

From: Nobuo Kawaguchi <[email-masked]>
Date: Tue, 18 Sep 2007 13:00:22 +0900

Dear all SAM-rg members,

> should be the preferred way (at least IMO), and make use of ALM if that

I'm in almost same idea.
Currently, in SAMTK, we are trying to provide
  - XCAST6 plugin (done!)
  - Multicast plugin (almost done)
  - ALM plugin (not yet)
In SAMTK, most simple multipoint communication mean is multiple UDP.

We are currently implement ALM plugin as a "manual ALM" plugin.
So one can manually control the topology of ALM.

yours,

Nobuo Kawaguchi