From rem-conf-request@es.net Tue Aug 01 09:47:36 1995 Received: from karon.his.se by osi-west.es.net with ESnet SMTP (PP); Tue, 1 Aug 1995 06:47:04 -0700 Received: from ida.his.se (mhost.ida.his.se) by karon.his.se (5.0/his.se-931126) id AA17425; Tue, 1 Aug 1995 15:46:18 +0200 Received: from hugin.ida.his.se by ida.his.se (5.x/SMI-SVR4-ida-2) id AA05711; Tue, 1 Aug 1995 15:46:58 +0200 Received: from hugin (localhost) by hugin.ida.his.se (4.1/hugin.ida.his.se-931115) id AA21045; Tue, 1 Aug 95 15:46:57 +0200 Message-Id: <9508011346.AA21045@hugin.ida.his.se> Date: Tue, 01 Aug 95 15:46:57 0200 Sender: a94jonbj@ida.his.se From: Jon Bjarnason X-Mailer: Mozilla 1.1N (X11; I; SunOS 4.1.3_DB sun4m) Mime-Version: 1.0 To: rem-conf@es.net Subject: (no subject) X-Url: http://www.fokus.gmd.de/step/employees/hgs/rtp/faq.html Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii content-length: 28 subsrcibe rem-conf@es.net From rem-conf-request@es.net Tue Aug 01 12:22:14 1995 Received: from bnr.ca (actually x400gate.bnr.ca) by osi-west.es.net with ESnet SMTP (PP); Tue, 1 Aug 1995 09:21:25 -0700 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 1 Aug 1995 10:50:41 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 1 Aug 1995 10:26:32 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 1 Aug 1995 10:25:00 -0400 Date: Tue, 1 Aug 1995 10:25:00 -0400 X400-Originator: /dd.id=1683277/g=bhumip/i=b/s=khasnabish/@bnr.ca To: Original-To: :; PP-Warning: Parse error in original version of preceding To line X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.051:01.07.95.14.26.32] X400-Content-Type: P2-1984 (2) Content-Identifier: CFP (textFile... From: "bhumip (b.) khasnabish" Sender: "bhumip (b.) khasnabish" Message-ID: <"13280 Tue Aug 1 10:27:38 1995"@bnr.ca> Subject: CFP (textFile): Workshop on Enterprise Networking (in ICC-96) X-Bulletin: potential contributors the workshop will be held either on june 23 or june 27, 1996 will let u know once it is finalized Thanx >------------------------------------------------------------------------ -o-----------------------------------------------------o- | EEEEEEEE N N W W " 9999999 666666 | | E N N N W W 99 99 66 | | EEEEE N N N W W W == 9999999 66666666 | | E N N N W W W W 99 66 66 | | EEEEEEEE N N W W 99999 66666666 | -o-----------------------------------------------------o- FIRST INTERNATIONAL IEEE WORKSHOP ON ENTERPRISE NETWORKING in Conjunction with ICC/SUPERCOMM '96, June 23-27, Dallas, Tx, USA =================================================================================== CALL FOR PARTICIPATION =================================================================================== This is the first International workshop on Enterprise Networking (EN) sponsored by the IEEE Communications Society's Technical Committee on Enterprise Networking. It attempts to bring together the EN service providers, corporate network managers, technicians, and operation personnel in informal environment, so that they can exchange their ideas and view points with peers and experts standing on the same platform. The goal is to bridge the gap across: (i) Enterprise-wide business drivers and (ii) Technology-driven solutions and enablers. Attendees will be benefitted by EXCHANGING their ideas on future directions of ENs in an informal environment with the professionals in varieties of areas (e.g., service providers, implementors) of ENs. They will also be able to SHARPEN their competitive edge by actively participating in the presentations and interacting with the internationally recognized experts on ENs. The purposes of this single-track one-day workshop are to: (1) Present the current view of the researchers, vendors, implementors, computing and telecommunications service providers, operators, and users. (2) Provide the attendees with the future directions of growth of the ENs. For example, how the standardization and interoperability issues can be resolved, how the emerging technologies like ATM, PCS, full-duplex LAN services, etc. can be exploited to help the evolution of the ENs, and (3) Show how the integration and interplays of ENs with the Internets and the information superhighways are going to create a really open universe, and how the billing and security issues can be handled in such scenarios. (4) Explore the principles and problems underlying the design, deployment, management and operations of ENs. Presentations are being planned in the following FOUR themes, and hence papers covering these areas are explicitly solicited and will be given preference: o Experience with and Current Challenges of the ENs o Future Directions of Growth of the ENs, o Integration of ENs with Emerging Technologies/Services, o Outsourcing the Operations, Management and Design of ENs. Please submit FOUR copies of summary (maximum 15 double-spaced pages excluding figures) of technical contribution mentioning the target theme to the organizing chair at the following address. Bhumip Khasnabish Lab. 5, Mail Stop: 262, Bell-Northern Research Ltd. 3500 Carling Avenue, P. O. Box: 3511, Station C Ottawa, Ontario, Canada, K1Y 4H7. Tel: +1 613 763 2698 Fax: +1 613 763 2626 Internet: bhumip@bnr.ca All contributions will be peer-reviewed and the accepted ones will be published in the proceedings of the workshop. Attendance to this workshop may be limited to 150 participants with preference given to those who 'submitted' or 'have accepted' contribution(s) to this workshop. The schedule (almost final) for this workshop is as follows: Deadline for Submission: ............. 15-th September, 1995. Acceptance Notification: ............. 1st January, 1996. Presentation Materials (10 pages) Due: 1st March, 1996. PROGRAM COMMITTEE: Chair: Bhumip Khasnabish (BNR, Canada) ComSoc Co-Ordinator: Tom Stevenson (IEEE ComSoc HQ) Committee Members: Majid Ahmadi (U of Windsor, Canada) Salah Aidarous (BNR, Canada) Robert S. Braudy (DMW Group, USA) Bob Fike (RNF Systems, USA) David Kirsch (SunNetworks, USA) Ken Lutz (BellCore, USA) Branislav Meandzija (MetaAccess, USA) Totumo Murase (NEC, Japan) Toshihiro Sikama (Mitsubishi, Japan) Karen Seo (BBN, USA) Douglas N. Zuckerman (AT&T, USA) Steven Weinstein (NEC, USA) From rem-conf-request@es.net Tue Aug 01 15:09:19 1995 Received: from adept.PRPA.Philips.COM by osi-west.es.net with ESnet SMTP (PP); Tue, 1 Aug 1995 12:08:50 -0700 Received: from jeanet.PRPA.Philips.COM by adept.PRPA.Philips.COM (4.1/SMI-4.1) id AA02845; Tue, 1 Aug 95 12:09:59 PDT Received: by jeanet.PRPA.Philips.COM (4.1/SMI-4.1) id AA02386; Tue, 1 Aug 95 12:10:08 PDT Date: Tue, 1 Aug 95 12:10:08 PDT From: nichols@PRPA.Philips.COM (Kathleen Nichols) Message-Id: <9508011910.AA02386@jeanet.PRPA.Philips.COM> To: rem-conf@es.net Subject: Hot Interconnects III Symposium HOT INTERCONNECTS III A Symposium on High-Performance Interconnects ADVANCE PROGRAM AND REGISTRATION FORM Sponsored by the Technical Committee on Microprocessors and Microcomputers of the IEEE Computer Society. Stanford University Memorial Audiorium Palo Alto, CA August 10-12, 1995 Thursday, August 10 Keynote "Future Prospects for Wide Area Telecommunications", Sandy Fraser, Vice President, AT&T Bell Labs. Hot Wireless "Performance Evaluation of Experimental 50-Mb/s Diffuse Infrared Wireless Link using On-Off Keying with Decision-Feedback Equalization" Gene Marsh and Joseph Kahn, UC Berkeley "A Frequency Hopping Protocol for ISM Wireless LANs", Ed Geiger, Apple "Experiences with a Wireless Network in MosquitoNet", Mary Baker and Stuart Cheshire, Stanford Hot Hybrids "California First: A Full Service Broadband Network", A. Mallya, Pacific Bell "Switched Digital Video (SDV) Architecture", Amalesh Sanku, James P. Runyon, AT&T "Broadband Modem Technology for Residential Applications", Ladd Wardani, ComStream Corporation "The Com21 System for the Transmission of Data and Voice Using ATM over Hybrid-Fiber Coaxial Cable Networks", Mark Laubach, COM21 Hot Media Servers "Interactive Video Servers", Robin Williams, IBM Almaden "Interactive Television: Client/Server and Network Architecture in Orlando" Thomas H. Speeter, Silicon Graphics "Strategies for Minimizing Latency for VCR Control on Media Servers", Frank Ma, HP "Plug and Play ATM Multimedia", Allywn Sequeira, First Virtual Corporation "The Design and Implementation of a Large-Scale, Real-Time Media Server", Mark Porter and Bill Bailey, Oracle Evening Panel Interactive Services: Who, What, Why, and When? RBOCs vs Cable vs Internet Moderator: Gordon Bell Friday, August 11 Cold Reality "LogP Quantified: The Case for Low-Overhead Local Area Networks", Kimberly Keeton, Thomas Anderson and David Patterson, UC Berkeley "The Bay Area Gigabit Testbed: Building a Real-Life Heterogeneous ATM MAN", Lance Berc, DEC SRC "Experiences and Evaluations of First Generation ATM Equipment", Helen Chen, Sandia Labs Real SCI "Gigabit SCI Cluster Interfaces" Knut Alnes, Bodo Parady, Bjorn Johsen, Dolphin and SUN "Using a 2 GByte/second Optical Data Link to Extend High-Bandwidth Busses", Richard Booth, Wayne Nation, David Engebretsen, John Crow and Daniel Kuchta, IBM "The SCX channel: A new, supercomputer-class system interconnect", Steve Scott, Cray Research Hot Products "Systems Architecture for the 90s: Introducing UPA From SPARC Technology Business", Kevin Normoyle and Zahir Ebrahim, SUN "Virtual Wires", Anant Agarwal, MIT Hot Switches "VC-level Flow Control and Shared Buffering in the Telegraphos Switch" Manolis Katevenis, Panagiota Vatsolaki, Aristides Efthymiou, and Manolis Stratakis FORTH and University of Crete "Reliable, High-Speed Serial Interconnections using SSA (Serial Storage Technology)", Robert Sellinger, Adaptec Hot Interfaces "Assessing Design Tradeoffs in Fast Network Interfaces", David Culler, UC Berkeley "Memory Channel Network for PCI: An Optimized Cluster Interconnect", Richard Gillet, DEC "User Level Communication on Cenju-3", Yasushi Kanoh, Koichi Konishi, Christopher Howson, Yosuke Takano and Tsutomu Maruyama, C&C Research Labs, NEC "Hamlyn: a high-performance network interface", Greg Buzzard, David Jacobson, Scot Marovich and John Wilkes, HP Labs Tutorials, Saturday August 12 Morning 1. High-Speed Wireless Infrared Communications, J. Kahn, UC Berkeley 2. CORBA and OLE: Interconnecting Distributed Objects, Keith Moore, HP Labs Afternoon 3. LAN Emulation and IP over ATM, George Marshall, ZeitNET 4. MPEG over ATM ORGANIZING COMMITTEE General Chair: Kathleen M. Nichols, Philips Research Palo Alto Program Co-Chairs: Thomas E. Anderson, UC Berkeley Vivian Shen, Hewlett-Packard Laboratories Local Arrangements: Cary Kornfeld, KDL Registration: Qiang Li, Santa Clara University Treasurer: Dima Khoury, TTC of Silicon Valley Publicity and Publications: S. Diane Smith, Consultant Tutorials: Doreen Cheng, Philips Research Palo Alto PROGRAM COMMITTEE MEMBERS Hasan AlKhatib, Santa Clara University Forrest Baskett, SGI Gordon Bell, consultant David Greaves, ATML England Raj Jain, Ohio State Ellen Khayata, Apple Computer Kai Li, Princeton University Greg Papadopolous, SUN Ed Szurkowski, AT&T Chuck Thacker, DEC SRC FEES for the TECHNICAL PROGRAM (Thursday and Friday): Early registration is before July 24, 1995. Fees for registration after July 24 are in parentheses. IEEE/CS or ACM Member: $210 ($265) Non-Member: $265 ($330) Student Member: $100 ($125) Registration for the Technical Program includes: attendance; one copy of the notes; parking; Thursday evening dinner and reception; two lunches; coffee breaks. A Stanford map, parking permit, the location of parking, a list of local hotels, and a receipt will be mailed to early registrants. On-campus housing can also be arranged through the Stanford Conference Office, (415) 725-1429. Please note that Stanford has instituted a very restrictive no-smoking policy on campus that is strictly enforced, including in on-campus housing. FEES for the TUTORIAL PROGRAM (Saturday): Early registration is before July 24, 1995. Fees for registration after July 21 are in parentheses. The following fees apply to each individual tutorial. Luncheon is included. IEEE/CS or ACM Member: $105 ($125) Non-Member: $130 ($155) Student Member: $25 ($35) Tax Id: Institute of Electrical and Electronics Engineers Computer Society 13-1656633 Cancellation of Registration: Must be made in writing prior to Thursday, August 3, 1995. A $40 fee will be charged for cancellation. On-Site Registration will start at 7:30 am, Thursday, August 10, 1995. Preregistration will be accepted through August 9, 1995. Registration may be faxed or e-mailed if paid by credit card. To register, contact: Dr. Qiang Li Dept. of Computer Engineering Santa Clara University Santa Clara, CA 95053 Voice: (408)554-5194 or (408)554-2730 Fax: (408)551-1634 Internet: hot-i@sunrise.scu.edu REGISTRATION INFORMATION REQUESTED: Name ______________________________ Affiliation ___________________________ Mailing Address_________________________ ______________________________________ Telephone ______________________________ Fax ___________________________________ E-mail________________________________ Check all that apply: ____ Please don't include my name in any mailing list ____ IEEE Member, membership number ___________________ ____ ACM Member, membership number ___________________ ____ Full-time student ____ Unemployed ____ Please send me housing information Payment Method: _____ Check (Make checks withdrawable fro a US Bank and payable to Hot Interconnects Symposium) _____ VISA _____ Mastercard If paying by credit card: Exact cardholder name: ____________________________ Credit Card number: __________________________ Expiration date: _____________________________ SELECTIONS AND FEES: Technical Program: _______ Tutorials: _______ ______ 8:30-12:00 Tutorial 1 ______ 8:30-12:00 Tutorial 2 ______ 1:30-5:00 Tutorial 3 ______ 1:30-5:00 Tutorial 4 TOTAL AMOUNT for Technical Program/Tutorials _______ From rem-conf-request@es.net Tue Aug 01 19:12:51 1995 Received: from arapaho.cse.ucsc.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 1 Aug 1995 16:12:17 -0700 Received: (from pang@localhost) by arapaho.cse.ucsc.edu (8.6.10/8.6.9) id QAA20557 for rem-conf@es.net; Tue, 1 Aug 1995 16:12:15 -0700 Date: Tue, 1 Aug 1995 16:12:15 -0700 From: Alex Pang Message-Id: <199508012312.QAA20557@arapaho.cse.ucsc.edu> To: rem-conf@es.net Subject: IEEE Visualization'95 IEEE Visualization 95 Sponsored by IEEE Computer Society Technical Committee on Computer Graphics In Cooperation with ACM/SIGGRAPH October 29 - November 3, 1995 Atlanta Airport Hilton and Towers Atlanta, Georgia +-------------------------------------------------------------------------+ | Get complete, up-to-date listings of program information from | | URL: http://www.gatech.edu/vis95.html, | | http://davinci.informatik.uni-kl.de/Vis95 (active late July) | | FTP server: ftp.erc.msstate.edu, directory vis95, or | | vis95.informatik.uni-kl.de, directory info, or | | contact: Bill Ribarsky, Georgia Institute of Technology, 404.894.6148, | | bill.ribarsky@oit.gatech.edu | +-------------------------------------------------------------------------+ Welcome to IEEE Visualization 95 The sixth annual IEEE Visualization conference will have the strongest and most varied technical program ever. This year we will extend our focus to all aspects of data and information visualization with applications ranging across scientific, medical, engineering, business, and entertainment fields. For the first time, we will have 3 Symposia (Parallel Rendering, Information Visualization, and Biomedical Visualization). In addition you will have your pick of a full slate of tutorials on Sunday, Monday, and Tuesday. The technical program on Wednesday will begin with a Keynote Address and Panel, followed by concurrent sessions of papers, panels, and case studies presenting the latest issues, research, and applications in visualization. Demonstrations of visualization products, tools, and applications will begin mid-day on Wednesday and continue through Thursday afternoon. Birds of a Feather sessions are scheduled on several days throughout the conference. We encourage you to join us in Atlanta the week of October 30 - November 3, 1995 for IEEE Visualization 95. You will have a unique opportunity to confer with researchers, developers, and your colleagues. Dont miss this conference, or you will miss the most effective compilation of significant topics in visualization this year. Bill Ribarsky, Georgia Institute of Technology Nahum Gershon, The MITRE Corporation IEEE Visualization 95 Conference Co-Chairs From rem-conf-request@es.net Wed Aug 02 07:18:23 1995 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Wed, 2 Aug 1995 04:17:48 -0700 Received: from relay.hf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sdbnz-000UevC; Wed, 2 Aug 95 04:17 PDT Received: from ccm.hf.intel.com by relay.hf.intel.com (Smail3.1.28.1 #2) id m0sdbnz-000qDLC; Wed, 2 Aug 95 04:17 PDT Original-Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 2 Aug 95 04:17:43 PST PP-warning: Illegal Received field on preceding line Date: Wed, 2 Aug 95 04:17:43 PST From: Peter Seeberg Message-ID: <950802041743_5@ccm.hf.intel.com> To: rem-conf@es.net Subject: subscribe From rem-conf-request@es.net Wed Aug 02 12:14:56 1995 Received: from scorpio.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 2 Aug 1995 09:14:28 -0700 Received: by scorpio.arc.nasa.gov (940816.SGI.8.6.9/1.35) id GAA10473; Wed, 2 Aug 1995 06:41:54 -0700 Date: Wed, 2 Aug 1995 06:41:54 -0700 From: garyp@scorpio.arc.nasa.gov (Gary Paden) Message-Id: <199508021341.GAA10473@scorpio.arc.nasa.gov> To: rem-conf@es.net Subject: STS-69 Shuttle Mission Delayed The STS-69 NASA Shuttle Mission has been delayed until mid-August. Due to technical difficulties NASA Management have decided to delay the mission. I will be sure to post the new mission schedule as soon as I receive it. Gary Paden From rem-conf-request@es.net Wed Aug 02 16:25:10 1995 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 2 Aug 1995 13:24:28 -0700 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.6.12/8.6.9) with ESMTP id QAA12981; Wed, 2 Aug 1995 16:24:26 -0400 Received: (from kevin@localhost) by flora.cc.gatech.edu (8.6.10/8.6.9) id QAA28551; Wed, 2 Aug 1995 16:24:22 -0400 Date: Wed, 2 Aug 1995 16:24:22 -0400 From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199508022024.QAA28551@flora.cc.gatech.edu> To: kevin@cc.gatech.edu Subject: Mbone Session Membership Collection Some of the recent discussion on the rem-conf and Mbone lists have dealt with collection of vat participant lists, and estimated group size numbers for various Mbone sessions including the recent Stockholm IETF and STS-71 Shuttle Mission broadcasts. This discussion relates to a research effort here at Georgia Tech to collect membership information and then characterize the participant behavior for Mbone audio sessions. We recently submitted a paper to INFOCOM, but I thought that based on the recent discussions, a WWW pointer would be more timely and useful to this group. I've included a text copy of the abstract below, and a WWW pointer can be found in my sig. -Kevin ---------------------------------------------------------------------- Characterization of Mbone Session Dynamics: Developing and Applying a Measurement Tool Kevin C. Almeroth Mostafa H. Ammar Much of our current understanding of the operational aspects and the network support requirements of multicast communication derives from the Mbone. As an experimental network that overlays the Internet, the Mbone has served as the testbed for many ideas. Most prominent is the development of a set of audio and video conferencing tools that have been used extensively in the last few years. This paper describes our efforts in developing and using a measurement tool for characterizing the dynamic behavior of Mbone sessions. Such a characterization will be of great benefit in understanding how any future networking infrastructure with multicast and real-time capabilities will be used. We discuss the challenges in monitoring Mbone session participation and report on a methodology for pre-processing observed data to make it better reflect the true behavior of participants in an Mbone session. We also report on the results of using our tool to determine temporal, geographical and resource usage characteristics of several Mbone sessions. ---------------------------------------------------------------------- Kevin Almeroth (kevin@cc.gatech.edu) Networking and Telecommunications Research Group College of Computing, Georgia Institute of Technology http://www.cc.gatech.edu/computing/Telecomm/people/Phd/kevin/kevin.html From rem-conf-request@es.net Wed Aug 02 17:15:04 1995 Received: from mail.barrnet.net by osi-west.es.net with ESnet SMTP (PP); Wed, 2 Aug 1995 14:14:37 -0700 Received: from fujitsu1.fujitsu.com (fujitsu1.fujitsu.com [133.164.254.1]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with SMTP id OAA11094 for ; Wed, 2 Aug 1995 14:14:36 -0700 Received: from fla.fujitsu.com (cad) by fujitsu1.fujitsu.com (4.1/SMI-4.1) id AA23664; Wed, 2 Aug 95 14:15:48 PDT Received: from milpitas.fla.fujitsu.com by fla.fujitsu.com (4.1/SMI-4.1) id AA03365; Wed, 2 Aug 95 14:15:17 PDT Received: by milpitas.fla.fujitsu.com (5.x/SMI-SVR4) id AA01580; Wed, 2 Aug 1995 14:14:49 -0700 Date: Wed, 2 Aug 1995 14:14:49 -0700 From: ychen@milpitas (Yao-Min Chen) Message-Id: <9508022114.AA01580@milpitas.fla.fujitsu.com> To: rem-conf@es.net Subject: SUBSCRIBE SUBSCRIBE From rem-conf-request@es.net Thu Aug 03 21:49:13 1995 Received: from ocfmail.ocf.llnl.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 3 Aug 1995 18:48:46 -0700 Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA10352; Thu, 3 Aug 95 18:48:43 PDT Date: Thu, 3 Aug 95 18:48:43 PDT From: wiltzius@ocfmail.ocf.llnl.gov (David P Wiltzius) Message-Id: <9508040148.AA10352@ocfmail.ocf.llnl.gov> To: rem-conf@es.net Subject: Mbone session Aug 14 Cc: bagnet@george.lbl.gov, wiltzius@llnl.gov I would like to transmit the following on the Mbone and BAGNet, audio and video, on August 14 at 15:30-16:30PDT. Dr.Herbert Walther, Director, Max-Planck-Institut fur Quantenoptik Professor of Physics, Univ. of Munich "Quantum optics of single atoms" For more details please see: http://www.llnl.gov/llnl/teleseminars.html Dave Wiltzius Lawrence Livermore Nat'l Lab wiltzius@llnl.gov From rem-conf-request@es.net Fri Aug 04 08:55:59 1995 Received: from network2.cs.usm.my by osi-west.es.net with ESnet SMTP (PP); Fri, 4 Aug 1995 05:55:27 -0700 Received: (from khnew@localhost) by network2.cs.usm.my (8.6.9/8.6.9) id UAA00977; Fri, 4 Aug 1995 20:54:10 +0800 Date: Fri, 4 Aug 1995 20:54:06 +0800 From: New Kok Hong Subject: NV on Reflector! To: rem-conf@es.net cc: cu-seeme-l@cornell.edu In-Reply-To: <9508040148.AA10352@ocfmail.ocf.llnl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Anyone out there encounter the following when running nv and connect it to the Cu-SeeMe reflector. When I run the nv-3.3b version and connect it CUSM reflector for Linux (Version 3.0b3) it gives me the following error? packet received through nv_ucast_sock NV client at 161.142.8.104 is opening a connection Unable to convert NV encoding for 161.142.8.104 deleting client The CUSM reflector was set to NV running on unicast at port 4444 with the following line in the reflect.conf file. NV-UV-PORT 4444 This reflector is running well if the CUSM client is connect to it. Also, it gives me the same problem by using the latest version of the CUSM reflector for Linux (version - 4.0b). Any idea? New Kok Hong khnew@network2.cs.usm.my http://network2.cs.usm.my/~khnew/ From rem-conf-request@es.net Fri Aug 04 10:58:19 1995 Received: from prom.engin.umich.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 4 Aug 1995 07:57:47 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id KAA16616; Fri, 4 Aug 1995 10:56:52 -0400 Date: Fri, 4 Aug 1995 10:56:17 -0400 (EDT) From: "david a. schlussel" Subject: Re: NV on Reflector! To: New Kok Hong cc: rem-conf@es.net, cu-seeme-l@cornell.edu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII its NV-UC-PORT, not NV-UV-PORT +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On Fri, 4 Aug 1995, New Kok Hong wrote: > Anyone out there encounter the following when running nv and connect it > to the Cu-SeeMe reflector. > When I run the nv-3.3b version and connect it CUSM reflector for Linux > (Version 3.0b3) it gives me the following error? > > packet received through nv_ucast_sock > NV client at 161.142.8.104 is opening a connection > Unable to convert NV encoding for 161.142.8.104 > deleting client > > The CUSM reflector was set to NV running on unicast at port 4444 with the > following line in the reflect.conf file. > > NV-UV-PORT 4444 > > This reflector is running well if the CUSM client is connect to it. > > Also, it gives me the same problem by using the latest version of the > CUSM reflector for Linux (version - 4.0b). > > Any idea? > > New Kok Hong > khnew@network2.cs.usm.my > http://network2.cs.usm.my/~khnew/ > > From rem-conf-request@es.net Fri Aug 04 11:41:59 1995 Received: from tower.lcs.mit.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 4 Aug 1995 08:41:36 -0700 Received: from beantown.lcs.mit.edu by tower.lcs.mit.edu (8.6.12/NSCS-1.0S) id LAA05871; Fri, 4 Aug 1995 11:41:14 -0400 Received: by beantown.lcs.mit.edu (940816.SGI.8.6.9/940406.SGI) id LAA08823; Fri, 4 Aug 1995 11:41:05 -0400 From: rabatin@beantown.lcs.mit.edu (George Rabatin) Message-Id: <199508041541.LAA08823@beantown.lcs.mit.edu> Subject: Re: NV on Reflector! To: khnew@network2.cs.usm.my (New Kok Hong) Date: Fri, 4 Aug 1995 11:41:05 -0400 (EDT) Cc: rem-conf@es.net, cu-seeme-l@cornell.edu In-Reply-To: from "New Kok Hong" at Aug 4, 95 08:54:06 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1070 You need to set the encoding from with nv to be cu-see-me. Do this with the "encoding" pulldown menu at the top of the window. If you don't, you get the exact message you've listed below... George Rabatin rabatin@lcs.mit.edu > > Anyone out there encounter the following when running nv and connect it > to the Cu-SeeMe reflector. > When I run the nv-3.3b version and connect it CUSM reflector for Linux > (Version 3.0b3) it gives me the following error? > > packet received through nv_ucast_sock > NV client at 161.142.8.104 is opening a connection > Unable to convert NV encoding for 161.142.8.104 > deleting client > > The CUSM reflector was set to NV running on unicast at port 4444 with the > following line in the reflect.conf file. > > NV-UV-PORT 4444 > > This reflector is running well if the CUSM client is connect to it. > > Also, it gives me the same problem by using the latest version of the > CUSM reflector for Linux (version - 4.0b). > > Any idea? > > New Kok Hong > khnew@network2.cs.usm.my > http://network2.cs.usm.my/~khnew/ > From rem-conf-request@es.net Sat Aug 05 23:39:43 1995 Received: from ibminet.awdpa.ibm.com by osi-west.es.net with ESnet SMTP (PP); Sat, 5 Aug 1995 20:39:17 -0700 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA12624; Sat, 5 Aug 95 20:51:32 -0700 Received: by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA28728; Sat, 5 Aug 95 20:29:03 -0700 Received: from cs.nps.navy.mil by ibminet.awdpa.ibm.com (5.61/1.15) id AA12427; Sat, 5 Aug 95 20:39:46 -0700 Received: from trouble.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA17960; Sat, 5 Aug 95 20:26:28 PDT Received: by trouble.cs.nps.navy.mil (950215.SGI.8.6.10/911001.SGI) for rem-conf%es.net@ibmpa.awdpa.ibm.com id UAA07122; Sat, 5 Aug 1995 20:25:33 -0700 From: Your VE info source Message-Id: <9508052025.ZM7120@trouble.cs.nps.navy.mil> Date: Sat, 5 Aug 1995 20:25:33 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: rem-conf%es.net@ibmpa.awdpa.ibm.com Subject: Latest InfoBahn Calls for Participation ... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii The following are some of the latest Infobahn Virtual Environment Calls for Participation: --> PRESENCE Special Issue on Augmented Reality --> Call Date: 15 October 95 --> IEEE Visualization '95 --> Location of web page. --> IEEE Workshop on Networked Realities Boston, Massachusetts --> Call Date: 15 August 95 Call for Papers: "Presence:Teleoperators and Virtual Environments" Special Issue on Augmented Reality Co-editors: Woodrow Barfield, University of Washington (barfield@u.washington.edu) Steve Feiner, Columbia University (feiner@cs.columbia.edu) Michitaka Hirose, University of Tokyo (hirose@ingram.mech.t.u-tokyo.ac.jp) **Submissions due: October 15, 1995** Augmented reality systems combine the real world with a virtual world, instead of replacing the real world with a virtual one. In the visual case, this is accomplished with see-through displays that superimpose synthesized graphics over live video or optically combine synthesized graphics with the directly-viewed real world. Other types of augmented-reality environments can also be created; for example, by integrating synthesized spatialized sound or computer-generated tactile and force feedback with a real-world scene. The earliest virtual-world system, created by Ivan Sutherland in the late 1960s, was also the first augmented-reality system, since it used an optical see-through head-mounted display. Recent developments in augmented reality have led to exciting new applications in science, engineering, medicine, and training. Augmented reality is being used to explore real-world environments that exist remotely, as is the case in telepresence, and to enhance local real-world environments. However, many of the technical problems of augmented-reality systems are even more challenging than those of self-contained virtual environments. For example, image registration, which is affected by temporal lag and geometric distortion, is an especially challenging and difficult problem to solve when overlaying real and virtual worlds. Original, unpublished research and applications-oriented papers are sought that address issues in the design, implementation, and evaluation of augmented reality systems. Topics include, but are not limited to: % applications in augmented reality % multisensory augmented reality systems % systems and applications for people with impairments and disabilities % software and hardware architectures for the design of augmented reality systems % empirical and psychophysical studies of augmented reality % methods for accurately registering the virtual and real worlds Five paper copies of each manuscript should be submitted to the address below. Manuscript submission should be supplemented with an ftp address >from which a PostScript file can be obtained. Fax or email submissions will not be accepted. Woodrow Barfield Sensory Engineering Laboratory Mechanical Engineering Building G12 Mail Stop 352650 University of Washington Seattle, WA 98195 USA Phone: 206-543-3350 Fax: 206-685-3072 Email: barfield@u.washington.edu Submission October 15, 1995 Notification December 15, 1995 Revision March 1, 1996 Publication 1996 ----------------------------------------------------------------------------- IEEE Visualization 95 Sponsored by IEEE Computer Society Technical Committee on Computer Graphics In Cooperation with ACM/SIGGRAPH October 29 - November 3, 1995 Atlanta Airport Hilton and Towers Atlanta, Georgia ------------------------------------------------------------------------------ Get complete, up-to-date listings of program information from URL: http://www.gatech.edu/vis95.html, http://davinci.informatik.uni-kl.de/Vis95 (active late July) FTP server: ftp.erc.msstate.edu, directory vis95, or vis95.informatik.uni-kl.de, directory info, or contact: Bill Ribarsky, Georgia Institute of Technology, 404.894.6148, bill.ribarsky@oit.gatech.edu ------------------------------------------------------------------------------ Welcome to IEEE Visualization 95 The sixth annual IEEE Visualization conference will have the strongest and most varied technical program ever. This year we will extend our focus to all aspects of data and information visualization with applications ranging across scientific, medical, engineering, business, and entertainment fields. For the first time, we will have 3 Symposia (Parallel Rendering, Information Visualization, and Biomedical Visualization). In addition you will have your pick of a full slate of tutorials on Sunday, Monday, and Tuesday. The technical program on Wednesday will begin with a Keynote Address and Panel, followed by concurrent sessions of papers, panels, and case studies presenting the latest issues, research, and applications in visualization. Demonstrations of visualization products, tools, and applications will begin mid-day on Wednesday and continue through Thursday afternoon. Birds of a Feather sessions are scheduled on several days throughout the conference. We encourage you to join us in Atlanta the week of October 30 - November 3, 1995 for IEEE Visualization 95. You will have a unique opportunity to confer with researchers, developers, and your colleagues. Dont miss this conference, or you will miss the most effective compilation of significant topics in visualization this year. Bill Ribarsky, Georgia Institute of Technology Nahum Gershon, The MITRE Corporation IEEE Visualization 95 Conference Co-Chairs ------------------------------------------------------------------------------ N N RRRRR 9999 5555 NN N R R 9 9 5 N N N RRRRR 9999 555 N N N R R 9 5 N NN R R 9 5 N N R R 9 555 THE SECOND IEEE WORKSHOP ON NETWORKED REALITIES Sheraton Boston Hotel BOSTON, MASSACHUSETTS, USA October 26-28, 1995 Cosponsored by the IEEE Communications and Computer Societies. THEME: "Emerging culture in networking" CALL FOR PAPERS NR '95 is the second international workshop addressing the technology, applications, and social, cultural, and psychological issues in joining computer-generated and computer-augmented environments with telecommunications and media technologies. Computer-generated interaction spaces in combination with real environments and communications networking creates new possibilities for the dynamic interaction of people with each other and with machines. Industrial, scientific, medical, commercial, artistic, and personal applications will be supported by a wide range of environmental "realities" generated in supercomputers, workstations, personal computers, set-top boxes, and personal wireless devices. This workshop offers a forum for presentation of views, description of applications, discussion of technical advances and obstacles, and consideration of the impacts on individuals and institutions. SUGGESTED TOPICS: - Applications such as remote robotics, visualized information spaces, medical image and therapeutic visualization, distributed educational environments, multiparty games, entertainment environments, and computer-supported cooperative working environments. [This list is far from comprehensive.] - Technologies including tools for creating shared applications, servers, displays (head mounted, screen, spatial sound) and user interfaces generally, software for multiparty interaction in computer-generated and computer-augmented environments, composition of mixed real/visualized environments. - Systems issues such as combination of real (e.g. photographic) and computer- generated environments, integration of distributed environments, cross- platform interoperability, protocols for interaction of participants (human and computer-generated), compatibility of media and computer standards. - Communication issues such as effects of network latency, setup and management of sessions, control of quality of service, internetworking of visualization applications. - Human impacts including those on interpersonal relations, the effectiveness of work and play groups, the creation of new art forms, the well being of medical patients, the nature of learning, and changes in work processes and expectations. Papers are not restricted to these topics. PAPER SUBMISSION SCHEDULE: Title and long abstract (1-3 pages) August 15, 1995 Notification of acceptance/rejection September 8, 1995 Full paper due October 1, 1995 Submissions should be made (preferably by email) to the Program Chair, or alternatively either General Co-chair at the addresses given below. REGISTRATION FEE: $345 advance registration for IEEE members including two lunches, refreshments, cocktail party $445 advance registration for non-members. WORKSHOP COMMITTEE REGISTRATION AND OTHER INFORMATION General Co-Chairs: Mrs. Judy Keller Dr. Takahiko Kamae, HP Laboratories Japan j.keller@ieee.org 3-2-2, Sakado, Takatsu-ku, Kawasaki-shi, tel: +1 212 705-8248 fax: +1 212 705-7865 Kanagawa, 213 Japan kamae@hplj.yhp.hp.com Stephen Weinstein, NEC USA Inc. C&C Laboratory 4 Independence Way Princeton, N.J. 08540, USA sbw@ccrl.nj.nec.com PROGRAM COMMITTEE Program chair: Christian Stary, Department of Information Systems Vienna University of Technology Paniglgasse 16, 1040 Vienna, AUSTRIA stary@vexpert.dbai.tuwien.ac.at Sudhir Ahuja, AT&T Bell Labs Jeff Derby, IBM, USA James Foley, Georgia Tech Thomas Furness, Univ. Washington, USA Nicolas Georganas, Univ. of Ottawa, Canada Charles Judice, Bell Atlantic, USA Fumio Kishino, ATR, Japan Andrew Lippman, MIT Media Lab, USA Carl Loeffler, Carnegie-Mellon Univ., USA Georg Michelitsch, NEC C&C Lab, USA Shuzo Morita, Fujitsu Labs, Ltd., Japan John Patterson, Lotus Development Corp., USA Peter Robinson, Univ. Cambridge, U.K. Lawrence Rowe, UC Berkeley, USA Ralph Schroeder, Brunell University, U.K. Mitsuhiro Takemura, Kyoto University of Art and Design, Japan Yoshinobu Tonomura, NTT Labs, Japan From rem-conf-request@es.net Sun Aug 06 04:17:26 1995 Received: from network2.cs.usm.my by osi-west.es.net with ESnet SMTP (PP); Sun, 6 Aug 1995 01:16:35 -0700 Received: (from khnew@localhost) by network2.cs.usm.my (8.6.9/8.6.9) id QAA04870; Sun, 6 Aug 1995 16:14:56 +0800 Date: Sun, 6 Aug 1995 16:14:54 +0800 From: New Kok Hong Subject: Re: NV on Reflector! To: George Rabatin cc: rem-conf@es.net, cu-seeme-l@cornell.edu In-Reply-To: <199508041541.LAA08823@beantown.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 4 Aug 1995, George Rabatin wrote: > You need to set the encoding from with nv to be cu-see-me. > Do this with the "encoding" pulldown menu at the top of the > window. If you don't, you get the exact message you've listed > below... Yep. It's still gives me the same mesagges although I'd select the 'cusm" encoding in the nv pulldown menu! > > Anyone out there encounter the following when running nv and connect it > > to the Cu-SeeMe reflector. > > When I run the nv-3.3b version and connect it CUSM reflector for Linux > > (Version 3.0b3) it gives me the following error? > > > > packet received through nv_ucast_sock > > NV client at 161.142.8.104 is opening a connection > > Unable to convert NV encoding for 161.142.8.104 > > deleting client > > > > The CUSM reflector was set to NV running on unicast at port 4444 with the > > following line in the reflect.conf file. > > > > NV-UV-PORT 4444 > > > > This reflector is running well if the CUSM client is connect to it. > > > > Also, it gives me the same problem by using the latest version of the > > CUSM reflector for Linux (version - 4.0b). > > > > Any idea? > > > > New Kok Hong > > khnew@network2.cs.usm.my > > http://network2.cs.usm.my/~khnew/ > > > New Kok Hong khnew@network2.cs.usm.my http://network2.cs.usm.my/~khnew/ From rem-conf-request@es.net Mon Aug 07 12:17:58 1995 Received: from prom.engin.umich.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 7 Aug 1995 09:17:32 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id MAA13274; Mon, 7 Aug 1995 12:17:27 -0400 Date: Mon, 7 Aug 1995 12:06:14 -0400 (EDT) From: "david a. schlussel" Subject: cpu time To: rem-conf@es.net, CU-SEEME Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII My reflector takes upp 91% of my CPU and no one is connected. That seems awfully high. I'm running version 4.00B1 on a sparc5 running 4.1.3_U1. I am also multicasting. I have another reflector running 4.00B1 (unicast only) on an IBM rs6000 running AIX version 3 that takes up 0% of the cpu. does this sound fishy to anyone else? +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ From rem-conf-request@es.net Mon Aug 07 21:00:01 1995 Received: from virginia.edu (actually uvaarpa.Virginia.EDU) by osi-west.es.net with ESnet SMTP (PP); Mon, 7 Aug 1995 17:59:34 -0700 Received: from server.cs.virginia.edu by uvaarpa.virginia.edu id aa21089; 7 Aug 95 20:59 EDT Received: from mamba.cs.Virginia.EDU (mamba-fo.cs.Virginia.EDU) by uvacs.cs.virginia.edu (4.1/5.1.UVA) id AA23996; Mon, 7 Aug 95 20:59:32 EDT Posted-Date: Mon, 7 Aug 1995 20:59:32 -0400 (EDT) Return-Path: Received: by mamba.cs.Virginia.EDU (5.x/SMI-2.0) id AA25805; Mon, 7 Aug 1995 20:59:32 -0400 From: act9m@server.cs.Virginia.EDU Message-Id: <9508080059.AA25805@mamba.cs.Virginia.EDU> Subject: MBONE Tools for Windows To: AVT Working Group Conference Date: Mon, 7 Aug 1995 20:59:32 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Does anyone know the status of nv, vat, and wb for the Windows platform? I remember reading about some porting a few months back. Thanks. Alan -- Alan Tai (act9m@virginia.edu) | Computer Science Dept | Computer Networks Lab Graduate Teaching Assistant | University of Virginia | From rem-conf-request@es.net Tue Aug 08 11:28:37 1995 Received: from uu7.psi.com by osi-west.es.net with ESnet SMTP (PP); Tue, 8 Aug 1995 08:28:09 -0700 Received: by uu7.psi.com (5.65b/4.0.940727-PSI/PSINet) via UUCP; id AA10934 for ; Tue, 8 Aug 95 11:16:48 -0400 Received: from mailgate1.insoft.com by insoft.com (4.1/InSoftMail-1.4) id AA17575; Tue, 8 Aug 95 11:13:39 EDT Original-Received: from cc:Mail by mailgate1.insoft.com id AA807904894 Tue, 08 Aug 95 11:01:34 EDT PP-warning: Illegal Received field on preceding line Date: Tue, 08 Aug 95 11:01:34 EDT From: es@insoft.com (Ed Skonecki) Message-Id: <9507088079.AA807904894@mailgate1.insoft.com> To: rem-conf@es.net Subject: SCO Unix Audio/Video Boards?? I am looking for information on any video and/or audio capture boards that have drivers for SCO Unix. Please respond to me directly at es@insoft.com Thank you in advance. Ed Skonecki From rem-conf-request@es.net Tue Aug 08 18:57:36 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Tue, 8 Aug 1995 15:57:09 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa19862; 8 Aug 95 16:46 EDT To: IETF-Announce:; cc: rem-conf@es.net From: The IESG Subject: Last Call: RTP payload format for H.261 video streams to Proposed Standard reply-to: iesg@IETF.CNRI.Reston.VA.US Date: Tue, 08 Aug 95 16:46:14 -0400 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9508081646.aa19862@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Audio/Video Transport Working Group to consider "RTP payload format for H.261 video streams" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by August 22, 1995. From rem-conf-request@es.net Tue Aug 08 18:59:57 1995 Received: from hplms26.hpl.hp.com by osi-west.es.net with ESnet SMTP (PP); Tue, 8 Aug 1995 15:59:23 -0700 Received: from hplabsz.hpl.hp.com by hplms26.hpl.hp.com with ESMTP ($Revision: 1.36.108.11 $/15.5+ECS 3.3+HPL1.1S) id AA214372813; Tue, 8 Aug 1995 16:00:13 -0700 Received: by hplabsz.hpl.hp.com (1.37.109.15/15.5+ECS 3.3+HPL1.1) id AA016112765; Tue, 8 Aug 1995 15:59:25 -0700 From: Laura de Leon Message-Id: <9508081559.ZM1609@hplabsz.hpl.hp.com> Date: Tue, 8 Aug 1995 15:59:25 -0700 X-Mailer: Z-Mail (3.0.0 15dec93) To: baylisa@baylisa.org, rem-conf@es.net, sage-announce@usenix.org Subject: BayLISA: Brent Chapman on Firewalls Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. BayLISA holds monthly meetings on the third Thursday of each month at 7:30 PM PST. We meet at Synopsys Building C in Mountain View, California off Highway 237 at Middlefield. This meeting will also be broadcast via MBONE. Schedule -------- August 17: Brent Chapman on firewalls Brent Chapman, manager of the "Firewalls" Internet mailing list and coauthor of the new book "Building Internet Firewalls" (O'Reilly & Associates; due out in mid-September) will be talking about current topics in building and managing Internet firewall security systems. August 20: PICNIC!!! Please join us at Sunnyvale Baylands Park at 1:00 PM for the annual BayLISA Picnic. Send mail to deleon@hpl.hp.com or blw@baylisa.org for more information. ***NOTE the date for the September meeting is the 2nd Thursday, not 3rd*** September 14: Mike Dixon, Xerox PARC Mike is speaking on Jupiter, a system for collaborative work that uses Lambda MOO and multicast technology to build "network places" (Schedule subject to revision) October 19: Chuck McManis, Sun, on Web Security For further information on BayLISA, check out our (minimal) web site: http://www.baylisa.org/ To get further information on the meeting location, you can also ftp it from ftp.baylisa.org:/BayLISA/location or you can query the BayLISA mail server by cutting and pasting the following line to your shell: echo "index baylisa" | mail majordomo@baylisa.org BayLISA makes video tapes of the meetings available to members. For more information on available videos, please send email to: video@baylisa.org For any other information, please send email to: info@baylisa.org If you have any questions, please contact me or any of the info alias listed above. From rem-conf-request@es.net Tue Aug 08 19:27:48 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Tue, 8 Aug 1995 16:27:15 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20060; 8 Aug 95 16:52 EDT To: IETF-Announce:; cc: rem-conf@es.net From: The IESG Subject: Last Call: RTP Profile for Audio and Video Conferences with Minimal Control to Proposed Standard reply-to: iesg@IETF.CNRI.Reston.VA.US Date: Tue, 08 Aug 95 16:52:54 -0400 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9508081652.aa20060@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Audio/Video Transport Working Group to consider "RTP Profile for Audio and Video Conferences with Minimal Control" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by August 22, 1995 From rem-conf-request@es.net Tue Aug 08 20:34:49 1995 Received: from eekaist.kaist.ac.kr by osi-west.es.net with ESnet SMTP (PP); Tue, 8 Aug 1995 17:34:11 -0700 Original-Received: by eekaist.kaist.ac.kr (8.6.9H1/8.6.4) id JAA15569 PP-warning: Illegal Received field on preceding line From: Byung-Cheol Shin Message-Id: <199508082335.JAA15569@eekaist.kaist.ac.kr> Subject: audio board for VME bus To: rem-conf@es.net Date: Wed, 9 Aug 1995 09:35:06 +0900 (GMT+9:00) Cc: bcshin@eekaist.kaist.ac.kr (Byung-Cheol Shin ) X-Mailer: ELM [version 2.4 PL21-h4] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 754 I am looking for 'audio board' for VME bus system for industrial applications. If no audio board for VME bus exists, some separate audio unit is also welcome if it can be connected to the VME bus-based computer through 'SCSI' interface. Thanks in advance for the informations. Shin. -------------------------------------------------------------------------- Shin, Byung-Cheol, Ph.D. | T:+82-42-869-3426(Research OFFice) Dept. of Elec. Eng. | T:+82-42-869-3402~4(Dept. Office) KAIST | T:+82-42-869-5426, 8026(Student Office) 373-1 Kusong-dong Yusong-gu | T:+82-42-861-0239(residence) Taejon, 305-701 Korea | F:+82-42-869-3410 | e.mail: bcshin@ee.kaist.ac.kr -------------------------------------------------------------------------- From rem-conf-request@es.net Wed Aug 09 17:08:59 1995 Received: from titan.iingen.unam.mx (actually 132.248.156.245) by osi-west.es.net with ESnet SMTP (PP); Wed, 9 Aug 1995 14:08:32 -0700 Received: by titan.iingen.unam.mx (940816.SGI.8.6.9/940406.SGI.AUTO) for rem-conf@es.net id PAA06115; Wed, 9 Aug 1995 15:09:38 -0600 Date: Wed, 9 Aug 1995 15:09:38 -0600 From: mbone@titan.iingen.unam.mx (Cristina Casimiro) Message-Id: <199508092109.PAA06115@titan.iingen.unam.mx> To: rem-conf@es.net Hi, We have sent several msg asking for a feed to joining to the MBONE. Our network provider is ANS, we have seen that they can provide this feed. We are going to use a SUN SPARCClassic as the mroute, the videoconferencing tools are up-and-running. Could it be possible that somebody give us a pointer to get the feed ? Thanks in advance Cristina Casimiro Coordinacion de Sistemas de Computo Instituto de Ingenieria - UNAM Phone (525)6 22 80 92 Fax (525)6 22 80 91 From rem-conf-request@es.net Wed Aug 09 17:49:03 1995 Received: from duke.poly.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 9 Aug 1995 14:48:13 -0700 Received: from rama.poly.edu by duke.poly.edu (8.6.9/1.34-032891-Polytechnic University) id RAA15044; Wed, 9 Aug 1995 17:46:02 -0400 Received: by rama.poly.edu (4.1/SMI-4.1) id AA24488; Wed, 9 Aug 95 17:49:53 EDT Date: Wed, 9 Aug 1995 17:49:53 -0400 (EDT) From: Charlie To: Cristina Casimiro Cc: rem-conf@es.net Subject: Re: your mail In-Reply-To: <199508092109.PAA06115@titan.iingen.unam.mx> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 9 Aug 1995, Cristina Casimiro wrote: > We are going to use a SUN SPARCClassic as the mroute, the > videoconferencing tools are up-and-running. > Could it be possible that somebody give us a pointer to get > the feed ? We've got the same sort of problem... I just got everything going here at our site... We're using a Sun Sparcstation 10... Everything's set, I just need to get someone to give us a feed... Can anyone help me figure out the process...?? alex... From rem-conf-request@es.net Wed Aug 09 19:38:50 1995 Received: from bnr.ca (actually x400gate.bnr.ca) by osi-west.es.net with ESnet SMTP (PP); Wed, 9 Aug 1995 16:38:06 -0700 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 9 Aug 1995 18:32:43 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 9 Aug 1995 15:37:15 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 9 Aug 1995 15:36:00 -0400 Date: Wed, 9 Aug 1995 15:36:00 -0400 X400-Originator: /dd.id=1683277/g=bhumip/i=b/s=khasnabish/@bnr.ca To: Original-To: :; PP-Warning: Parse error in original version of preceding To line X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.183:09.07.95.19.37.15] X400-Content-Type: P2-1984 (2) Content-Identifier: CFP (text fil... From: "bhumip (b.) khasnabish" Sender: "bhumip (b.) khasnabish" Message-ID: <"7186 Wed Aug 9 15:37:25 1995"@bnr.ca> Subject: CFP (text file): Sp. Issue of ACM Wireless Networks Journal X-Bulletin: Potential Contributors |------------------------------------------------------------------------| | You are hereby invited to submit a contribution. | | | | Also please distribute the CFP among your peers and colleagues. Thanx. | |------------------------------------------------------------------------| Call for Papers ACM Wireless Networks Journal (in co-operation with Baltzer Science Publishers) Special Topics Issue on "Enterprise Networking - the Wireless Segment(s)" A special issue of the Journal of Wireless Networks is being planned to address the issue dealing with various aspects of the wireless segment of Enterprise Networks (ENs). Starting with the status of current ENs which support both wireless and mobile computing and communications, it will present the trends for evolution to ENs whose segments can support cellular packet data, voice, video and still picture and images for QOS-specific, reliable, high-performance storage, computing and communications over a wide area to give eye and ear the geographical proximity needed to satisfy most of the criteria of face-to-face meetings, discussions, and negotiations. Topics of interests include but are not limited to: - Wireless LAN Emulation versus IP over Wireless ATM Channel, - Bandwidth consolidation over mobile and wireless channel of ENs, - Reports on Experience and Experiments with Wireless segments of ENs, - ATM and non-ATM services interworking over Wireless segments of ENs. - Coding and compression mechanisms to meet the QOSs demanded by services. All papers should include considerations of the effects of accommodating highly reliable multiprotocol interconnects for high-bandwidth packet/ cell transmission over mobile and wireless segments of the ENs. We are particularly interested to see how technological discontinuities (narrow-band or broadband wireless ISDN to MPI, ATM, etc.) are handled in the evolution of the wireless segment of the ENs. The main idea is to see how wireless multimedia computing and communications are evolving in enterprise-wide environments where currently there exists physically separate wired and wireless networks for voice, data, and video communications and computing. The following schedule will be followed: Papers submission deadline:... January 15, 1996 Notification of acceptance:... March 26, 1996 Final revised manuscript due:. May 15, 1996 Publication date:............. 4-th Quarter, 1996 All contributions (the size of a contribution should not exceed 20 double spaced pages, excluding figures and diagrams) will be reviewed according to the policy of the editorial board of the ACM Wireless Networks journal. No fax submission will be accepted. Complete manuscript may be submitted to any one of the guest editors: Bhumip Khasnabish Hamid Ahmadi Bell-Northern Research Ltd., IBM Research 3500 Carling Avenue, T. J. Watson Research Cente P. O. Box: 3511, Station C, Room H3-C04, P. O. BOX 704 Ottawa, Ontario, Canada, K1Y 4H7. Yorktown Height, NY, 10598 Tel: +1 613 763 2698 Tel: +1 914 784 7219 Fax: +1 613 763 2626 Fax: +1 914 784 6208 Email: bhumip@bnr.ca E-mail: hamid@watson.ibm.com ======================================================================= From rem-conf-request@es.net Thu Aug 10 20:30:57 1995 Received: from inet-gw-2.pa.dec.com by osi-west.es.net with ESnet SMTP (PP); Thu, 10 Aug 1995 17:30:22 -0700 Received: from bigpink.pa.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA29165; Thu, 10 Aug 95 17:24:32 -0700 Received: by bigpink.pa.dec.com; id AA01208; Thu, 10 Aug 1995 17:24:40 -0700 Message-Id: <9508110024.AA01208@bigpink.pa.dec.com> To: rem-conf@es.net, mbone@isi.edu Cc: bagnet@george.lbl.gov, berc@pa.dec.com, templin@pa.dec.com, ajay@zk3.dec.com Subject: *Alpha version* Pruning Multicast for Digital Unix 3.2 Date: Thu, 10 Aug 95 17:24:40 -0700 From: berc@pa.dec.com X-Mts: smtp We're making an *alpha* kit of pruning IP-multicast code for Digital Unix 3.2 available for those who would like to help test it. The kit replaces several .o files and has binaries for several IP multicast tools (mrouted-3.6, mrinfo, etc.). You can't run the new mrouted without the kernel modifications. Although we think it works, Digital makes no warrantees against damage or loss due to bugs, fire, flood, acts of God, or Severe Tire Damage MCasts. The kit is available at: http://chocolate.research.digital.com/mbone/ipm35_decosf_v32.tar.Z Please send any comments to Ajay Kacharni, ajay@zk3.dec.com. lance Lance M Berc Systems Research Center Digital Equipment Corporation berc@src.dec.com From rem-conf-request@es.net Fri Aug 11 00:48:15 1995 Received: from morinda.cs.ntu.edu.au by osi-west.es.net with ESnet SMTP (PP); Thu, 10 Aug 1995 21:47:33 -0700 Received: (from malcolm@localhost) by morinda.cs.ntu.edu.au (8.6.10/8.6.6) id OAA08677 for rem-conf@es.net; Fri, 11 Aug 1995 14:17:12 +0930 From: Malcolm Caldwell Message-Id: <199508110447.OAA08677@morinda.cs.ntu.edu.au> Subject: PC version of VAT To: rem-conf@es.net Date: Fri, 11 Aug 1995 14:17:11 +0930 (CST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 458 I remember reading here that there is a PC version of vat available, that can use multicast with certain TCP stacks on the PC. Can anyone tell me where this version of vat is, and what stacks support multicast. -- Malcolm Caldwell - Network Supervisor Email:malcolm@it.ntu.edu.au Information Technology Support Ph: +61 89 466631 Northern Territory University,Darwin Fax: +61 89 466630 CASUARINA 0909 Australia From rem-conf-request@es.net Fri Aug 11 11:23:18 1995 Received: from ccpntc1.in2p3.fr by osi-west.es.net with ESnet SMTP (PP); Fri, 11 Aug 1995 08:22:51 -0700 Received: by ccpntc1.in2p3.fr with SMTP (1.37.109.16/16.2) id AA151614566; Fri, 11 Aug 1995 17:22:46 +0200 X-Mailer: exmh version 1.5.3 12/28/94 To: rem-conf@es.net X-Uri: URL:http://ccpnws.in2p3.fr/cgi-bin/annuaire?val=bernier&srv=Telecom Subject: IN2P3 Mbone broadcast: CERN School of Computing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Aug 1995 17:22:45 +0200 From: Jerome Bernier IN2P3 is pleased to announce the broadcast of the CERN SCHOOL OF COMPUTING ------------------------ From the 21th of August to the 2nd of September ---------------------------------------------- between 09:00 a.m. and 1:00 p.m. French Time (GMT+2) (i.e. 07:00 and 11:00 a.m.) and between 05:30 and 07:30 p.m. (GMT+2) Monday, 21 August 09.00-10.00 Opening H. Curien, President of CERN Council 10.00-11.00 Collaborative Software Engineering D.R. Quarrie 11.30-12.30 Human Computer Interfaces J. Gallop 14.30-15.30 Information Superhighways W. Bauerfeld 15.30-16.30 Parallel Architectures (MPP) R. Groves Tuesday, 22 August 09.00-10.00 Human Computer Interfaces J. Gallop 10.00-11.00 Collaborative Software Engineering J.-M. LeGoff 11.30-12.30 Human Computer Interfaces J. Gallop 17.30-18.30 Information Superhighways W. Bauerfeld 18.30-19.30 Parallel Architectures (MPP) D. Walker Wednesday, 23 August 09.00-10.00 Collaborative Software Engineering J.-M. Le Goff 10.00-11.00 Human Computer Interfaces J. Gallop 11.30-12.30 Collaborative Software Engineering RD Schaffer 17.30-18.30 Information Superhighways B. De Roure 18.30-19.30 Parallel Architectures (MPP) D. Walker Thursday, 24 August 09.00-10.00 Information Superhighways B. De Roure 10.00-11.00 Human Computer Interfaces H. Drevermann 11.30-12.30 Collaborative Software Engineering R. Jones 17.30-18.30 Information Superhighways D. De Roure 18.30-19.30 Parallel Architectures (MPP) R. Walker Friday, 25 August 09.00-10.00 Collaborative Software Engineering R. Jones 10.00-11.00 Human Computer Interfaces H. Drevermann 11.30-12.30 Collaborative Software Engineering D.R. Quarrie 17.30-18.30 WorldWideWeb for Physics H. Lie 18.30-19.30 Parallel Architectures (MPP) R. Walker Saturday, 26 August 09.00-10.00 WorldWideWeb for Physics B. Rousseau 10.00-11.00 Collaborative Software Enginering D.R. Quarrie 11.30-12.30 WorldWideWeb for Physics M. Donszelmann Monday, 28 August 09.00-10.00 Data Acquisition Systems M. Letheren 10.00-11.00 WorldWideWeb for Physics B. Rousseau 11.30-12.30 Human Computer Interfaces S. de Gennaro 17.30-18.30 Mathematical Computing M. Trott 18.30-19.30 Human Computer Interfaces S. De Gennaro Tuesday, 29 August 09.00-10.00 Data Acquisition Systems M. Letheren 10.00-11.00 WorldWideWeb for Physics M. Donszelmann 11.30-12.30 Trends in Computer Architecture/Industry T. Engbersen 17.30-18.30 Mathematical Computing M. Trott Wednesday, 30 August 09.00-10.00 Data Acquisition Systems M. Letheren 10.00-11.00 Mathematical Computing M. Trott 11.30-12.30 Trends in Computer Architecture/Industry T. Engbersen Thursday, 31 August 09.00-10.00 Data Acquisition Systems M. Haney 10.00-11.00 Mathematical Computing R. Barlow 11.30-12.30 Trends in Computer Architecture/Industry C. Maillot 17.30-18.30 Trends in Computer Architecture/Industry M. Metcalf Friday, 1 September 09.00-10.00 Data Acquisition Systems M. Haney 10.00-11.00 Mathematical Computing R. Barlow 11.30-12.30 Trends in Computer Architecture/Industry M. Metcalf 17.30-18.30 Parallel Architectures (MPP) M. Chesney 19.30 Banquet More detailed information is available at URL: http://www.cern.ch/Physics/Conferences/C1995/CSC/ The sessions will be announced in sd with a ttl of 127. Vat will be used for audio and nv (128kbps) will be used for video. Please inform us if this broadcast may interfere with other sessions. Francois Etienne Jerome Bernier Emergency telephone during session: +33 78 93 08 80 From rem-conf-request@es.net Fri Aug 11 11:57:26 1995 Received: from viipuri.nersc.gov by osi-east.es.net with ESnet SMTP (PP); Fri, 11 Aug 1995 08:56:53 -0700 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA22904; Fri, 11 Aug 95 08:56:52 PDT Date: Fri, 11 Aug 95 08:56:52 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9508111556.AA22904@viipuri.nersc.gov> To: rem-conf@es.net Subject: Death of MBONE predicted: StreamWorks form Xing Technology Recalling Progressive's RealAudio audio-stream-on-demand announcements earlier this year, I was surprised by an article announcing that EZ Communications subsidiary RadiaDataGroup intends to begin broadcasting "live audio on the Internet's World Wide Web later this month." According to Michael Rau, president of Radio Data Group, commercial service is to begin 8/19 from station KMPS in Seattle. However, instead of using RealAudio, Progressive Networks' product, "...EZ Communications will be the first commercial broadcast company using Xing Technology's StreamWorks software, which delivers live audio, and video, to personal computers via the Internet. The software is based on the MPEG (Motion Picture Experts Group) standard and includes the same audio compression employed in many digital audio broadcasting applications. "The operation of the Xing software is very simple, much like the operation of a radio receiver," says Rau. "When a hypertext link is structured, the radio station program is instantly available and is the same program material that is being broadcast at the time. It is not an audio file that needs to be downloaded, or otherwise manipulated in any way." ... "Xing's listener software can be downloaded from the California company's Web site, at http://www.xingtech.com . The client software, when registered for $29, includes full technical support. It is available for Windows and Unix/X-windows. The company says a Macintosh client will be available later this year. While the Xing Technology software offers radio stations the ability to send their programming to the Web, it also offers the possibility of nearly anyone becoming a radio or television broadcaster. In addition to the client software, Xing offers server software at a cost of $3,500 to $6,500. "With this system, virtually anyone can become an audio or << X-Mailer: exmh version 1.6.2 7/18/95 To: ari@es.net (Ari Ollikainen) cc: rem-conf@es.net Subject: Re: Death of MBONE predicted: StreamWorks form Xing Technology In-reply-to: Your message of "Fri, 11 Aug 1995 08:56:52 PDT." <9508111556.AA22904@viipuri.nersc.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Aug 1995 11:18:10 -0700 From: "Amancio Hasty Jr." >>> Ari Ollikainen said: > > Recalling Progressive's RealAudio audio-stream-on-demand announcements > earlier this year, I was surprised by an article announcing that > EZ Communications subsidiary RadiaDataGroup intends to begin > broadcasting "live audio on the Internet's World Wide Web later this > month." Hmmm... Does streamworks use ip multicasting or unicast ip? Amancio From rem-conf-request@es.net Fri Aug 11 14:51:50 1995 Received: from aimnet.com (actually aimnet.aimnet.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 11 Aug 1995 11:51:15 -0700 Received: from [204.118.88.57] (dial-cup2-14.iway.aimnet.com [204.118.88.44]) by aimnet.com (8.6.12/8.6.12) with SMTP id LAA22045; Fri, 11 Aug 1995 11:50:54 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 11 Aug 1995 11:51:14 -0700 To: ari@es.net (Ari Ollikainen) From: Dave Crocker Subject: Re: Death of MBONE predicted: StreamWorks form Xing Technology Cc: rem-conf@es.net At 8:56 AM 8/11/95, Ari Ollikainen wrote: > the operation of a radio receiver," says Rau. "When a hypertext > link is structured, the radio station program is instantly well, THIS is gonna be pretty awful. One stream per user. Great. Just great. It won't be the death of the mbone. It'll be the death of the Internet. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From rem-conf-request@es.net Sun Aug 13 07:50:34 1995 Received: from ocfmail.ocf.llnl.gov by osi-west.es.net with ESnet SMTP (PP); Sun, 13 Aug 1995 04:49:57 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA08189; Sun, 13 Aug 95 04:49:49 PDT Message-Id: <9508131149.AA08189@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Aug 1995 04:49:51 -0700 To: rem-conf@es.net From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: R.e. Death of MBONE predicted: StreamWorks form Xing Technology Cc: Howard Gordon Since we haven't heard from Xing directly in responce to this concern (?), I thought I would ask them about it. Here is the salient part of the query that I sent out: _______________________________________________________________ >To: streams@xingtech.com >From: jed@llnl.gov (James E. [Jed] Donnelley) >Subject: Xing Technology is listed >I have read your press announcement and some of the other material >on your WWW site. I don't understand how you can >deliver on what you suggest in your press release: http://www.xingtech.com/products/xdma/press_release.html (for example: Because StreamWorks is transparently integrated with the World-Wide Web, Internet surfers will be able to access audio and video in real-time, using their existing browser. For example, a NetScape user can listen to an Internet radio station by simply selecting StreamWorks enabled Web sites via their browser. Equally, StreamWorks delivers video to a HTML-browser within standard viewing screens. All that is required is that StreamWorks client software to be installed on the user's workstation. ) >IP multicast, still >based as it is largely on the MBone system of Unix routers over >"tunnels" spanning parts of the Internet, is not capable of handling >the sort of service that you are describing - in my opinion. Loss >rates on the current MBone are often horrendous for a variety of >reasons. Not the least of these reasons is the rapid expansion of >multicasters that have little knowledge of the MBone and its >limitations, or are not inclined to participate in the experimental >and colleageal sharing of limited bandwidth that is currently >available. > >It appears to me that if you proceed with your efforts to put >more multicasting users onto IP multicast with little understanding >of the its current limitations, you will disappoint your clients and >outrage the other MBone users - who are a substantial fraction of >the influential Internet users. Not a good way to make friends >and influence people. ___________________________________________________________ The responce from Howard Gordon at Xing Technology was: ___________________________________________________________ We need to clarify our literature. We are using IP-multicast for delivery of the NBC and Reuters feeds over MFS's ATM backbone as well as on LAN's, but we are not using IP-multicast for fanout from our servers to the Internet. However, we have a nice scheme which allows any of our servers to act as clients to a fanout process, effectively allowing us to propagate feeds geometrically without requiring tunneling. Clearly, we need to communicate how this will work in our literature. Howard Gordon hgordon@xingtech.com ___________________________________________________________ What I understand from this is that they are only using IP-multicast on isolated networks that can handle the load. However, I don't understand the implications of the "nice scheme" that he describes. I would expect that the consequences of this scheme would depend strongly on how many of their servers get out onto the Internet. It doesn't sound to me like it has the "one transmission" per line quality of a properly configured Multicast transmission scheme. Perhaps Mr. Gordon can clarify this when he clarifies his literature on the Web: http://www.xingtech.com/ It would also seem that whatever representation Xing has on rem-conf didn't pick up this direct reference to their company (or didn't respond to the list). It would seem to me that if they are using IP multicast (even on restricted networks) and particularly if they are sending multimedia out on Internet, it would be a good idea for someone at Xing to monitor this (rem-conf and? mbone) list. Of course, this might just be a matter of timing. Many of us are concerned about the consequences of loading the Internet with multimedia - particularly if it is not effectively put out on the network (e.g. improperly "multicast"). It sounds like Xing is one more example area of concern. However, it appears more of a general Internet concern than a specific MBone concern at this point. The message from Mr. Gordon also contained: _____________________________________________________________ Welcome to the StreamWorks Test Program You'll find StreamWorks product information, pricing and press release information from links on http://www.xingtech.com/. Internet testers: http://www.xingtech.com user name: xdma password: xing123 if firewall - punch a hole for UDP traffic in both directions on Port 1558 (our IP=204.62.160.253) Please send problem reports to streams@xingtech.com Thank you for helping us test the Internet's first live and on-demand MPEG video / audio server. Howard Gordon Xing Technology _____________________________________________________________ I don't know about "Death of the MBone", but I am certainly concerned about the future of the Internet. In my message that Mr. Gordon responded to I also noted: ____________________________ I hope that we are soon able to reach a state of Internet where people can multicast multimedia onto the Internet in a relatively unconstrained way. I don't know how to get there from here. Additional bandwidth will certainly help. The rapid expansion of Internet users is not really doing much to help this situation. Certainly the available bandwidth is increasing, but so is the number of users sharing it. The net effect seems to me to be less bandwidth available per average user. On the other hand there are communication technologies waiting in the wings such as wavelength division multiplexing that have the potential to provide tremendous increases in available bandwidth (e.g. ~10 tbits/sec/fiber). I am not sure that swamping the currently available Internet IP multicast will get us to higher available Internet bandwidth, but it might. It is an interesting position that you (Xing) are in. ____________________________ I guess it is an interesting position that we are all in. I don't find it comfortable. It seems clear that some combination of higher available bandwidth and/or some effective sort of constraint (cost, convenience, etc.) is going to be needed to keep (or make?) the Internet effective at service delivery. I don't believe that increasing the backbone to OC3 rates is going to solve the problem for long without some other sort of help. I hope I am wrong about this, however, because I don't see much help from other quarters at this point. --Jed http://www-atp.llnl.gov/atp/jed-signature.html From rem-conf-request@es.net Sun Aug 13 09:09:11 1995 Received: from video.xingtech.com by osi-west.es.net with ESnet SMTP (PP); Sun, 13 Aug 1995 06:08:45 -0700 Received: by video.xingtech.com id AA07574 (5.67b/IDA-1.5 for ); Sun, 13 Aug 1995 06:04:57 -0700 Received: from system.xingtech.com(204.62.160.92) by video.xingtech.com via smap (V1.3) id sma007572; Sun Aug 13 06:04:36 1995 Received: by xingtech.com id AA06212 (5.67b/IDA-1.5); Sun, 13 Aug 1995 06:17:32 -0700 Date: Sun, 13 Aug 1995 06:17:31 -0700 (PDT) From: Howard Gordon To: jed@llnl.gov Cc: rem-conf@es.net Subject: R.e. Death of MBONE predicted: StreamWorks from Xing Technology In-Reply-To: <9508131149.AA08189@ocfmail.ocf.llnl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > What I understand from this is that they are only using IP-multicast > on isolated networks that can handle the load. that is correct > However, I don't understand the implications of the "nice > scheme" that he describes. I would expect that the consequences > of this scheme would depend strongly on how many of their > servers get out onto the Internet. It doesn't sound to me > like it has the "one transmission" per line quality of a properly > configured Multicast transmission scheme. Perhaps Mr. Gordon > can clarify this when he clarifies his literature on the Web: I didn't intend to obfuscate - the "nice scheme" is simply that we have the ability to propagate streams through a device called a "fanout process", and any fanout process can be the client of any other fanout process. You're 100% correct that our ability to keep traffic off the backbone depends on our ability to deploy servers through ISP networks, and we're aggressively pursuing this. > It would also seem that whatever representation Xing has > on rem-conf didn't pick up this direct reference to their company > (or didn't respond to the list). I personally have monitored rem-conf in the past, but found the volume of messages vs. the relevance of the content to our application unmanagable. If an unduplicated copy of each relevant message was forwarded to me, I would do my best to respond. > Many of us are concerned about the consequences of loading > the Internet with multimedia - particularly if it is not effectively > put out on the network (e.g. improperly "multicast"). It sounds > like Xing is one more example area of concern. However, it appears > more of a general Internet concern than a specific MBone concern > at this point. While I understand the concern, we are doing our best to minimize the loading impact of Internet multimedia by focusing on minimizing backbone traffic and delivering relatively efficient streams (the majority are in the range of 8-24kbps). Long term, we have a viable business only if the content we enable can actually reach its intended audience. > I guess it is an interesting position that we are all in. I > don't find it comfortable. It seems clear that some combination > of higher available bandwidth and/or some effective sort of > constraint (cost, convenience, etc.) is going to be needed to > keep (or make?) the Internet effective at service delivery. I don't > believe that increasing the backbone to OC3 rates is going to solve > the problem for long without some other sort of help. > I hope I am wrong about this, however, because I don't see > much help from other quarters at this point. I think, at least for the content we're generating, you'll see us moving many of our originating streams off the "public Internet" and onto "private internets" as (or before) quality of service begins to degrade. You can be assured (as some form of natural law) that general Internet traffic will eventually expand to fill any channel, but this is a self limiting process. Howard Gordon Xing Technology hgordon@xingtech.com From rem-conf-request@es.net Sun Aug 13 13:23:55 1995 Received: from aimnet.com (actually aimnet.aimnet.com) by osi-west.es.net with ESnet SMTP (PP); Sun, 13 Aug 1995 10:23:29 -0700 Received: from [204.118.88.44] (dial-cup2-6.iway.aimnet.com [204.118.88.36]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA01457; Sun, 13 Aug 1995 10:23:09 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Aug 1995 10:23:27 -0700 To: jed@llnl.gov (James E. [Jed] Donnelley) From: Dave Crocker Subject: Re: R.e. Death of MBONE predicted: StreamWorks form Xing Technology Cc: rem-conf@es.net, Howard Gordon At 4:49 AM 8/13/95, James E. [Jed] Donnelley wrote: >but we are not using IP-multicast for fanout from our servers to the here 'tis folks. presumably they will, of course, use one-per-user, connection-based TCP so that the real-time traffic will be delivered in a nice, retransmitted, reliable fashion, never mind the congestion explosion that will result (or the lousy user service.) d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From rem-conf-request@es.net Sun Aug 13 15:11:16 1995 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Sun, 13 Aug 1995 12:10:49 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with ESMTP id MAA11124; Sun, 13 Aug 1995 12:09:26 -0700 Message-Id: <199508131909.MAA11124@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Howard Gordon cc: jed@llnl.gov, rem-conf@es.net Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology In-reply-to: Your message of "Sun, 13 Aug 1995 06:17:31 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Aug 1995 12:09:25 -0700 From: "Amancio Hasty Jr." >>> Howard Gordon said: > > I didn't intend to obfuscate - the "nice scheme" is simply that we have > the ability to propagate streams through a device called a "fanout > process", and any fanout process can be the client of any other fanout > process. You're 100% correct that our ability to keep traffic off the > backbone depends on our ability to deploy servers through ISP networks, > and we're aggressively pursuing this. Curious why are you not using mrouted? Are your protocol specifications available? Why? Well, I run Freebsd and I tend to write my own software or drivers if need be . We now have hardware mpeg support for the Talisman mpeg playback board and it will be nice if could playback your streamworks. As for the Death of the MBone, I would be more concern about individuals generating massive amount of traffic as the technology of IP Multicast, greater and higher speed connectivity with the Net, video/sound is more understood by general programmers and the ip or ip-multicast apps become more wide-spread. Amancio From rem-conf-request@es.net Sun Aug 13 16:21:36 1995 Received: from mailhost.lut.ac.uk (actually bgate.lut.ac.uk) by osi-west.es.net with ESnet SMTP (PP); Sun, 13 Aug 1995 13:20:59 -0700 Received: (jon@localhost) by weeble.lut.ac.uk (8.6.12/8.6.9) id PAA05637; Sun, 13 Aug 1995 15:55:30 +0100 Date: Sun, 13 Aug 1995 15:55:30 +0100 (BST) From: Jon Knight To: Howard Gordon cc: jed@llnl.gov, rem-conf@es.net Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 13 Aug 1995, Howard Gordon wrote: > You're 100% correct that our ability to keep traffic off the > backbone depends on our ability to deploy servers through ISP networks, > and we're aggressively pursuing this. You might not have seen this if you've not been reading the rem-conf and mbone mailing lists recently, but quite a few commercial ISPs seem in favour of banning (or at least heavily restricting the use of) Internet based audio and video streams. Looks like there's going to be an interesting commercial fight coming up. Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Researcher, Sysop and General Dogsbody, Department of Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. *** Nothing looks so like a man of sense as a fool who holds his tongue *** From rem-conf-request@es.net Mon Aug 14 04:50:22 1995 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 14 Aug 1995 01:49:43 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 14 Aug 1995 09:49:16 +0100 To: Jon Knight cc: Howard Gordon , jed@llnl.gov, rem-conf@es.net Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology In-reply-to: Your message of "Sun, 13 Aug 95 15:55:30 BST." Date: Mon, 14 Aug 95 09:49:13 +0100 Message-ID: <744.808390153@cs.ucl.ac.uk> From: Jon Crowcroft >On Sun, 13 Aug 1995, Howard Gordon wrote: >> You're 100% correct that our ability to keep traffic off the >> backbone depends on our ability to deploy servers through ISP networks, >> and we're aggressively pursuing this. >You might not have seen this if you've not been reading the rem-conf and >mbone mailing lists recently, but quite a few commercial ISPs seem in >favour of banning (or at least heavily restricting the use of) Internet >based audio and video streams. Looks like there's going to be an >interesting commercial fight coming up. yes - the problem is to do with the very nature of "end to end" services the providers bill people for being connected, but dimensio nthe net on the basis of typical TCP senders.... video/audio senders would like to bill users on the basis of what they provide, and then have some quid pro quo with the net provider ....ratehr than have any per transmission fee (check out pay per view tv, it works and the bandwidth they use totally dwarfs the internet)... the problem is that til we have authenticated RSVP, you cannot make this change in the fundamental model of billing/usage.... what you can do is have a "commons" of multimedia, where greatest-good-for greatest-possible-number type mbone events are the only ones we tolerate..... luckily (glad to see) Xing have said they appreciate this, and that they will move onto private Internets where the billing model is, errr, different.... the other thing is that if the net provider is _also_ the mbone router or CUSeeMe reflector, or Xing fanout/server provider, then they _can_ engineer the network and the traffic for each other.... gee, what fun....politics, economics and queueing theory #101 jon From rem-conf-request@es.net Mon Aug 14 15:08:55 1995 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Mon, 14 Aug 1995 12:08:22 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15137(5)>; Mon, 14 Aug 1995 12:07:56 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Mon, 14 Aug 1995 12:07:37 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: Howard Gordon cc: jed@llnl.gov, rem-conf@es.net Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology In-reply-to: Your message of "Sun, 13 Aug 95 06:17:31 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Aug 1995 12:07:35 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Aug14.120737pdt.177475@crevenia.parc.xerox.com> In message you wr ite: >I didn't intend to obfuscate - the "nice scheme" is simply that we have >the ability to propagate streams through a device called a "fanout >process", and any fanout process can be the client of any other fanout >process. You're 100% correct that our ability to keep traffic off the >backbone depends on our ability to deploy servers through ISP networks, >and we're aggressively pursuing this. So, essentially, you need to engineer your network of servers in exactly the same way as the MBONE needs to be engineered, except that the MBONE works for any traffic and your fanout servers only work for your service. Why not expend the same amount of effort on engineering the MBONE, instead of wasting it building a parallel structure? Bill From rem-conf-request@es.net Mon Aug 14 16:04:44 1995 Received: from video.xingtech.com by osi-west.es.net with ESnet SMTP (PP); Mon, 14 Aug 1995 13:04:10 -0700 Received: by video.xingtech.com id AA24979 (5.67b/IDA-1.5 for ); Mon, 14 Aug 1995 13:00:37 -0700 Received: from system.xingtech.com(204.62.160.92) by video.xingtech.com via smap (V1.3) id sma024977; Mon Aug 14 13:00:15 1995 Received: by xingtech.com id AA12588 (5.67b/IDA-1.5); Mon, 14 Aug 1995 13:13:18 -0700 Date: Mon, 14 Aug 1995 13:13:16 -0700 (PDT) From: Howard Gordon To: Bill Fenner Cc: jed@llnl.gov, rem-conf@es.net Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology In-Reply-To: <95Aug14.120737pdt.177475@crevenia.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > So, essentially, you need to engineer your network of servers in exactly the > same way as the MBONE needs to be engineered, except that the MBONE works for > any traffic and your fanout servers only work for your service. > > Why not expend the same amount of effort on engineering the MBONE, instead of > wasting it building a parallel structure? because: 1. most users don't have mbone access 2. the mbone routers don't give use store&forward, on-the-fly bitrate reduction and stream accounting we did originally consider this as an option Howard From rem-conf-request@es.net Mon Aug 14 17:35:12 1995 Received: from ocfmail.ocf.llnl.gov by osi-west.es.net with ESnet SMTP (PP); Mon, 14 Aug 1995 14:34:38 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA19705; Mon, 14 Aug 95 14:32:27 PDT Message-Id: <9508142132.AA19705@ocfmail.ocf.llnl.gov> X-Sender: jed@ocfmail.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Aug 1995 14:32:29 -0700 To: Howard Gordon From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: More Xing and MBone discussion - Fenner's concern. Cc: rem-conf@es.net >> So, essentially, you need to engineer your network of servers in exactly the >> same way as the MBONE needs to be engineered, except that the MBONE works >>for >> any traffic and your fanout servers only work for your service. >> >> Why not expend the same amount of effort on engineering the MBONE, instead >>of >> wasting it building a parallel structure? > >because: > >1. most users don't have mbone access >2. the mbone routers don't give use store&forward, on-the-fly bitrate > reduction and stream accounting > >we did originally consider this as an option > >Howard I share Bill Fenner's concern. When you say (#1) that most users don't have MBone access - while this is certainly true, it is also true that most users don't have access to your system of servers. I would guess that more people have access to MBone than to your servers at this point. Until a few years ago most "users" didn't have Internet access (probably they still don't ;-). If multicast is useful, it seems to me that we want to work toward the day when "everyone" has access to it. I believe that it is useful, so I hope we can spend our energies making general multicast available to more users. I don't know exactly what you mean by your comment in #2. At a high level I would say that if these features are important, then let's make them available to everyone that uses IP multicast or "stream" services on top of it. The fundamental concern that I believe I share with Bill Fenner is that there is a fair amount of rather tedious and somewhat awkward engineering to put the MBone together, keep it together, and keep it reasonably optimal. Dealing with these same engineering issues again in an essentially parallel network also layered on Internet doesn't seem wise to me. I can understand that it may be much simplier to add some features to software that you are distributing anyway to build multicast capability as a byproduct of that distribution rather than to have to deal with connection to the MBone to make this aspect of your product useful.. I believe that in the longer run, however, this approach will not work out well. I believe that particularly if you consider the trend toward multicast capable router deployment (e.g. the Cisco work), cutting yourself off from that capability is unwise. --Jed http://www-atp.llnl.gov/atp/jed-signature.html From rem-conf-request@es.net Mon Aug 14 19:11:15 1995 Received: from video.xingtech.com by osi-west.es.net with ESnet SMTP (PP); Mon, 14 Aug 1995 16:10:47 -0700 Received: by video.xingtech.com id AA28699 (5.67b/IDA-1.5 for ); Mon, 14 Aug 1995 16:07:18 -0700 Received: from system.xingtech.com(204.62.160.92) by video.xingtech.com via smap (V1.3) id sma028694; Mon Aug 14 16:07:08 1995 Received: by xingtech.com id AA13895 (5.67b/IDA-1.5); Mon, 14 Aug 1995 16:20:13 -0700 Date: Mon, 14 Aug 1995 16:20:12 -0700 (PDT) From: Howard Gordon To: jed@llnl.gov Cc: rem-conf@es.net Subject: Re: More Xing and MBone discussion - Fenner's concern. In-Reply-To: <9508142132.AA19705@ocfmail.ocf.llnl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I can understand that it may be much simplier to add some features > to software that you are distributing anyway to build multicast capability > as a byproduct of that distribution rather than to have to deal with connection > to the MBone to make this aspect of your product useful.. I believe that in > the longer run, however, this approach will not work out well. I believe that > particularly if you consider the trend toward multicast capable router > deployment (e.g. the Cisco work), cutting yourself off from that capability > is unwise. I think what you're asking is whether we'll support MBONE instead of (or in addition to) building a parallel network. It's a very good question, and I'll give an unqualified answer - we'll gladly support MBONE. StreamWorks started out as a 100% multicast network, our NBC and Reuters content is still distributed using IP-multicast, and we only built alternatives because we didn't see the practicality of using it for commercial distribution of content. I can't see any reason why we can't work to redirect some of the streams our products generate to MBONE. We're already compensated for enabling the broadcasters, and they're likely to be pleased to reach a broader audience. Tell us what you want to do. Howard hgordon@xingtech.com From rem-conf-request@es.net Tue Aug 15 13:35:54 1995 Received: from davinci.gmu.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 15 Aug 1995 10:35:26 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id NAA15029; Tue, 15 Aug 1995 13:34:47 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199508151734.NAA15029@davinci.gmu.edu> Subject: Re: More Xing and MBone discussion - Fenner's concern. To: hgordon@system.xingtech.com (Howard Gordon) Date: Tue, 15 Aug 1995 13:34:47 -0400 (EDT) Cc: jed@llnl.gov, rem-conf@es.net In-Reply-To: from "Howard Gordon" at Aug 14, 95 04:20:12 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1852 Am I missing something here? To be it sounds like a like of duplication of work in order to be able to own the method for deployment. Surely the designers of the mbone network missed so much at the engineering level that their work had to be put to the side in favor of a completely new effort? Michael > > > > I can understand that it may be much simplier to add some features > > to software that you are distributing anyway to build multicast capability > > as a byproduct of that distribution rather than to have to deal with connection > > to the MBone to make this aspect of your product useful.. I believe that in > > the longer run, however, this approach will not work out well. I believe that > > particularly if you consider the trend toward multicast capable router > > deployment (e.g. the Cisco work), cutting yourself off from that capability > > is unwise. > > I think what you're asking is whether we'll support MBONE instead of (or > in addition to) building a parallel network. It's a very good question, > and I'll give an unqualified answer - we'll gladly support MBONE. > > StreamWorks started out as a 100% multicast network, our NBC and Reuters > content is still distributed using IP-multicast, and we only built > alternatives because we didn't see the practicality of using it for > commercial distribution of content. > > I can't see any reason why we can't work to redirect some of the streams > our products generate to MBONE. We're already compensated for enabling > the broadcasters, and they're likely to be pleased to reach a broader > audience. Tell us what you want to do. > > Howard > hgordon@xingtech.com > > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From rem-conf-request@es.net Tue Aug 15 13:37:52 1995 Received: from davinci.gmu.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 15 Aug 1995 10:37:29 -0700 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id NAA15044; Tue, 15 Aug 1995 13:36:58 -0400 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199508151736.NAA15044@davinci.gmu.edu> Subject: Re: More Xing and MBone discussion - Fenner's concern. To: mbenson@davinci.gmu.edu (mbenson) Date: Tue, 15 Aug 1995 13:36:58 -0400 (EDT) Cc: hgordon@system.xingtech.com, jed@llnl.gov, rem-conf@es.net In-Reply-To: from "mbenson" at Aug 15, 95 01:34:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2500 Pardon my speedy typing, my corrected state lies below: Am I missing something here? To me it sounds like a like of duplication of work in order to be able to own the method for deployment. Surely the designers of the mbone network DID NOT miss so much at the engineering level that their work had to be put to the side in favor of a completely new effort? > > Am I missing something here? To be it sounds like a like of duplication > of work in order to be able to own the method for deployment. Surely > the designers of the mbone network missed so much at the engineering > level that their work had to be put to the side in favor of a completely > new effort? > > Michael > > > > > > > > > I can understand that it may be much simplier to add some features > > > to software that you are distributing anyway to build multicast capability > > > as a byproduct of that distribution rather than to have to deal with connection > > > to the MBone to make this aspect of your product useful.. I believe that in > > > the longer run, however, this approach will not work out well. I believe that > > > particularly if you consider the trend toward multicast capable router > > > deployment (e.g. the Cisco work), cutting yourself off from that capability > > > is unwise. > > > > I think what you're asking is whether we'll support MBONE instead of (or > > in addition to) building a parallel network. It's a very good question, > > and I'll give an unqualified answer - we'll gladly support MBONE. > > > > StreamWorks started out as a 100% multicast network, our NBC and Reuters > > content is still distributed using IP-multicast, and we only built > > alternatives because we didn't see the practicality of using it for > > commercial distribution of content. > > > > I can't see any reason why we can't work to redirect some of the streams > > our products generate to MBONE. We're already compensated for enabling > > the broadcasters, and they're likely to be pleased to reach a broader > > audience. Tell us what you want to do. > > > > Howard > > hgordon@xingtech.com > > > > > > > -- > Michael Benson > Computer science graduate student at George Mason University > WWW: http://cne.gmu.edu/~mbenson > Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From rem-conf-request@es.net Tue Aug 15 13:46:09 1995 Received: from crdems.ge.com by osi-west.es.net with ESnet SMTP (PP); Tue, 15 Aug 1995 10:45:38 -0700 Received: from grymoire.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA20126; Tue, 15 Aug 95 13:34:31 -0400 Received: by grymoire.crd.ge.com (5.x/GE-CRD Standard Sendmail Version S1.5)id AA16387; Tue, 15 Aug 1995 13:35:21 -0400 Date: Tue, 15 Aug 1995 13:35:21 -0400 From: barnett@grymoire.crd.ge.com (Bruce Barnett) Message-Id: <9508151735.AA16387@grymoire.crd.ge.com> To: hgordon@system.xingtech.com, hasty@rah.star-gate.com Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology Cc: jed@llnl.gov, rem-conf@es.net X-Sun-Charset: US-ASCII > Curious why are you not using mrouted? Well, I wrote something vaguely "similar" to mrouted for NBC Desktop Video. I can offer some insight. Perhaps others can show me the errors of my ways, and tell me why I should have used mrouted.... The "broadcasts" are continuous, 24 hours a day, and routing is fixed. All "channels" are known ahead of time, as is their port/network numbers. Information flow is always uni-directional, and the client can never transmit to the source. The origin decides who receives the information. The client does not decide. The clients do not support IGMP. Reconfiguration must be authenticated and/or controlled. In some cases, output had to be converted to unicast or broadcast, as well as multicast. Or any combination of the above. Bruce Barnett uunet!crdras!barnett GE Corporate Research and Development Center From rem-conf-request@es.net Tue Aug 15 14:05:10 1995 Received: from sirius.brunel.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 15 Aug 1995 11:04:29 -0700 Received: from lindenau.brunel.ac.uk by sirius.brunel.ac.uk with SMTP (PP) id <01710-0@sirius.brunel.ac.uk>; Tue, 15 Aug 1995 19:04:20 +0100 From: Andrew.Findlay@brunel.ac.uk Message-Id: <982.9508151804@lindenau.brunel.ac.uk> Subject: Re: More Xing and MBone discussion - Fenner's concern. To: mbenson@davinci.gmu.edu (Michael Benson) Date: Tue, 15 Aug 1995 19:04:12 +0100 (BST) Cc: hgordon@system.xingtech.com, jed@llnl.gov, rem-conf@es.net In-Reply-To: <199508151736.NAA15044@davinci.gmu.edu> from "Michael Benson" at Aug 15, 95 01:36:58 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Am I missing something here? To me it sounds like a like of duplication > of work in order to be able to own the method for deployment. Surely > the designers of the mbone network DID NOT miss so much at the engineering > level that their work had to be put to the side in favor of a completely > new effort? Depends how you read the original message: My understanding was that Xing were creating a parallel network *on thier own leased circuits* to avoid competing for bandwidth on the more clogged-up bits of the public Internet. This makes a lot of sense for any commercial provider at the moment because customers expect some reasonable level of service, and the public Internet is just too overloaded to provide it. Maybe when reservation protocols come in, and the telcos charge more acceptable prices for international bandwidth, this sort of trick will not be needed (in fact I expect it will become uneconomic for most companies, just as running a private international phone network is now). Perhaps someone will clarify. Andrew ---------------------------------------------------------------------------- | From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK | | Andrew.Findlay@brunel.ac.uk +44 1895 203066 or +44 1895 274000 x2512 | ---------------------------------------------------------------------------- From rem-conf-request@es.net Tue Aug 15 15:24:27 1995 Received: from kentfm.wksu.kent.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 15 Aug 1995 12:23:33 -0700 Received: from netware.wksu.kent.edu by kentfm.wksu.kent.edu (8.6.10/wksu.95.02.23) id PAA20362; Tue, 15 Aug 1995 15:24:35 -0400 Received: from WKSU/MAILQUEUE by netware.wksu.kent.edu (Mercury 1.20); 15 Aug 95 15:23:22 -0500 Received: from MAILQUEUE by WKSU (Mercury 1.20); 15 Aug 95 15:23:18 -0500 From: Chuck Poulton Organization: WKSU Radio / Kent State University To: rem-conf@es.net, raplay@prognet.com Date: Tue, 15 Aug 1995 15:23:09 EST -0500 Subject: Maestro Leonard Slatkin to Speak Priority: normal X-mailer: Pegasus Mail v3.22 Message-ID: <21CC19512EB@netware.wksu.kent.edu> Leonard Slatkin, Festival Director of The Cleveland Orchestra's Blossom Music Festival, will speak to the Akron Roundtable at 12:30 EDT (1630 GMT) on Thursday, August 17, at Tangier Restaurant in Akron, Ohio. His topic will be: "The Relationship of Orchestras to the Community." This audio-only session will be carried live on the MBONE, and will be announced in sd. Slatkin's talk will also be available on the Web via Real Audio at http://www.wksu.kent.edu/ shortly after the event. (We may also be testing a Xing Technolgy Streamworks feed [see http://www.xingtech.com] if we are able to keep the Xing multicast feed off of the MBONE with the equipment currently at our disposal. Check the WKSU Web page the day of the event for more information on this.) Maestro Slatkin's performances throughout North America, Europe, Eastern Asia and Australia have been hailed for imaginative programming and praised for his interpretations of both the standard repertoire and contemporary works. He has conducted performances at New York's Metropolitan Opera, the Vienna State Opera, the Hamburg and Stuttgart Operas and is heard regularly in Berlin, London, Paris, TelAviv and Tokyo. Additional information about Slaktin and the Akron Roundtable is also available at the above URL. From rem-conf-request@es.net Tue Aug 15 15:37:08 1995 Received: from video.xingtech.com by osi-west.es.net with ESnet SMTP (PP); Tue, 15 Aug 1995 12:36:36 -0700 Received: by video.xingtech.com id AA04361 (5.67b/IDA-1.5 for ); Tue, 15 Aug 1995 12:33:03 -0700 Received: from system.xingtech.com(204.62.160.92) by video.xingtech.com via smap (V1.3) id sma004359; Tue Aug 15 12:32:53 1995 Received: by xingtech.com id AA18634 (5.67b/IDA-1.5); Tue, 15 Aug 1995 12:46:02 -0700 Date: Tue, 15 Aug 1995 12:46:00 -0700 (PDT) From: Howard Gordon To: Andrew.Findlay@brunel.ac.uk Cc: Michael Benson , jed@llnl.gov, rem-conf@es.net Subject: Re: More Xing and MBone discussion - Fenner's concern. In-Reply-To: <982.9508151804@lindenau.brunel.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Depends how you read the original message: My understanding was that > Xing were creating a parallel network *on thier own leased circuits* > to avoid competing for bandwidth on the more clogged-up bits of the > public Internet. This makes a lot of sense for any commercial provider > at the moment because customers expect some reasonable level of > service, and the public Internet is just too overloaded to provide it. > Maybe when reservation protocols come in, and the telcos charge more > acceptable prices for international bandwidth, this sort of trick will > not be needed (in fact I expect it will become uneconomic for most > companies, just as running a private international phone network is > now). We're initially using Internet, but we expect to move much of the traffic over to private networks. Howard From rem-conf-request@es.net Tue Aug 15 16:04:57 1995 Received: from news.cis.ohio-state.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 15 Aug 1995 13:03:42 -0700 Received: from rose.cis.ohio-state.edu (rose.cis.ohio-state.edu [164.107.44.4]) by news.cis.ohio-state.edu (8.6.8.1/8.6.4) with ESMTP id QAA17663 for ; Tue, 15 Aug 1995 16:03:40 -0400 From: Samuel Johnson Received: (johnso-s@localhost) by rose.cis.ohio-state.edu (8.6.7/8.6.4) id QAA10091 for rem-conf@es.net; Tue, 15 Aug 1995 16:03:37 -0400 Message-Id: <199508152003.QAA10091@rose.cis.ohio-state.edu> Subject: UNSUBSCRIBE To: rem-conf@es.net Date: Tue, 15 Aug 1995 16:03:35 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 185 UNSUBSCRIBE -- Sam Johnson | "In crisis e-mail(Internet): johnso-s@cis.ohio-state.edu | there is always sjohnson@magnus.acs.ohio-state.edu| opportunity" From rem-conf-request@es.net Tue Aug 15 16:14:22 1995 Received: from sgigate.sgi.com by osi-west.es.net with ESnet SMTP (PP); Tue, 15 Aug 1995 13:13:03 -0700 Received: from sgihub.corp.sgi.com by sgigate.sgi.com via ESMTP (940816.SGI.8.6.9/940406.SGI) for <@sgigate.sgi.com:rem-conf@es.net> id NAA05995; Tue, 15 Aug 1995 13:13:01 -0700 Received: from nafasi.corp.sgi.com by sgihub.corp.sgi.com via ESMTP (950413.SGI.8.6.12/911001.SGI) for <@sgi.com:rem-conf@es.net> id NAA19886; Tue, 15 Aug 1995 13:13:00 -0700 Received: by nafasi.corp.sgi.com (940816.SGI.8.6.9/911001.SGI) for rem-conf@es.net id NAA15727; Tue, 15 Aug 1995 13:12:59 -0700 From: Samuel Johnson Message-Id: <9508151312.ZM15725@nafasi.corp.sgi.com> Date: Tue, 15 Aug 1995 13:12:59 -0700 X-Mailer: Z-Mail (3.2.1 6apr95 MediaMail) To: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii SUBSCRIBE -- Samuel Johnson Silicon Graphics Inc. Application Services - Corporate I/S M/S# 15L-719 2011 N. Shorline Blvd. Mountain View, CA 94043-1389 Phone# (415) 933-6383 samij@corp.sgi.com From rem-conf-request@es.net Tue Aug 15 19:27:58 1995 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Tue, 15 Aug 1995 16:27:31 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with ESMTP id QAA00779; Tue, 15 Aug 1995 16:27:03 -0700 Message-Id: <199508152327.QAA00779@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: barnett@grymoire.crd.ge.com (Bruce Barnett) cc: hgordon@system.xingtech.com, jed@llnl.gov, rem-conf@es.net Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology In-reply-to: Your message of "Tue, 15 Aug 1995 13:35:21 EDT." <9508151735.AA16387@grymoire.crd.ge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Aug 1995 16:27:02 -0700 From: "Amancio Hasty Jr." >>> Bruce Barnett said: > > > Curious why are you not using mrouted? > > Well, I wrote something vaguely "similar" to mrouted for NBC Desktop > Video. I can offer some insight. Perhaps others can show me the > errors of my ways, and tell me why I should have used mrouted.... > > > The "broadcasts" are continuous, 24 hours a day, and routing is > fixed. All "channels" are known ahead of time, as is their port/network > numbers. Information flow is always uni-directional, and the client > can never transmit to the source. The origin decides who receives the > information. The client does not decide. The clients do not support > IGMP. Reconfiguration must be authenticated and/or controlled. > > In some cases, output had to be converted to unicast or > broadcast, as well as multicast. Or any combination of the above. > > Bruce Barnett uunet!crdras!barnett > GE Corporate Research and Development Center > Care to elaborate how the mbone can not accomodate you? Again, a simple model: mrouted <-------tunnel---------> mrouted ---->vat -----> to wherever you want to .... I am just using vat as an example of tapping into the ip multicast and then do whatever you want with the stream .... Amancio From rem-conf-request@es.net Wed Aug 16 08:41:34 1995 Received: from crdems.ge.com by osi-west.es.net with ESnet SMTP (PP); Wed, 16 Aug 1995 05:40:33 -0700 Received: from grymoire.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA10228; Wed, 16 Aug 95 08:37:28 -0400 Received: by grymoire.crd.ge.com (5.x/GE-CRD Standard Sendmail Version S1.5)id AA19979; Wed, 16 Aug 1995 08:38:16 -0400 Date: Wed, 16 Aug 1995 08:38:16 -0400 From: barnett@grymoire.crd.ge.com (Bruce Barnett) Message-Id: <9508161238.AA19979@grymoire.crd.ge.com> To: barnett@grymoire.crd.ge.com, hasty@rah.star-gate.com Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology Cc: hgordon@system.xingtech.com, jed@llnl.gov, rem-conf@es.net X-Sun-Charset: US-ASCII > > The "broadcasts" are continuous, 24 hours a day, and routing is > > fixed. All "channels" are known ahead of time, as is their port/network > > numbers. Information flow is always uni-directional, and the client > > can never transmit to the source. The origin decides who receives the > > information. The client does not decide. The clients do not support > > IGMP. Reconfiguration must be authenticated and/or controlled. > Care to elaborate how the mbone can not accomodate you? > > Again, a simple model: > > mrouted <-------tunnel---------> mrouted ---->vat -----> to wherever you want > to .... > > I am just using vat as an example of tapping into the ip multicast and then > do whatever you want with the stream .... Try this model: [ WAN with several multicast "channels"] ===> router ===> [LAN] No tunneling. No clients on the LAN can send packets to ANY multicast addresses. No clients can see/receive multicast channels without permission. Only "approved" channels are visible to the client. I didn't think mrouted could do this without extensive modification. If I am wrong, I would appreciate a correction. From rem-conf-request@es.net Wed Aug 16 11:56:54 1995 Received: from portal.netedge.com by osi-west.es.net with ESnet SMTP (PP); Wed, 16 Aug 1995 08:56:13 -0700 Received: from NetEdge.COM by portal.netedge.com id AA28334; Wed, 16 Aug 95 11:56:39 EDT Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA11639; Wed, 16 Aug 95 11:56:00 EDT Return-Path: Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA09300; Wed, 16 Aug 95 11:56:37 EDT Message-Id: <9508161556.AA09300@NetEdge.COM> To: barnett@grymoire.crd.ge.com (Bruce Barnett) Cc: rem-conf@es.net Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology In-Reply-To: Your message of "Wed, 16 Aug 1995 08:38:16 EDT." <9508161238.AA19979@grymoire.crd.ge.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <9297.808588596.1@suicidesix.netedge.com> Date: Wed, 16 Aug 1995 11:56:37 -0400 From: Thomas Pusateri In message <9508161238.AA19979@grymoire.crd.ge.com> you write: > > No tunneling. > No clients on the LAN can send packets to ANY multicast addresses. > No clients can see/receive multicast channels without permission. > Only "approved" channels are visible to the client. > > >I didn't think mrouted could do this without extensive modification. >If I am wrong, I would appreciate a correction. There seems to be two alternatives here: 1. You can use your conceptual model and write a lot of code. Afterward it will require a lot of administrative overhead. Labor is expensive compared to automation since it doesn't scale as well but on the other hand, the telco's have used static tables for years and are doing fine. Personally, I wouldn't want the headaches associated with all this administration. That's where the beauty of dynamic routing wins. 2. You can still use the current IP multicast model if you conceptualize it differently. Clients signal that they are ready to receive by joining a particular group and listening on a port. It doesn't do any good to put data on a lan if no listeners are even powered on. And if there are a lot of hops to reach a particular listener, whey congest all the routers down to the leaf when noone is listening at the end. This is where dynamic IP multicast routing wins. Data or important portions of data is encrypted such that viewing the unencrypted portions would be meaningless. Decryption keys are passed out to those listeners that buy the service. Others who aren't buying the service can still join the group and get the meaningless data but it does them no good. Sooner or later they'll realize they are just decreasing their own performance and quit. Its no different than the cable company putting a filter on your cable to prevent watching pay channels. Dynamic IP multicast routing (through DVMRP, MOSPF, PIM, or CBT) will always make more efficient use of bandwidth and this is where you will end up spending most of your money. IP packet filters can be installed in the leaf routers not to accept data back from the clients (or the concept of single source groups could be added to IP Multicast with a group address range). I think there are lots of ways to use the existing model to 1. save time and get out to market quicker 2. save money (not such a bad idea in general) 3. save administrative overhead as this grows out of control. Tom From rem-conf-request@es.net Wed Aug 16 12:31:20 1995 Received: from crdems.ge.com by osi-west.es.net with ESnet SMTP (PP); Wed, 16 Aug 1995 09:30:52 -0700 Received: from grymoire.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA14833; Wed, 16 Aug 95 12:28:33 -0400 Received: by grymoire.crd.ge.com (5.x/GE-CRD Standard Sendmail Version S1.5)id AA22366; Wed, 16 Aug 1995 12:29:19 -0400 Date: Wed, 16 Aug 1995 12:29:19 -0400 From: barnett@grymoire.crd.ge.com (Bruce Barnett) Message-Id: <9508161629.AA22366@grymoire.crd.ge.com> To: barnett@grymoire.crd.ge.com, pusateri@NetEdge.COM Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology Cc: rem-conf@es.net X-Sun-Charset: US-ASCII > 1. You can use your conceptual model and write a lot of code. It's written. The initial prototype was 586 lines of PERL. There are other features that I've added that are not in mrouted. I would say there is only 5% of common functionality of my code and mrouted. > Afterward it will require a lot of administrative overhead. Not so far. Routing is static. Set it and forget it. Our administration problems are elsewhere. > 2. You can still use the current IP multicast model if you conceptualize it > differently. Clients signal that they are ready to receive by > joining a particular group and listening on a port. You are assuming all clients support IGMP. Not many PC clients have TCP stacks that support IGMP. And, as you said - you need IP filtering to prevent information from going back. Can you do this with mrouted without requiring another box? Or extensively modifying mrouted? > I think there are lots of ways to use the existing model to > 1. save time and get out to market quicker > 2. save money (not such a bad idea in general) > 3. save administrative overhead as this grows out of control. NBC Desktop Video is being sold now. I'm not sure how long it has been on the market. Perhaps 6-12 months. From rem-conf-request@es.net Wed Aug 16 14:02:26 1995 Received: from portal.netedge.com by osi-west.es.net with ESnet SMTP (PP); Wed, 16 Aug 1995 11:01:24 -0700 Received: from NetEdge.COM by portal.netedge.com id AA29728; Wed, 16 Aug 95 14:01:44 EDT Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA11906; Wed, 16 Aug 95 14:01:04 EDT Return-Path: Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA09417; Wed, 16 Aug 95 14:01:35 EDT Message-Id: <9508161801.AA09417@NetEdge.COM> To: barnett@grymoire.crd.ge.com (Bruce Barnett) Cc: rem-conf@es.net Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology In-Reply-To: Your message of "Wed, 16 Aug 1995 12:29:19 EDT." <9508161629.AA22366@grymoire.crd.ge.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <9414.808596094.1@suicidesix.netedge.com> Date: Wed, 16 Aug 1995 14:01:35 -0400 From: Thomas Pusateri In message <9508161629.AA22366@grymoire.crd.ge.com> you write: > >> 1. You can use your conceptual model and write a lot of code. > >It's written. The initial prototype was 586 lines of PERL. There are >other features that I've added that are not in mrouted. I would say >there is only 5% of common functionality of my code and mrouted. To use IP multicast fowarding, you must add forwarding cache entries to the kernel. I would think this would be difficult to do in a language with no data structures. But scaling would be even a bigger problem. Most of the people in the IP Multicast camp worry about providing solutions that scale to the world. If we solve that problem, then it will certainly work for a small subset of the world. If you design your system for a small subset of the world, then you end up redesigning constantly to prevent it from collapsing. This is usually done under much pressure and undesirable compromises are made. >> Afterward it will require a lot of administrative overhead. > >Not so far. Routing is static. Set it and forget it. >Our administration problems are elsewhere. Everytime you get a new customer, you must determine the branch where they fit the best. This problem is such that you can eyeball it and come up with a solution that may or may not be optimal or run an algorithm like an SPF algorithm that will determine a minimum spanning tree to reach all of your receivers. After adding new customers, it is likely that your tree branches will change and the number of reconfigurations of your "static mrouted replacement" will increase exponentially. This is what I mean by adminstrative overhead. You can't set it and forget it, unless of course, if you have no new customers. > >> 2. You can still use the current IP multicast model if you conceptualize it >> differently. Clients signal that they are ready to receive by >> joining a particular group and listening on a port. > >You are assuming all clients support IGMP. Not many PC clients have TCP >stacks that support IGMP. And, as you said - you need IP filtering to >prevent information from going back. Can you do this with mrouted >without requiring another box? Or extensively modifying mrouted? If FTP software supports it and Windows 95 supports it and others are being added all the time, then what more do you want for PC support? Filtering of IP multicast could conceptually be done by mrouted by just not building the multicast forwarding cache entries to allow multiple senders. As I alluded to earlier, this could be done very simply by defining a single source address range. This is just off the top of my head so it would require some more thought but I think a solution is probably not too difficult. >NBC Desktop Video is being sold now. I'm not sure how long it has >been on the market. Perhaps 6-12 months. As you experience growth problems, you may want to revisit this thread. Tom From rem-conf-request@es.net Wed Aug 16 14:55:45 1995 Received: from crdems.ge.com by osi-west.es.net with ESnet SMTP (PP); Wed, 16 Aug 1995 11:55:19 -0700 Received: from grymoire.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA19139; Wed, 16 Aug 95 14:54:25 -0400 Received: by grymoire.crd.ge.com (5.x/GE-CRD Standard Sendmail Version S1.5)id AA23449; Wed, 16 Aug 1995 14:55:10 -0400 Date: Wed, 16 Aug 1995 14:55:10 -0400 From: barnett@grymoire.crd.ge.com (Bruce Barnett) Message-Id: <9508161855.AA23449@grymoire.crd.ge.com> To: barnett@grymoire.crd.ge.com, pusateri@NetEdge.COM Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology Cc: rem-conf@es.net X-Sun-Charset: US-ASCII > I would think this would be difficult to do in a > language with no data structures. But scaling would be even a bigger > problem. > The PROTOTYPE was written in PERL. The production version is in ANSI C. As for administration overhead, we are well aware of the problems, including some that you may never have seen, and I repeat, routing is a very small part. I'm sorry for this response, as it is blunt, but just because you think something will be difficult doesn't make it true for all cases. My main purpose for bringing this up is to discuss why we decided not to use mrouted for our application. So far, no one has convinced me the decision was wrong. >Most of the people in the IP Multicast camp worry about providing >solutions that scale to the world. I am talking real world. NBC is making money with their system today. Can you blame me for being sensitive to people who tell me our solution isn't practical? And how do you know it doesn't scale? From rem-conf-request@es.net Fri Aug 18 23:21:31 1995 Received: from servo.ipsilon.com (actually foobar.Ipsilon.COM) by osi-west.es.net with ESnet SMTP (PP); Fri, 18 Aug 1995 20:20:57 -0700 Received: from localhost.ipsilon.com (localhost.ipsilon.com [127.0.0.1]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id UAA01919; Fri, 18 Aug 1995 20:20:18 -0700 Message-Id: <199508190320.UAA01919@servo.ipsilon.com> X-Authentication-Warning: servo.ipsilon.com: Host localhost.ipsilon.com didn't use HELO protocol X-Mailer: exmh version 1.6beta 3/23/95 To: barnett@grymoire.crd.ge.com (Bruce Barnett) cc: rem-conf@es.net Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology In-reply-to: Your message of "Wed, 16 Aug 1995 08:38:16 EDT." <9508161238.AA19979@grymoire.crd.ge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Aug 1995 20:20:17 -0700 From: Greg Minshall > No tunneling. > No clients on the LAN can send packets to ANY multicast addresses. > No clients can see/receive multicast channels without permission. > Only "approved" channels are visible to the client. >I didn't think mrouted could do this without extensive modification. >If I am wrong, I would appreciate a correction. I think it might be useful in this discussion to separate *protocols* from *implementions*. There are lots of implementations of routing protocols and forwarding engines that don't support various forms of administrative/security policy. That doesn't mean that the protocols, themselves, are somehow hostile to this form of policy. So, *routed* (the RIP beast in BSD) doesn't support restrictions on who tells it what. The standard BSD kernel forwarding engine (router) doesn't care who tells it to send what where. But, one can produce a RIP implementation that only accepts certain routes >from certain nodes connected via certain interfaces. And, one can produce a forwarding engine that throws away packets based on some site-determined policy. (I assume that cisco or bay routers provide existence proofs for both these assertions.) So, it shouldn't surprise anyone that stock mrouted, running on a BSD kernel, doesn't support a lot of these sorts of policies. Most of your requests can, i believe, be supported by the specialized implementations of the *protocols* (IGMP and DVMRP). (The hard part, of course, is preventing one client on a LAN from seeing packets in a group which is being "subscribed to" by an authorized client on the same LAN; i think that either encryption, as Tom P. suggested, or star wiring structures are probably the only ways to accomplish that.) Greg Minshall Ipsilon Networks, Inc. From rem-conf-request@es.net Sat Aug 19 19:40:33 1995 Received: from crdems.ge.com by osi-west.es.net with ESnet SMTP (PP); Sat, 19 Aug 1995 16:40:05 -0700 Received: from grymoire.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA07170; Sat, 19 Aug 95 19:38:35 -0400 Received: by grymoire.crd.ge.com (5.x/GE-CRD Standard Sendmail Version S1.5)id AA15231; Sat, 19 Aug 1995 19:39:23 -0400 Date: Sat, 19 Aug 1995 19:39:23 -0400 From: barnett@grymoire.crd.ge.com (Bruce Barnett) Message-Id: <9508192339.AA15231@grymoire.crd.ge.com> To: minshall@Ipsilon.COM Subject: Re: R.e. Death of MBONE predicted: StreamWorks from Xing Technology Cc: rem-conf@es.net >I think it might be useful in this discussion to separate *protocols* from >*implementions*. I spoke up primarily to show that there are many problems to be solved, and multicast routing is only one of them. Reliability, dependability, quality and resource management are also issues to be addressed. Since NBC is using a private, dedicated network, the types of problems we face are very different than those seen on the Internet (and in some ways, the problems are simpler). Routing protocols are HARD. I never meant to imply that there was anything inferior to the implementation or protocols discussed. I tip my hat to those who do work on mrouted, and routing protocols. From rem-conf-request@es.net Mon Aug 21 03:06:03 1995 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 21 Aug 1995 00:05:06 -0700 Received: by precept.com (5.x/SMI-4.1) id AA01865; Mon, 21 Aug 1995 00:04:59 -0700 Date: Mon, 21 Aug 1995 00:04:59 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Comments on RTP A/V Profile Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To the Audio/Video Transport Working Group: Some comments on the Audio/Video Profile draft The IANA and others have expressed some concern about the assignment of payload type codes in a relatively small space (7 bits). The motivation for designing this small space was to minimize header overhead; the rationale for accepting it was that the natural forces promoting interoperation would dictate a fairly small set of useful encodings. Note that part of the payload type range is dedicated to dynamic assignments to be made through higher-level control protocols. For example, there was some recent discussion about including the means to define dynamic payload types in SDP as part of a session description. Similarly, proprietary applications that perform a control negotiation before establishing media flows can also define dynamic payload types. The set of static payload types is intended to promote interoperation among multiple implementations of audio and video applications when using "minimal control". In order to keep the list of static payload types as useful as possible for interoperation, it may be appropriate to define some constraints that IANA may use in deciding to accept a request for such an assignment. During a recent discussion with some folks at Xerox PARC, it was suggested that a reasonable constraint would be that static payload type assignments should only be made for encodings that may be used in multiple interoperating implementations. Primarily, this would be encodings for which there are publicly available specifications or source code, but it might also include encodings for which implementations of the encoder and/or decoder are freely available in binary form (the CPV decoder in the nv program is an example). It may also be appropriate to review the list of existing assignments before the Profile is published as an RFC. Those which have not been implemented under RTPv2, or for which implementations are not underway, could be removed and replaced with a "Reserved" designation allowing future reassignment as appropriate. Note that applications using RTPv1 and RTPv2 will not be interoperable, so there is no strong requirement that identical type codes be assigned for a given payload type under both versions. In particular, the HDCC and PicW video encodings may be candidates for removal, especially if RTPv2 implementations by Silicon Graphics and BBN, respectively, are not planned. In addition, the two proprietary voice encodings, TSP0 and VSC, might not meet the assignment constraint proposed above. I would like to hear comments on any of the point in this message, but in particular comments for or against the removal of the encodings listed, as well as suggestions of other encodings that should be removed or added at this time. -- Steve Casner From rem-conf-request@es.net Mon Aug 21 07:53:55 1995 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 21 Aug 1995 04:52:58 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 21 Aug 1995 12:50:50 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: Stephen Casner cc: rem-conf@es.net Subject: Re: Comments on RTP A/V Profile In-reply-to: Your message of "Mon, 21 Aug 95 00:04:59 PDT." Date: Mon, 21 Aug 95 12:50:47 +0100 Message-ID: <3082.809005847@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >The IANA and others have expressed some concern about the assignment >of payload type codes in a relatively small space (7 bits). The >motivation for designing this small space was to minimize header >overhead; the rationale for accepting it was that the natural forces >promoting interoperation would dictate a fairly small set of useful >encodings. ... >During a recent discussion with some folks at Xerox PARC, it was >suggested that a reasonable constraint would be that static payload >type assignments should only be made for encodings that may be used in >multiple interoperating implementations. I agree with both the concern and the suggested constraint. However, what is the recommended course of action for people developing new encodings? I would feel happier if there was a mechanism for requesting the reservation of a payload type so that if my new encoding did become widely used, and satisfied IANA's criteria, I wouldn't have to attempt to get a new and incompatible version of my code out to my existing users. My only real alternative to this appears to be to use a dynamic encoding, which doesn't seem appropriate in this case. Mark From rem-conf-request@es.net Mon Aug 21 15:07:51 1995 Received: from dub-img-2.compuserve.com by osi-west.es.net with ESnet SMTP (PP); Mon, 21 Aug 1995 12:07:22 -0700 Received: by dub-img-2.compuserve.com (8.6.10/5.950515) id PAA20184; Mon, 21 Aug 1995 15:07:20 -0400 Date: 21 Aug 95 14:03:18 EDT From: Christian Olschewski <100445.2164@compuserve.com> To: Mail list 1 Subject: help Message-ID: <950821180318_100445.2164_BHG78-1@CompuServe.COM> help From rem-conf-request@es.net Mon Aug 21 19:17:41 1995 Received: from milou.comp.lancs.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 21 Aug 1995 16:17:08 -0700 Received: from dcl-vitus.comp.lancs.ac.uk by milou.comp.lancs.ac.uk; Tue, 22 Aug 1995 00:14:12 +0100 From: Mr S A Namuye Message-Id: <4882.199508212321@dcl-vitus.comp.lancs.ac.uk> Received: by dcl-vitus.comp.lancs.ac.uk; Tue, 22 Aug 1995 00:21:25 +0100 Subject: MICE International Seminar Series To: rem-conf@es.net Date: Tue, 22 Aug 1995 00:21:25 +0100 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 294 Please add me the list of participants for MICE International Seminar Series. Are the summer sessions still on? Do I need to have special facilities or configuration in my work space to be able to tune in the sessions? Silvester A Namuye Lancaster University e-mail: namuye@comp.lancs.ac.uk From rem-conf-request@es.net Mon Aug 21 23:30:30 1995 Received: from davinci (actually 206.197.101.10) by osi-west.es.net with ESnet SMTP (PP); Mon, 21 Aug 1995 20:30:02 -0700 Received: by davinci (950215.SGI.8.6.10/940406.SGI.AUTO) id XAA02313; Mon, 21 Aug 1995 23:29:23 -0400 From: mbenson@davinci (Michael Benson) Message-Id: <199508220329.XAA02313@davinci> Subject: Re: MICE International Seminar Series To: namuye@comp.lancs.ac.uk (Mr S A Namuye) Date: Mon, 21 Aug 1995 23:29:23 -0400 (EDT) Cc: rem-conf@es.net In-Reply-To: <4882.199508212321@dcl-vitus.comp.lancs.ac.uk> from "Mr S A Namuye" at Aug 22, 95 00:21:25 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 629 If anyone can get in on this, I too would be interested. Michael (I must have missed the announcement... how I do not know. :) > > Please add me the list of participants for MICE International Seminar > Series. Are the summer sessions still on? Do I need to have special > facilities or configuration in my work space to be able to tune in the > sessions? > > Silvester A Namuye > Lancaster University > e-mail: namuye@comp.lancs.ac.uk > -- Michael Benson Computer science graduate student at George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From rem-conf-request@es.net Tue Aug 22 05:26:39 1995 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 22 Aug 1995 02:26:10 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 22 Aug 1995 10:25:18 +0100 To: mbenson@gmu.edu cc: namuye@comp.lancs.ac.uk (Mr S A Namuye), rem-conf@es.net Subject: Re: MICE International Seminar Series In-reply-to: Your message of "Mon, 21 Aug 95 23:29:23 EDT." <199508220329.XAA02313@davinci> Date: Tue, 22 Aug 95 10:25:17 +0100 From: Roy Bennett Michael The original series was multicast live from the US Naval Postgraduate School in Monterey California and is currently being re-multicast by the MICE National Support Centre in England at ttl 63 for Europe only. The rationale is that, by transmitting at 9:00 UTC to Europe, we use the mbone at a time when it is less heavily loaded and at a better time for Europeans. It is our intention to store the series in our digital video-on-demand archive which is currently under development. This will provide a European source to match the planned one at Monterey. Don Brutzman and Tracey Emswiler provided us with video tapes of the originals to retransmit and will be handling the digital archiving at their end. The MICE project (http://www.cs.ucl.ac.uk/mice/) has been running a series of seminars in "Multimedia, Communications, Networks, Distributed Systems and CSCW" on the Mbone since 1993 and will continue to do so. Details of the current activities are always to be found in http://www.cs.ucl.ac.uk/mice/seminars/ These are transmitted at ttl 127 and have world-wide participation, so I hope you will get to see some of them. They are always in sd and are notified to rem-conf a week or so in advance. We use the MBone Session Global Agenda (http://www.cilea.it/MBone/agenda.html) to reserve the necessary bandwidth. Hope this helps. Sorry you dont get to see the repeats :-( but soon you will have them "on-demand" :-) Best wishes Roy >If anyone can get in on this, I too would be interested. > >Michael >(I must have missed the announcement... how I do not know. :) > >> >> Please add me the list of participants for MICE International Seminar >> Series. Are the summer sessions still on? Do I need to have special >> facilities or configuration in my work space to be able to tune in the >> sessions? >> >> Silvester A Namuye >> Lancaster University >> e-mail: namuye@comp.lancs.ac.uk >> > > >-- >Michael Benson >Computer science graduate student at George Mason University >WWW: http://cne.gmu.edu/~mbenson >Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson ------------------------------------------------------------------------- Roy Bennett EMMA - Enhanced Multicast for Multimedia Applications Computer Science Phone: +44 171 380 7934 University College London Fax: +44 171 387 1397 Gower Street, LONDON WC1E 6BT Email: rbennett@cs.ucl.ac.uk ------------ URL http://www.cs.ucl.ac.uk/staff/R.Bennett ---------------- MICE Multimedia Integrated Conferencing Support Centre, England mice-nsc-england@cs.ucl.ac.uk http://www.cs.ucl.ac.uk/mice/mice-nsc/ ------------------------------------------------------------------------- From rem-conf-request@es.net Tue Aug 22 13:13:02 1995 Received: from darwin.cesup.ufrgs.br by osi-west.es.net with ESnet SMTP (PP); Tue, 22 Aug 1995 10:12:24 -0700 Received: from UPF.tche.BR ([200.17.166.1]) by darwin.cesup.ufrgs.br (051895/8.6.11) with SMTP id OAA09013 for ; Tue, 22 Aug 1995 14:11:45 -0300 Received: by UPF.tche.BR (5.x/SMI-SVR4) id AA03870; Tue, 22 Aug 1995 14:11:09 -0300 Date: Tue, 22 Aug 1995 14:11:09 -0300 From: trentin@vitoria.UPF.tche.BR (Marco Trentin) Message-Id: <9508221711.AA03870@UPF.tche.BR> To: rem-conf@es.net Subject: sd-launch and tcl2c I am trying to use sd-launch,(it allow launching of MBONE sessions via WWW) but I can't compile it because I need tcl2c, and it isn't more in the place where it supost stay. Anybody can help me? Anybody use sd-launch? I will use it in SunOs 4.1.1 and Solaris 2.3. Any help will be welcome. Thanks in advance. Marco Trentin. -- E-mail : trentin@upf.tche.br From rem-conf-request@es.net Tue Aug 22 18:43:02 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Tue, 22 Aug 1995 15:42:24 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21188; 22 Aug 95 17:11 EDT To: webmaster@cilea.it cc: rem-conf@es.net Subject: Correction to MBONE booking Date: Tue, 22 Aug 95 17:11:54 -0400 From: Steve Coya Message-ID: <9508221711.aa21188@IETF.CNRI.Reston.VA.US> Whoops - I made a mistake (but it WAS my first attempt to book mbone sessions :-) When entering the data for the 35th IETF meeting, I mistakenly entered the wrong city. It SHOULD read Los Angelas, CA (not Montreal, Ontario, Canada). Steve From rem-conf-request@es.net Tue Aug 22 19:17:36 1995 Received: from mach3.directnet.com by osi-west.es.net with ESnet SMTP (PP); Tue, 22 Aug 1995 16:16:59 -0700 Received: from kona.directnet.com by mach3.directnet.com via ESMTP (940816.SGI.8.6.9/940406.SGI) for <@mach3.directnet.com:rem-conf@es.net> id QAA20927; Tue, 22 Aug 1995 16:13:50 -0700 Received: by kona.directnet.com (940816.SGI.8.6.9/940406.SGI) for rem-conf@es.net id QAA05394; Tue, 22 Aug 1995 16:13:49 -0700 From: Chris Gwynne Message-Id: <9508221613.ZM5392@kona.directnet.com> Date: Tue, 22 Aug 1995 16:13:49 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii subscribe jett@directnet.com -- ~~~~ Help trapped on planet uni~X~ Please return space modulator Losing caffeine quickly From rem-conf-request@es.net Tue Aug 22 20:38:33 1995 Received: from qucis.queensu.ca by osi-west.es.net with ESnet SMTP (PP); Tue, 22 Aug 1995 17:37:55 -0700 Received: from quick.qucis.queensu.ca by qucis.queensu.ca (5.x/SMI-SVR4-qs1.6) id AA26385; Tue, 22 Aug 1995 20:36:21 -0400 Received: by quick.qucis.queensu.ca (5.x/SMI-SVR4-qc1.3) id AA23392; Tue, 22 Aug 1995 20:36:19 -0400 Message-Id: <9508230036.AA23392@quick.qucis.queensu.ca> From: Jonathan Layes Date: Tue, 22 Aug 1995 20:36:19 +0000 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rem-conf@es.net unsubscribe rem-conf (my apologies if this ends up going to the whole list, but a number of attempts to unsubscribe using rem-conf-request@es.net have not worked) From rem-conf-request@es.net Tue Aug 22 23:13:27 1995 Received: from aohakobe.ipc.chiba-u.ac.jp by osi-west.es.net with ESnet SMTP (PP); Tue, 22 Aug 1995 20:13:00 -0700 Received: from aohakobe (localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.6.12/3.4Wbeta3 (-: 95041617) with ESMTP id MAA28586; Wed, 23 Aug 1995 12:09:32 +0900 Message-Id: <199508230309.MAA28586@aohakobe.ipc.chiba-u.ac.jp> To: trentin@vitoria.UPF.tche.BR (Marco Trentin) cc: rem-conf@es.net Subject: Re: sd-launch and tcl2c In-reply-to: Your message of "Tue, 22 Aug 1995 14:11:09 -0300." <9508221711.AA03870@UPF.tche.BR> Date: Wed, 23 Aug 1995 12:09:32 +0900 From: Yozo Toda (TELEPHONE +81-43-290-3539) > I am trying to use sd-launch,(it allow launching of MBONE sessions > via WWW) but I can't compile it because I need tcl2c, and it > isn't more in the place where it supost stay. Anybody can help me? I don't use sd_launch, but I can find tcl2c.c in nv or vic package. very small file, here it is. -- yozo. %%%% %%%% from nvsrc-3.3beta.tar.Z %%%% %%%% /* Netvideo version 3.3 Written by Ron Frederick Simple hack to translate a Tcl/Tk init file into a C string constant */ /* * Copyright (c) Xerox Corporation 1992. All rights reserved. * * License is granted to copy, to use, and to make and to use derivative * works for research and evaluation purposes, provided that Xerox is * acknowledged in all documentation pertaining to any such copy or derivative * work. Xerox grants no other licenses expressed or implied. The Xerox trade * name should not be used in any advertising without its written permission. * * XEROX CORPORATION MAKES NO REPRESENTATIONS CONCERNING EITHER THE * MERCHANTABILITY OF THIS SOFTWARE OR THE SUITABILITY OF THIS SOFTWARE * FOR ANY PARTICULAR PURPOSE. The software is provided "as is" without * express or implied warranty of any kind. * * These notices must be retained in any copies of any part of this software. */ #include main(int argc, char **argv) { int c, count=0; if (argc < 2) { fprintf(stderr, "Usage: %s stringname\n", argv[0]); exit(1); } printf("char %s[] = {\n ", argv[1]); while ((c = getchar()) != EOF) { switch (c) { case '\'': printf("'\\'', "); break; case '\\': printf("'\\\\', "); break; case '\t': printf("'\\t', "); break; case '\n': printf("'\\n', "); count = 10; break; default: printf("'%c', ", c); break; } if (count++ == 10) { printf("\n "); count = 0; } } printf("'\\0' };\n"); exit(0); /*NOTREACHED*/ } %%%% %%%% %%%% %%%% From rem-conf-request@es.net Wed Aug 23 00:28:39 1995 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 22 Aug 1995 21:28:10 -0700 Received: by precept.com (5.x/SMI-4.1) id AA00495; Tue, 22 Aug 1995 21:27:59 -0700 Date: Tue, 22 Aug 1995 21:27:58 -0700 (PDT) From: Stephen Casner To: Mark Handley Cc: rem-conf@es.net Subject: Re: Comments on RTP A/V Profile In-Reply-To: <3082.809005847@cs.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Regarding specifying a constraint for IANA to use in accepting requests for RTP payload type code assignments, On Mon, 21 Aug 1995, Mark Handley wrote: > I agree with both the concern and the suggested constraint. > > However, what is the recommended course of action for people > developing new encodings? I would feel happier if there was a > mechanism for requesting the reservation of a payload type so that if > my new encoding did become widely used, and satisfied IANA's criteria, > I wouldn't have to attempt to get a new and incompatible version of my > code out to my existing users. That seems reasonable. If a requestor promises to provide specs or whatever to meet the constraint, IANA could reserve a code for an agreed-upon period. If the constraint was not met in that time, then the reservation could be removed. If it is met, then the assignment could be made official and published. > My only real alternative to this appears to be to use a dynamic > encoding, which doesn't seem appropriate in this case. What is the case you are referring to? I ask because if SDP includes a mechanism for dynamic assignment, that covers many of the current cases. -- Steve From rem-conf-request@es.net Wed Aug 23 05:25:02 1995 Received: from dxmint.cern.ch by osi-west.es.net with ESnet SMTP (PP); Wed, 23 Aug 1995 02:24:13 -0700 Received: from afcoms.cern.ch by dxmint.cern.ch id AA01821; Wed, 23 Aug 1995 11:24:04 +0200 Received: by afcoms.cern.ch; (5.65/1.1.8.2/28Jul95-0949AM) id AA09575; Wed, 23 Aug 1995 11:23:56 +0200 Message-Id: <9508230923.AA09575@afcoms.cern.ch> Subject: CERN-ATLAS MBONE Announcement To: teleconf@cearn.cern.ch, tele-ext@cearn.cern.ch, rem-conf@es.net, htc@cearn.cern.ch, hrc@cearn.cern.ch Date: Wed, 23 Aug 1995 11:23:56 +0200 (MET DST) From: Christian Isnard - CERN/CN/CS X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 927 CERN is pleased to announce the MBONE broadcast of the next plenary sessions of the ATLAS physics collaboration. These sessions will be held at CERN on: Thursday 28th Sept. starting at 14:00 (GMT+1) Friday 29th Sept. starting at 08:30 (GMT+1) Details about agenda and possible playback sessions will be given later. The session will be advertised in sd session directory as "CERN - ATLAS". vat v3.4 (audio) and nv v3.3 (video) will be used with ttl 127. In case of questions or problems about this broadcast please contact: Before Aug. 25th and after Sept. 25th: Christian Isnard Between Aug. 25th and Sept. 25th: Olivier H. Martin -- Christian Isnard Email: isnard@dxcoms.cern.ch European Laboratory for Particle Physics CERN - CN/CS/EN Computers and Networks division CH-1211 Geneva 23 - Switzerland From rem-conf-request@es.net Wed Aug 23 08:29:12 1995 Received: from sun4nl.NL.net by osi-west.es.net with ESnet SMTP (PP); Wed, 23 Aug 1995 05:28:31 -0700 Received: from baltzer.nl by sun4nl.NL.net with SMTP id AA16480 (5.65b/CWI-3.3); Wed, 23 Aug 1995 14:15:32 +0200 Date: Wed, 23 Aug 1995 14:15:32 +0200 Message-Id: <9508231215.AA16480@sun4nl.NL.net> X-Sender: Pbaltzer@sun4nl.nluug.nl Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: From: publish@baltzer.nl (Baltzer Science Publishers) Subject: WIRELESS NETWORKS - CONTENTS CONTENTS WIRELESS NETWORKS, ISSN 1022-0038, Co-published with the ACM (Association for Computing Machinery) The journal of mobile communication, computation and information Editor-in-Chief: I. Chlamtac, Department of Electrical and Computer Engineering, University of Massachusetts, Amherst MA 01003, USA Aims & Scope: The wireless communication revolution is bringing fundamental changes to communication and computing. From wide-area cellular systems to wireless LANs, mobile and wireless networks are on the verge of providing fully distributed and ubiquitous mobile computing and communications any time, anywhere.Through a seamless integration with fixed network infrastructures the future promises a universal communication grid, bringing an end to the tyranny of geography. A parallel evolution and proliferation of services for the mobile user are changing the scope of communication and the nature of user and machine interaction paradigms. Wireless Networks will serve as the publication vehicle for high-quality, in-depth original articles addressing networks, systems, algorithms, and applications that support the symbiosis of portable computers, wireless networks, mobile communication and computation, and their integration into the global network of the future. Regularly addressed topics will include: Network architectures for nomadic LAN to WAN communication and computation; mobile and wireless communications protocols, media access control algorithms, algorithms for mobility and mobility management including hand-off, registration, location, tracking, and routing; performance evaluation of mobile/wireless networks; systems topology design including cell architectures, capacity allocation and coverage issues, mobility, bandwidth, or intermittent connectivity related communication and computing issues; network management, control and signaling; security, scalability and reliability issues; database design and management for mobility; software principles, operating systems and resource management for nomadic computing; service integration and interworking of wired and wireless networks; applications, computing services and service algorithms in the mobile environment; enabling technologies for wireless and mobile communication including wireless signal propagation studies, portable hardware technologies, energy efficient and low-power design and components; network demonstrations, experimentation, and testbeds. Contents Volume 1, No. II pp. 129-138, J.P.M.G. Linnartz, On the performance of packet switched cellular networks for wireless data communication pp. 139-146, Z. Haas and S. Paul, Limited lifetime shared access in mobile systems pp. 147-160, I Rubin and S. Shambayati, Performance evaluation of a reservation random access scheme for packetized wireless systems with call control and hand-off loading pp. 161-174, K.Y. Eng, M.J. Karol, M. Veeraraghavan, E. Ayanoglu, C.B. Woodworth, and R.A. Valenzuela, A wireless broadband ad-hoc ATM local-area network pp. 175-186, A. Bar-Noy, I. Kessler and M. Sidi, Mobile users: To update or not to update? pp. 187-196, I. Akyildiz and J. S.M. Ho, Dynamic mobile user location update for wireless PCS networks pp. 197-210, R. Jain and Yi-Bing Lin, An auxiliary user location strategy employing forward pointers to reduce network impacts of PCS pp. 211-220, C. Rose and R. Yates, Minimizing the average cost of paging under delay constraints pp. 221-226, A. Farago, On the complexity of finding sparsest and densest parts in wireless networks pp. 227-239, M. Zorzi, Mobile radio slotted ALOHA with capture and diversity Submissions of articles and proposals for special issues are to be addressed to the Editor-in-Chief: I. Chlamtac Requests for FREE SPECIMEN copies and orders for Wireless Networks are to be sent to: E-mail: publish@baltzer.nl or see our homepage http://www.NL.net/~baltzer/ . From rem-conf-request@es.net Thu Aug 24 14:35:18 1995 Received: from tigger.Read.TASC.COM by osi-west.es.net with ESnet SMTP (PP); Thu, 24 Aug 1995 11:34:50 -0700 Received: by tigger.Read.TASC.COM (5.0/TASC-NONDOM-1.7) id AA10405; Thu, 24 Aug 1995 14:35:29 +0500 Date: Thu, 24 Aug 1995 14:35:29 +0500 From: wgsmith@tigger.Read.TASC.COM (W. Garth Smith) Message-Id: <9508241835.AA10405@tigger.Read.TASC.COM> To: rem-conf@es.net Subject: mrouted questions X-Sun-Charset: US-ASCII content-length: 1053 We have been using mrouted and have some questions concerning general behavior on SUN Solaris 2.4 machines: - are there man pages for mrouted (ftp location?) - we have noticed that a "ps -elf | grep mrouted" command does not show an active process (even though tunneling is active). This works fine on an SGI. Any feedback would be helpful. Garth ____________________________________________________________________________ W. Garth Smith _/_/_/_/_/ _/_/_/_/ _/_/_/_/ _/_/_/_/ TASC _/ _/ _/ _/ _/ _/ _/ 55 Walkers Brook Drive _/ _/ _/ _/ _/ Reading, MA 01867-3297 _/ _/_/_/_/ _/_/_/_/ _/ voice: 617-942-2000 (ext. 2417) _/ _/ _/ _/ _/ fax: 617-942-7100 _/ _/ _/ _/ _/ _/ _/ email: wgsmith@tasc.com _/ _/ _/ _/_/_/_/ _/_/_/_/ web: http://www.tasc.com ____________________________________________________________________________ From rem-conf-request@es.net Fri Aug 25 09:09:47 1995 Received: from mail.rwth-aachen.de by osi-west.es.net with ESnet SMTP (PP); Fri, 25 Aug 1995 06:09:13 -0700 Return-receipt-to: NOLDEN Received: from majestix.hdz-ima.RWTH-Aachen.DE by mail.rwth-aachen.de (PMDF V4.3-10 #7297) id <01HUHT40DDCG008BS5@mail.rwth-aachen.de>; Fri, 25 Aug 1995 15:04:16 +0100 Received: from MAJESTIX/MAIL by HDZ-IMA.RWTH-Aachen.de (Mercury 1.20) ; 25 Aug 95 15:01:30 +0 Received: from MAIL by MAJESTIX (Mercury 1.20); 25 Aug 95 15:01:14 +0 Date: Fri, 25 Aug 1995 15:01:09 +0000 From: NOLDEN Subject: mbone mailing-list To: rem-conf@es.net Message-id: <1E88A0111F@HDZ-IMA.RWTH-Aachen.de> Organization: HDZ/IMA X-Mailer: Pegasus Mail/Windows (v1.22) Content-transfer-encoding: 7BIT Priority: normal Lehrstuhl Informatik im Maschinenbau und Hochschuldidaktisches Zentrum der RWTH Aachen We are interested in participating at the mbone events. Therefore, please include our address in your mailing-list. i.A. Andreas Nolden From rem-conf-request@es.net Fri Aug 25 21:06:20 1995 Received: from cs.rpi.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 25 Aug 1995 18:05:47 -0700 Received: from colossus.cs.rpi.edu by cs.rpi.edu (5.67a/1.4-RPI-CS-Dept) id AA14973; Fri, 25 Aug 1995 21:05:26 -0400 (glinert from colossus.cs.rpi.edu) Date: Fri, 25 Aug 95 21:05:14 EDT From: glinert@cs.rpi.edu Received: by colossus.cs.rpi.edu (4.1/2.3-RPI-CS-client) id AA07639; Fri, 25 Aug 95 21:05:14 EDT Message-Id: <9508260105.AA07639@colossus.cs.rpi.edu> To: end2end-interest@venera.isi.edu, f-troup@AURORA.CIS.UPENN.edu, ietf@venera.isi.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, rem-conf@es.net, sound@PASCAL.acm.org, tccc@cs.umass.edu Subject: Call For Participation Call For Participation Call For Participation =--=--=--=--=--=--=--= =--=--=--=--=--=--=--= ASSETS'96 The 2nd ACM/SIGCAPH Conference on Assistive Technologies -=--=--=--=--=--=--=--=--=--=--=--=--=- April 11-12, 1996 Waterfront Center Hotel Vancouver, Canada Sponsored by the ACM's Special Interest Group on Computers and the Physically Handicapped, ASSETS'96 will be the second in a new series of conferences whose goal is to provide a forum where researchers and developers, from academia and industry, can meet to exchange ideas and report on new developments relating to computer-based systems to help people. The conference scope spans disabilities and special needs of all kinds, including but not limited to: sensory (hearing, vision); motor (orthopedic); cognitive (learning, speech, mental); and emotional. TECHNICAL PAPERS of the high quality expected at major ACM conferences should be up to 8 pages in length and may be of various kinds: (a) Presentation of original and significant research. (b) Results of relevant and rigorous empirical studies. (c) Description of the ``look and feel'' and discussion of the internal workings of an implemented system. Authors are encouraged to send a short VIDEOTAPE with their paper, if possible, to clarify and reinforce the concepts discussed. Papers must be set in 11 point type and formatted in two-column conference style. PANEL PROPOSALS up to 3 pages in length on timely and controversial topics are also welcome. These submissions should be formatted like a technical paper, and will if accepted be included in the conference proceedings. They should include: (a) An introduction by the organizer/moderator. (b) Position statements from each panelist. (c) Brief biographical sketches of all participants. ALL SUBMISSIONS WILL BE REFEREED, and no more will be accepted than can be comfortably presented in a single track (no parallel sessions). Authors of accepted papers will be required to prepare an electronic version for the on-line conference proceedings which will supplement the traditional printed volume. Some authors will also be asked to submit an electronic version of their paper for review purposes prior to acceptance, in ASCII or other human-readable format. Send 7 copies of full papers along with 2 copies of any accompanying videos, and 4 copies of panel proposals, to the Program Chair: David L. Jaffe Dept. of Veteran Affairs Medical Center 3801 Miranda Avenue - Mail Stop 153 Palo Alto CA 94304 ======================================================================== All submissions must be received no later than Tuesday, OCTOBER 17, 1995 ======================================================================== QUESTIONS regarding submissions should be directed to the Program Chair; for information regarding registration or other matters, please contact the General Chair. Here's how to reach these people: Program Chair: David L. Jaffe via phone: (415) 493 5000, ext 4480 via fax: (415) 493 4919 via Email: jaffe@roses.stanford.edu General Chair: Ephraim P. Glinert via phone: (518) 276 2657 via fax: (518) 276 4033 via Email: glinert@cs.rpi.edu BONUS: Plan now to attend two key conferences for the price of a single air ticket! ASSETS'96 will immediately precede CHI'96, which will take place in Vancouver on April 13-18, 1996. See you in Vancouver, Canada's jewel of the northwest! =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= General Chair: =--=--=--=--=--= Ephraim P. Glinert, Rensselaer Polytechnic Institute Program Committee: =--=--=--=--=--=--= David L. Jaffe (Chair), VA Medical Center, Palo Alto Meera M. Blattner, LLNL and University of California at Davis Julie Baca, Waterways Experiment Station James L. Caldwell, IBM Alireza Darvishi, University of Zurich (Switzerland) Patrick Demasco, University of Delaware Alistair D.N. Edwards, University of York (UK) Gerald L. Engel, NSF Harriet J. Fell, Northeastern University Carl Friedlander, ISX Corp. Ralph Guertin, MITRE Corp. Robert J.K. Jacob, Tufts University Earl Johnson, Sun Microsystems Laboratories Arthur I. Karshmer, New Mexico State University R. Benjamin Knapp, Stanford University Karen Kukich, Bell Communications Research Richard E. Ladner, University of Washington Clayton Lewis, University of Colorado at Boulder Elizabeth D. Mynatt, Georgia Institute of Technology David W. Patmore, University of California at Santa Cruz Helen Petrie, University of Hertfordshire (UK) T.V. Raman, DEC Cambridge Research Center Richard D. Steele, Tolfa Corp. Gary W. Strong, National Science Foundation Jim Thatcher, IBM Research A. Rudy Vener, AT&T Bell Labs Nicole Yankelovich, Sun Microsystems Treasurer: =--=--=--= David H. Leserman, NOAA From rem-conf-request@es.net Sun Aug 27 16:04:23 1995 Received: from cdp.igc.apc.org by osi-west.es.net with ESnet SMTP (PP); Sun, 27 Aug 1995 13:03:53 -0700 Received: from igc3.igc.apc.org (igc3.igc.apc.org [192.82.108.33]) by cdp.igc.apc.org (8.6.12/Revision: 1.204 ) with SMTP id NAA20087 for ; Sun, 27 Aug 1995 13:03:36 -0700 Received: from ppp25.igc.org (rswenson@ppp25.igc.org [198.94.6.25]) by igc3.igc.apc.org (8.6.12/Revision: 1.6 ) with SMTP id NAA10149 for ; Sun, 27 Aug 1995 13:03:29 -0700 Message-Id: <199508272003.NAA10149@igc3.igc.apc.org> X-Old-Sender: From: Ron Swenson Organization: Enigma Logic To: rem-conf@es.net Date: Tue, 22 Aug 1995 21:28:28 +0000 Subject: Content Development for Multicasts Reply-to: rswenson@igc.apc.org Priority: normal X-mailer: Pegasus Mail/Windows (v1.22) Sender: rswenson@igc.org Since joining this conference, I've seen mostly references to technical conferences and music concerts as multicasts on the M-Bone. I'm curious to know what near-term applications are being given serious consideration, and where to go to communicate with others who want to work with the medium from a creative arts standpoint. Is this (rem-conf) the place to do so? Thanks, Ron Swenson Enigma Logic [Dynamic Password ID Verification/Authentication] From rem-conf-request@es.net Sun Aug 27 17:36:23 1995 Received: from cs.nps.navy.mil by osi-west.es.net with ESnet SMTP (PP); Sun, 27 Aug 1995 14:35:49 -0700 Received: by cs.nps.navy.mil (4.1/SMI-4.1) id AA08093; Sun, 27 Aug 95 14:34:35 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9508272134.AA08093@cs.nps.navy.mil> Subject: Re: Content Development for Multicasts To: rswenson@igc.apc.org Date: Sun, 27 Aug 1995 14:34:24 -0700 (PDT) Cc: mbone@isi.edu (Multicast Backbone mail list), rem-conf@es.net (Remote Conferencing mail list), i3la_netdesign@mbari.org (I3LA Network Design Team) In-Reply-To: <199508272003.NAA10149@igc3.igc.apc.org> from "Ron Swenson" at Aug 22, 95 09:28:28 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 5405 You asked what efforts were underway for providing new content on the MBone. Our intention is to provide multicast capability to regional K-12 schools when working native multicast is supported and MBone tools have been ported to Macintosh and Windows. The schools we have connected are using 128 Kbps Frame Relay, but both lines and CSU/DSU hardware can scale to T1. Thus we expect a variety of educational content to eventually be ported to MBone. Technical considerations will include training and safeguards to prevent unintended global bandwidth disruptions. We hope to enable teachers and students to use these tools, but ordinarily just within our region (Monterey and Santa Cruz counties). Details on both our regional collaboration and school internetworking follow. Networked Ocean Science Research and Education, Monterey Bay California Don Brutzman, Ph.D. Code UW/Br, Naval Postgraduate School Monterey, California 93943 USA 408.656.2149 voice, 408.656.3679 fax brutzman@nps.navy.mil http://inet.nttam.com/HMP/PAPER/039/ INET 95 page with user comments form ftp://taurus.cs.nps.navy.mil/pub/i3la/i3laisoc.html Hypertext ftp://taurus.cs.nps.navy.mil/pub/i3la/i3laisoc.txt Text ftp://taurus.cs.nps.navy.mil/pub/i3la/i3laisoc.ps Postscript (4.5 M) ftp://taurus.cs.nps.navy.mil/pub/i3la/i3laisoc.au Audio abstract (752 K) Abstract. The Monterey BayNet regional network is connecting students, educators, researchers, institutions and individuals around a common theme of environmental and ocean science. A variety of exciting volunteer efforts are building networked information links that can effectively and compatibly operate at low and high speeds. Connectivity, content, access and applications are the four key areas of action. Throughout this large project we have learned that people issues are just as important as technical issues. Our efforts have developed a regional model which effectively supports education at all levels together with the conduct of active scientific research. This paper was presented at INET'95, the Internet Society's 1995 International Networking Conference in Honolulu, Hawaii, 27-30 June 1995. For more information, see: http://info.isoc.org/inet95.html ========== Internetworking: Planning and Implementing A Wide-Area Network (WAN) for K-12 Schools Randall J. Bigelow THESIS MASTER OF SCIENCE IN INFORMATION TECHNOLOGY MANAGEMENT NAVAL POSTGRADUATE SCHOOL September 1995 Available in hypertext, PostScript & text formats. http://www.stl.nps.navy.mil/~rjbigelo/thesis.html ABSTRACT. This thesis documents the planning, design and implementation of a regional wide-area network connecting K-12 schools, research institutions, libraries and institutions of higher education throughout the Monterey Bay area of California's central coast. The goal of the network is to enable students and educators to have access to the environmental information and resources available regionally via the Internet, at speeds which will encourage interaction and maintain interest. The wide-area network design process presents numerous human and technical challenges. These challenges are further amplified by the need to enable educators to design and implement school local area networks concurrent with the wide-area network solution. The processes used to resolve these myriad issues and the resulting solutions are of direct relevance to the K-12 community as well as network planners, administrators and funding partners. TABLE OF CONTENTS I. INTRODUCTION II. RELATED WORK III. PROBLEM STATEMENT IV. SOFTWARE APPLICATION SELECTION V. LOCAL AREA NETWORK (LAN) DESIGN VI. WIDE AREA NETWORK (WAN) DESIGN VII. IMPLEMENTATION RESULTS VIII. APPLICABILITY TO DEPARTMENT OF THE NAVY (DoN) SHORE COMMANDS IX. CONCLUSIONS APPENDIX A. MACINTOSH SOFTWARE DOWNLOAD SITES APPENDIX B. WINDOWS SOFTWARE DOWNLOAD SITES APPENDIX C. EIA/TIA-568B WIRING SCHEME IN A 10BASE-T PLUG APPENDIX D. EXAMPLE LAN DESIGNS APPENDIX E. MONTEREY BAYNET EQUIPMENT RECOMMENDATIONS APPENDIX F. REGISTERED JACK NUMBER 48 (RJ-48) PINOUT AND WIRING BETWEEN NIU AND CSU APPENDIX G. CHANNEL SERVICE UNIT/DIGITAL SERVICE UNIT (CSU/DSU) CONFIGURATION APPENDIX H. CISCO 2514 ROUTER CONFIGURATION APPENDIX I. MONTEREY BAYNET TOPOLOGY APPENDIX J. COMMITTED INFORMATION RATE (CIR) MATRIX APPENDIX K. OBTAINING AN IP NETWORK NUMBER APPENDIX L. MONTEREY BAYNET DOMAIN NAME SERVICE APPENDIX M. INSTRUCTIONS FOR THE US DOMAIN APPENDIX N. REGISTERING FOR AN AUTONOMOUS SYSTEM NUMBER APPENDIX O. MACTCP CONFIGURATION APPENDIX P. WINDOWS TRUMPET WINSOCK PACKET DRIVER CONFIGURATION APPENDIX Q. ACRONYMS LIST OF REFERENCES INITIAL DISTRIBUTION LIST Additional links: http://www.stl.nps.navy.mil/~rjbigelo/ all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA [Root 200] fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv_uvw.html From rem-conf-request@es.net Sun Aug 27 19:39:20 1995 Received: from relay.cdnnet.ca by osi-west.es.net with ESnet SMTP (PP); Sun, 27 Aug 1995 16:38:56 -0700 Received: (from ean@localhost) by relay.cdnnet.ca (8.6.10/8.6.9) id QAA18049 for rem-conf@es.net; Sun, 27 Aug 1995 16:38:54 -0700 X400-Received: by /PRMD=CA/ADMD=CDNnet/C=CA/; Relayed; Sun, 27 Aug 1995 16:38:52 UTC-0700 X400-Received: by /PRMD=CA/ADMD=CDNnet/C=CA/; Relayed; Sun, 27 Aug 1995 16:38:50 UTC-0700 Date: Sun, 27 Aug 1995 16:38:50 UTC-0700 X400-Originator: demco@cs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-MTS-Identifier: [/PRMD=CA/ADMD=CDNnet/C=CA/;950827163850] Content-Identifier: 37449 From: John Demco To: rem-conf@es.net Message-ID: <"37449*demco@cs.ubc.ca"@MHS> Subject: looking for remote control video camera MIME-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Hi, we're looking for a remote control video camera, something that allows remote pan, tilt, zoom, and focus and is controllable via an RS-232 interface. Any pointers, experiences, etc would be much appreciated. Thanks, --John John Demco E-mail: demco@cs.ubc.ca Department of Computer Science Tel: +1 (604) 822 6724 University of British Columbia Fax: +1 (604) 822 5485 Vancouver, BC, Canada V6T 1Z4 From rem-conf-request@es.net Sun Aug 27 20:33:35 1995 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Sun, 27 Aug 1995 17:32:20 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with ESMTP id RAA05728; Sun, 27 Aug 1995 17:31:56 -0700 Message-Id: <199508280031.RAA05728@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: brutzman@cs.nps.navy.mil (Don Brutzman) cc: rswenson@igc.apc.org, mbone@ISI.EDU (Multicast Backbone mail list), rem-conf@es.net (Remote Conferencing mail list), i3la_netdesign@mbari.org (I3LA Network Design Team) Subject: Re: Content Development for Multicasts In-reply-to: Your message of "Sun, 27 Aug 1995 14:34:24 PDT." <9508272134.AA08093@cs.nps.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 27 Aug 1995 17:31:56 -0700 From: "Amancio Hasty Jr." >>> Don Brutzman said: > You asked what efforts were underway for providing new content on the MBone. Why not give FreeBSD or Linux a chance ? One benefit that I can see right away is the pre-emptive multitask capability in FreeBSD and Linux. Amancio From rem-conf-request@es.net Sun Aug 27 22:04:38 1995 Received: from yorkie.cisco.com by osi-west.es.net with ESnet SMTP (PP); Sun, 27 Aug 1995 19:04:04 -0700 Received: (arch@localhost) by yorkie.cisco.com (8.6.8+c/8.6.5) id TAA00982; Sun, 27 Aug 1995 19:03:28 -0700 From: Arch Mott Message-Id: <199508280203.TAA00982@yorkie.cisco.com> Subject: Re: looking for remote control video camera To: demco@cs.ubc.ca (John Demco) Date: Sun, 27 Aug 1995 19:03:27 -0700 (PDT) Cc: rem-conf@es.net In-Reply-To: <"37449*demco@cs.ubc.ca"@MHS> from "John Demco" at Aug 27, 95 04:38:50 pm X-Mailer: ELM [version 2.5 PL0a6] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 312 In a mail message John Demco writes: > > Hi, we're looking for a remote control video camera, something that allows > remote pan, tilt, zoom, and focus and is controllable via an RS-232 > interface. Any pointers, experiences, etc would be much appreciated. > > Thanks, The Canon VC-C1 does this. -Arch. From rem-conf-request@es.net Mon Aug 28 01:06:56 1995 Received: from Csli.Stanford.EDU by osi-west.es.net with ESnet SMTP (PP); Sun, 27 Aug 1995 22:06:24 -0700 Received: from Csli.Stanford.EDU (localhost.Stanford.EDU [127.0.0.1]) by Csli.Stanford.EDU (8.6.11/8.6.11) with ESMTP id WAA25074; Sun, 27 Aug 1995 22:06:10 -0700 Message-Id: <199508280506.WAA25074@Csli.Stanford.EDU> To: Arch Mott cc: demco@cs.ubc.ca (John Demco), rem-conf@es.net Subject: Re: looking for remote control video camera In-reply-to: Your message of Sun, 27 Aug 1995 19:03:27 PDT. <199508280203.TAA00982@yorkie.cisco.com> Date: Sun, 27 Aug 1995 22:06:08 -0700 From: Christian Wettergren | In a mail message John Demco writes: | > | > Hi, we're looking for a remote control video camera, something that allow s | > remote pan, tilt, zoom, and focus and is controllable via an RS-232 | > interface. Any pointers, experiences, etc would be much appreciated. | > | > Thanks, | | The Canon VC-C1 does this. It might be that it is this model that only allows one operation at a time, which pretty much makes it useless. If it is cheap, be suspicious! :-) /Christian From rem-conf-request@es.net Mon Aug 28 03:54:15 1995 Received: from netcom20.netcom.com by osi-west.es.net with ESnet SMTP (PP); Mon, 28 Aug 1995 00:53:27 -0700 Received: by netcom20.netcom.com (8.6.12/Netcom) id AAA27240; Mon, 28 Aug 1995 00:50:59 -0700 From: sujo@netcom.com (Suresh K Jois) Message-Id: <199508280750.AAA27240@netcom20.netcom.com> Subject: Mbone app dev resources To: mbone@isi.edu, rem-conf@es.net Date: Mon, 28 Aug 1995 00:50:59 -0700 (PDT) Cc: sujo@netcom.com (Suresh K Jois) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1147 Hi, This is my first post to both mbone and rem-conf lists. Please excuse any transgressions. I'm planning on writing a set of mbone audio and video apps with special emphasis on multi-platform portability and close interface integration and some additional features over the existing ones. Given the fact that I'm completely MBONE unaware except for brief usage when I was at Sun and SGI (my current employer has no MBONE feed), what resources do I need to gather to do this, in terms of: - Network programming experience - Existing code base (is there any sort of library/API on top of which exising apps are built ?) - Ideal dev platform (Solaris/Windows NT - my preference/Linux ..) - Multicast capability addins for Windows NT/95 and Macintosh. I'm also looking for material on comparative analysis (from an engineering as well as commercial/business perspective) of MBONE vs. other technologies such as XING's proposed MPEG streamers, Cu-Seeme, RealAudio and Mulimedia IRC. Which of these will most likely be the future successful bearer of live multimedia content on the Internet. Much thanks for any input on this. - Suresh From rem-conf-request@es.net Mon Aug 28 05:24:25 1995 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Mon, 28 Aug 1995 02:23:56 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id LAA20168 (8.6.12/7.4f-FAU);; Mon, 28 Aug 1995 11:23:12 +0200 From: Toerless Eckert Message-Id: <199508280923.LAA20168@faui40.informatik.uni-erlangen.de> Subject: Re: looking for remote control video camera To: cwe@Csli.Stanford.EDU (Christian Wettergren) Date: Mon, 28 Aug 1995 11:23:10 +0200 (MET DST) Cc: arch@cisco.com, demco@cs.ubc.ca, rem-conf@es.net In-Reply-To: <199508280506.WAA25074@Csli.Stanford.EDU> from "Christian Wettergren" at Aug 27, 95 10:06:08 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 457 > It might be that it is this model that only allows one operation at a > time, which pretty much makes it useless. If it is cheap, be > suspicious! :-) The only thing you can't do are smooth pan & tilts, so you can either pan or tilt at a moment which means you can't do good movie pictures but for conferencing it's currently the best i know of (list price was somewhere at 2000$ or 3000 DM so there's nothing comparable at this price target). Toerless From rem-conf-request@es.net Mon Aug 28 07:29:10 1995 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Mon, 28 Aug 1995 04:28:39 -0700 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Mon, 28 Aug 1995 11:52:57 +0200 X-Mailer: exmh version 1.6.2 8/09/95 To: Toerless Eckert cc: cwe@csli.stanford.edu (Christian Wettergren), arch@cisco.com, demco@cs.ubc.ca, rem-conf@es.net From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: looking for remote control video camera In-reply-to: Your message of "Mon, 28 Aug 1995 11:23:10 +0200." <199508280923.LAA20168@faui40.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Aug 1995 11:49:01 +0200 Sender: schulzrinne@fokus.gmd.de Another possibility (although probably requiring significantly more interfacing work) is to use the mounts designed for security cameras. I just happened to pick up a catalogue by Soligor, which sells a motor mount for around $180, plus a control unit for $150 to $300 (translated German prices). Henning From rem-conf-request@es.net Mon Aug 28 10:00:08 1995 Received: from charon.cwi.nl by osi-west.es.net with ESnet SMTP (PP); Mon, 28 Aug 1995 06:59:42 -0700 Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP id ; Mon, 28 Aug 1995 15:59:38 +0200 Received: by schelvis.cwi.nl with SMTP id ; Mon, 28 Aug 1995 15:59:37 +0200 Message-Id: <9508281359.AA08562=jack@schelvis.cwi.nl> To: rem-conf@es.net Subject: Re: looking for remote control video camera In-Reply-To: Message by Toerless Eckert , Mon, 28 Aug 1995 11:23:10 +0200 (MET DST) , <199508280923.LAA20168@faui40.informatik.uni-erlangen.de> Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam Phone: +31 20 5924098(work), +31 20 5924199 (fax), +31 20 6160335(home) X-Last-Band-Seen: Campingflight to Lowlands Paradise (25 to 27-8) X-Mini-Review: Brilliant, despite the weather. Discovery: Heideroosjes! Date: Mon, 28 Aug 1995 15:59:36 +0200 From: Jack Jansen I've looked at the Sony HVR-500, but as far as I could tell from the datasheet it is not interfaceable with RS-232, it comes with a dedicated control box. If people know of a way to control this animal with RS-232 (or something else for which a computer interface is available) I would dearly like to know this. Besides doing pan/tilt the machine also interfaces to the remote control of a sony camera to allow you to do zooms. And it is only around $1000... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From rem-conf-request@es.net Mon Aug 28 10:07:37 1995 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Mon, 28 Aug 1995 07:06:36 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id QAA23081 (8.6.12/7.4f-FAU);; Mon, 28 Aug 1995 16:01:27 +0200 From: Toerless Eckert Message-Id: <199508281401.QAA23081@faui40.informatik.uni-erlangen.de> Subject: Re: looking for remote control video camera To: schulzrinne@fokus.gmd.de (Henning Schulzrinne) Date: Mon, 28 Aug 1995 15:59:26 +0200 (MET DST) Cc: Toerless.Eckert@informatik.uni-erlangen.de, cwe@csli.stanford.edu, arch@cisco.com, demco@cs.ubc.ca, rem-conf@es.net In-Reply-To: <199508281346.PAA27968@faui45.informatik.uni-erlangen.de> from "Henning Schulzrinne" at Aug 28, 95 11:49:01 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 406 > Another possibility (although probably requiring significantly more > interfacing work) is to use the mounts designed for security cameras. I > just happened to pick up a catalogue by Soligor, which sells a motor > mount for around $180, plus a control unit for $150 to $300 (translated > German prices). Those are very imprecise and do not allow control via rs232 from the host computer. Toerless From rem-conf-request@es.net Mon Aug 28 10:15:11 1995 Received: from prom.engin.umich.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 28 Aug 1995 07:14:15 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id KAA26763; Mon, 28 Aug 1995 10:13:57 -0400 Date: Mon, 28 Aug 1995 10:13:51 -0400 (EDT) From: "david a. schlussel" Subject: Re: looking for remote control video camera To: John Demco cc: rem-conf@es.net In-Reply-To: <"37449*demco@cs.ubc.ca"@MHS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII http://www.indstate.edu/msattler/sci-tech/comp/misc/remote-control.html +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On Sun, 27 Aug 1995, John Demco wrote: > Hi, we're looking for a remote control video camera, something that allows > remote pan, tilt, zoom, and focus and is controllable via an RS-232 > interface. Any pointers, experiences, etc would be much appreciated. > > Thanks, > --John > > John Demco E-mail: demco@cs.ubc.ca > Department of Computer Science Tel: +1 (604) 822 6724 > University of British Columbia Fax: +1 (604) 822 5485 > Vancouver, BC, Canada V6T 1Z4 > > From rem-conf-request@es.net Mon Aug 28 12:18:51 1995 Received: from Csli.Stanford.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 28 Aug 1995 09:18:08 -0700 Received: from Csli.Stanford.EDU (localhost.Stanford.EDU [127.0.0.1]) by Csli.Stanford.EDU (8.6.11/8.6.11) with ESMTP id JAA12150; Mon, 28 Aug 1995 09:17:58 -0700 Message-Id: <199508281617.JAA12150@Csli.Stanford.EDU> To: rem-conf@es.net cc: karl@it.kth.se Subject: Re: looking for remote control video camera Date: Mon, 28 Aug 1995 09:17:56 -0700 From: Christian Wettergren Info from our local camera-head guru! Hope you didn't mind Karl? :-) /Christian ------- Forwarded Message To: demco@cs.ubc.ca Cc: cwe@csli.stanford.edu, mex@it.kth.se Subject: Re: looking for remote control video camera Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 28 Aug 1995 10:32:54 +0200 From: Karl Simon Berg From: Christian Wettergren Subject: Re: looking for remote control video camera Date: Sun, 27 Aug 1995 19:08:24 -0700 > > | Hi, we're looking for a remote control video camera, something that allows > | remote pan, tilt, zoom, and focus and is controllable via an RS-232 > | interface. Any pointers, experiences, etc would be much appreciated. > > We have a camera head that can do most of these things, controllable > over Internet. It was used during the 33rd IETF by us. More details > are available by the cc:ed people. > > /Christian > During the IETF we used to types of camera heads: Canon VCC-1 which has a built in camera. It can be controlled through a remote control or via RS-232. It supports absolute positioning of pan, tilt and zoom, but only relative positioning of focus (or you can use auto focus, which isn't always that good). One annoying things about it is that it can only do one thing at a time (pan,tilt,focus,zoom). It's well documented and the protocol makes some sense. Parkervison Cameraman XLX on wich you can mount any camera you wish. If you wan't to control focus, iris and zoom you'll need a camera that supports this (haven't tried this yet because I don't know how to do it). It's normally control via a remote control and a builtin tracking system, but using an extra box you can use RS-232. It can move smoothly in all directions at the same time. The biggest problem is the lack of a good manual (seems like there's only one person in the word that really knows how to use the protocol, since he wrote it :-( ) We plan to try other cameras too, but so far these are the only ones I'm experienced with. simon ------- End of Forwarded Message From rem-conf-request@es.net Mon Aug 28 14:42:37 1995 Received: from mail1.digital.com by osi-west.es.net with ESnet SMTP (PP); Mon, 28 Aug 1995 11:41:59 -0700 Received: from bigpink.pa.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA23502; Mon, 28 Aug 1995 11:29:58 -0700 Received: by bigpink.pa.dec.com; id AA17423; Mon, 28 Aug 1995 10:50:44 -0700 Message-Id: <9508281750.AA17423@bigpink.pa.dec.com> To: John Demco Cc: rem-conf@es.net Subject: Re: looking for remote control video camera Date: Mon, 28 Aug 95 10:50:44 -0700 From: berc@pa.dec.com X-Mts: smtp We've been using a Cannon VC-C1 for the Severe Tire Damage mcasts. It's hooked up to the serial port of an Alpha, and is controlled by a stack of code (a camera daemon, some tcl programs and various cgi-bin scripts). The camera is on loan from Xerox; Ron Frederick and Berry Kercheval wrote most of the code and might make it available to the world. Two WWW interfaces to the camera control are at: http://chocolate.research.digital.com/grab.html http://chocolate.research.digital.com/std/control.html In general it seems to be a reasonable camera, though I'm not very happy with its exposure control. lance From rem-conf-request@es.net Tue Aug 29 00:45:18 1995 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Mon, 28 Aug 1995 21:44:50 -0700 Received: from kalonia.parc.xerox.com ([13.2.116.65]) by alpha.xerox.com with SMTP id <16695(2)>; Mon, 28 Aug 1995 21:44:43 PDT Received: from localhost by kalonia.parc.xerox.com with SMTP id <81931>; Mon, 28 Aug 1995 21:44:35 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: John Demco cc: rem-conf@es.net Subject: Re: looking for remote control video camera In-reply-to: Your message of "Sun, 27 Aug 95 16:38:50 PDT." <"37449*demco@cs.ubc.ca"@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Aug 1995 21:44:31 PDT Sender: Mark Weiser From: Mark Weiser Message-Id: <95Aug28.214435pdt.81931@kalonia.parc.xerox.com> Canon has a great RS-232 controllable pan-tilt-zoom, etc. camera. It is called the Canon VC-C1. -mark ----------- Spoken: Mark Weiser Email: weiser@ubiq.com URL: http://www.ubiq.com/weiser.html From rem-conf-request@es.net Tue Aug 29 12:07:11 1995 Received: from scorpio.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 29 Aug 1995 09:06:42 -0700 Received: by scorpio.arc.nasa.gov (940816.SGI.8.6.9/1.35) id GAA02125; Tue, 29 Aug 1995 06:07:43 -0700 Date: Tue, 29 Aug 1995 06:07:43 -0700 From: garyp@scorpio.arc.nasa.gov (Gary Paden) Message-Id: <199508291307.GAA02125@scorpio.arc.nasa.gov> To: rem-conf@es.net Subject: NASA Shuttle Mission STS-69 We are planning a Mbone broadcast August 31, 1995 - September 1,1995. We will be broadcasting at TTL 127 using nv. Detailed Mission Objectives can be found via the WWW at http://www.ksc.nasa.gov /shuttle/missions/sts-69/mission-sts-69.html Please contact me if this broadcast conflicts with any previously scheduled transmissions. Thanks Gary Paden Gary Paden NASA-Ames/Sterling garyp@scorpio.arc.nasa.gov (415)604-0082 From rem-conf-request@es.net Tue Aug 29 13:30:36 1995 Received: from quest.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 29 Aug 1995 10:29:53 -0700 Received: by quest.arc.nasa.gov (8.6.10/1.35) id KAA16945; Tue, 29 Aug 1995 10:31:19 -0700 Date: Tue, 29 Aug 1995 10:31:19 -0700 (PDT) From: Khamsa Enaya To: rem-conf@es.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe khamsa enaya From rem-conf-request@es.net Tue Aug 29 16:40:01 1995 Received: from rs1.hrz.th-darmstadt.de by osi-west.es.net with ESnet SMTP (PP); Tue, 29 Aug 1995 13:39:34 -0700 Received: from rs3.hrz.th-darmstadt.de (rs3.hrz.th-darmstadt.de [130.83.55.75]) by rs1.hrz.th-darmstadt.de (8.6.10/8.6.4) with ESMTP id WAA18199 for ; Tue, 29 Aug 1995 22:39:26 +0200 Received: from irx2.hrz.th-darmstadt.de (irx2.hrz.th-darmstadt.de [130.83.55.27]) by rs3.hrz.th-darmstadt.de (8.6.10/8.6.9pm+udb) with ESMTP id WAA15839 for ; Tue, 29 Aug 1995 22:39:15 +0200 From: Robert Kaempf Received: (kaempf@localhost) by irx2.hrz.th-darmstadt.de (950215.SGI.8.6.10/8.6.9) id WAA02896 for rem-conf@es.net; Tue, 29 Aug 1995 22:39:14 +0200 Message-Id: <199508292039.WAA02896@irx2.hrz.th-darmstadt.de> Subject: help To: rem-conf@es.net Date: Tue, 29 Aug 1995 22:39:14 +0200 (CDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 167 help -- Robert Kaempf, THD, Hochschulrechenzentrum, Petersenstr. 30, D-64287 Darmstadt E-Mail: kaempf@hrz.th-darmstadt.de Tel. +49 (0)6151 16-5588 Fax 16-3050 From rem-conf-request@es.net Tue Aug 29 21:04:39 1995 Received: from decu13.triumf.ca by osi-west.es.net with ESnet SMTP (PP); Tue, 29 Aug 1995 18:04:09 -0700 Received: by decu13.triumf.ca (5.65/DEC-Ultrix/4.3) id AA18669; Tue, 29 Aug 1995 18:04:06 -0700 Date: Tue, 29 Aug 1995 18:08:24 -0700 (PDT) From: Andrew Daviel To: rem-conf@es.net Subject: Timeshifting software ? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Email, ftp, WWW freed us from timezone problems. Mbone brings them back :( Is there any timeshifting software that would let someone record a sceduled conference at night and retransmit it locally during the day? Something that could be started from crontab and would record all common formats (nv, vat, wb, ivs ....) would be nice... I guess a couple of hours should fit on a mere 150Mb or so... Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 4004 Wesbrook Mall fax: 604-222-7307 Vancouver BC http://andrew.triumf.ca/~andrew Canada V6T 2A3 49D14.7N 123D13.6W From rem-conf-request@es.net Wed Aug 30 02:12:39 1995 Received: from taurus.cs.nps.navy.mil (actually cs.nps.navy.mil) by osi-west.es.net with ESnet SMTP (PP); Tue, 29 Aug 1995 23:12:11 -0700 Received: from libra.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA20477; Tue, 29 Aug 95 23:10:25 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9508300610.AA20477@taurus.cs.nps.navy.mil> Subject: unplugged.html To: graphicsnet@siggraph.org (GraphicsNet mail list), coco@siggraph.org (Coco Conn), zane@isaac.exploratorium.edu (zane vella), pax@ankh.metrolink.com (Garry Paxinos), web.s95@flsig.org (SIGGRAPH OnLine), earle@isolar.tujunga.ca.us (Greg Earle) Date: Tue, 29 Aug 1995 23:10:24 -0700 (PDT) Cc: mbone@isi.edu (Multicast Backbone mail list), rem-conf@es.net (Remote Conferencing mail list), i3la_edu@mbari.org (I3LA Education Team), evans@skaface.arc.nasa.gov (Dan Evans), JoSanders@wposmtp.nps.navy.mil (John Sanders), CWetteland@mntry.nps.navy.mil (Clyde Wetteland), mpesce@netcom.com (Mark D. Pesce) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 16512 Here is a detailed recap of our recent SIGGRAPH multicast. Comments and further lessons learned are welcome. Some pretty nice images and a quicktime video are on the home page. [Sorry but schedule and a diskspace bottleneck have delayed adding further video clips and audio from VRML and other taped sessions.] X-Within-Url: http://www.stl.nps.navy.mil/~brutzman/unplugged.html "MBONE UNPLUGGED" - or - how we created a wireless mobile television studio and multicast SIGGRAPH 95 world-wide over the Internet. _________________________________________________________________ WHAT, WHEN and WHERE was SIGGRAPH? Cool! Catalytic! Connected! The annual conference of the Association for Computing Machinery (ACM) Special Interest Group on Graphics (SIGGRAPH) includes over 30,000 computer experts, explorers, and enthusiasts from all over the world. All focused on the adventurous edge of cyberspace, interactive digital techniques, new entertainment media, networked communities, and the science that creates tomorrow's technologies. August 6-11 1995, Los Angeles Convention Center, Los Angeles California USA. OUR OBJECTIVES * Create a mobile studio for a weeklong KSIG-TV. SIGGRAPH exhibitors were our programs. * Provide content and lab facilities for local educators to learn about the Internet. Here is a video clip from local television station KCBA. They interviewed Tracey Emswiler about our efforts. The 50-second clip is a 19.2 MB QuickTime video. Tracey Emswiler KCBA video _________________________________________________________________ Enter the Cart... Here is the "MBone Unplugged" cart Jon Bigelow put together: MBone Cart The cart was WAY COOL! It included the following gear: * Silicon Graphics Inc. (SGI) entry-level Indy workstation * AirLAN wireless bridges (2 Mbps bandwidth, spread spectrum, ~ 1 GHz frequency band, no FCC license required) * Uninterruptible Power Supply (UPS), good for about 15 minutes * Standard VHS VCR and television monitor * Two VHS videocameras with tape capability and single mobile tripod * Wireless microphones, lapel and hand-held * Switch box to select camera/audio source * Video projector to put live imagery on any nearby wall * LOTS of wires, cables and adapters, all labeled at each end * Two cellular telephones for coordination and mobility * Broomstick to lift wireless antenna above cart * Various NPS master's students and passersby to push the darn thing This is the workstation of the future. It has everything: computing, graphics, live 2-way audio/video, mobility and global scope. We all want one now! Undoubtedly someone can make a much more compact version. The usefulness of this approach is perhaps the most important lesson we've learned. _________________________________________________________________ NETWORK CONSIDERATIONS GraphicsNet GraphicsNet was SIGGRAPH 95's high-performance, state-of-the-art communications infrastructure. It included ATM, HIPPI and Ethernet networks. We are particularly grateful for the help and expertise of the GraphicsNet team. Multicast Backbone (MBone) Here are links to an article on the Multicast Backbone (MBone) and an local MBone home page pointing to other free software and information resources. The following are a few of the MBone issues we grappled with. More will be added. We announced our intention to multicast during the week of 6-11 August 95 to the remote conferencing list (rem-conf@es.net). and also to the MBone Session Agenda scheduling home page at http://www.cilea.it/MBone/agenda.html. There were no objections to our plans. We intentionally stressed the MBone as much as possible, remaining within the community guidelines regarding permissible use. Our motivation was that the most interesting problems and fixes on the MBone often occur when someone is "pushing the envelope" of current capabilities. Originally we expected to share global MBone bandwidth with the NASA Select channel. Since the space shuttle mission was cancelled, we were able to use 256 Kbps video bandwidth as opposed to 128 Kbps video (the ordinary default). It was very helpful not to have to share bandwidth. Some coordination on site was neccessary with the GraphicsOnline team, but few difficulties occurred. We were glad to see that the MBone held up well. There were occasional problems with users elsewhere inadvertantly sending high-bandwidth video, but these were quickly detected and corrected, either by Van Jacobson (University of California, Lawrence Berkeley Laboratory) or the offending users themselves. This is a long-standing training problem. It has been alleviated somewhat by making transmission a little harder fro for naive users to turn on. Nevertheless we think it is a people problem which needs a people solution (e.g. simple effective training). mrouted difficulties and recovery In addition to the cart, we brought an old Sun 3/110 workstation to serve as the multicast router. Unfortunately there is a tiny switch on the back which we inadvertantly moved from "NORMAL" to "DIAGNOSTIC." This meant it would not boot and was effectively inoperable. If we had a flashlight, we might have figured out what we were doing wrong. As it turned out, Sun Microsystems loaned us a Sparc 20 workstation as a replacement mrouter. Greg Earle of NASA JPL reconfigured the kernel and saved us. Dan Evans of NASA Ames provided the encapsulated multicast tunnel from Moffett Field. On several occasions our mrouter stopped sending multicast due to bugs in the vic video tool crashing on the Sun mrouter. At the same time the machine appeared to be operational based on normal routing and continuous ping checks. This condition was hard to diagnose given our minimal use of multicast diagnostic tools. Better tool usability is needed. We are also considering putting the multicast router and tunnel endpoint right on the mobile machine. As long as it has enough cycles to operate, complete system state is right there for the user to evaluate. Our distance from the mrouter made it difficult to determine if our mrouter or an mrouter upstream from the convention center was the cause of MBone connectivity losses. As it turned out, all of our difficulties were tracable to our GraphicsNet mrouter. The production environment at SIGGRAPH was too noisy and dynamic to permit monitoring e-mail. We were able to get effective out-of-band communications from remote viewers by modifying the name field in the video-audio tool (vat). We used the net video (nv) software to multicast video. Our motivation for using nv was to permit another workstation to act as a reflector to CU-SeeMe. Unfortunately our CU-SeeMe expert never showed, and we didn't have time to learn it ourselves in mid-conference. In general, vic in .H261 mode is superior. H261 (part of the MPEG standards suite) is an asymmetric encoding, meaning that more computational work is performed by sender while higher framerate and lower effective bandwidth is enjoyed by the receivers. Previous tests showed that our Indy was able to handle this load effectively. We used vat audio software. Standard settings were employed (encoding PCM2). Modifications included setting Lecture mode for longer playouts, "Mike mutes Net" to prevent offsite interuptions, and use of the user's Name field to list each event by name as they occurred. It is of course very important to make sure someone is keeping track of the videotape being recorded so that new ones are started as soon as they are needed. Tracey Emswiler was in charge of event scheduling and coordinating the transitions to the next venue. It was a big help having a single person keep everything on track. Wireless considerations The AirLAN bridges are very slick. Called "smart bridges," they operate by listening for IP numbers on either side. Once the bridges know that a host is on one side or the other, any packets appearing on the opposite side are automatically sent across the bridge. Thus each side looks like a singe local-area network (LAN) without manual route reconfigurations. We found them to be reliable in a mobile environment, and the frequency agility of a spread spectrum approach made the link very robust despite lots of "trash RF" in this very crowded exhibition hall environment. _________________________________________________________________ EDUCATOR TRAINING IN MONTEREY [IMAGE] Teacher training is an ongoing project for us. K-12 collaboration has been particularly productive in helping us learn which technologies work for people and which don't. Click on the map above to learn more about our regional projects. These are the home pages we created for Monterey Bay use during this event. * Flyer: http://www.stl.nps.navy.mil/~tlemswil/flyer.html * What's happening: http://www.stl.nps.navy.mil/~tlemswil/ * Schedule: http://www.stl.nps.navy.mil/~tlemswil/schedule.html * Top 14 List - For Researchers, Educators and Kids: http://www.stl.nps.navy.mil/~tlemswil/ResearchersTop_14.html * Top 10 List - For Water Discovery Institute Teachers: http://www.stl.nps.navy.mil/~tlemswil/WaterDiscoveryTop_10.html More about our efforts in networked K-12 education: * Networked Ocean Science Research and Education, Monterey Bay California, available at http://inet.nttam.com/HMP/PAPER/039/ * Learning About Monterey Bay (LAMBAY) http://lambay.cse.ucsc.edu/mb * Monterey Bay Regional Education Futures (MBReEF) Consortium http://www.ucsc.edu/mbay-region * Initiative for Information Infrastructure & Linkage Applications (I3LA) ftp://taurus.cs.nps.navy.mil/pub/i3la/i3la.html * Real-time Environmental Information Network & Analysis System (REINAS) http://csl.cse.ucsc.edu/reinas.html _________________________________________________________________ FUTURE WORK We are still thinking over lessons learned and future work. Many of these issues will likely become theses for masters students in the NPS Information Infrastructure Research Group (IIRG). Queries are welcome. * digitally archive recorded videotapes for MBone-compatible access on demand * record a full week of K-12 Internet sessions at INET 96, Montreal Canada * do more cool educational stuff for free * learn new answers and new questions * cost-benefit comparisons between building custom videoteleconferencing (VTC) classrooms and mobile networked VTC carts * do the same thing at much higher bandwidth over ATM * show that Macs and PCs can be used for this, once they get multicast support built into the operating system kernel * distribute the software tools and technical exertise to regional K-12 schools when the technology is ready _________________________________________________________________ PEOPLE The "Unplugged" (unhinged?) Team in LA: MBone Unplugged Team * Don Brutzman (UW/Br) (brutzman@nps.navy.mil) AUV / IIRG / NPSNET research groups * Tracey Emswiler (ITM) (tlemswil@nps.navy.mil) Hamming "Learning to Learn" Multicast (graduates September 95) * Jon Bigelow (ITM) (rjbigelo@nps.navy.mil) Monterey BayNet (graduates August 95) * Beth Bacon (bbacon@attmail.com) Writer and communications consultant * Dan Bacon (CS) (bacon@cs.nps.navy.mil) Adding a physically based submarine to NPSNET (graduates September 95) and also in LA (but not pictured) * John Sanders (JoSanders@wposmtp.nps.navy.mil) NPS Public Affairs Officer (PAO) * LT Clyde Wetteland USN (CWetteland@mntry.nps.navy.mil) NPS Assistant Public Affairs Officer (PAO) Back in Monterey helping the teachers and students and researchers: * Dennis Trepanier (ITM) (dmtrepan@nps.navy.mil) Regional K-12 network management (graduates September 95) * Matthew Koebbe (Dr. Longhair) (phaedrus@nps.navy.mil) NPS Visualization Lab * CDR Bob Ellis (bellis@cs.nps.navy.mil) Computer Science Curriculum Officer * Charles Peyton Taylor (ctaylor@nps.navy.mil) Root 262 Macintosh Lab Manager * Katie Muir (kmuir@mbayaq.org) Monterey Bay Aquarium (MBA) Water Discovery Institute * Ray McClain (kmuir@mbayaq.org) Moss Landing Marine Laboratory - Researchers' Invitational * Jeff Forte (CS/ITM)(jeforte@nps.navy.mil) ATM, dual degree CS/ITM (September 96) * Michael Tiddy (ITM) (metiddy@nps.navy.mil) (September 96) _________________________________________________________________ THANKS * ACM SIGGRAPH * Coco Conn and Zane Vella, Interactive Communities and Digital Circus * GraphicsNet team including chair Marke Clinger (Fore Systems), Peter Haddad (Hewlett-Packard), Jeannette Dravk and Craig Schell and Amy Wong (Fore Systems) and the rest of the gang * Garry Paxinos (MetroLink Inc.) and the SIGGRAPH OnLine team * Virtual Reality Modeling Language (VRML) group * Diane Sena, Steve Webster, Jeff Bryant and Katie Muir (Monterey Bay Aquarium - MBA) * Peter Brewer and Bruce Gritton (Monterey Bay Aquarium Research Institute - MBARI) * John Morales, Frank Cardoza, Harry Thomas (NPS Electronic Media Division) and Tracy Hammond (NPS Registrar) * Mike Zyda, Dave Pratt, Mike Macedonia and the NPSNET group * Dan Evans and Greg Earle (NASA Ames and JPL) * Van Jacobson and the MBone list participants * Theresa-Marie Rhyne (Lockheed Martin) and the "Future Technologies" panel * Ray McClain (MLML) and Bob Ellis (NPS) * Terry Williams, Milena Cochran, Stefan Hudson and Gary Porter (NPS Systems Technology Lab) * Mike McCann and Matthew Koebbe (NPS Visualization Lab) * Mike Newman (Newman and Associates) * Silicon Graphics Inc. (SGI) and Sun Microsystems * I3LA Monterey Bay Educators * Hotel Nikko, Beverly Hills * and everyone else who helped that we've inadvertantly forgotten. T-SHIRTS AND BUTTONS These are the most competitive measure of SIGGRAPH value. We got t-shirts, buttons and a few paper sacks stuffed with unmarked bills from the following folks: * SIGGRAPH 95, SIGGRAPH 96 and ACM * GraphicsNet * Silicon Graphics Inc. and the OpenInventor group * Sun Microsystems * Journal of Graphics Tools * Mark Pesce, author of the new book "VRML: Entering CyberSpace" from New Riders Press * Hard Rock Cafe * Ed Debevic's Good Eats (including my favorite, "I'd Rather Be Bowling") Who OWES us shirts (we have long memories): * Parallax Graphics _________________________________________________________________ Still to write about: MBone monitoring tools, lessons learned from Monterey side, ATM demo with Parallax, individual sessions we recorded to tape digitized and placed online, etc. _________________________________________________________________ This is a first draft, more will be added. AUTHORS: DON BRUTZMAN AND TRACEY EMSWILER "MBone Unplugged" http://www.stl.nps.navy.mil/~brutzman/unplugged.html -- Don Brutzman Naval Postgraduate School, Code UW/Br work 408.656.2149 Monterey California 93943-5000 USA [Root 200] fax 408.656.3679 AUV Underwater Virtual World ftp://taurus.cs.nps.navy.mil/pub/auv/auv_uvw.html From rem-conf-request@es.net Wed Aug 30 08:59:16 1995 Received: from cismsun.univ-lyon1.fr by osi-west.es.net with ESnet SMTP (PP); Wed, 30 Aug 1995 05:58:48 -0700 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id OAA28126 for rem-conf@es.net; Wed, 30 Aug 1995 14:58:42 +0200 Message-Id: <199508301258.OAA28126@cismsun.univ-lyon1.fr> Subject: Parallax card To: rem-conf@es.net Date: Wed, 30 Aug 1995 14:58:41 +0200 (MET DST) From: Lucia Gradinariu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 299 Hi, have anybody experienced with a Parallax card on SS20/611MP (bipros upgraded from ss20/50) as I've got into a real problem: the station locks in the Power On Test at boot time and (ats SUN sais) the Parallax card "burns" the Sparc modules. thanks for any help! Lucia.Gradinariu@univ-lyon1.fr From rem-conf-request@es.net Wed Aug 30 10:32:51 1995 Received: from barque.mdcorp.ksc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 30 Aug 1995 07:32:14 -0700 Received: by barque.mdcorp.ksc.nasa.gov (940816.SGI.8.6.9/940406.SGI.db4) id KAA07763; Wed, 30 Aug 1995 10:33:48 -0400 From: Daniel Beavers Message-Id: <9508301033.ZM7761@barque.mdcorp.ksc.nasa.gov> Date: Wed, 30 Aug 1995 10:33:47 -0400 In-Reply-To: Andrew Daviel "Timeshifting software ?" (Aug 29, 21:17) References: X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Andrew Daviel , rem-conf@es.net Subject: Re: Timeshifting software ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 29, 21:17, Andrew Daviel wrote: > Subject: Timeshifting software ? > Email, ftp, WWW freed us from timezone problems. Mbone brings them back :( > > Is there any timeshifting software that would let someone record a > sceduled conference at night and retransmit it locally during the day? > Something that could be started from crontab and would record all common > formats (nv, vat, wb, ivs ....) would be nice... I guess a couple of > hours should fit on a mere 150Mb or so... >-- End of excerpt from Andrew Daviel How about a VCR and a simple cron script? -- Daniel Beavers, Daniel.Beavers-1@ksc.nasa.gov, Voice: 407/383-2877, Fax: 407/269-6202, McDonnell Douglas, PO Box 21233, Dep F164, Kennedy Space Ctr, FL 32815 From rem-conf-request@es.net Wed Aug 30 11:22:03 1995 Received: from stargate.ecn.purdue.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 30 Aug 1995 08:21:39 -0700 Received: from stargate.ecn.purdue.edu (salama@localhost) by stargate.ecn.purdue.edu (8.6.12/3.7davy) id KAA11734; Wed, 30 Aug 1995 10:21:37 -0500 Message-Id: <199508301521.KAA11734@stargate.ecn.purdue.edu> From: Paul Salama Subject: unsubscribe To: rem-conf@es.net Date: Wed, 30 Aug 1995 10:21:36 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 12 unsubscribe From rem-conf-request@es.net Wed Aug 30 16:29:19 1995 Received: from decu13.triumf.ca by osi-west.es.net with ESnet SMTP (PP); Wed, 30 Aug 1995 13:28:45 -0700 Received: by decu13.triumf.ca (5.65/DEC-Ultrix/4.3) id AA23908; Wed, 30 Aug 1995 13:28:40 -0700 Date: Wed, 30 Aug 1995 13:32:58 -0700 (PDT) From: Andrew Daviel To: rem-conf@es.net Subject: IP addresses in the multicast domain, & choosing new ones Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just discovered that there are a number of IP addresses assigned in the multicast domain (mcast.net). If everyone knew but me, my apologies. On my Linux system I can get the list by using "host -l mcast.net". There is a sorted copy in http://andrew.triumf.ca/pub/mbone/mcast-hosts.txt My next question - the README I have for sd says that it picks a "unique, non-conflicting multicast address" for a new session. If some organisations have laid claim to a particular address, should one therefore avoid named addresses in creating new sessions? Does sd do this already? Should we all register a name with InterNIC if we want to generate global conferences? If I create a new session with a TTL of 127, is there any mechanism to prevent it conflicting with an address in use by someone in another country with a small TTL, which my sd wouldn't see, except that I ought to ask on rem-conf? Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 4004 Wesbrook Mall fax: 604-222-7307 Vancouver BC http://andrew.triumf.ca/~andrew Canada V6T 2A3 49D14.7N 123D13.6W From rem-conf-request@es.net Wed Aug 30 18:49:52 1995 Received: from mail1.eworld.com (actually hp1.online.apple.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 30 Aug 1995 15:49:27 -0700 Received: by hp1.online.apple.com (1.37.109.16/16.2) id AA221412935; Wed, 30 Aug 1995 15:48:55 -0700 Date: Wed, 30 Aug 1995 15:48:55 -0700 From: Davidwfox@eworld.com Message-Id: <950830154851_14164706@eWorld.com> To: rem-conf@es.net Subject: ISDN & M-Bone Greetings, Just about to install 128k ISDN connected to Mac server network in our home. Will we be able to connect to the M-Bone and if so, what special equipment do we need? thanks David Fox KnowledgeWeb www.kweb.com From rem-conf-request@es.net Thu Aug 31 07:46:08 1995 Received: from farsta.trab.se (actually sibaratorn.farsta.trab.se) by osi-west.es.net with ESnet SMTP (PP); Thu, 31 Aug 1995 04:45:28 -0700 Received: by farsta.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Thu, 31 Aug 95 12:57:22 +0200 (MET) Date: Thu, 31 Aug 95 12:57:22 +0200 From: Erling Mattsson Message-Id: <9508311057.AA18371@farsta.trab.se> To: rem-conf@es.net Subject: rem-conf-request@es.net From rem-conf-request@es.net Thu Aug 31 08:45:01 1995 Received: from farsta.trab.se (actually sibaratorn.farsta.trab.se) by osi-west.es.net with ESnet SMTP (PP); Thu, 31 Aug 1995 05:44:30 -0700 Received: by farsta.trab.se (5.65+bind 1.7+ida 1.4.2/TRM-1-NS); Thu, 31 Aug 95 14:40:41 +0200 (MET) Date: Thu, 31 Aug 95 14:40:41 +0200 From: Erling Mattsson Message-Id: <9508311240.AA18667@farsta.trab.se> To: rem-conf@es.net Subject: From rem-conf-request@es.net Thu Aug 31 09:49:17 1995 Received: from dragon.cc.ncsu.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 31 Aug 1995 06:48:46 -0700 Received: by dragon.cc.ncsu.edu (8.6.9/UC06jan95) id JAA22401; Thu, 31 Aug 1995 09:48:44 -0400 From: paemer@unity.ncsu.edu Message-Id: <199508311348.JAA22401@dragon.cc.ncsu.edu> Subject: linux mrouted To: rem-conf@es.net Date: Thu, 31 Aug 1995 09:48:43 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24/POP] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 521 group, Can someone direct me to an ftp site for a linux mrouted binary - or the source? thanks, phil -- ======================================================================== Phillip Emer | phil_emer@ncsu.edu Network Engineer | 919-515-5491 Research, Development and Data Communications | North Carolina State University | 110 Hillsborough Bldg. ======================================================================== From rem-conf-request@es.net Thu Aug 31 12:42:09 1995 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Thu, 31 Aug 1995 09:41:34 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15947(1)>; Thu, 31 Aug 1995 09:41:15 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Thu, 31 Aug 1995 09:41:07 -0700 To: paemer@unity.ncsu.edu cc: rem-conf@es.net Subject: Re: linux mrouted In-reply-to: Your message of "Thu, 31 Aug 95 06:48:43 PDT." <199508311348.JAA22401@dragon.cc.ncsu.edu> Date: Thu, 31 Aug 1995 09:40:52 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Aug31.094107pdt.177475@crevenia.parc.xerox.com> In message <199508311348.JAA22401@dragon.cc.ncsu.edu> you write: >Can someone direct me to an ftp site for a linux mrouted binary - or the >source? The mrouted source is available from ftp.parc.xerox.com in /pub/net-research/ipmulti/mrouted-3.6.tar.gz . However, multicast forwarding requires kernel support, which I don't think exists in Linux yet. Bill From rem-conf-request@es.net Thu Aug 31 12:45:36 1995 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Thu, 31 Aug 1995 09:44:53 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15967(5)>; Thu, 31 Aug 1995 09:44:36 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Thu, 31 Aug 1995 09:44:23 -0700 To: Davidwfox@eworld.com cc: rem-conf@es.net Subject: Re: ISDN & M-Bone In-reply-to: Your message of "Wed, 30 Aug 95 15:48:55 PDT." <950830154851_14164706@eWorld.com> Date: Thu, 31 Aug 1995 09:44:11 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Aug31.094423pdt.177475@crevenia.parc.xerox.com> In message <950830154851_14164706@eWorld.com> you write: >Just about to install 128k ISDN connected to Mac server network in our home. >Will we be able to connect to the M-Bone and if so, what special equipment do >we need? I occasionally run a tunnel over my ISDN link, it works very well for audio and if you do priority dropping you can get some vague idea of what the video is supposed to look like. You need a multicast capable router at your home. I'm pretty sure that MacTCP doesn't do multicast forwarding; I don't know if MachTen does or not. You might need to find a UNIX box (e.g. a cheap PC running FreeBSD) to put at your end. Or, if the ends of the ISDN line are real routers, (as opposed to a bridge), you might be able to turn on multicast forwarding on them. Bill From rem-conf-request@es.net Thu Aug 31 14:47:11 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Thu, 31 Aug 1995 11:46:32 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12847; 31 Aug 95 14:37 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-avt-cellb-06.txt Date: Thu, 31 Aug 95 14:37:07 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9508311437.aa12847@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format of CellB Video Encoding Author(s) : M. Speer, D. Hoffman Filename : draft-ietf-avt-cellb-06.txt Pages : 22 Date : 08/29/1995 This draft describes a packetization scheme for the CellB video encoding. The scheme proposed allow applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB. Internet-Drafts are 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-avt-cellb-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-cellb-06.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-cellb-06.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@cnri.reston.va.us. 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@ds.internic.net" Content-Type: text/plain Content-ID: <19950829135614.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-cellb-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-cellb-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950829135614.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Aug 31 14:59:00 1995 Received: from apple.com by osi-west.es.net with ESnet SMTP (PP); Thu, 31 Aug 1995 11:57:57 -0700 Received: from atg.apple.com by apple.com with SMTP (5.61/8-Oct-1993-eef) id AA19429; Thu, 31 Aug 95 11:57:55 -0700 for rem-conf@es.net Received: from [17.255.9.143] (jpallas.atg.apple.com [17.255.9.143]) by atg.apple.com (8.6.12/8.6.9) with SMTP id LAA17068; Thu, 31 Aug 1995 11:52:36 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Aug 1995 11:55:32 -0700 To: Bill Fenner , Davidwfox@eworld.com From: Pallas@Apple.COM (Joe Pallas) Subject: Re: ISDN & M-Bone Cc: rem-conf@es.net At 9:44 AM 8/31/95, Bill Fenner wrote: >You need a multicast capable router at your home. I'm pretty sure that >MacTCP doesn't do multicast forwarding; Correct. The new OpenTransport networking stack supports host-level multicast. The code for multicast routing is also in there, but as far as I know it has never been tested. joe -- Joe Pallas Apple Computer, Advanced Technology Group, Lab X From rem-conf-request@es.net Thu Aug 31 15:01:27 1995 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Thu, 31 Aug 1995 12:00:21 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with ESMTP id LAA00807; Thu, 31 Aug 1995 11:59:41 -0700 Message-Id: <199508311859.LAA00807@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Bill Fenner cc: Davidwfox@eworld.com, rem-conf@es.net Subject: Re: ISDN & M-Bone In-reply-to: Your message of "Thu, 31 Aug 1995 09:44:11 PDT." <95Aug31.094423pdt.177475@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Aug 1995 11:59:40 -0700 From: "Amancio Hasty Jr." Hmm.. I have a 128kb ISDN line and it works okay for mbone applications. A few weeks ago , we did a test of nv point to point from Wisconsin to here in San Francisco . The video was acceptable and the audio using bat was great. In fact the demo was so good that I am upgrading my system to a PCI based motherboard and I am going to buy a video capture and a camera. BTW: Does anyone have a suggestion for a video camera? Tnks, Amancio >>> Bill Fenner said: > In message <950830154851_14164706@eWorld.com> you write: > >Just about to install 128k ISDN connected to Mac server network in our home . > >Will we be able to connect to the M-Bone and if so, what special equipment do > >we need? > > I occasionally run a tunnel over my ISDN link, it works very well for audio > and if you do priority dropping you can get some vague idea of what the > video is supposed to look like. > > You need a multicast capable router at your home. I'm pretty sure that > MacTCP doesn't do multicast forwarding; I don't know if MachTen does or > not. You might need to find a UNIX box (e.g. a cheap PC running FreeBSD) > to put at your end. Or, if the ends of the ISDN line are real routers, > (as opposed to a bridge), you might be able to turn on multicast forwarding > on them. > > Bill Amancio Hasty Hasty Software Consulting Services Tel: 415-495-3046 Cellular: 415-309-8434 e-mail: hasty@star-gate.com Powered by FreeBSD From rem-conf-request@es.net Thu Aug 31 15:02:54 1995 Received: from mail2.digital.com by osi-west.es.net with ESnet SMTP (PP); Thu, 31 Aug 1995 12:01:50 -0700 Received: from us2rmc.zko.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA27611; Thu, 31 Aug 1995 11:48:09 -0700 Received: from samson.enet by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA16054; Thu, 31 Aug 95 14:45:52 -0400 Message-Id: <9508311845.AA16054@us2rmc.zko.dec.com> Received: from samson.enet; by us2rmc.enet; Thu, 31 Aug 95 14:45:52 EDT Date: Thu, 31 Aug 95 14:45:52 EDT From: MobiCom 95 - Removing the Shackles 31-Aug-1995 1448 To: rem-conf@es.net Apparently-To: rem-conf@es.net Subject: ACM MobiCom '95 - Advance Program ----- Please accept our apologies if you receive this message multiple times. This is because your name is on multiple mailing lists to which this memo has been targetted. ----- ACM presents ============== MobiCom '95 ============== THE FIRST INTERNATIONAL CONFERENCE ON MOBILE COMPUTING AND NETWORKING 1995 November 13-15, 1995 Claremont Hotel, Berkeley, California, USA ------------------------------------------------------------- Sponsored by ACM's Special Interest Groups: SIGCOM, SIGOPS, SIGMETRICS, SIGACT and by CESDIS NASA ------------------------------------------------------------- --------------------------------------------- Important Deadlines: * Early Registration: October 20, 1995 * Guaranteed Hotel Rates: October 12, 1995 --------------------------------------------- MobiCom is ACM's annual international conference, established to serve as the premier forum for addressing networks, systems, algorithms and applications that support the symbiosis of portable computers and wireless networks. MobiCom '95 is the first conference to bring together computing researchers and professionals studying mobility issues from several different perspectives: * Designing effective mobile computing environments that can deal with changing and sporadic connectivity * Architecting end-to-end networks of wireless and wired segments * Building applications for providing robust ubiquitous service. ----------------------------------- Tech Track: November 14-15, 1995 ----------------------------------- Two days of intensive single-track highly selective technical sessions, including: + Impact of Mobility on + ATM & Wireless Networks Data Management + Mobile Systems Performance + Mobile Network Protocols + Multimedia in a mobile + Location Management environment + TCP/IP over Wireless Networks + Other Emerging Issues --------------------------------- Special Highlights --------------------------------- + Tutorials on Mobile Computing, Mobile IP and Wireless Mobile Networking, November 13, 1995 + Keynote speech on "Nomadic Computing" by Leonard Kleinrock, UCLA + Invited talk: "Mobile and Wireless Computing: From Packet Radio to Mobile Information Infrastructure", Barry Leiner, ARPA + Panel: "Future Mobile Communications and Government funded Research" + Opportunities to demo; to "cross-pollinate" among people with overlapping interests but different emphases --------------------------------- Social Events --------------------------------- + Opening night Welcome Reception + Lunches and breaks included with conference registration + Tuesday night cocktails and conference Dinner Banquet + Opportunity to view state-of-art demonstrations in mobile computing and networking + Exclusive invitation for MobiCom participants to view InfoPad and Barwan projects ---------------------------- Hotel Information ---------------------------- Claremont Resort Hotel Phone: +1 800 551-7266 Ashby and Domingo Avenues +1 510 843-3000 Berkeley, CA 94623-0363, USA Fax: +1 510 848-6208 MobiCom '95 will be held at the Claremont Resort, Spa and Tennis Club located in Berkeley, California at Ashby and Domingo Avenues. The Claremont is a castle-like hotel located on 22 beautifully landscaped acres in the Berkeley Hills, at the Berkeley /Oakland border. It was built in 1915 in time for the Pan-Pacific Exposition, and provides spectacular views of the San Francisco Bay and the Golden Gate Bridge. It is 10 minutes from UC Berkeley and half an hour from San Francisco. ---------------------------- For More Information ---------------------------- We invite you to visit our Web Page and/or grab the Advance Program and registration information for MobiCom '95 via anonymous ftp. See for yourself the details of an exciting program planned for this first MobiCom Conference. Web Page: http://www.acm.org/sigcomm/mobicom95/ FTP Site: ftp.cs.utexas.edu ( /pub/mobicom95/ ) Email: mobicom95@samson.enet.dec.com * We hope to see you in Berkeley, California in November for MobiCom '95 * From rem-conf-request@es.net Thu Aug 31 15:05:17 1995 Received: from decu13.triumf.ca by osi-west.es.net with ESnet SMTP (PP); Thu, 31 Aug 1995 12:03:08 -0700 Received: by decu13.triumf.ca (5.65/DEC-Ultrix/4.3) id AA05956; Thu, 31 Aug 1995 12:01:16 -0700 Date: Thu, 31 Aug 1995 12:06:12 -0700 (PDT) From: Andrew Daviel To: paemer@unity.ncsu.edu Cc: rem-conf@es.net Subject: Re: linux mrouted In-Reply-To: <95Aug31.094107pdt.177475@crevenia.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In message <199508311348.JAA22401@dragon.cc.ncsu.edu> you write: >Can someone direct me to an ftp site for a linux mrouted binary - or the >source? On Thu, 31 Aug 1995, Bill Fenner wrote: > However, multicast > forwarding requires kernel support, which I don't think exists in > Linux yet. =From: Alan Cox =To: linux-multicast@www.linux.org.uk =Subject: mrouted =Progress: = I have a very clean working port of mrouted user mode code running. = =I've added the VIF code and fixed the IGMP code in Linux 1.3.x (mix of =stupid programmer bug and gcc bugs). mrouted now configures the vifs =correctly. I don't yet have a pair of 1.3.22pre kernels going to test =mrouted->mrouted but thats next. 1.3.22 should include the code so far =and I'll distribute the test mrouted set. If that builds the trees right =then I'll fix the ip forwarding flow control problems and drop in =the multicast routing caches. Sounds like you need to wait a bit yet. You could subscribe to the linux-multicast list to keep abreast. Send mail to linux-multicast-request@www.linux.org.uk Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 4004 Wesbrook Mall fax: 604-222-7307 Vancouver BC http://andrew.triumf.ca/~andrew Canada V6T 2A3 49D14.7N 123D13.6W