From sam-bounces@irtf.org Sun Sep 16 23:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX6tA-0007Hz-3c; Sun, 16 Sep 2007 23:03:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX6t9-0007Hu-Ch for sam@irtf.org; Sun, 16 Sep 2007 23:03:07 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IX6t7-0004NP-G4 for sam@irtf.org; Sun, 16 Sep 2007 23:03:07 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id l8H32uok029250; Mon, 17 Sep 2007 12:02:57 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id l8H32v911712; Mon, 17 Sep 2007 12:02:57 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/mariners) with SMTP id l8H330319899; Mon, 17 Sep 2007 12:03:00 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SAM] SAMTK @irtf69 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Mon, 17 Sep 2007 11:02:50 +0800 Message-ID: <769E965D82021346949AF2BC41D8EAB71FB331@prdcm-mail.prdcm.panasonic.com.my> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SAM] SAMTK @irtf69 thread-index: AcfgtVjuCZJfCN5tTA+vExRXrx1Q1AYH1xmQ From: "Lim Boon Ping" To: , "Nobuo Kawaguchi" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.5 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: , Errors-To: sam-bounces@irtf.org 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;=20 * topology construction (at initial stage), * topology re-construction (upon membership change),=20 * topology refinement (upon network condition or performance metrics change), * topology distribution (for centralized approach),=20 * 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. =20 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:kawaguti@nagoya-u.jp]=20 Sent: Friday, August 17, 2007 6:00 PM To: Lim Boon Ping Cc: sam@irtf.org; 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=20 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=3DNULL); bool start(ushort selfport); qint64 readDatagram ( char * data, qint64 maxSize, QHostAddress *address=3D0, quint16 *port =3D 0); bool hasPendingDatagrams () const; qint64 pendingDatagramSize (); =20 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=20 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, >=20 > =20 >=20 > 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.=20 >=20 > =20 >=20 > We are particularly interested to understand more on SAMTK by Mr. Kawaguchi, > specifically on SAMTK integration with Topology Management module. >=20 > 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. >=20 > =20 > 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?=20 > =20 > 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)?=20 > =20 > 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?=20 > =20 >=20 > Hope to hear your thought on this soon!=20 >=20 > =20 >=20 > =20 >=20 > Yours truly, >=20 > Boon Ping >=20 > Panasonic Kuala Lumpur Lab >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 >=20 >=20 > = ------------------------------------------------------------------------ >=20 > _______________________________________________ > SAM mailing list > SAM@irtf.org > https://www1.ietf.org/mailman/listinfo/sam _______________________________________________ SAM mailing list SAM@irtf.org https://www1.ietf.org/mailman/listinfo/sam From sam-bounces@irtf.org Mon Sep 17 04:55:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXCNh-0005wk-AA; Mon, 17 Sep 2007 04:55:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXCNg-0005we-0J for sam@irtf.org; Mon, 17 Sep 2007 04:55:00 -0400 Received: from mailer.gwdg.de ([134.76.10.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXCNe-000547-DB for sam@irtf.org; Mon, 17 Sep 2007 04:54:59 -0400 Received: from gwdexc-fe1.exc.top.gwdg.de ([134.76.26.171] helo=vsmtpgwdexc.exc.top.gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.67) (envelope-from ) id 1IXCNV-0006Sc-5B; Mon, 17 Sep 2007 10:54:49 +0200 Received: from lei ([134.76.81.25]) by vsmtpgwdexc.exc.top.gwdg.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Sep 2007 10:54:48 +0200 Message-ID: <002001c7f908$6c44a0c0$050016ac@lei> From: "Jun Lei" To: "Lim Boon Ping" , References: <769E965D82021346949AF2BC41D8EAB71FB331@prdcm-mail.prdcm.panasonic.com.my> Subject: Re: [SAM] SAMTK @irtf69 Date: Mon, 17 Sep 2007 10:54:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 17 Sep 2007 08:54:48.0717 (UTC) FILETIME=[670AE3D0:01C7F908] X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.5 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: , Errors-To: sam-bounces@irtf.org 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: lei@informatik.uni-goettingen.de ****************************************************************** ----- Original Message ----- From: "Lim Boon Ping" To: ; "Nobuo Kawaguchi" Sent: Monday, September 17, 2007 5:02 AM Subject: RE: [SAM] SAMTK @irtf69 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? [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:kawaguti@nagoya-u.jp] Sent: Friday, August 17, 2007 6:00 PM To: Lim Boon Ping Cc: sam@irtf.org; 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 > SAM@irtf.org > https://www1.ietf.org/mailman/listinfo/sam _______________________________________________ SAM mailing list SAM@irtf.org https://www1.ietf.org/mailman/listinfo/sam _______________________________________________ SAM mailing list SAM@irtf.org https://www1.ietf.org/mailman/listinfo/sam From sam-bounces@irtf.org Mon Sep 17 05:28:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXCtg-0006mp-UP; Mon, 17 Sep 2007 05:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXCtf-0006mf-U4 for sam@irtf.org; Mon, 17 Sep 2007 05:28:03 -0400 Received: from tyholt.uninett.no ([158.38.62.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXCte-00067Z-Et for sam@irtf.org; Mon, 17 Sep 2007 05:28:03 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 5C2E32BAFA8; Mon, 17 Sep 2007 11:23:00 +0200 (CEST) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05198-01-60; Mon, 17 Sep 2007 11:23:00 +0200 (CEST) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id 1006A2BAF61; Mon, 17 Sep 2007 11:23:00 +0200 (CEST) Message-ID: <46EE4773.2090807@uninett.no> Date: Mon, 17 Sep 2007 11:22:59 +0200 From: Stig Venaas User-Agent: Thunderbird 2.0.0.6 (X11/20070910) MIME-Version: 1.0 To: Jun Lei Subject: Re: [SAM] SAMTK @irtf69 References: <769E965D82021346949AF2BC41D8EAB71FB331@prdcm-mail.prdcm.panasonic.com.my> <002001c7f908$6c44a0c0$050016ac@lei> In-Reply-To: <002001c7f908$6c44a0c0$050016ac@lei> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sam@irtf.org X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.5 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: , Errors-To: sam-bounces@irtf.org Jun Lei wrote: > Dear Lim, [...] > 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? > > [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. 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 > > Anyway, I would keep my eyes on it. > > Cheers > > Jun > > > Best Regards, > Boon Ping _______________________________________________ SAM mailing list SAM@irtf.org https://www1.ietf.org/mailman/listinfo/sam From sam-bounces@irtf.org Tue Sep 18 00:01:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXUGa-0005ym-LS; Tue, 18 Sep 2007 00:00:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXUGZ-0005yX-7J for sam@irtf.org; Tue, 18 Sep 2007 00:00:51 -0400 Received: from mail1.nagoya-u.jp ([133.6.1.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXUGS-00037s-Ux for sam@irtf.org; Tue, 18 Sep 2007 00:00:51 -0400 Received: from [192.168.0.182] (unknown [85.127.181.104]) by mail1.nagoya-u.jp (Postfix) with ESMTP id A157B80B6D; Tue, 18 Sep 2007 13:00:21 +0900 (JST) Message-ID: <46EF4D56.8010009@nagoya-u.jp> Date: Tue, 18 Sep 2007 13:00:22 +0900 From: Nobuo Kawaguchi Organization: Nagoya University User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stig Venaas Subject: Re: [SAM] SAMTK @irtf69 References: <769E965D82021346949AF2BC41D8EAB71FB331@prdcm-mail.prdcm.panasonic.com.my> <002001c7f908$6c44a0c0$050016ac@lei> <46EE4773.2090807@uninett.no> In-Reply-To: <46EE4773.2090807@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sam@irtf.org X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.5 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: , Errors-To: sam-bounces@irtf.org Dear all SAM-rg members, > Jun Lei wrote: > > 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 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 _______________________________________________ SAM mailing list SAM@irtf.org https://www1.ietf.org/mailman/listinfo/sam From sam-bounces@irtf.org Tue Sep 18 00:31:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXUkA-0005bg-5K; Tue, 18 Sep 2007 00:31:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXUk8-0005bZ-HS for sam@irtf.org; Tue, 18 Sep 2007 00:31:24 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXUk2-0003WF-1Y for sam@irtf.org; Tue, 18 Sep 2007 00:31:24 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kings) with ESMTP id l8I4V3SQ021232 for ; Tue, 18 Sep 2007 13:31:03 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id l8I4V4K22742 for ; Tue, 18 Sep 2007 13:31:04 +0900 (JST) Received: from epochmail.jp.panasonic.com (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/astros) with ESMTP id l8I4V2o11028 for ; Tue, 18 Sep 2007 13:31:02 +0900 (JST) Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/soml26) id l8I4V2S0020112 for sam@irtf.org; Tue, 18 Sep 2007 13:31:02 +0900 (JST) Received: from donau.mrit.mei.co.jp by soml26.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id l8I4V10s020080 for ; Tue, 18 Sep 2007 13:31:01 +0900 (JST) Date: Tue, 18 Sep 2007 13:31:25 +0900 From: Eiichi Muramoto To: sam@irtf.org Subject: Re: [SAM] SAMTK @irtf69 Message-Id: <20070918133012.E274.MURAMOTO.EIICHI@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.27 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.5 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: , Errors-To: sam-bounces@irtf.org Hello > We are currently implement ALM plugin as a "manual ALM" plugin. > So one can manually control the topology of ALM. I saw the demonstration of the alpha version of SAMTK last week. It worked. I think SAMTK can provide group membership management function to ALM researcher. ALM researcher do not want to develop such a function because it is not core. If they use SAMTK they need not develop those. If a researcher develop "automatic ALM" plugin, he/she can use SAMTK group management function and SAMTK sample application like VC with M-JPEG and G7xx. I think the "manual ALM" plugin will be a skeleton for ALM researchers. Best Regards, Eiichi Muramoto On Tue, 18 Sep 2007 13:00:22 +0900 Nobuo Kawaguchi wrote: > Dear all SAM-rg members, > > > Jun Lei wrote: > > > > 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 > > 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 > > > _______________________________________________ > SAM mailing list > SAM@irtf.org > https://www1.ietf.org/mailman/listinfo/sam _______________________________________________ SAM mailing list SAM@irtf.org https://www1.ietf.org/mailman/listinfo/sam From sam-bounces@irtf.org Tue Sep 18 07:14:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXb2R-0006Wb-0g; Tue, 18 Sep 2007 07:14:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXb2P-0006T1-CG for sam@irtf.org; Tue, 18 Sep 2007 07:14:41 -0400 Received: from smtp.mei.co.jp ([133.183.129.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXb2N-0004Ff-GT for sam@irtf.org; Tue, 18 Sep 2007 07:14:41 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/bulls) with ESMTP id l8IBDwPc022124 for ; Tue, 18 Sep 2007 20:13:58 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id l8IBE0K25567 for ; Tue, 18 Sep 2007 20:14:00 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with SMTP id l8IBDx820832 for ; Tue, 18 Sep 2007 20:13:59 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [SAM] SAMTK @irtf69 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Tue, 18 Sep 2007 19:13:48 +0800 Message-ID: <769E965D82021346949AF2BC41D8EAB71FB33D@prdcm-mail.prdcm.panasonic.com.my> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SAM] SAMTK @irtf69 thread-index: Acf5rPMZ6H1KgjAKQxOpSDs3vxeCLQAMLwXA From: "Lim Boon Ping" To: "Muramoto" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: "Tan Pek Yew \(PSL\)" X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.5 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: , Errors-To: sam-bounces@irtf.org Dear all, Thank you for your warm responses!=20 >If a researcher develop "automatic ALM" plugin, he/she can use=20 >SAMTK group management function and SAMTK sample application=20 >like VC with M-JPEG and G7xx. > I think the "manual ALM" plugin will be a skeleton for ALM = researchers. I think it's indeed beneficial to the RG by providing list of wrapper = API for topology management, which would further facilitate seamless integration = of "automatic ALM" plugin" into framework like SAMTK. But it's definitely = not an easy task to cover ALM/OM/Native Multicast in one simple list of wrapper = API, considering the functions and parameters required by each protocol are different. > > >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. Take the existing ALM/OM protocol/framework as an example, existing ALM protocols can be largely divided into two clusters: centralized topology management (such as ALMI) and distributed topology management (such as Narada, NICE, YOID, Bayeux etc). In centralized approach, topology construction/reconstruction/refinement is triggered at centralized = server node and the constructed forwarding path is subsequently distributed to = all client nodes. On the other hand, in distributed approach, client node initiates connection request to root/parent node in order to setup = forwarding path. The role of topology construction/reconstruction/refinement can be triggered or performed by the parent/child/root node. =20 It will be good to compile a common list of parameters/values required = for ALM plugin, considering different architecture and role of a node which trigger the functions in ALM plugin. Best Regards, Boon Ping -----Original Message----- From: Eiichi Muramoto [mailto:muramoto.eiichi@jp.panasonic.com]=20 Sent: Tuesday, September 18, 2007 12:31 PM To: sam@irtf.org Subject: Re: [SAM] SAMTK @irtf69 Hello > We are currently implement ALM plugin as a "manual ALM" plugin. > So one can manually control the topology of ALM. I saw the demonstration of the alpha version of SAMTK last week.=20 It worked. I think SAMTK can provide group membership management function to ALM researcher. ALM researcher do not want to develop=20 such a function because it is not core. If they use SAMTK they need not=20 develop those. If a researcher develop "automatic ALM" plugin, he/she can use=20 SAMTK group management function and SAMTK sample application=20 like VC with M-JPEG and G7xx. I think the "manual ALM" plugin will be a skeleton for ALM researchers. Best Regards, Eiichi Muramoto On Tue, 18 Sep 2007 13:00:22 +0900 Nobuo Kawaguchi wrote: > Dear all SAM-rg members, >=20 > > Jun Lei wrote: > > > > 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. > >=20 > > Stig >=20 > 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. >=20 > We are currently implement ALM plugin as a "manual ALM" plugin. > So one can manually control the topology of ALM. >=20 > yours, >=20 > Nobuo Kawaguchi >=20 >=20 > _______________________________________________ > SAM mailing list > SAM@irtf.org > https://www1.ietf.org/mailman/listinfo/sam _______________________________________________ SAM mailing list SAM@irtf.org https://www1.ietf.org/mailman/listinfo/sam _______________________________________________ SAM mailing list SAM@irtf.org https://www1.ietf.org/mailman/listinfo/sam