From daemon@ns.ietf.org Tue Feb 5 17:58:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22548 for ; Tue, 5 Feb 2002 17:58:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA07045 for rmt-archive@odin.ietf.org; Tue, 5 Feb 2002 17:58:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06832; Tue, 5 Feb 2002 17:53:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06803 for ; Tue, 5 Feb 2002 17:53:21 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22343; Tue, 5 Feb 2002 17:53:05 -0500 (EST) Message-Id: <200202052253.RAA22343@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , rmt@ietf.org From: The IESG Date: Tue, 05 Feb 2002 17:53:05 -0500 Subject: [Rmt] Document Action: Author Guidelines for RMT Building Blocks and Protocol Instantiation documents to Informational Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org The IESG has approved the Internet-Draft 'Author Guidelines for RMT Building Blocks and Protocol Instantiation documents' as an Informational RFC. This document is the product of the Reliable Multicast Transport Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Fri Feb 8 10:19:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10603 for ; Fri, 8 Feb 2002 10:19:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12793 for rmt-archive@odin.ietf.org; Fri, 8 Feb 2002 10:19:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12005; Fri, 8 Feb 2002 10:04:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11976 for ; Fri, 8 Feb 2002 10:04:22 -0500 (EST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09811 for ; Fri, 8 Feb 2002 10:04:18 -0500 (EST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id g18F4JE25526 for ; Fri, 8 Feb 2002 07:04:19 -0800 (PST) Received: from hanmir.com ([211.206.9.41]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id g18F4HJ25522 for ; Fri, 8 Feb 2002 07:04:18 -0800 (PST) Message-Id: <200202081504.g18F4HJ25522@SpamWall.lbl.gov> Reply-To: sua95@hanmir.com From: K보트닷컴 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 9 Feb 2002 00:03:58 +0900 X-User: 2.61-gjhkelkn-lmplgp-Eejjr Subject: [Rmt] [광고]고무보트 구경 오세요! Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org 광고 메일
 
 
본 메일은 발신 전용 광고 메일 입니다.
수신거부를 원 하시면 여기를 클릭하여 주세요!
------------------------------------------------------------
보트가족 여러분 안녕 하세요?
보트가족 에게 겨울은 너무 깁니다. 이제 입춘도 지나고 봄이 멀지 않았습니다.
다가올 새 봄엔 어복도 풍만 하시고 건강과 행운이 함께하는
레저생활 되시기 바랍니다.
저희는 보트를 생산한지 20여년 된 고무보트 전문 생산업체 입니다.
이제 여러분과 함께 새 봄을 준비 하고자 "K보트닷컴"이란 이름으로
사이버 전시장을 마련 했습니다.
많은 지도 편달 바랍니다. "Click!!" http://www.kboat.com
-"K보트닷컴" 관리자 드림-
------------------------------------------------------------
 
_______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Fri Feb 8 17:36:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26738 for ; Fri, 8 Feb 2002 17:36:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA10006 for rmt-archive@odin.ietf.org; Fri, 8 Feb 2002 17:36:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09336; Fri, 8 Feb 2002 17:27:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09305 for ; Fri, 8 Feb 2002 17:27:55 -0500 (EST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26554 for ; Fri, 8 Feb 2002 17:27:50 -0500 (EST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id g18MRqE28986 for ; Fri, 8 Feb 2002 14:27:52 -0800 (PST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id g18MRpJ28965 for ; Fri, 8 Feb 2002 14:27:51 -0800 (PST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Fri Feb 8 17:26:17 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g18MQ3S82864; Fri, 8 Feb 2002 17:26:03 -0500 (EST) Received: from dnrc.bell-labs.com (jcb2-pcho [135.180.144.92]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA02581; Fri, 8 Feb 2002 17:26:01 -0500 (EST) Message-ID: <3C64505A.98D7CF8E@dnrc.bell-labs.com> Date: Fri, 08 Feb 2002 17:25:30 -0500 From: Jose Carlos Brustoloni Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: tci-announce@computer.org, cost264@lip6.fr, rm@openmash.org, rmt@lbl.gov, mboned@network-services.uoregon.edu, rem-conf@es.net, manet@itd.nrl.navy.mil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Rmt] CFP: High-Speed Networks Symposium at Globecom'2002 (HSN'2002) Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org Content-Transfer-Encoding: 7bit [Please feel free to share this announcement with your colleagues, and accept our apologies in case you have already received it.] High-Speed Networks Symposium at Globecom'2002 (HSN'2002) Taipei, Taiwan November 17-21, 2001 http://opnear.utdallas.edu/hsnhome.htm ---------------------------------------------------------------------- CALL FOR PAPERS New generations of local, metropolitan, wide-area, access, and wireless networks are pushing the envelope on network speeds. Faster, more capable networks herald the convergence of voice, video, and data and promise to facilitate applications ranging from video-conferencing to grid computing. However, the challenges are many, requiring improved network architectures, protocols, routers, switches, and components, appropriate programming and operating system support, novel approaches for network management, security, and quality of service, sensible migration paths, and successful pilot studies. The High-Speed Networks Symposium 2002 (HSN'2002) will be held as part of Globecom'2002 to address these and other topics relevant to high- speed networking. Globecom is the flagship annual conference of the IEEE Communications Society and this year will be held in Taipei, Taiwan, from November 17 to 21. Researchers, developers, and practitioners of all areas of industry, academia, and governmental agencies of all nations are encouraged to submit papers to HSN'2002. Topics of interest include but are not limited to: - Last-mile solutions, pilot studies, and deployment projections and evaluation - Metropolitan-area networks, including Metro Ethernet and Resilient Packet Rings - Optical networks, including switching technologies, dynamic provisioning, protection, and restoration - Wireless networks, including 802.11x, 3G/4G, and All-IP - Novel mechanisms for scheduling, buffering, switching, routing, and multicast - Programming and operating system support for network processors and high-speed nodes - Network management, traffic engineering, quality of service, and security in high-speed networks - Inter-layer interactions (e.g., IP/SONET and electrical/optical) and interoperability in high-speed networks - Viability studies and migration paths, e.g., from ATM to (G)MPLS-based core networks - Governmental initiatives and regulatory agenda and concerns - Applications, including video-conferencing, video-on-demand, telecommuting, VPNs, network-based storage, thin clients, grid computing, and respective pilot studies and deployment evaluation Papers should be at most 5 pages long and conform to Globecom'2002 guidelines. Papers must be submitted electronically via the Globecom'2002 web site at: http://www.globecom2002.com/submissions/ To ensure proper paper routing, authors should indicate that their papers are being submitted to the High-Speed Networks Symposium. Each paper will be refereed by at least three reviewers. Accepted papers will be published by IEEE in the Proceedings of Globecom'2002. Best paper award ---------------- IEEE TCGN will distinguish with its Best Paper Award one paper submitted to HSN'2002. This paper will be selected by the HSN'2002 technical program committee. Student travel grants --------------------- IEEE Communications Society will award a limited number of grants to full-time graduate students who need to travel from another region to present an accepted paper at HSN'2002. Other sessions -------------- In addition to refereed paper sessions, HSN'2002 will feature a keynote address on optical networking by Dr. David Lee (head of Bell Labs Research China) and a panel discussion on metropolitan networks organized by Prof. Hui Zhang (Turin Networks and Carnegie Mellon University). Important dates --------------- - Submission deadline: February 25, 2002 - Notification of acceptance: June 30, 2002 - Camera-ready version due: August 15, 2002 - Presentations: November 18-20, 2002 Web sites --------- HSN'2002 - http://opnear.utdallas.edu/hsnhome.htm Globecom'2002 - http://www.globecom2002.com/ HSN'2002 Program Co-chairs -------------------------- Jose' Brustoloni (jcb@dnrc.bell-labs.com), Bell Labs, Lucent Technologies, USA Andrea Fumagalli (andreaf@utdallas.edu), The University of Texas at Dallas, USA HSN'2002 Technical Program Committee ------------------------------------ Marco Ajmone Marsan, Politecnico di Torino, Italy Ian F. Akyildiz, Georgia Tech, USA Javier Aracil, University of Navarra, Spain Larry Bernstein, Stevens Institute of Technology, USA Hakki Candan Cankaya, Alcatel, USA Prashant Chandra, Intel, USA Fabio Chiussi, Bell Labs, Lucent Technologies, USA Cheng C. Chen, NEC, USA Jacek Chrostowski, Cisco Systems, Canada Yuguang "Michael" Fang, University of Florida, USA Andras Farago, The University of Texas at Dallas, USA Joseph B. Evans, The University of Kansas, USA Jeff Fitchett, Nortel Networks, Canada Nelson Fonseca, Campinas State University, Brazil Ibrahim W. Habib, Telcordia, USA Y. Thomas Hou, Fujitsu Labs of America, USA Jennifer Hou, University of Illinois at Urbana-Champaign, USA Rauf Izmailov, NEC, USA Laszlo Jereb, Technical University of Budapest, Hungary Admela Jukan, Vienna University of Technology, Austria Mark Karol, Avaya Labs, USA Tanja Kauppinen, Ericsson Telecom, Sweden G.S. Kuo, National Chengchi University, Taiwan Wan-Jiun Liao, National Taiwan University, Taiwan Antonio Manzalini, Telecom Italia Lab, Italy Muriel Medard, MIT, USA Alberto Paradisi, CPqD, Brazil Steve Pope, AT&T Labs Cambridge, England Fabrice Poppe, Alcatel, Belgium Chunming Qiao, The State University of New York at Buffalo, USA Kamel Rahouna, RIST++, Austria Patricia Sagmeister, IBM, Switzerland Galen Sasaki, University of Hawaii, USA Ken-ichi Sato, NTT, Japan Marco Schneider, SBC Technology Resources, USA Edmundo de Souza e Silva, UFRJ, Brazil James P.G. Sterbenz, BBN Technologies, USA Suresh Subramaniam, George Washington University, USA Kenji Suzuki, Advanced Communications Co., Japan Franco Travostino, Nortel Networks, USA Si Qing Zheng, The University of Texas at Dallas, USA Naoaki Yamanaka, NTT, Japan Sponsoring organizations ------------------------ The following committees of the IEEE Communications Society are technical co-sponsors of HSN'2002: - Gigabit Networking Technical Committee - Communications Software Technical Committee - Communications Switching & Routing Technical Committee - Computer Communications Technical Committee - Internet Technical Committee - Multimedia Communications Technical Committee -- Jose' Brustoloni Tel.: (732) 332-5368 Address: Bell Laboratories Fax: (732) 949-0399 101 Crawfords Corner Rd. Email: jcb@dnrc.bell-labs.com Room 4E-630 http://www.bell-labs.com/~jcb/ Holmdel, NJ 07733 - USA _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 05:33:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07351 for ; Tue, 12 Feb 2002 05:33:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA13571 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 05:33:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12746; Tue, 12 Feb 2002 05:20:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12720 for ; Tue, 12 Feb 2002 05:20:56 -0500 (EST) Received: from rover.inria.fr (IDENT:root@rover.inria.fr [138.96.88.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07242 for ; Tue, 12 Feb 2002 05:20:53 -0500 (EST) Received: from sophia.inria.fr by rover.inria.fr (8.11.6/8.10.0) with ESMTP id g1CAKsm11803; Tue, 12 Feb 2002 11:20:54 +0100 X-Authentication-Warning: rover.inria.fr: Host localhost [127.0.0.1] claimed to be sophia.inria.fr Message-ID: <3C68EC86.4080703@sophia.inria.fr> Date: Tue, 12 Feb 2002 11:20:54 +0100 From: Fethi Filali Organization: INRIA Sophia-Antipolis (http://www.inria.fr) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: fr-FR, en MIME-Version: 1.0 To: rmt@ietf.org CC: pim@catarina.usc.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Rmt] pim-sm and layered multicast Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org Content-Transfer-Encoding: 7bit Hi all, Suppose that we use PIM-SM as multicast routing protocol and the multicast source uses a layered multicast congestion control protocol (RLM, FLID-DL, ...) to send data to the receivers. Each layer uses a different multicast group address. These addresses may be mapped to different RP using the bootstrap mechanism of PIM-SM (which allow only 4 group adresses to be mapped to the same RP). Suppose that we do not switch immediatly to the SPT (we van use a *private* mechanism to decide the switching rather than the rate-based one given as example in pim-sm draft). The problem is that a multicast receiver may receive layers from different paths (because of using different RP per layer), the congestion may occur in lower layers paths but not in higher layer paths. Two problems hold: 1. the receiver take more time to detect the congestion because it leaves layer by layer and estimate again the loss rate. 2. the receiver will leave higher layer, while it follows un-congestioned paths !! My questions are: 1. Do you agree with me ? 2. If so, are there any works on these pbs? Fethi. PS: the same problem may be hold if we use a QoS-based multicast routing protocols (no deployable one exist) !! _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 05:44:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07440 for ; Tue, 12 Feb 2002 05:44:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA13891 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 05:44:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13635; Tue, 12 Feb 2002 05:34:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13607 for ; Tue, 12 Feb 2002 05:34:22 -0500 (EST) Received: from wisbech.cl.cam.ac.uk (exim@mta1.cl.cam.ac.uk [128.232.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07368 for ; Tue, 12 Feb 2002 05:34:19 -0500 (EST) Received: from shep.cl.cam.ac.uk ([128.232.8.11] helo=cl.cam.ac.uk ident=jac22) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 16aaGS-0003SV-00; Tue, 12 Feb 2002 10:34:20 +0000 To: Fethi Filali cc: rmt@ietf.org, pim@catarina.usc.edu Subject: Re: [Rmt] pim-sm and layered multicast In-Reply-To: Message from Fethi Filali of "Tue, 12 Feb 2002 11:20:54 +0100." <3C68EC86.4080703@sophia.inria.fr> Date: Tue, 12 Feb 2002 10:34:20 +0000 From: Jon Crowcroft Message-Id: Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org In message <3C68EC86.4080703@sophia.inria.fr>, Fethi Filali typed: >>Suppose that we use PIM-SM as multicast routing protocol and the >>multicast source uses a layered multicast congestion control protocol >>(RLM, FLID-DL, ...) to send data to the receivers. Each layer uses a >>different multicast group address. These addresses may be mapped to >>different RP using the bootstrap mechanism of PIM-SM (which allow only 4 >> group adresses to be mapped to the same RP). >> >>Suppose that we do not switch immediatly to the SPT (we van use a >>*private* mechanism to decide the switching rather than the rate-based >>one given as example in pim-sm draft). >> >>The problem is that a multicast receiver may receive layers from >>different paths (because of using different RP per layer), the >>congestion may occur in lower layers paths but not in higher layer >>paths. Two problems hold: >> >>1. the receiver take more time to detect the congestion because it >>leaves layer by layer and estimate again the loss rate. >> >>2. the receiver will leave higher layer, while it follows >>un-congestioned paths !! >>My questions are: >>1. Do you agree with me ? hypothtically, sure >>2. If so, are there any works on these pbs? i guess also note that a source that actually is multiple sources to different grouops could fall foul of MSDP timers too - if the layer increase/decrease stuff was sufficiently infrequemt./.. >>PS: the same problem may be hold if we use a QoS-based multicast routing >>protocols (no deployable one exist) !! spose so >> >>_______________________________________________ >>Rmt mailing list >>Rmt@ietf.org >>https://www1.ietf.org/mailman/listinfo/rmt cheers jon _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 07:11:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09122 for ; Tue, 12 Feb 2002 07:11:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA17910 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 07:11:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17257; Tue, 12 Feb 2002 07:03:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17228 for ; Tue, 12 Feb 2002 07:03:11 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08660; Tue, 12 Feb 2002 07:03:09 -0500 (EST) Message-Id: <200202121203.HAA08660@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 12 Feb 2002 07:03:09 -0500 Subject: [Rmt] I-D ACTION:draft-ietf-rmt-pi-alc-05.txt,.ps Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Asynchronous Layered Coding protocol instantiation Author(s) : M. Luby et al. Filename : draft-ietf-rmt-pi-alc-05.txt,.ps Pages : 33 Date : 11-Feb-02 This document describes the Asynchronous Layered Coding protocol, a massively scalable reliable content delivery protocol, hereafter referred to as ALC. ALC combines the LCT [11], WEBRC [12] and FEC [10] building blocks to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-pi-alc-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-pi-alc-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020211152505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-alc-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-alc-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020211152505.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 07:13:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09222 for ; Tue, 12 Feb 2002 07:13:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18001 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 07:13:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17339; Tue, 12 Feb 2002 07:03:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17308 for ; Tue, 12 Feb 2002 07:03:22 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08692; Tue, 12 Feb 2002 07:03:21 -0500 (EST) Message-Id: <200202121203.HAA08692@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 12 Feb 2002 07:03:20 -0500 Subject: [Rmt] I-D ACTION:draft-ietf-rmt-bb-fec-06.txt,.ps Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Forward Error Correction building block Author(s) : M. Luby et al. Filename : draft-ietf-rmt-bb-fec-06.txt,.ps Pages : 8 Date : 11-Feb-02 This document describes the abstract packet formats and IANA registration procedures for use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-bb-fec-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-bb-fec-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020211152531.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-fec-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-fec-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020211152531.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 07:19:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09306 for ; Tue, 12 Feb 2002 07:19:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18182 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 07:19:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17300; Tue, 12 Feb 2002 07:03:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17267 for ; Tue, 12 Feb 2002 07:03:17 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08676; Tue, 12 Feb 2002 07:03:15 -0500 (EST) Message-Id: <200202121203.HAA08676@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 12 Feb 2002 07:03:15 -0500 Subject: [Rmt] I-D ACTION:draft-ietf-rmt-bb-lct-04.txt,.ps Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Layered Coding Transport building block Author(s) : M. Luby et al. Filename : draft-ietf-rmt-bb-lct-04.txt,.ps Pages : 32 Date : 11-Feb-02 Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides muliple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-bb-lct-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-bb-lct-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020211152518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-bb-lct-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-bb-lct-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020211152518.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 07:19:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09322 for ; Tue, 12 Feb 2002 07:19:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18206 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 07:19:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17381; Tue, 12 Feb 2002 07:03:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17348 for ; Tue, 12 Feb 2002 07:03:30 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08708; Tue, 12 Feb 2002 07:03:28 -0500 (EST) Message-Id: <200202121203.HAA08708@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 12 Feb 2002 07:03:28 -0500 Subject: [Rmt] I-D ACTION:draft-ietf-rmt-info-fec-02.txt,.ps Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : The use of Forward Error Correction in Reliable Multicast Author(s) : M. Luby et al. Filename : draft-ietf-rmt-info-fec-02.txt,.ps Pages : 18 Date : 11-Feb-02 This memo describes the use of Forward Error Correction (FEC) codes within the context of reliable IP multicast transport and provides an introduction to some commonly-used FEC codes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-info-fec-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-info-fec-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-info-fec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020211152541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-info-fec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-info-fec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020211152541.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 09:11:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12232 for ; Tue, 12 Feb 2002 09:11:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23030 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 09:11:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22323; Tue, 12 Feb 2002 09:03:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22295 for ; Tue, 12 Feb 2002 09:03:37 -0500 (EST) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11877 for ; Tue, 12 Feb 2002 09:03:34 -0500 (EST) Received: from [165.247.109.162] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1254157; Tue, 12 Feb 2002 08:31:11 -0500 From: "Marshall Eubanks" Subject: Re: [Rmt] pim-sm and layered multicast To: Fethi Filali , rmt@ietf.org Cc: pim@catarina.usc.edu, Bill Fenner , Bill Nickless X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Tue, 12 Feb 2002 08:31:11 -0500 Message-ID: In-Reply-To: <3C68EC86.4080703@sophia.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org Content-Transfer-Encoding: 8bit On Tue, 12 Feb 2002 11:20:54 +0100 Fethi Filali wrote: > Hi all, > > Suppose that we use PIM-SM as multicast routing protocol > and the > multicast source uses a layered multicast congestion > control protocol > (RLM, FLID-DL, ...) to send data to the receivers. Each > layer uses a > different multicast group address. These addresses may be > mapped to > different RP using the bootstrap mechanism of PIM-SM > (which allow only 4 > group adresses to be mapped to the same RP). You are referring to RFC 2362 Section 3.7. This is set by the hash mask : 1 For RP addresses in the RP-Set, whose Group-prefix covers G, select the RPs with the highest priority (i.e. lowest `Priority' value), and compute a value: Value(G,M,C(i))= (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + 12345) mod 2^31 where C_i is the RP address and M is a hash-mask included in Bootstrap messages. The hash-mask allows a small number of consecutive groups (e.g., 4) to always hash to the same RP. For instance, hierarchically-encoded data can be sent on consecutive group addresses to get the same delay and fate-sharing characteristics. The intent as I read it is not that _only_ four group members be assigned to each RP, but that _at least_ four consecutive group addresses be assigned to each RP. In many domains, one RP handles all groups. This was probably written before GLOP. Also, I know of no specificiation or recommendation for the hash-mask M. Given the relative success of GLOP, maybe a hash value of 0.0.0.255 be used - so that an entire GLOP would be handled by one RP by default. > > Suppose that we do not switch immediatly to the SPT (we > van use a > *private* mechanism to decide the switching rather than > the rate-based > one given as example in pim-sm draft). > I have a feeling that ASM may move to a "never switch to the SPT" as SSM takes off and ASM is used mostly for teleconference type applications, so this seems germaine. Regards Marshall Eubanks > The problem is that a multicast receiver may receive > layers from > different paths (because of using different RP per > layer), the > congestion may occur in lower layers paths but not in > higher layer > paths. Two problems hold: > > 1. the receiver take more time to detect the congestion > because it > leaves layer by layer and estimate again the loss rate. > > 2. the receiver will leave higher layer, while it follows > un-congestioned paths !! > > My questions are: > > 1. Do you agree with me ? > 2. If so, are there any works on these pbs? > > > Fethi. > > PS: the same problem may be hold if we use a QoS-based > multicast routing > protocols (no deployable one exist) !! > > > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www1.ietf.org/mailman/listinfo/rmt _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 09:20:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12606 for ; Tue, 12 Feb 2002 09:20:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23417 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 09:20:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22389; Tue, 12 Feb 2002 09:05:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22358 for ; Tue, 12 Feb 2002 09:04:58 -0500 (EST) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11898 for ; Tue, 12 Feb 2002 09:04:53 -0500 (EST) Received: from maroon.jnpr.net (maroon.jnpr.net [172.24.244.36]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1CE4E631525; Tue, 12 Feb 2002 06:04:14 -0800 (PST) (envelope-from shep@juniper.net) Received: from localhost (shep@localhost) by maroon.jnpr.net (8.11.3/8.11.3) with ESMTP id g1CE49537121; Tue, 12 Feb 2002 06:04:09 -0800 (PST) (envelope-from shep@juniper.net) X-Authentication-Warning: maroon.jnpr.net: shep owned process doing -bs Date: Tue, 12 Feb 2002 06:04:09 -0800 (PST) From: Greg Shepherd X-X-Sender: To: Jon Crowcroft cc: Fethi Filali , , Subject: Re: [Rmt] pim-sm and layered multicast In-Reply-To: Message-ID: <20020212053301.N35884-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org On Tue, 12 Feb 2002, Jon Crowcroft wrote: > > In message <3C68EC86.4080703@sophia.inria.fr>, Fethi Filali typed: > > >>Suppose that we use PIM-SM as multicast routing protocol and the > >>multicast source uses a layered multicast congestion control protocol > >>(RLM, FLID-DL, ...) to send data to the receivers. Each layer uses a > >>different multicast group address. These addresses may be mapped to > >>different RP using the bootstrap mechanism of PIM-SM (which allow only 4 > >> group adresses to be mapped to the same RP). > >> > >>Suppose that we do not switch immediatly to the SPT (we van use a > >>*private* mechanism to decide the switching rather than the rate-based > >>one given as example in pim-sm draft). > >> > >>The problem is that a multicast receiver may receive layers from > >>different paths (because of using different RP per layer), the > >>congestion may occur in lower layers paths but not in higher layer > >>paths. Two problems hold: > >> > >>1. the receiver take more time to detect the congestion because it > >>leaves layer by layer and estimate again the loss rate. > >> > >>2. the receiver will leave higher layer, while it follows > >>un-congestioned paths !! > > >>My questions are: > > >>1. Do you agree with me ? > > hypothtically, sure Okay, sure in theory 'yes'. BUT, if this content is using layered-cc, then I would assume its all coming from the same network if not the same source. Though I've seen some pretty shocking configs/deploys, I can't imagine why a content owner would devide their groups space (I'm assuming a content owner would be using GLOP addressing) across multiple RPs then intentionaly cross RP boundaries with layered-cc content. But, I've seen worse things, received complaints about performance, then helped them do it right. Networks don't kill people; people kill people. In addition, true the redundant RP's will have different paths to the receiver, but in the real world, a content owner's network would devide RP services in some balanced fassion (most likely using Anycast-RP, NOT BSR, but..) meaning that the paths may be different but negligibly different. The source of ~most congestion is the last mile. And if the content owner had a congestion problem due to their network topo or content load balancing, they will fix the problem or loose business. > >>2. If so, are there any works on these pbs? > > i guess > > also note that a source that actually is multiple sources to different grouops could > fall foul of MSDP timers too - if the layer increase/decrease stuff was sufficiently > infrequemt./.. Hmm, I don't follow this. The source(s) are sending to all used groups all the time therefore the MSDP timers are never an issue. The periodicity is on the receiver end. Greg > >>PS: the same problem may be hold if we use a QoS-based multicast routing > >>protocols (no deployable one exist) !! > > spose so > >> > >>_______________________________________________ > >>Rmt mailing list > >>Rmt@ietf.org > >>https://www1.ietf.org/mailman/listinfo/rmt > > cheers > > jon > > > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www1.ietf.org/mailman/listinfo/rmt > _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 09:43:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13510 for ; Tue, 12 Feb 2002 09:43:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24521 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 09:43:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24209; Tue, 12 Feb 2002 09:35:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24180 for ; Tue, 12 Feb 2002 09:35:24 -0500 (EST) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13258 for ; Tue, 12 Feb 2002 09:35:19 -0500 (EST) Received: from maroon.jnpr.net (maroon.jnpr.net [172.24.244.36]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1CEY8632199; Tue, 12 Feb 2002 06:34:08 -0800 (PST) (envelope-from shep@juniper.net) Received: from localhost (shep@localhost) by maroon.jnpr.net (8.11.3/8.11.3) with ESMTP id g1CEY8j38125; Tue, 12 Feb 2002 06:34:08 -0800 (PST) (envelope-from shep@juniper.net) X-Authentication-Warning: maroon.jnpr.net: shep owned process doing -bs Date: Tue, 12 Feb 2002 06:34:08 -0800 (PST) From: Greg Shepherd X-X-Sender: To: Marshall Eubanks cc: Fethi Filali , , , Bill Fenner , Bill Nickless Subject: Re: [Rmt] pim-sm and layered multicast In-Reply-To: Message-ID: <20020212063120.C35884-100000@maroon.jnpr.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org > The intent as I read it is not that _only_ four group > members be assigned to each RP, but that _at least_ four > consecutive group addresses be assigned to each RP. In many > domains, one RP handles all groups. A content owner/provider has spoken-up. Thanks! > This was probably written before GLOP. Also, I know of no > specificiation or recommendation for the hash-mask M. > Given the relative success of GLOP, maybe a hash value of > 0.0.0.255 be used - so that an entire GLOP would be handled > by one RP by default. > > > > > Suppose that we do not switch immediatly to the SPT (we > > van use a > > *private* mechanism to decide the switching rather than > > the rate-based > > one given as example in pim-sm draft). > > > > I have a feeling that ASM may move to a "never switch to the > SPT" as SSM takes off and ASM is used mostly for > teleconference type applications, so this seems germaine. This is off the thread a bit, but I don't agree here. ASM will always have S,G trees from the reciever RPs to the sources. If it were to move to "never switch to SPT" the only place where this would have an affect is in the receiver networks - at the tail end of the trees. Greg > Regards > Marshall Eubanks > > > The problem is that a multicast receiver may receive > > layers from > > different paths (because of using different RP per > > layer), the > > congestion may occur in lower layers paths but not in > > higher layer > > paths. Two problems hold: > > > > 1. the receiver take more time to detect the congestion > > because it > > leaves layer by layer and estimate again the loss rate. > > > > 2. the receiver will leave higher layer, while it follows > > un-congestioned paths !! > > > > My questions are: > > > > 1. Do you agree with me ? > > 2. If so, are there any works on these pbs? > > > > > > Fethi. > > > > PS: the same problem may be hold if we use a QoS-based > > multicast routing > > protocols (no deployable one exist) !! > > > > > > _______________________________________________ > > Rmt mailing list > > Rmt@ietf.org > > https://www1.ietf.org/mailman/listinfo/rmt > > > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www1.ietf.org/mailman/listinfo/rmt > _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 10:05:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14172 for ; Tue, 12 Feb 2002 10:05:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25820 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 10:05:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24770; Tue, 12 Feb 2002 09:49:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24741 for ; Tue, 12 Feb 2002 09:49:42 -0500 (EST) Received: from wisbech.cl.cam.ac.uk (exim@mta1.cl.cam.ac.uk [128.232.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13690 for ; Tue, 12 Feb 2002 09:49:39 -0500 (EST) Received: from shep.cl.cam.ac.uk ([128.232.8.11] helo=cl.cam.ac.uk ident=jac22) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 16aeFW-00074Y-00; Tue, 12 Feb 2002 14:49:38 +0000 To: Greg Shepherd cc: Fethi Filali , rmt@ietf.org, pim@catarina.usc.edu, Jon.Crowcroft@cl.cam.ac.uk Subject: Re: [Rmt] pim-sm and layered multicast In-Reply-To: Message from Greg Shepherd of "Tue, 12 Feb 2002 06:04:09 PST." <20020212053301.N35884-100000@maroon.jnpr.net> Date: Tue, 12 Feb 2002 14:49:38 +0000 From: Jon Crowcroft Message-Id: Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org In message <20020212053301.N35884-100000@maroon.jnpr.net>, Greg Shepherd typed: >>> >>1. Do you agree with me ? >>> hypothtically, sure >>Okay, sure in theory 'yes'. BUT, if this content is using layered-cc, then >>I would assume its all coming from the same network if not the same you're right - though there are reasons for sourceing different layers from different sources (liegitimate - e.g. load blaancing, late join to different qos levels etc) >>source. Though I've seen some pretty shocking configs/deploys, I can't >>imagine why a content owner would devide their groups space (I'm assuming >>a content owner would be using GLOP addressing) across multiple RPs then >>intentionaly cross RP boundaries with layered-cc content. But, >>I've seen worse things, received complaints about performance, >>then helped them do it right. Networks don't kill people; people kill >>people. >> >>In addition, true the redundant RP's will have different paths to the >>receiver, but in the real world, a content owner's network would devide RP >>services in some balanced fassion (most likely using Anycast-RP, NOT BSR, >>but..) meaning that the paths may be different but negligibly different. >>The source of ~most congestion is the last mile. And if the content owner >>had a congestion problem due to their network topo or content load >>balancing, they will fix the problem or loose business. >> >>> >>2. If so, are there any works on these pbs? >>> >>> i guess >>> >>> also note that a source that actually is multiple sources to different grouops could >>> fall foul of MSDP timers too - if the layer increase/decrease stuff was sufficiently >>> infrequemt./.. >> >>Hmm, I don't follow this. The source(s) are sending to all used groups all >>the time therefore the MSDP timers are never an issue. The periodicity is on >>the receiver end. >> >>Greg >> >>> >>PS: the same problem may be hold if we use a QoS-based multicast routing >>> >>protocols (no deployable one exist) !! >>> >>> spose so >>> >> >>> >>_______________________________________________ >>> >>Rmt mailing list >>> >>Rmt@ietf.org >>> >>https://www1.ietf.org/mailman/listinfo/rmt >>> >>> cheers >>> >>> jon >>> >>> >>> _______________________________________________ >>> Rmt mailing list >>> Rmt@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rmt >>> >> cheers jon _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 12:19:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19116 for ; Tue, 12 Feb 2002 12:19:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA04277 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 12:19:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02715; Tue, 12 Feb 2002 12:00:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02484 for ; Tue, 12 Feb 2002 12:00:14 -0500 (EST) Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18491 for ; Tue, 12 Feb 2002 12:00:11 -0500 (EST) Received: from [165.247.109.162] (account ) by multicasttech.com (CommuniGate Pro WebUser 3.4.8) with HTTP id 1254302; Tue, 12 Feb 2002 11:59:54 -0500 From: "Marshall Eubanks" Subject: Re: [Rmt] pim-sm and layered multicast To: "Marshall Eubanks" , Fethi Filali , rmt@ietf.org Cc: pim@catarina.usc.edu, Bill Fenner , Bill Nickless X-Mailer: CommuniGate Pro Web Mailer v.3.4.8 Date: Tue, 12 Feb 2002 11:59:54 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org Content-Transfer-Encoding: 8bit On Tue, 12 Feb 2002 08:31:11 -0500 "Marshall Eubanks" wrote: > On Tue, 12 Feb 2002 11:20:54 +0100 > Fethi Filali wrote: > > Hi all, > > > > Suppose that we use PIM-SM as multicast routing > protocol > > and the > > multicast source uses a layered multicast congestion > > control protocol > > (RLM, FLID-DL, ...) to send data to the receivers. Each > > layer uses a > > different multicast group address. These addresses may > be > > mapped to > > different RP using the bootstrap mechanism of PIM-SM > > (which allow only 4 > > group adresses to be mapped to the same RP). > > You are referring to RFC 2362 Section 3.7. This is set by > the hash mask : > > 1 For RP addresses in the RP-Set, whose > Group-prefix > covers > G, select the RPs with the highest priority (i.e. > lowest > `Priority' value), and compute a value: > > Value(G,M,C(i))= > (1103515245 * ((1103515245 * (G&M)+12345) XOR C(i)) + > 12345) mod 2^31 > > where C_i is the RP address and M is a hash-mask > included in > Bootstrap messages. The hash-mask allows a small > number of > consecutive groups (e.g., 4) to always hash to > the > same RP. For > instance, hierarchically-encoded data can be sent > on > consecutive > group addresses to get the same delay and > fate-sharing > characteristics. > > The intent as I read it is not that _only_ four group > members be assigned to each RP, but that _at least_ four > consecutive group addresses be assigned to each RP. In > many > domains, one RP handles all groups. > > This was probably written before GLOP. Also, I know of no > specificiation or recommendation for the hash-mask M. > Given the relative success of GLOP, maybe a hash value of > 0.0.0.255 be used - so that an entire GLOP would be Just for the record : Of course, I flipped the bits here - the suitable mask would be 255.255.255.0 Thats what I get for placing e-mail before coffee. Marshall > handled > by one RP by default. > > > > > Suppose that we do not switch immediatly to the SPT (we > > van use a > > *private* mechanism to decide the switching rather than > > the rate-based > > one given as example in pim-sm draft). > > > > I have a feeling that ASM may move to a "never switch to > the > SPT" as SSM takes off and ASM is used mostly for > teleconference type applications, so this seems germaine. > > Regards > Marshall Eubanks > > > The problem is that a multicast receiver may receive > > layers from > > different paths (because of using different RP per > > layer), the > > congestion may occur in lower layers paths but not in > > higher layer > > paths. Two problems hold: > > > > 1. the receiver take more time to detect the congestion > > because it > > leaves layer by layer and estimate again the loss rate. > > > > 2. the receiver will leave higher layer, while it > follows > > un-congestioned paths !! > > > > My questions are: > > > > 1. Do you agree with me ? > > 2. If so, are there any works on these pbs? > > > > > > Fethi. > > > > PS: the same problem may be hold if we use a QoS-based > > multicast routing > > protocols (no deployable one exist) !! > > > > > > _______________________________________________ > > Rmt mailing list > > Rmt@ietf.org > > https://www1.ietf.org/mailman/listinfo/rmt > > > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www1.ietf.org/mailman/listinfo/rmt _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 14:29:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22978 for ; Tue, 12 Feb 2002 14:29:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA09916 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 14:29:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09265; Tue, 12 Feb 2002 14:11:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09239 for ; Tue, 12 Feb 2002 14:11:33 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22508 for ; Tue, 12 Feb 2002 14:11:31 -0500 (EST) Received: (from lorenzo@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id LAA10618; Tue, 12 Feb 2002 11:11:02 -0800 (PST) Date: Tue, 12 Feb 2002 11:11:02 -0800 From: Lorenzo Vicisano To: rmt@ietf.org Cc: Scott Bradner , Roger Kermode , Allison Mankin , Lorenzo Vicisano Message-ID: <20020212111102.B13589@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Subject: [Rmt] WG draft last-call Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org dear RMT-ers, please be advised that the following drafts are in WG last-call expiring in 15 days: draft-ietf-rmt-pi-alc-05.{txt,ps} draft-ietf-rmt-bb-lct-04.{txt,ps} draft-ietf-rmt-bb-fec-06.{txt,ps} draft-ietf-rmt-info-fec-02.{txt,ps} Please note that these drafts have not been announced yet, but are currently available in the draft directory (http://www.ietf.org/internet-drafts/). If you have comments, please post them to this list by February 26th, 2002. thank you, the WG chairs. _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 16:57:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28843 for ; Tue, 12 Feb 2002 16:57:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15857 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 16:57:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15296; Tue, 12 Feb 2002 16:36:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15262 for ; Tue, 12 Feb 2002 16:36:26 -0500 (EST) Received: from mx.webfountain.com (mx.webfountain.com [63.161.54.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28320 for ; Tue, 12 Feb 2002 16:36:22 -0500 (EST) Received: (qmail 2447 invoked from network); 12 Feb 2002 21:35:53 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 12 Feb 2002 21:35:53 -0000 Received: from okutan ([10.1.3.201]) by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id g1CLZaKa016242; Tue, 12 Feb 2002 13:35:36 -0800 From: "Michael Luby" To: "Rmt@ietf. org" Cc: "Michael Luby" , "Lorenzo Vicisano" , "Roger Kermode" Date: Tue, 12 Feb 2002 13:37:15 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003F_01C1B3CA.61FEAA90" 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 V5.50.4807.1700 Importance: Normal Subject: [Rmt] Deltas in new drafts Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C1B3CA.61FEAA90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RMT'ers, Attached are the list of changes between the previous versions and the new versions of the drafts (1) draft-ietf-rmt-bb-lct-04.txt (2) draft-ietf-rmt-bb-fec-06.txt (3) draft-ietf-rmt-info-fec-02.txt (4) draft-ietf-rmt-pi-alc-05.txt that were just submitted to the IETF and now posted. Mike ------=_NextPart_000_003F_01C1B3CA.61FEAA90 Content-Type: text/plain; name="LCT BB 04 changes.txt" Content-Disposition: attachment; filename="LCT BB 04 changes.txt" Content-Transfer-Encoding: quoted-printable LCT 03 -- 04 change =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (1) Capitlisation of "MUST", "MUST NOT", etc to differentiate between normal english is fixed. (2) Full references included for all RFCs mentioned (3) GRA no longer referenced since there is nothing permanent to = reference. (4) Changed C field from 1 bit to 2 bits to allow congestion control = information field to be 32 bits, 64 bits, 96 bits or 128 bits. (5) Changed version number from 0 to 1 since there are deployed versions = of LCT that this would be incompatible with. (6) Reorganized content in draft to be in Conformance with and checklist = from the Author Guidelines. (7) Sender operation: split the list of "could be included" information = in the session description into "must be" and "optional" information (8) Security considerations beefed up. Greater detail added about attacks to LCT out of band information Suggested prevention measures including use of an authenticated session initiation protocol, packet authentication, and content = integrity checks. ------=_NextPart_000_003F_01C1B3CA.61FEAA90 Content-Type: text/plain; name="FEC BB 06 changes.txt" Content-Disposition: attachment; filename="FEC BB 06 changes.txt" Content-Transfer-Encoding: quoted-printable FEC BB 05 -- 06 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (1) Fixed a couple of typos (2) Conformance with Author Guidelines (3) Added Security Considerations section (4) IANA Considerations, referenced RFC2434, changed FEC Encoding IDs to = Specification Required from First Come First Served, FEC Encoding Names = are FCFS. ------=_NextPart_000_003F_01C1B3CA.61FEAA90 Content-Type: text/plain; name="FEC INFO 02 changes.txt" Content-Disposition: attachment; filename="FEC INFO 02 changes.txt" Content-Transfer-Encoding: 7bit FEC INFO 01 -- 02 =============== (1) Minor typos fixed ------=_NextPart_000_003F_01C1B3CA.61FEAA90 Content-Type: text/plain; name="ALC PI 05 changes.txt" Content-Disposition: attachment; filename="ALC PI 05 changes.txt" Content-Transfer-Encoding: quoted-printable ALC PI 04 -- 05 change =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (1) Much more specific and fleshed out as a complete protocol (2) Reorganized substantially, now conforms to Author Guidelines = document (3) Added explicit session description requirements (4) Specified congestion control is WEBRC, much more specific than = before. This adds a dependence on the ALC document specifically to the = standardization of WEBRC. (5) This is now version 1 of the ALC protocol to match the LCT version = number. (6) The FEC Encoding ID now MUST be carried in the Codepoint field of = the LCT portion of the header. (7) The length of the Congestion Control Information field now = determines its format as will be specified in the WEBRC document. There = are two formats, one is 32 bits in length and the other 64 bits in = length, the longer just doubles the length of each field from the = shorter. (8) The combination of (6) and (7) and how the LCT header format works = implies that the ALC header format is now self-describing.=20 (9) Capitlisation of "MUST", "MUST NOT", etc to differentiate between normal english is fixed. (10) Full references included for all RFCs mentioned (11) GRA no longer referenced since there is nothing permanent to = reference. (12) Restrictions beyond what appear in LCT are made that are specific = to ALC, e.g., the Transport Session Identifier MUST be included in the = LCT portion of the ALC header. (13) Sender operation and receiver operation is now much more specific. (14) Specifically lists what the protocol tries to achieve and what it = does not try to achieve. (15) Security considerations beefed up. Greater detail added about attacks to ALC out of band information Suggested prevention measures including use of an authenticated session initiation protocol, packet authentication, and content = integrity checks. ------=_NextPart_000_003F_01C1B3CA.61FEAA90-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 12 17:35:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29727 for ; Tue, 12 Feb 2002 17:35:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18631 for rmt-archive@odin.ietf.org; Tue, 12 Feb 2002 17:35:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17078; Tue, 12 Feb 2002 17:10:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17049 for ; Tue, 12 Feb 2002 17:10:41 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29139 for ; Tue, 12 Feb 2002 17:10:37 -0500 (EST) Received: (from lorenzo@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA29841; Tue, 12 Feb 2002 14:10:09 -0800 (PST) Date: Tue, 12 Feb 2002 14:10:08 -0800 From: Lorenzo Vicisano To: rmt@ietf.org Cc: Scott Bradner , Roger Kermode , Allison Mankin Subject: Re: [Rmt] WG draft last-call Message-ID: <20020212141008.N13589@cisco.com> References: <20020212111102.B13589@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020212111102.B13589@cisco.com> User-Agent: Mutt/1.3.23i Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org It turned out that there are still a few small issues to be sorted out in draft-ietf-rmt-pi-alc-05.{txt,ps}, hence this *is not* in WG-last call. The other three *are*. sorry for the confusion. Thanks, Lorenzo On Tue, Feb 12, 2002 at 11:11:02AM -0800, Lorenzo Vicisano wrote: > dear RMT-ers, > > please be advised that the following drafts are in WG last-call > expiring in 15 days: > > draft-ietf-rmt-pi-alc-05.{txt,ps} > draft-ietf-rmt-bb-lct-04.{txt,ps} > draft-ietf-rmt-bb-fec-06.{txt,ps} > draft-ietf-rmt-info-fec-02.{txt,ps} > > Please note that these drafts have not been announced yet, but are > currently available in the draft directory > (http://www.ietf.org/internet-drafts/). > > If you have comments, please post them to this list by February 26th, > 2002. > > thank you, > the WG chairs. > > > _______________________________________________ > Rmt mailing list > Rmt@ietf.org > https://www1.ietf.org/mailman/listinfo/rmt _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Wed Feb 13 04:26:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24488 for ; Wed, 13 Feb 2002 04:26:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA22891 for rmt-archive@odin.ietf.org; Wed, 13 Feb 2002 04:26:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22095; Wed, 13 Feb 2002 04:01:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22047 for ; Wed, 13 Feb 2002 04:00:55 -0500 (EST) Received: from chamomile.mlab.t.u-tokyo.ac.jp (chamomile.mlab.t.u-tokyo.ac.jp [133.11.87.225]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24004 for ; Wed, 13 Feb 2002 04:00:51 -0500 (EST) Received: (qmail 26348 invoked from network); 13 Feb 2002 09:00:46 -0000 Received: from sunflower.mlab.t.u-tokyo.ac.jp (192.168.1.1) by chamomile.mlab.t.u-tokyo.ac.jp with SMTP; 13 Feb 2002 09:00:46 -0000 Received: (qmail 23308 invoked by alias); 13 Feb 2002 09:00:45 -0000 Received: (qmail 23298 invoked from network); 13 Feb 2002 09:00:45 -0000 Received: from qosgw.mlab.t.u-tokyo.ac.jp (HELO qos-gw.qos.mlab.t.u-tokyo.ac.jp) (192.168.1.131) by sunflower.mlab.t.u-tokyo.ac.jp with SMTP; 13 Feb 2002 09:00:45 -0000 Date: Wed, 13 Feb 2002 18:00:45 +0900 From: "T.H.Nguyen" To: rmt@ietf.org, pim@catarina.usc.edu Subject: Re: [eagle 00635] Fw: [Rmt] pim-sm and layered multicast Message-Id: <20020213180045.5d5b7db3.haguen@mlab.t.u-tokyo.ac.jp> In-Reply-To: <3C68F6A42C4.4722NAKAUCHI@mailhost.mlab.t.u-tokyo.ac.jp> References: <3C68F6A42C4.4722NAKAUCHI@mailhost.mlab.t.u-tokyo.ac.jp> Organization: The University of Tokyo X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org Content-Transfer-Encoding: 7bit > From: Jon Crowcroft > To: Fethi Filali > Cc: rmt@ietf.org, pim@catarina.usc.edu > Date: Tue, 12 Feb 2002 10:34:20 +0000 > Subject: Re: [Rmt] pim-sm and layered multicast > -- > > > In message <3C68EC86.4080703@sophia.inria.fr>, Fethi Filali typed: > > >>Suppose that we use PIM-SM as multicast routing protocol and the > >>multicast source uses a layered multicast congestion control protocol > >>(RLM, FLID-DL, ...) to send data to the receivers. Each layer uses a > >>different multicast group address. These addresses may be mapped to > >>different RP using the bootstrap mechanism of PIM-SM (which allow only 4 > >> group adresses to be mapped to the same RP). > >> > >>Suppose that we do not switch immediatly to the SPT (we van use a > >>*private* mechanism to decide the switching rather than the rate-based > >>one given as example in pim-sm draft). > >> > >>The problem is that a multicast receiver may receive layers from > >>different paths (because of using different RP per layer), the > >>congestion may occur in lower layers paths but not in higher layer > >>paths. Two problems hold: > >> > >>1. the receiver take more time to detect the congestion because it > >>leaves layer by layer and estimate again the loss rate. > >> > >>2. the receiver will leave higher layer, while it follows > >>un-congestioned paths !! > > >>My questions are: > > >>1. Do you agree with me ? > > hypothtically, sure > > >>2. If so, are there any works on these pbs? > > i guess These problems were described in the following paper: "Rendezvous Points based Layered Multicast", IEICE Trans. Commun., Vol. E84-B, No. 12, Dec. 2001. Abstract and PDF file are available at this URL: http://search.ieice.org/2001/files/e000b12.htm#e84-b,12,3133 > also note that a source that actually is multiple sources to different grouops could > fall foul of MSDP timers too - if the layer increase/decrease stuff was sufficiently > infrequemt./.. > >>PS: the same problem may be hold if we use a QoS-based multicast routing > >>protocols (no deployable one exist) !! > > spose so -- Tran Ha Nguyen Aoyama Morikawa Laboratory Department of Information and Communication Engineering School of Engineering, The University of Tokyo Tel: +81-3-5841-6710, FAX: +81-3-5841-6776 Email: haguen@mlab.t.u-tokyo.ac.jp _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Wed Feb 13 18:24:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24073 for ; Wed, 13 Feb 2002 18:24:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08933 for rmt-archive@odin.ietf.org; Wed, 13 Feb 2002 18:24:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07491; Wed, 13 Feb 2002 17:57:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07446 for ; Wed, 13 Feb 2002 17:57:55 -0500 (EST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23564 for ; Wed, 13 Feb 2002 17:57:51 -0500 (EST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id g1DMvrE13335 for ; Wed, 13 Feb 2002 14:57:53 -0800 (PST) Received: from hananet.net ([211.202.87.13]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id g1DMvqJ13313 for ; Wed, 13 Feb 2002 14:57:52 -0800 (PST) Message-Id: <200202132257.g1DMvqJ13313@SpamWall.lbl.gov> Reply-To: ktt21c@hananet.net From: 다이얼톡 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 14 Feb 2002 07:43:29 +0900 X-User: 2.62-gjhkemjt-mmqlmn-Eejhj Subject: [Rmt] [홍보] 엠피쓰리 플레이어를 무료로 드립니다 Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org

     




 



귀하의 승락없이 전자 우편을 보내게 된 점 정중히 사과 드립니다. 저희회사는 정보통신부의 요구사항인 수신 거부 장치를 필히 마련하고 있습니다. 귀하의 전자 우편 주소는 인터넷상의 공개된 장소에서 확인하였으며, 귀하의 전자우편 주소외 어떠한 개인 정보도 확인되지 않으므로 안심하시기 바랍니다. 동일한 내용의 메일수신을 거부하신다면 귀하의 의사를 존중하여 삭제처리하겠습니다. 감사합니다.
_______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Thu Feb 14 04:40:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14205 for ; Thu, 14 Feb 2002 04:40:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18849 for rmt-archive@odin.ietf.org; Thu, 14 Feb 2002 04:40:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18580; Thu, 14 Feb 2002 04:36:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18540 for ; Thu, 14 Feb 2002 04:36:36 -0500 (EST) Received: from wisbech.cl.cam.ac.uk (mta1.cl.cam.ac.uk [128.232.0.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14115 for ; Thu, 14 Feb 2002 04:36:21 -0500 (EST) Received: from shep.cl.cam.ac.uk ([128.232.8.11] helo=cl.cam.ac.uk ident=jac22) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 16bIIo-0003WR-00; Thu, 14 Feb 2002 09:35:42 +0000 To: "T.H.Nguyen" cc: rmt@ietf.org, pim@catarina.usc.edu Subject: Re: [eagle 00635] Fw: [Rmt] pim-sm and layered multicast In-Reply-To: Message from "T.H.Nguyen" of "Wed, 13 Feb 2002 18:00:45 +0900." <20020213180045.5d5b7db3.haguen@mlab.t.u-tokyo.ac.jp> Date: Thu, 14 Feb 2002 09:35:38 +0000 From: Jon Crowcroft Message-Id: Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org In message <20020213180045.5d5b7db3.haguen@mlab.t.u-tokyo.ac.jp>, "T.H.Nguyen" typed: >>These problems were described in the following paper: >>"Rendezvous Points based Layered Multicast", IEICE Trans. >>Commun., Vol. E84-B, No. 12, Dec. 2001. >>Abstract and PDF file are available at this URL: >>http://search.ieice.org/2001/files/e000b12.htm#e84-b,12,3133 cool - neat paper note that one reason for hashing to different RPs is to load balance so there are two problems with layered coded schemes and this 1/ if yo uhave 2 flowss with potentuialyl 2 layers, and 2 RPs, then instead of getting 1 layer for each flow on each RP, you could end up with the each layer of 1 flow on each RP, and none of the second flow - this is clearly unfair, 2/is loss at an RP really correlated with bottlenecks ? in the UK national and MAN nets, RPs are in overprovisoned palces, and loss is typically in the leaf/site networks (we think, and others seem to agree)...if we could say use ECN, then the RP could monitor ECN rate per group...which might then be a really cute way of extendign your idea cheers jon _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Fri Feb 15 02:18:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28816 for ; Fri, 15 Feb 2002 02:18:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01649 for rmt-archive@odin.ietf.org; Fri, 15 Feb 2002 02:18:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00743; Fri, 15 Feb 2002 02:00:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00697 for ; Fri, 15 Feb 2002 02:00:04 -0500 (EST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20873 for ; Fri, 15 Feb 2002 02:00:02 -0500 (EST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id g1F702E17704 for ; Thu, 14 Feb 2002 23:00:02 -0800 (PST) Received: from Localhost ([211.228.142.168]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id g1F6xnJ17640 for ; Thu, 14 Feb 2002 22:59:53 -0800 (PST) Message-Id: <200202150659.g1F6xnJ17640@SpamWall.lbl.gov> From: "mgpwkr" To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 15 Feb 2002 15:58:16 +0900 Subject: [Rmt] [광고] 종량제 봉투 절약형 압축쓰레기통 소개 Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org



 

▷ 원치않은 정보였다면 정중히 사과 드리며, 수신 거부를 해주시면 다음부터는 메일이 발송되지 않을 것입니다.
▷ 메일클라이언트의 필터 기능을 이용하여 [광고] 문구를 필터링하면 모든 광고 메일을 자동으로 차단하실 수 있습니다.
수신거부(Unsubscribe)
_______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Fri Feb 15 08:55:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05270 for ; Fri, 15 Feb 2002 08:55:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20588 for rmt-archive@odin.ietf.org; Fri, 15 Feb 2002 08:55:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20040; Fri, 15 Feb 2002 08:38:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20015 for ; Fri, 15 Feb 2002 08:38:08 -0500 (EST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04930 for ; Fri, 15 Feb 2002 08:38:03 -0500 (EST) From: iteducation@frontier.co.kr Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id g1FDboE11340 for ; Fri, 15 Feb 2002 05:37:50 -0800 (PST) Received: from dsjang.frontier.co.kr ([211.255.227.72]) by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id g1FDbjJ11318 for ; Fri, 15 Feb 2002 05:37:45 -0800 (PST) Received: from localhost.localdomain (IDENT:root@dsjang.frontier.co.kr [127.0.0.1]) by dsjang.frontier.co.kr (8.11.5/8.11.5) with ESMTP id g1FDUGY29909; Fri, 15 Feb 2002 22:30:16 +0900 Date: Fri, 15 Feb 2002 22:30:16 +0900 Message-ID: <2782784.1013779816251.JavaMail.root@localhost.localdomain> To: artema@neolife.net, rmt@lbl.gov, doori815@hanmail.net, hio@chicken.or.kr, yhchoi78@lycos.co.kr, 62392009@263.net, chobna@hanmir.com, office@bamaar.tom.pl, kiko@munkyung.ac.kr, joyuk@hanmail.net Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id IAA20016 Subject: [Rmt] =?euc-kr?B?KluxpCCw7V0qILOqtMIgwd+xub+hvK0gucy3obimIMHYuvHH0bTZLiA=?= Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org Content-Transfer-Encoding: 8bit [ 제2기 중국 현지 중국어 & IT 동시 교육과정 연수생 선발 ] 중국 요녕성 정부 후원으로 프론티어시스템(주)는 중국 심양대학교와 함께 중국IT전문가 과정을 모집합니다. 사진자료,관련기사 및 자세한 자료는 http://www.frontier.co.kr 을 참고하십시오. 모집인원 80명 (20명이 1개반으로써 4개반 선착순 모집) 연수기간 6개월 (2002년 2월 28일부터 2002년 8월 29일까지) 연수과목 중국어, 중국어 회화, 중국학, 컴퓨터 기초, Java 프로그래밍 연수내용 　 2002. 2. 28~2002. 8. 29 - 중국어 기초~중급과정 - 실용 표준중국어, 회화, 문법, 작문 - HSK시험(中國漢語水平考試) 1일 4시간 (오전) 2002. 2. 28~2002. 5. 30 - 중국학 강의(역사, 지리, 경제, 문화, 법률, 교육등) - 심양대학교 추천 대학생과 Free Talking 1일 2시간 (오후) 2002. 5. 31~2002. 8. 30 - 컴퓨터 기초교육 (중국 컴퓨터 환경숙지) - JAVA Programming (SCJP과정) 1일 2시간 (오후) 　 2002. 7 - 중국문화 유적지 탐방 (4박5일) 배낭여행(교통, 숙식제공) 연수금액 420만원 (식비, 기숙사비, 비행기표 , 비자, 신체검사, 공항이용료, HSK응시료, 중국문화 탐방여행 경비 일체 포함. 본인이 비자, 신체검사서를 준비할 경우에는 15만원을 제하여 드립니다.) 제출서류 여권(비자발급시 필요), 주민등록등본 3통, 여권사진 5장 연수신청 및 연수비 납부 2002년 1월 3일부터 2002년 2월 20일까지 <계좌번호 : 한빛은행 169-148429-13-101 예금주: 프론티어시스템㈜> 기타 - 방과후 심양대학교 학생과 2인1조 대화를 통한 실질적 교육기회 제공(심양대학 측에서 추천한 발음이 정확하고 표준어를 구사하는 심양대 학생과 함께 살아있는 현지 중국어 및 중국 문화를 습득할 수 있는 좋은 기회입니다.) - 전원 기숙사에서 숙식 (2001년11월에 준공한 최신식 아파트형으로 2인1실) - 6개월 연수 후 심양대학교에서 수료증 발급 - 중국문화 유적지 탐방 4박5일 여행 제공 - HSK 시험(中國漢語水平考試) 중국현지에서 응시 - Java 프로그램 연수 후 Sun Certified Java Programmer 자격시험응시가능 - 연말연시 연휴 관계로 비자 발급 등에 만전을 기하기 위해 희망자는 미리 신청하여 주시기 바랍니다. - 비자 발급, 신체검사 절차 대행함. - 교육 수료후 대기업,중소기업 및 벤처기업 중국 담당자로 취업 추천 주요교육대상 - 중국유학을 준비하는 수험생 (중국어 초보자 가능) - 중국어 어학연수 희망 대학생 - 중국관련 사업계획중인 기업체 임직원 일정계획 2002년 2월 20일 접수마감 (연수금, 주민등록등본 3통, 반명함판 사진5매, 도장) 2002년 2월 25일 비자발급, 신체검사 완료 2002년 2월 26일 출국 예비소집 (당사 회의실에서 여권/비자 드림) 2002년 2월 28일 12:30 인천국제공항에서 중국 심양으로 출국 (중국북방항공) 14:30 심양대학교 기숙사 입소 및 오리엔테이션 2002년 7월 중국문화 유적지 탐방 (4박5일) 2002년 8월 HSK 시험(中國漢語水平考試) 응시 2002년 8월28일 종강 및 수료식 2002년 8월29일 중국 심양에서 인천국제공항으로 귀국 문의처 - 프론티어시스템(주) 서울시 서초구 서초동 1554-1 (경중빌딩3층) (전화 : 02-3473-3910, 팩스 : 02-3473-3990, 홈페이지: www.frontier.co.kr) - 중국심양대학교 : 심양시 대동구 연합로 54호 심양대학교 외사처 (전화 : 024-8850-6607, 팩스 : 024-8852-3363) - 주최:프론티어시스템(주) 주관: 중국 심양대학교 - 후원: 중국 정부기관(요령성) (주)캠퍼스넷 www.campus.co.kr _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Sun Feb 17 14:37:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10433 for ; Sun, 17 Feb 2002 14:37:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24615 for rmt-archive@odin.ietf.org; Sun, 17 Feb 2002 14:37:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23574; Sun, 17 Feb 2002 14:21:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23544 for ; Sun, 17 Feb 2002 14:21:29 -0500 (EST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10226 for ; Sun, 17 Feb 2002 14:21:25 -0500 (EST) From: RCPMailing@hotmail.com Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id g1HJLRE01243 for ; Sun, 17 Feb 2002 11:21:27 -0800 (PST) Received: from yourwebsite.com (adsl-66-136-202-106.dsl.austtx.swbell.net [66.136.202.106]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id g1HJLPJ01238 for ; Sun, 17 Feb 2002 11:21:25 -0800 (PST) Message-Id: <200202171921.g1HJLPJ01238@SpamWall.lbl.gov> Reply-To: RCPMailing@hotmail.com To: rmt@lbl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 17 Feb 2002 13:21:44 -0600 Subject: [Rmt] Receive $2 for every envelope you stuff for our company! Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org Receive $2 for every envelope you stuff for our company! No experience required! Visit http://www.rcplanet.tv for more information! Regards, RCPM Staff This is a one time e-mail and you will not recieve any more e-mails from us. _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Sun Feb 17 19:06:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13307 for ; Sun, 17 Feb 2002 19:06:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA06667 for rmt-archive@odin.ietf.org; Sun, 17 Feb 2002 19:06:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05695; Sun, 17 Feb 2002 18:52:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05664 for ; Sun, 17 Feb 2002 18:52:00 -0500 (EST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13121 for ; Sun, 17 Feb 2002 18:51:55 -0500 (EST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id g1HNpwE21306 for ; Sun, 17 Feb 2002 15:51:58 -0800 (PST) Received: from localhost (s211-33-25-156.thrunet.ne.kr [211.33.25.156]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id g1HNpsJ21300 for ; Sun, 17 Feb 2002 15:51:56 -0800 (PST) Message-Id: <200202172351.g1HNpsJ21300@SpamWall.lbl.gov> Reply-To: qkqkfkkr@yahoo.co.kr From: 김선애 To: rmt@lbl.gov Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 18 Feb 2017 08:50:03 +0900 Subject: [Rmt] [광고]★★★3/1일 정식 open 지금확인해 보세요~~★★★ Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org
 
                                              귀하의 메일주소는 웹 서핑중 알게된 것이며, E-Mail 주소 외에 다른 정보는 갖고 있지
                                           않습니다. 정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다.
                                                 또한 원치 않는 분들을 위해 아래에 수신거부 장치를 필히 마련하고 있습니다.
 
 
 
PHASE 4 DOWNLINE CLUB】

2002년 3월에 정식 오픈하는 곳입니다.
3월 오픈 전까지 무료회원을 모집하고 있습니다.
오픈 전까지 TOP 100에 들기만 하면 대박입니다. 빨리 가입하고 추천인만 모으세요.
2x10 강제매트릭스 입니다.

■■◆◆당장 가입해야 하는 이유◆◆■■

1.가입은 FREE(무료) 이다. 고로 다운을 모집하기 쉽다.
2.FREE 가입후 저에게 메일주시면 이메일추출기 및 발송기, (35만원 상당)
3.스폰서를 제일 많이한 TOP 100명 에게는 매트릭스에서 1~100 지위를 부여한다.(대박)
4.현재 TOP 100의 추천인원은 21명으로 당신도 이 대열에 참여할 수 있다.
(21명만 모집하더라도 가입순번에 관계없이 바로 TOP 100 안으로 진출, 3월까지 약 25,000명 회원 모집 예정)
5.50명의 인원만 매트릭스에 채워진다 하더라도 $79,000 을 받을 수 있다.(스필오버 포함)

일단, FREE로 가입하시면 이메일추출기와 발송기를 드립니다.
가입후 전혀 활동을 하지 않으셔도 상관없습니다.가입하시는 모든분들을 제가 홍보해 드릴께요.
일단 제가 TOP 100에 진입하는데 도움이 될것이기 때문입니다. 충분히 가치가 있습니다.
참고로 저는 절실히 성공하고픈 사람입니다. 활동을 하지 않으시더라도 일단 FREE로 가입하여 저를 도와주기를 바랍니다.

■■◆◆보상플랜◆◆■■

PHASE ONE: 2x10 FORCED MATRIX = $92,070
PHASE TWO: 2x10 FORCED MATRIX = $276,210
PHASE THREE: 2x10 FORCED MATRIX = $941,160
PHASE FOUR: 2x10 FORCED MATRIX = $1,923,240

2*10 매트릭스
다운라인클럽의 가입하는 순서에 의하여 아래의 매트릭스를 짜나간다고 생각하시면 이해가 빨리 갈것으로 생각됩니다.

나
1단계 2명
2단계 4명
3단계 8명
4단계 16명
5단계 32명
6단계 64명
7단계 128명
8단계 256명
9단계 512명
10단계 1,024명
============
토탈 2,046명

PHASE ONE으로부터 시작하며 PHASE FOUR까지 당신의 스폰서를 따라다닙니다.
다시 말해서 한번의 매트릭스 구성으로 큰 보상이 보장됩니다.
당신의 다운라인은 4개의 매트릭스에서 당신을 따라 다닙니다!
만약 4개의 매트릭스에서 단지 50명의 인원만 채워지더라도 $79,000 을 받게 될것입니다.
이것은 강제 매트릭스입니다.
단지 2명만 스폰서하여도 다운라인클럽의 멤버라는 이유로 수많은 스필오버를 받게될 것입니다.
한줄 라인 다운라인으로(A Straight Downline) 당신뒤에 가입한 사람은 모두 매트릭스상에서 당신 뒤에 배치되게 됩니다.
저는 41255번째 가입하였으며 가입순번 ,즉 41255가 ID가 됩니다.
매트릭스는 가입순번 1에서부터 2*10 구조로 만들어집니다.
Launch하게 되는 3월 첫달에 $79,000 을 저와 함께 받지 않으시렵니까?
많은 멤버들이 론치하는 첫달에 이를 받을것입니다.
오늘 Phase 4 Downline Club에 가입하세요!!! FREE!!!


<a href="http://phase4dlc.com/vdownline.html?41255">☞[가입하러가기]</a>
    
가입하실 분은  상위를 누르고 들어가면 맨 하단에 가입란이 있습니다.

Email Address: 메일주소
First Name: 이름  Last Name: 성
City: 도시명   State/prov : 비워두세요..
Country: south korea 선택

모두 기입후 아래의 Done를 누르시면 가입완료입니다.
가입후 가입한 메일로 숫자가 포함된 주소와 아이디, 임시패스워드가 옵니다. 거기로 들어가 임시패스워드를 치고 들어가 화면 중간 아이콘중에 Update personal details & password 를 누르시고 들어가 패스워드및 자기의 정보를 수정하시면 됩니다.
추천인 모집할때는 (http://phase4dlc.com/vdownline.html?자신의 아이디)로 홍보하시면 됩니다.

가입하고 메일 보내시면 이메일 추출기 . 발송기를 보내 드릴께요~~
 
 
                                                                                                  
                                                    수신을 원치 않으시면 수신거부를 눌러주세요
_______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Mon Feb 18 11:18:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06877 for ; Mon, 18 Feb 2002 11:18:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27692 for rmt-archive@odin.ietf.org; Mon, 18 Feb 2002 11:18:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27254; Mon, 18 Feb 2002 11:11:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27224 for ; Mon, 18 Feb 2002 11:11:38 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06484; Mon, 18 Feb 2002 11:11:33 -0500 (EST) Message-Id: <200202181611.LAA06484@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rmt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 18 Feb 2002 11:11:33 -0500 Subject: [Rmt] I-D ACTION:draft-ietf-rmt-pi-alc-06.txt,.ps Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Asynchronous Layered Coding protocol instantiation Author(s) : M. Luby et al. Filename : draft-ietf-rmt-pi-alc-06.txt,.ps Pages : 34 Date : 15-Feb-02 This document describes the Asynchronous Layered Coding protocol, a massively scalable reliable content delivery protocol, hereafter referred to as ALC. ALC combines the LCT [13] building block, a multiple rate congestion control building block that is in compliance with RFC2357 [14] and the FEC [12] building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-pi-alc-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-pi-alc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020215100838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rmt-pi-alc-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rmt-pi-alc-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020215100838.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Mon Feb 18 16:16:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18846 for ; Mon, 18 Feb 2002 16:16:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12805 for rmt-archive@odin.ietf.org; Mon, 18 Feb 2002 16:16:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11226; Mon, 18 Feb 2002 15:40:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11192 for ; Mon, 18 Feb 2002 15:40:49 -0500 (EST) Received: from mx.webfountain.com (mx.webfountain.com [63.161.54.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17438 for ; Mon, 18 Feb 2002 15:40:45 -0500 (EST) Received: (qmail 8435 invoked from network); 18 Feb 2002 20:40:18 -0000 Received: from mail.intranet (10.1.1.37) by mx.webfountain.com with SMTP; 18 Feb 2002 20:40:18 -0000 Received: from magnemite (pptp-10-1-129-60.intranet [10.1.129.60]) by mail.intranet (8.12.1/8.12.1/Debian -5) with SMTP id g1IKe9Ka010590; Mon, 18 Feb 2002 12:40:09 -0800 From: "Michael Luby" To: Cc: "Michael Luby" , "Lorenzo Vicisano" , "Roger Kermode" Subject: RE: [Rmt] I-D ACTION:draft-ietf-rmt-pi-alc-06.txt,.ps Date: Mon, 18 Feb 2002 12:49:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000A_01C1B87A.A717A4B0" 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 V5.50.4807.1700 Importance: Normal In-Reply-To: <200202181611.LAA06484@ietf.org> Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C1B87A.A717A4B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit For those interested in the deltas between the 05 draft and the 06 draft, they are summarized in the attached document. Mike -----Original Message----- From: rmt-admin@ietf.org [mailto:rmt-admin@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Monday, February 18, 2002 8:12 AM To: IETF-Announce: Cc: rmt@ietf.org Subject: [Rmt] I-D ACTION:draft-ietf-rmt-pi-alc-06.txt,.ps A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reliable Multicast Transport Working Group of the IETF. Title : Asynchronous Layered Coding protocol instantiation Author(s) : M. Luby et al. Filename : draft-ietf-rmt-pi-alc-06.txt,.ps Pages : 34 Date : 15-Feb-02 This document describes the Asynchronous Layered Coding protocol, a massively scalable reliable content delivery protocol, hereafter referred to as ALC. ALC combines the LCT [13] building block, a multiple rate congestion control building block that is in compliance with RFC2357 [14] and the FEC [12] building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rmt-pi-alc-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rmt-pi-alc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_000A_01C1B87A.A717A4B0 Content-Type: text/plain; name="ALC PI 06 changes.txt" Content-Disposition: attachment; filename="ALC PI 06 changes.txt" Content-Transfer-Encoding: quoted-printable ALC PI 05 -- 06 change =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Note: Although many of the changes between the 04 -- 05 versions=20 of the ALC draft were significant improvements, there were a couple=20 of changes made that went beyond what was reasonable in terms of=20 maintaining flexibility, and in particular they went beyond=20 the intent of the working group. In particular, it is important that ALC remain flexible enough that=20 different congestion control building blocks could be used with ALC, and this flexibility was removed in the 05 version of the draft. =20 Furthermore, the use of the Codepoint value was restricted beyond its = intended use in the 05 version of the ALC draft. Both of these shortcomings have been amended in the 06 version of the = ALC draft. The overall changes between the 04 version of the draft and the 06 = version of the draft have had the overall effect of making it possible to build a = complete protocol based on the document, while maintaining the intention of the = working group in terms of allowing flexibility for what congestion control protocols = can be used with ALC, as well as maintaining the flexibility of communicating = in-band through the use of the Codepoint the settings of portions of the session = description that may change within a session. (1) Changed congestion control requirement from specifically WEBRC to = more generally any multiple rate congestion control building block (MRCC)=20 that conforms to RFC2357. The requirements on congestion control are as = follows: (a) The MRCC to be used MUST be communicated out-of-band to the = receiver through the session description. This MAY be implicit, i.e., an = application MAY always use the same MRCC and the receiver would know this based on = the application. (b) The Congestion Control Information is the in-band packet = information carried in the LCT header that is used for congestion control. The MRCC MUSt specify a format for the Congestion Control Information = (CCI) that MUST be either 32, 64, 96 or 128 bits in length. The MRCC MAY specify formats for more than one length, but there MUST be at most one format per length. The C value that specifies the length of the CCI field carried in the LCT header together with the particular MRCC associated with the session uniquely determines which format is used for the CCI = field. =20 (2) There are portions of the session description that may vary within a = session. Changed the Codepoint field use from specifically carrying the FEC = Encoding ID to more generally communicating to receivers which of the settings are = in use at each point in time. If used, the mapping between the settings is = communicated in the session description, and the mapping is outside the scope of ALC. For example, the FEC Encoding ID and the packet authentication scheme = may vary within a session. Thus, the session description could associate Codepoint values with different combinations of settings of the FEC = Encoding ID and packet authentication scheme to use, and the Codepoint value carried = in=20 the LCT header would determine which of these settings is in force at = each point in time. ------=_NextPart_000_000A_01C1B87A.A717A4B0-- _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Wed Feb 20 13:59:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16046 for ; Wed, 20 Feb 2002 13:59:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14085 for rmt-archive@odin.ietf.org; Wed, 20 Feb 2002 13:59:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13290; Wed, 20 Feb 2002 13:42:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13257 for ; Wed, 20 Feb 2002 13:42:20 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15440 for ; Wed, 20 Feb 2002 13:42:18 -0500 (EST) Received: (from lorenzo@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id KAA13648; Wed, 20 Feb 2002 10:41:49 -0800 (PST) Date: Wed, 20 Feb 2002 10:41:49 -0800 From: Lorenzo Vicisano To: rmt@ietf.org Cc: Allison Mankin , Scott Bradner , Roger Kermode Message-ID: <20020220104149.D29783@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Subject: [Rmt] WG last-call for draft-ietf-rmt-pi-alc-06.{txt,ps} Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org dear RMT-ers, please be advised that the draft draft-ietf-rmt-pi-alc-06.{txt,ps} is in WG last-call expiring in 15 days. If you have comments, please post them to this list by March 7, 2002. As a reminder, the following drafts are also in WG last-call expiring February 26th, 2002: draft-ietf-rmt-bb-lct-04.{txt,ps} draft-ietf-rmt-bb-fec-06.{txt,ps} draft-ietf-rmt-info-fec-02.{txt,ps} thank you, the WG chairs. _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Sat Feb 23 16:04:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24200 for ; Sat, 23 Feb 2002 16:04:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29417 for rmt-archive@odin.ietf.org; Sat, 23 Feb 2002 16:04:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28445; Sat, 23 Feb 2002 15:45:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28416 for ; Sat, 23 Feb 2002 15:45:12 -0500 (EST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24055 for ; Sat, 23 Feb 2002 15:45:07 -0500 (EST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id g1NKj8E10384 for ; Sat, 23 Feb 2002 12:45:09 -0800 (PST) Received: from dreamwiz.com ([211.187.28.222]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id g1NKhPJ10257 for ; Sat, 23 Feb 2002 12:43:37 -0800 (PST) Message-Id: <200202232043.g1NKhPJ10257@SpamWall.lbl.gov> Reply-To: sexycodi@dreamwiz.com From: 예쁜코디 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 24 Feb 2002 05:43:48 +0900 Subject: [Rmt] [코디정보] "7cm 커진 키"와 "Shark 쟈크 히틀러가방", 정말 멋져요! 새학기엔 새로운 모습으로.. [광고] Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org SEXYcodi magazine
 SEXYcodi magazine Feb. 24, 2002 

Nicol Necol
   > 거리스케치 스쿨룩 커플룩 해외스케치 나어때?
This week codi
   > 이번주코디제안 ... 멋진 코디, 이렇게.. 어떠세요? - 앙드레 지니
      > ♣♧♣체형별 코디♧♣♧
      > ◀◀◀문양과 무늬별 코디▶▶▶
   > 섹시코디 이번주 코디 제안 > [뽀대남] [뽀대녀] =>
Magazine
   > 인터뷰 > 흑인음악창작동호회(SNP)-Defconn - 재원,진웅,영민
   > 싸이코 칼럼 > 우리의 사랑, 섹스 후에는 어떻게 달라질까? - 이규환 박사
SEXYcodi Magazine     
무료회원 등록하기     
1-Click만으로 OK!     
Seco Shop
  걍 이뿐 것들이구여~
키가 커지니까 자신감도 커지죠!
1.7~10cm 정도 다리가 길어 보여 쭉쭉빵빵!
2.인체공학적 키높이 까래의 설계로 발바닥의 형태에 알맞은 착용감.
3.하체의 다이어트 및 허리근육을 강화하는 효과.
4.싸이즈 230~270 까지
5.갑피재료:천연가죽, 겉창재료:알파창
화끈한 Shark 쟈크의 히틀러 가방 !
신학기 최고 뽀대 배낭가방입니다.
요모조모 옆에 내부에 다양한 주머니들..
실물 보시고 뿅~!가지 않는 분은 어떤 분일까?
한정수량이므로 서두르세요.












- "정보통신망이용촉진등에관한법률시행규칙개정령"에 의거 제목에 [광고]라 표시된 광고 메일입니다.
- 메일수신거부를 하실 경우 더 이상 메일이 가지 않습니다.
- 귀하의 email ID는 게시판 등 기타 공개된 자료에서 수집된 것으로 이상의 다른 개인정보는 없습니다.
- email 서비스를 원하지 않으시면 [수신거부]를 클릭하세요.
- 섹시코디 매거진 서비스를 계속 받고 싶으시면 [섹시코디 매거진 회원등록]을 한번 클릭하세요.
_______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Sun Feb 24 07:27:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10432 for ; Sun, 24 Feb 2002 07:27:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA08578 for rmt-archive@odin.ietf.org; Sun, 24 Feb 2002 07:27:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08428; Sun, 24 Feb 2002 07:23:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08402 for ; Sun, 24 Feb 2002 07:23:24 -0500 (EST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10397 for ; Sun, 24 Feb 2002 07:23:21 -0500 (EST) From: VirusWall@lbl.gov Received: from localhost (root@localhost) by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id g1OCNMO23388 for ; Sun, 24 Feb 2002 04:23:22 -0800 (PST) Date: Sun, 24 Feb 2002 04:23:22 -0800 (PST) Message-Id: <200202241223.g1OCNMO23388@postal1.lbl.gov> To: rmt@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Rmt] Virus Alert Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org Content-Transfer-Encoding: 7bit This is an automated message from the LBNL VirusWall. The mail message you recently received from: which included the file: sample.exe contained the virus: PE_NIMDA.E. PLEASE NOTE: 1. The virus has been REMOVED from the email message by the LBNL VirusWall and will NOT INFECT your computer. 2. It is SAFE to read the message and open the attachment, though you should always use caution when opening attachments from people you do not know. 3. You do not need to notify anyone that you received this message. For more information take a look at our virus protection web page: http://www.lbl.gov/ITSD/Security/resources/ If you have any questions, please contact the LBNL Help Desk at http://www.lbl.gov/help/, or 510-486-4357. Thanks, The VirusWall Lawrence Berkeley National Laboratory _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Mon Feb 25 11:11:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15753 for ; Mon, 25 Feb 2002 11:11:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29421 for rmt-archive@odin.ietf.org; Mon, 25 Feb 2002 11:11:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28696; Mon, 25 Feb 2002 11:02:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28664 for ; Mon, 25 Feb 2002 11:01:56 -0500 (EST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15256 for ; Mon, 25 Feb 2002 11:01:51 -0500 (EST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id g1PG1sE11080 for ; Mon, 25 Feb 2002 08:01:54 -0800 (PST) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id g1PG1kJ11011 for ; Mon, 25 Feb 2002 08:01:46 -0800 (PST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Feb 25 11:01:47 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g1PG1PS06604; Mon, 25 Feb 2002 11:01:25 -0500 (EST) Received: from dnrc.bell-labs.com (jcb2-pcho [135.180.144.92]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA10758; Mon, 25 Feb 2002 11:01:23 -0500 (EST) Message-ID: <3C7A5F50.4302117C@dnrc.bell-labs.com> Date: Mon, 25 Feb 2002 10:59:12 -0500 From: Jose Carlos Brustoloni Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cost264@lip6.fr, rm@openmash.org, rmt@lbl.gov, mboned@network-services.uoregon.edu, manet@itd.nrl.navy.mil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Rmt] CFP: High-Speed Networks Symposium at Globecom'2002 (HSN'2002) Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org Content-Transfer-Encoding: 7bit EXTENDED DEADLINE: MARCH 18, 2002 ^^^^^^^^^^^^^^ [our apologies in case you receive this announcement multiple times] High-Speed Networks Symposium at Globecom'2002 (HSN'2002) Taipei, Taiwan November 17-21, 2002 http://opnear.utdallas.edu/hsnhome.htm ---------------------------------------------------------------------- CALL FOR PAPERS New generations of local, metropolitan, wide-area, access, and wireless networks are pushing the envelope on network speeds. Faster, more capable networks herald the convergence of voice, video, and data and promise to facilitate applications ranging from video-conferencing to grid computing. However, the challenges are many, requiring improved network architectures, protocols, routers, switches, and components, appropriate programming and operating system support, novel approaches for network management, security, and quality of service, sensible migration paths, and successful pilot studies. The High-Speed Networks Symposium 2002 (HSN'2002) will be held as part of Globecom'2002 to address these and other topics relevant to high- speed networking. Globecom is the flagship annual conference of the IEEE Communications Society and this year will be held in Taipei, Taiwan, from November 17 to 21. Researchers, developers, and practitioners of all areas of industry, academia, and governmental agencies of all nations are encouraged to submit papers to HSN'2002. Topics of interest include but are not limited to: - Last-mile solutions, pilot studies, and deployment projections and evaluation - Metropolitan-area networks, including Metro Ethernet and Resilient Packet Rings - Optical networks, including switching technologies, dynamic provisioning, protection, and restoration - Wireless networks, including 802.11x, 3G/4G, and All-IP - Novel mechanisms for scheduling, buffering, switching, routing, and multicast - Programming and operating system support for network processors and high-speed nodes - Network management, traffic engineering, quality of service, and security in high-speed networks - Inter-layer interactions (e.g., IP/SONET and electrical/optical) and interoperability in high-speed networks - Viability studies and migration paths, e.g., from ATM to (G)MPLS-based core networks - Governmental initiatives and regulatory agenda and concerns - Applications, including video-conferencing, video-on-demand, telecommuting, VPNs, network-based storage, thin clients, grid computing, and respective pilot studies and deployment evaluation Papers should be at most 5 pages long and conform to Globecom'2002 guidelines. Papers must be submitted electronically via the Globecom'2002 web site at: http://www.globecom2002.com/submissions/ To ensure proper paper routing, authors should indicate that their papers are being submitted to the High-Speed Networks Symposium. It is suggested that contact authors also send to the HSN'2002 co-chairs (jcb@dnrc.bell-labs.com, andreaf@utdallas.edu) an email message containing their papers' title, abstract, and author list. Each paper will be refereed by at least three reviewers. Accepted papers will be published by IEEE in the Proceedings of Globecom'2002. Best paper award ---------------- IEEE TCGN will distinguish with its Best Paper Award one paper submitted to HSN'2002. This paper will be selected by the HSN'2002 technical program committee. Student travel grants --------------------- IEEE Communications Society will award a limited number of grants to authors who are full-time students and need to travel from another region to present an accepted paper at HSN'2002. Other sessions -------------- In addition to refereed paper sessions, HSN'2002 will feature a keynote address on optical networking by Dr. David Lee (head of Bell Labs Research China) and a panel discussion on metropolitan networks organized by Prof. Hui Zhang (Turin Networks and Carnegie Mellon University). Important dates --------------- - Submission deadline: March 18, 2002 (5:00 p.m. New York time) - Notification of acceptance: June 30, 2002 - Camera-ready version due: August 15, 2002 - Presentations: November 18-20, 2002 Web sites --------- HSN'2002 - http://opnear.utdallas.edu/hsnhome.htm Globecom'2002 - http://www.globecom2002.com/ HSN'2002 Program Co-chairs -------------------------- Jose' Brustoloni (jcb@dnrc.bell-labs.com), Bell Labs, Lucent Technologies, USA Andrea Fumagalli (andreaf@utdallas.edu), The University of Texas at Dallas, USA HSN'2002 Technical Program Committee ------------------------------------ Marco Ajmone Marsan, Politecnico di Torino, Italy Ian F. Akyildiz, Georgia Tech, USA Javier Aracil, University of Navarra, Spain Larry Bernstein, Stevens Institute of Technology, USA Hakki Candan Cankaya, Alcatel, USA Prashant Chandra, Intel, USA Cheng C. Chen, NEC, USA Fabio Chiussi, Bell Labs, Lucent Technologies, USA Jacek Chrostowski, Cisco Systems, Canada Yuguang "Michael" Fang, University of Florida, USA Andras Farago, The University of Texas at Dallas, USA Joseph B. Evans, The University of Kansas, USA Jeff Fitchett, Nortel Networks, Canada Nelson Fonseca, Campinas State University, Brazil Ibrahim W. Habib, City University of New York, USA Jennifer Hou, University of Illinois at Urbana-Champaign, USA Y. Thomas Hou, Fujitsu Labs of America, USA Rauf Izmailov, NEC, USA Laszlo Jereb, Technical University of Budapest, Hungary Admela Jukan, Vienna University of Technology, Austria Mark Karol, Avaya Labs, USA Tanja Kauppinen, Ericsson Telecom, Sweden G.S. Kuo, National Chengchi University, Taiwan Wan-Jiun Liao, National Taiwan University, Taiwan Antonio Manzalini, Telecom Italia Lab, Italy Muriel Medard, MIT, USA Alberto Paradisi, CPqD, Brazil Steve Pope, AT&T Labs Cambridge, England Fabrice Poppe, Alcatel, Belgium Chunming Qiao, The State University of New York at Buffalo, USA Kamel Rahouna, RIST++, Austria Patricia Sagmeister, IBM, Switzerland Galen Sasaki, University of Hawaii, USA Ken-ichi Sato, NTT, Japan Marco Schneider, SBC Technology Resources, USA Edmundo de Souza e Silva, UFRJ, Brazil James P.G. Sterbenz, BBN Technologies, USA Suresh Subramaniam, George Washington University, USA Kenji Suzuki, Advanced Communications Co., Japan Franco Travostino, Nortel Networks, USA Naoaki Yamanaka, NTT, Japan Si Qing Zheng, The University of Texas at Dallas, USA Sponsoring organizations ------------------------ The following Technical Committees of the IEEE Communications Society are technical co-sponsors of HSN'2002: - Gigabit Networking - Communications Software - Communications Switching & Routing - Computer Communications - Internet - Multimedia Communications -- Jose' Brustoloni Tel.: (732) 332-5368 Address: Bell Laboratories Fax: (732) 949-0399 101 Crawfords Corner Rd. Email: jcb@dnrc.bell-labs.com Room 4E-630 http://www.bell-labs.com/~jcb/ Holmdel, NJ 07733 - USA _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Tue Feb 26 13:39:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15282 for ; Tue, 26 Feb 2002 13:39:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10726 for rmt-archive@odin.ietf.org; Tue, 26 Feb 2002 13:39:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10390; Tue, 26 Feb 2002 13:32:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10361 for ; Tue, 26 Feb 2002 13:32:09 -0500 (EST) Received: from cmmail.com ([218.6.2.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15000 for ; Tue, 26 Feb 2002 13:32:01 -0500 (EST) Message-Id: <200202261832.NAA15000@ietf.org> From: "L.Mi" To: Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Wed, 27 Feb 2002 02:28:24 +0800 Reply-To: "L.Mi" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Rmt] Internet Marketing Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org Content-Transfer-Encoding: 8bit Dear friend

Dear friend :

Now there are billions of email users in the world,and this amount is increasing greatly every 
year .  People are now sending informations and conducting the  internet marketing  through
email , because of its cheap cost and fast connection .  If you want to introduce and sell your
product or service ,  it would be the best way  for you  to use the  email to  contact  with  your 
targeted  customers  ( of  course you should be aware of  the  email address of the targeted  
customers  firstly  )  . Targeted  email  is no doubt very effective .  If  you could introduce your 
product or  service  through  email  directly  to  the  customer  who  are interested in them , it 
will bring to you much  more business chance and success.

We,XinLan Internet Marketing Center,have many years of experience in developing & utilizing 
internet resources.We have set up global business email address databases, which  contain
millions  of   email  addresses of  commercial  enterprises and  consumers all over the world. 
These email addresses are sorted by countries and fields. By using  advanced  professional
technology, we also continuously update our databases,add new addresses ,  remove undel-
iverables and unsubscribe addresses.With the cooperation with our partners, We are able to
supply  valid targeted email  addresses  according  to  your  requirements ( for example,  you 
need some email addresses of Importers in the field of auto spare part in England ). With our 
supplied email addresses,you can easily and directly contact your potential customers.

We also supply  a  wide variety  of software. 
For example , WORLDCAST,  the software for  fast-sending emails: this software will enable 
you to send  emails  at  the rate of  over 10,000  pcs  per hour, and to release  information  to 
thousands of people in a short  time.

We are pleased to tell you that we are now offering our best prices :

          Emails  or  Software                                       Remark     Price
100,000 targeted email addresses 
We are  able  to  supply  valid  targeted  email address according to your requirements , which are all compiled  upon your order,such as region / country / occupation / field / Domain Name (like AOL.com or MSN.com) etc.

   USD 30.00 
     623,000 email addresses
                    623,000 email addresses of
     global auto parts  importer/wholesaler/distributors
 		  USD 110.00 
    8 millions email addresses
8 millions global commercial enterprises email addresses
 		  USD 240.00 
        Wcast software 
Software for fast-sending emails 
 		   USD 39.00 
       Email searcher software  Software for searching email addresses
   USD 68.00 
        Global Trade Poster
Spreading information about your business or products over 3000 trade message boards and newgroups.  
 		  USD 135.00 
       Jet-Hits Plus 2000 Pro 
Software for submitting website to 8000+  search engines 
 		   USD 79.00 


You can order the emails or  softwares  directly  from our website. For more details, please 
refer to our website: http://www.biz-help.com  

It is our honour if you are interested in our services or softwares.  Please do not hesitate to
contact us if any queries or concerns. It is always our pleasure to serve you.


Thanks and best regards !

                    K. Peng
Marketing Manager
Marketing@biz-help.com
Http://www.biz-help.com
XinLan Internet Marketing Center

To help your business succeed, biz-help.com

_______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Wed Feb 27 16:23:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19273 for ; Wed, 27 Feb 2002 16:23:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00349 for rmt-archive@odin.ietf.org; Wed, 27 Feb 2002 16:23:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29322; Wed, 27 Feb 2002 16:09:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29297 for ; Wed, 27 Feb 2002 16:09:10 -0500 (EST) Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18304 for ; Wed, 27 Feb 2002 16:09:04 -0500 (EST) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id g1RL8uW15088 for ; Wed, 27 Feb 2002 13:08:56 -0800 (PST) Received: from localhost ([211.204.131.96]) by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id g1RIQpj02671 for ; Wed, 27 Feb 2002 10:26:52 -0800 (PST) Message-Id: <200202271826.g1RIQpj02671@SpamWall.lbl.gov> Reply-To: kisroom@yahoo.co.kr From: 에벤에셀 To: rmt@lbl.gov Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 17 Dec 1999 15:20:14 +0900 Subject: [Rmt] [광고]미국5위 전세계24개국진출.신화의 네트워크 한국진출! Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org 본메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다.
전자우편 주소 외 어떠한 개인 정보도 가지고 있지 않으므로 안심하시기 바랍니다.
이메일 수신을 원치 않으시면 아래주소로[수신거부] 를하여 주십시오. 저희는귀하의 의사를 존중합니다.
수신거부된 메일은 절대로 메일을 재발송하지 않겠습니다.



안녕하세요?
정보전략연구 소장인 윤은기 박사는
"21세기는 신인재가 이끌어가는 사회가 될 것이고, 창업의시대"라고 도 했습니다.
점포가 필요없는 시대가 도래할 것입니다.

학력을 내세우던 시대는 이제 지났습니다.
신사고를 하는 신지식인의 시대가 온 것입니다.
학력보다는 idea가, 분석력보다는 실천력이 요구되는시대입니다.
학력불문, 나이불문, 성별불문, 전공불문.누구나 할 수 있는 사업입니다.

현 직장인이라면, 남는 시간에 부업으로하시면 됩니다.
소박한 꿈마저도 없는 분이라면 사양합니다.
2년 전의 생활과 지금의 생활을 비교했을 때, 아주만족하십니까?
그럼, 2년 후는 어떻게 될까요?

같은 문을 열면 같은 결과밖에 나오지 않습니다.
이제 다른 문을 열어볼 때가 되었습니다.
신지식인이 되고자 하시는 분은 주저마시고 연락주십시요.
기회는 평등합니다.
하지만 보상은 차등 됩니다.
노력하시는 분이 성공합니다.
2년 후엔 엄청난 결과가 있을 것입니다.

새로운 님의 미래를 에서 시작하십시요..
NFLI 의비젼은 세계인이 증명하였습니다.
세계20여개국에서 한번의 실패도 없이 85% 재구매율이라는
경이적인 실적으로 성장하고 있습니다.
580여가지의 다양한 상품군과 70%의 자체생산으로 가격이나
품질경쟁력에서 타회사의 우위를 고수할수있는원인이라 할수있습니다.

(제품 : 생활용품, 세재류, 건강식품, 화장품, 주방용품, 허벌제품, 개인용품
다이어트식품, 커피와 차류,스낵류, 미네랄 케어, 바이오워트 기타)

그런데 회사가 아무리 좋다고 님이 성공을 하는것은 아니겠지요...
4명의 메트릭스방식으로 구성되는 래그에서 님은 어떤 라인에서 사업을
하느냐도 중요한 문제이니 신중하게 결정을 해야겠지요.
우리 클럽은 가상회원이라는 제도를 구축하여 가입회원의 모든 네트웍회사의
비젼을 확인하고 가입을 하게끔 시도하여 엄청난 호응을 불러일으키고 있습니다.

하루 200명 이상의 회원이 새로운 사업을 저희클럽에서 시도하고 있습니다.
님이 동참의사가 있으시다면 첫걸음부터 안내하겠습니다.
님은 최소한의 의지만 있으면 됩니다.
모든 PLAN은 저희가 이미 준비하였습니다.
님은 합류만하면 됩니다.

온라인 무료등록하시고 다운라인 형성되는것 직접
다운라인 조회에서 확인하세요...
당신과 당신이 홍보하여 형성되는 파트너까지
모두 홈페이지를 실시간으로 지원합니다.

http://ebiz7.net/myteam/index.php?id= 본인아이디

본인의 아이디는 아래에서 가상멤버 등록의 아이디를 말합니다.

본 클럽에서는 절대 님의 의사를 존중합니다.
본 클럽을 성공의 발판으로 삼으시길 바랍니다.
아래의 홈페이지를 클릭하여 가입하신후 연락을 주십시요.

모든 성공 사업에는 아이템과 타이밍이 가장 중요합니다.
아무리 훌륭한 사업도 타이밍이 지난 뒤에는 성공의 기회 역시 사라집니다.
그리고 오프라인으로만 진행을 할 경우,많은 분들이 두려움을느낍니다.

"나는 아는 사람이 별로 없는데."
"다른 사람에게 말할 자신이 없는데."
"시간이 없어서 못해요."
" 열심히 해도 수입이 안돼요."

네트워크 마케팅을 오프라인보다는 인터넷홍보에 중점적으로 뛰는 팀으로 누구나 쉽게 사업을 진행하실 수 있습니다.
요즘 경기가 안 좋아 수입이 적은 분들,부업을 원하는 분들,가정 주부 등등 누구나 하실 수 있습니다.(재택근무)

富를 창출하는 가장 좋은 방법은 새로운 기회를 발견하고 만들어내는 것 입니다.
인터넷 경제에서는 새로운 기회를 누가 얼마나 빨리 포착하느냐가 성공의 관건이 되고 있습니다.
인터넷 세상에서 1년은 예전의 10년과 같습니다. 님의 빠른 행동만이 정보의 가치를 살릴 수 있습니다.
그러나 시장선점을 할 수 있는 사업적 타이밍은 백만장자의 가능성을 현실화 할 수 있는 최고의 조건인 것 입니다.

진심으로 권하고 싶습니다. 우리가 평생을 살아가면서 이처럼 좋은 사업 기회는 쉽게오지 않을 것 입니다.
마지막으로 이 글이 여러분에게 불편을 끼쳤드렸다면 다시한번 사과드립니다.

즐거운 하루되십시오.

10년 안에는 쉽게 오지 않을 세계적인 e-비지니스의 기회를 결코 놓치지 마십시오.
그럼 더자세한 알고싶으시면 아래주소를 클릭하십시요.

홈페이지바로가기

e-mail :kisroom@yahoo.co.kr

손폰 : 016-9757-2535
_______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt From daemon@optimus.ietf.org Thu Feb 28 17:43:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24149 for ; Thu, 28 Feb 2002 17:43:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA07104 for rmt-archive@odin.ietf.org; Thu, 28 Feb 2002 17:43:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06470; Thu, 28 Feb 2002 17:34:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06432 for ; Thu, 28 Feb 2002 17:34:09 -0500 (EST) Received: from yourwebsite.com (evrtwa1-ar13-4-3-033-042.evrtwa1.vz.dsl.gtei.net [4.3.33.42]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23706 for ; Thu, 28 Feb 2002 17:34:04 -0500 (EST) From: dailythrower@yahoo.com Message-Id: <200202282234.RAA23706@ietf.org> Reply-To: makemoney@big-marketing.com To: rmt@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 28 Feb 2002 14:13:11 -0800 Subject: [Rmt] Make $1250 a day with this confidential report Sender: rmt-admin@ietf.org Errors-To: rmt-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Reliable Multicast Transport X-BeenThere: rmt@ietf.org Hello, Just thought I'd fill you in on an amazing Million Dollar report that uncovers confidential information you are not supposed to know about. It reveals hush, hush info like... *How a banking secret, which bankers don't want published, can help you get $5,000 to $15,000 to use for any purpose within 30 days. *How to use a "Back Door" method to get listed on Yahoo. There is a back door to Yahoo that has been kept hush hush until recently. Best of all it takes only 1 minute to do. *How to use an extremely powerful technique to get your web site listed at the top of the major search engines and directories like Yahoo, AOL, Lycos and more within FIVE Business days. This technique is so new it was just introduced to the internet in November 2001. *Get a list of over 100 major corporations offering legitimate work opportunities for telecommute home workers paying $500 to $1,500 per week. In today's economy corporations like Bank of America, Dell Computer, Motorala and many other such companies finding it less costly to hire people to work from their homes. The list includes contact information for the corporations that need your help. *How to open a checking account if you currently are unable to because you have a bad rating with Chex- systems or Telecheck. *How you can get 1,000,000 hits to your web site in 1 year. Even Microsoft has tried to patent this one but can't. *How to get $3,000 to $50,000 within 1 week regard- less of your credit if you currently have a merchant account. *How you can resell this information with a tested, proven Sales Letter that is EXPLODING wiht sales everywhere. WARNING! Check out this updated, FREE REport before you try any other of the many business plans on the internet. This information may not be available much longer. This may be THE LAST TIME you see this report! Get yours before the deadline by sending a Blank Email to: mailto: makemoney@big-marketing.com It will arrive in just a few minutes. Yours truly, Chase _______________________________________________ Rmt mailing list Rmt@ietf.org https://www1.ietf.org/mailman/listinfo/rmt