From sam-bounces@irtf.org Sat Sep 02 14:55:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJadg-0001V1-T6; Sat, 02 Sep 2006 14:54:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJadg-0001Um-Aw for sam@irtf.org; Sat, 02 Sep 2006 14:54:44 -0400 Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJadb-0000yi-VF for sam@irtf.org; Sat, 02 Sep 2006 14:54:44 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k82Isdiq007880 for ; Sat, 2 Sep 2006 14:54:39 -0400 Received: from bufordw2 ([150.169.17.3]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with SMTP id AIU67827; Sat, 2 Sep 2006 14:51:42 -0400 (EDT) From: "John Buford" To: Date: Sat, 2 Sep 2006 14:54:30 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Junkmail-Status: score=10/57, host=redwood.research.panasonic.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090205.44F9D209.0024,ss=1,fgs=0, ip=150.169.17.3, so=2006-02-11 11:31:14, dmn=5.2.113/2006-07-26 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by oak.research.panasonic.com id k82Isdiq007880 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [SAM] Last Call - P2P Multicasting (P2PM07) - Call For Papers Sept 7 deadline 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 This message is cross-posted to several lists. Apologies for any duplicate postings. CALL FOR PAPERS Workshop on Peer-to-Peer Multicasting (P2PM'07) www.samrg.org/p2pm07/ hosted by IEEE Consumer and Communications and Networking Conference 2007 (IEEE CCNC 2007) Jan 11, 2007, Las Vegas, NV, USA www.ieee-ccnc.org The convergence of networked consumer electronics and peer-to-peer networking enables new applications that require efficient multicast communication. These applications include peercasting of multimedia streams, multi-party conferencing, multi-player games, and group chat. Many consumer applications of multicasting involve small groups of users, and future P2P multicast services could need to support millions of simultaneous groups. Due to delayed deployment of native multicast, various end-system, application layer (ALM) and overlay multicast (OM) designs have been proposed. In the future, these protocols are expected to coexist and integrate with native IP multicast protocols while offering more flexible deployment options and scaling to support a greater number of simultaneous multicast groups. P2PM=9207 is intended to serve as a continuing forum for scientists and engineers in academia and industry to exchange and discuss their experiences, new ideas, and research results about all aspects of P2P multicasting. It will address the challenges, technologies, and architectures leading to real-world solutions that provide P2P users with efficient, flexible, and deployable multicast services. The principal theme of P2PM=9207 is the development of protocols, architectures and applications of peer-to-peer multicasting and the performance evaluation of these designs. Topics of particular interest include, but are not limited to: =AD Peer-to-peer overlays with multicast support =AD Small group multicast =AD Explicit multicasting =AD Application Layer Multicast (ALM) =AD Overlay Multicast (OM) =AD Peercasting Multicasting in mobile networks =AD Hybrid multicasting architectures =AD Comparitive analysis of ALM and OM architectures =AD Scalable integration of QoS mechanisms =AD Overlay content distribution =AD Multi-path routing for overlay multicasting =AD Methods for group formation and discovery that scale to large numbers of groups =AD Support for highly dynamic group membership =AD Efficient multicast for limited-resource nodes and access links =AD Control mechanisms for hybrid systems =AD Underlay network support and optimization =AD Deploying, diagnosing, debugging, and managing P2P multicast services =AD Geocasting =AD Multicasting in the global information grid (GIG) =AD Integration with network- and application-layer security mechanisms Important dates: Sept 7, 2006 Papers due Sept 30, 2006 Reviews returned Oct 10, 2006 Camera ready copy due Jan 11, 2007 Workshop Organizers John Buford, Panasonic Princeton Laboratory Keith Ross, Polytechnic University Technical Program Committee (preliminary) William Atwood (Concordia University) Bobby Bhattacharjee (University of Maryland) Fabi=E1n Bustamante (Northwestern University) Gary Chan (Hong Kong University of Science and Technology) Xiaoming Fu (University of Goettingen) Ali Ghodsi (Swedish Institute of Computer Science) Baochun Li (University of Toronto) Alan Messer (Samsung Electronics) Jeremy Mineweaser (MIT Lincoln Laboratory) Khaled Ragab (University of Tokyo) Mark Pullen (George Mason University) Sanjay Rao (Purdue University) Keith Ross (Polytechnic University) G=FCnter Sch=E4fer (Technische Universit=E4t Ilmenau) Zahir Tari (RMIT University) Kurt Tutschku (University of W=FCrzburg) Li Xiao (Michigan State University) Heather Yu (Panasonic Princeton Laboratory) Wenjun Zeng (University of Missouri, Columbia) Further information: See the following web sites: www.samrg.org/p2pm07/ http://www.ieee-ccnc.org/callforpapers/P2PM_workshop/index.html _______________________________________________ SAM mailing list SAM@irtf.org https://www1.ietf.org/mailman/listinfo/sam From sam-bounces@irtf.org Mon Sep 25 10:33:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrWY-0002qO-CG; Mon, 25 Sep 2006 10:33:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrWX-0002qI-7H for sam@irtf.org; Mon, 25 Sep 2006 10:33:33 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrWV-0006g6-T3 for sam@irtf.org; Mon, 25 Sep 2006 10:33:33 -0400 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k8PEXVNh016776 for ; Mon, 25 Sep 2006 07:33:31 -0700 (MST) Received: from [10.232.37.227] ([10.232.37.227]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k8PEXSZf003644; Mon, 25 Sep 2006 09:33:29 -0500 (CDT) Message-ID: <4517E8B5.8090200@motorola.com> Date: Mon, 25 Sep 2006 20:03:25 +0530 From: Shiv User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: sam@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.3 (++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Gangaram Vihang-A20783 , Ram O V Vishnu-A14676 Subject: [SAM] Mobility in SAM problem. 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 Buford, I work in the multicast area. I was reading the sam problem statement draft (draft-irtf-sam-problem-statement-00.txt). I think you have succinctly summarised the problem. I have some comments to the draft. Please let me know if these are relevant. we see that there are 2 mobility scenarios associated with multicast: If the mobileip is the mobility solution of choice and the overlay is transparent to this: (example scenarios with native multicast is given below): Section 4 Mobility: 1 - If foreign network has multicast router, mobile node can join the multicast group through that multicast router. a - If mobile node is coloacated then it uses coa as the source address of control mesages, otherwise Mobile Node MAY use its home address(But if mobile node want to send packets to multicast group in foreign network, source ip of packets should be coloacated ip). b - causes a leave-join sequence. c - If router is not a part of multicast SPT, joining in foreign network causes delay. 2 - Home agent tunnels packets to/from mobile node. a - mobile node used home address for multicast control messages. b - No need to join/leave during handoff. c - may result in duplicate packets if MN is not coloacated. Consider two mobile nodes belonging to different network which are in the same foreign network. Both subscribe to same group, then packets of same multicast group are coming from two networks. Possible solutions to this are: 1 - Applications in mobile node will take care of duplicate packets. 2 - Multicast packets will be sent to mobile node as unicast packets(Mobile IPv4 uses this solution). But in case of coloacated MN multicast packets are directly tunneled to MN. It would be good to add both these scenarios in the problem statement draft. Need to consider the movement scenario between heterogenous multicast networks (say, from native multicast region to overlay(OL/ALM) multicast region or viceversa). Yet another problem is that some of the solutions to the packet loss advocates buffering packets at HA: This may result in duplicate packets. If foreign network already has mobile node subscribed to same group, when handoff happens these buffered packets are duplicate packets to that mobile node. a - potential solutions might be to transfer the buffered packets to mobile node as unicast packets. b - let the applications handle duplicate detection. Instead of buffering at HA, it is better to buffer at old router(Access router/FA). how to handle multicast service advertisements? multicast advertisements are also multicast packets with well known multicast group ip and port number. Should these multicast service packets be tunneled to mobile nodes which are in foreign network? If not how mobile nodes will come to know about services provided by the home network. 5 Security: Will sam specify the interworking between the security mechanisms of the heterogenous mc mechanisms? Thanks, Shivanand Kadadi. _______________________________________________ SAM mailing list SAM@irtf.org https://www1.ietf.org/mailman/listinfo/sam From sam-bounces@irtf.org Mon Sep 25 11:05:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRs1b-0007f5-6o; Mon, 25 Sep 2006 11:05:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRs1Z-0007e5-Fv for sam@irtf.org; Mon, 25 Sep 2006 11:05:37 -0400 Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRs1C-0000aS-Ck for sam@irtf.org; Mon, 25 Sep 2006 11:05:37 -0400 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k8PF5LkF002004; Mon, 25 Sep 2006 11:05:21 -0400 Received: from bufordw2 ([150.169.17.1]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with SMTP id AJW07487; Mon, 25 Sep 2006 11:02:05 -0400 (EDT) From: "John Buford" To: "Shiv" , Subject: RE: [SAM] Mobility in SAM problem. Date: Mon, 25 Sep 2006 11:05:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <4517E8B5.8090200@motorola.com> X-Junkmail-Status: score=10/57, host=redwood.research.panasonic.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090207.4517EE19.0056,ss=1,fgs=0, ip=150.169.17.1, so=2006-02-11 11:31:14, dmn=5.2.113/2006-07-26 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Gangaram Vihang-A20783 , Ram O V Vishnu-A14676 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 Shiv, Thanks for your comments on the Problem Statement. The two IP Multicast mobility scenarios you provide would be a good addition to the mobility section. Your other points about heterogeneous movement, buffering, and multicast service advertisements are also good ones. Regarding the security question, interoperability of existing mc security mechanisms is in scope. Would you be able to edit section 4 of the draft to incorporate your scenarios and issues? If so, send me the revised text you propose and we can issue a new draft for comment by the mailing list. John -----Original Message----- From: Shiv [mailto:a22063@motorola.com] Sent: Monday, September 25, 2006 10:33 AM To: sam@irtf.org Cc: Gangaram Vihang-A20783; Ram O V Vishnu-A14676 Subject: [SAM] Mobility in SAM problem. Dear Buford, I work in the multicast area. I was reading the sam problem statement draft (draft-irtf-sam-problem-statement-00.txt). I think you have succinctly summarised the problem. I have some comments to the draft. Please let me know if these are relevant. we see that there are 2 mobility scenarios associated with multicast: If the mobileip is the mobility solution of choice and the overlay is transparent to this: (example scenarios with native multicast is given below): Section 4 Mobility: 1 - If foreign network has multicast router, mobile node can join the multicast group through that multicast router. a - If mobile node is coloacated then it uses coa as the source address of control mesages, otherwise Mobile Node MAY use its home address(But if mobile node want to send packets to multicast group in foreign network, source ip of packets should be coloacated ip). b - causes a leave-join sequence. c - If router is not a part of multicast SPT, joining in foreign network causes delay. 2 - Home agent tunnels packets to/from mobile node. a - mobile node used home address for multicast control messages. b - No need to join/leave during handoff. c - may result in duplicate packets if MN is not coloacated. Consider two mobile nodes belonging to different network which are in the same foreign network. Both subscribe to same group, then packets of same multicast group are coming from two networks. Possible solutions to this are: 1 - Applications in mobile node will take care of duplicate packets. 2 - Multicast packets will be sent to mobile node as unicast packets(Mobile IPv4 uses this solution). But in case of coloacated MN multicast packets are directly tunneled to MN. It would be good to add both these scenarios in the problem statement draft. Need to consider the movement scenario between heterogenous multicast networks (say, from native multicast region to overlay(OL/ALM) multicast region or viceversa). Yet another problem is that some of the solutions to the packet loss advocates buffering packets at HA: This may result in duplicate packets. If foreign network already has mobile node subscribed to same group, when handoff happens these buffered packets are duplicate packets to that mobile node. a - potential solutions might be to transfer the buffered packets to mobile node as unicast packets. b - let the applications handle duplicate detection. Instead of buffering at HA, it is better to buffer at old router(Access router/FA). how to handle multicast service advertisements? multicast advertisements are also multicast packets with well known multicast group ip and port number. Should these multicast service packets be tunneled to mobile nodes which are in foreign network? If not how mobile nodes will come to know about services provided by the home network. 5 Security: Will sam specify the interworking between the security mechanisms of the heterogenous mc mechanisms? Thanks, Shivanand Kadadi. _______________________________________________ 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 26 06:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSA6F-00014b-9v; Tue, 26 Sep 2006 06:23:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSA6D-00014A-Qh for sam@irtf.org; Tue, 26 Sep 2006 06:23:37 -0400 Received: from emailer.gwdg.de ([134.76.10.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSA6C-0007JG-99 for sam@irtf.org; Tue, 26 Sep 2006 06:23:37 -0400 Received: from s4.ifi.informatik.uni-goettingen.de ([134.76.81.226] helo=smtp.ifi.informatik.uni-goettingen.de) by mailer.gwdg.de with esmtp (Exim 4.60) (envelope-from ) id 1GSA52-0006KN-ON; Tue, 26 Sep 2006 12:22:25 +0200 Received: from [172.22.0.22] (tmg22.tmg.loc [172.22.0.22]) by smtp.ifi.informatik.uni-goettingen.de (Postfix) with ESMTP; Tue, 26 Sep 2006 12:22:23 +0200 (CEST) Message-ID: <4518FF21.9080009@informatik.uni-goettingen.de> Date: Tue, 26 Sep 2006 12:21:21 +0200 From: Jun Lei User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Buford , sam@irtf.org Subject: Re: [SAM] Mobility in SAM problem. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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: It's so great to hear some voices from SAM. Overaly technologies could be well used in Mobility solutions and several researches have been focusing on this topic. John: Regarding the draft, I am just wondering whether the following issue fall into the problem statement as well? - In Section 2.2, you've mentioned "regional transitions". How about the transience of group members? Since application level multicast systems are mainly dependent on the group members to maintain such an overlay network. - If we need to consider the transience of nodes, then two situations are required: graceful leave & unexpected leave a. graceful leave: need to consider tree re-construction b. ungraceful leave: failure detection + failure recovery By the way, I am currently focusing on above topic. I will try to give an brief overview on this topic by next week. Best Regards Jun > Shiv, > Thanks for your comments on the Problem Statement. > > The two IP Multicast mobility scenarios you > provide would be a good addition to the mobility > section. > > Your other points about heterogeneous movement, > buffering, and multicast service advertisements > are also good ones. > > Regarding the security question, interoperability > of existing mc security mechanisms is in scope. > > Would you be able to edit section 4 of the > draft to incorporate your scenarios and issues? > If so, send me the revised text you propose and > we can issue a new draft for comment by the mailing > list. > > John > > -----Original Message----- > From: Shiv [mailto:a22063@motorola.com] > Sent: Monday, September 25, 2006 10:33 AM > To: sam@irtf.org > Cc: Gangaram Vihang-A20783; Ram O V Vishnu-A14676 > Subject: [SAM] Mobility in SAM problem. > > > Dear Buford, > > I work in the multicast area. I was reading the sam problem statement > draft (draft-irtf-sam-problem-statement-00.txt). > I think you have succinctly summarised the problem. I have some > comments to the draft. > Please let me know if these are relevant. > > we see that there are 2 mobility scenarios associated with multicast: > > If the mobileip is the mobility solution of choice and the overlay is > transparent to this: (example scenarios with native multicast is given > below): > > Section 4 Mobility: > > 1 - If foreign network has multicast router, mobile node can join the > multicast group through that multicast router. > a - If mobile node is coloacated then it uses coa as the source > address of control mesages, otherwise Mobile Node MAY use its home > address(But if mobile node want to send packets to multicast group in > foreign network, source ip of packets should be coloacated ip). > b - causes a leave-join sequence. > c - If router is not a part of multicast SPT, joining in > foreign network causes delay. > > 2 - Home agent tunnels packets to/from mobile node. > a - mobile node used home address for multicast control messages. > b - No need to join/leave during handoff. > c - may result in duplicate packets if MN is not coloacated. > Consider two mobile nodes belonging to different network which are in > the same foreign network. Both subscribe to same group, then packets of > same multicast group are coming from two networks. Possible solutions to > this are: > 1 - Applications in mobile node will take care of duplicate packets. > 2 - Multicast packets will be sent to mobile node as unicast > packets(Mobile IPv4 uses this solution). > But in case of coloacated MN multicast packets are directly > tunneled to MN. > > It would be good to add both these scenarios in the problem statement draft. > > Need to consider the movement scenario between heterogenous multicast > networks (say, from native multicast region to overlay(OL/ALM) multicast > region or viceversa). > Yet another problem is that some of the solutions to the packet loss > advocates buffering packets at HA: > This may result in duplicate packets. If foreign network already has > mobile node subscribed to same group, when handoff happens these > buffered packets are duplicate packets to that mobile node. > a - potential solutions might be to transfer the buffered > packets to mobile node as unicast packets. > b - let the applications handle duplicate detection. > Instead of buffering at HA, it is better to buffer at old router(Access > router/FA). > > how to handle multicast service advertisements? > multicast advertisements are also multicast packets with well known > multicast group ip and port number. Should these multicast service > packets be > tunneled to mobile nodes which are in foreign network? If not how mobile > nodes > will come to know about services provided by the home network. > > 5 Security: > Will sam specify the interworking between the security > mechanisms of the heterogenous mc mechanisms? > > Thanks, > Shivanand Kadadi. > > > _______________________________________________ > 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 -- Jun Lei PhD Student 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 _______________________________________________ SAM mailing list SAM@irtf.org https://www1.ietf.org/mailman/listinfo/sam