From rem-conf-request@es.net Tue Jul 04 04:03:22 1995 Received: from voga.rmit.EDU.AU by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Jul 1995 01:02:51 -0700 Received: from exxilon.xx.rmit.EDU.AU by voga.rmit.EDU.AU with SMTP id AA28354 (5.65c/IDA-1.5/qva1-oz for ); Tue, 4 Jul 1995 18:02:38 +1000 Received: (richard@localhost) by exxilon.xx.rmit.EDU.AU (8.6.12/8.6.4/ram5) id SAA19008 for rem-conf@es.net; Tue, 4 Jul 1995 18:02:07 +1000 From: "Richard A. Muirden" Message-Id: <199507040802.SAA19008@exxilon.xx.rmit.EDU.AU> Subject: Short Notice of broadcast To: rem-conf@es.net Date: Tue, 4 Jul 1995 18:02:05 +1000 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1087 Hi all, >From 14:00 AEST July 5, 1995, The Hon. Paul Keating, Prime Minister of Australia will be attending The Royal Melbourne Institute of Technology (University) - RMIT - To officially open a new building. This broadcast will be carried to the Mbone along with CU-SeeMe (reflector: reflector.rmit.edu.au). The PM is expected to arrive at approx. 14:45 for the ceremonies. Sorry for the short notice here but I have only just returned from INET '95 and found out! Broadcast will comprise audio and vic/h.261 encoded video. An 'sd' session will appear shortly. An entry has been placed on the Mbone Agenda. -richard. -- Richard A. Muirden, Sys. Admin |Fan of Shostakovich, "Star Trek" and BOEING! Mailto: richard@rmit.EDU.AU |The Boeing 777 - The Magnificient Sevens!!! Phone: (+61 3) 9660 3814 |I created alt.fan.shostakovich! Fly: UA,AN,WN http://www.rmit.edu.au/richard |Can *YOU* beat my 113 Shost CD's? :-) "If it ain't Boeing, I ain't going!" * "I pity all of us who must fly Airbus!" * 1995: Remembering 20 years since the death of Shostakovich (1906-75) * From rem-conf-request@es.net Wed Jul 05 09:41:34 1995 Received: from crdems.ge.com by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jul 1995 06:40:42 -0700 Received: from grymoire.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA22436; Wed, 5 Jul 95 09:39:57 -0400 Received: by grymoire.crd.ge.com (5.x/GE-CRD Standard Sendmail Version S1.5)id AA00960; Wed, 5 Jul 1995 09:40:39 -0400 Date: Wed, 5 Jul 1995 09:40:39 -0400 From: barnett@grymoire.crd.ge.com (Bruce Barnett) Message-Id: <9507051340.AA00960@grymoire.crd.ge.com> To: rem-conf@es.net, idmr@cs.ucl.ac.uk Subject: Need for large bank of private, static Multicast Addresses X-Sun-Charset: US-ASCII GE/NBC has the immediate need for a bank of Class D addresses (20 to 100). SD, IGMP. do not meet our current requirements, and the addresses are assigned statically. This is for dozens of private, dedicated networks, tying into a LAN at a customer's site through a specialized (non-Internet) firewall router. Therefore, we could use any Class D address without impacting the Internet. The sites are not on the MBONE, and are not connected to the Internet. Still, we'd like to follow as many of the standards as possible. In one of Van Jacobson's papers about administrative scoping, he mentioned the address range 239.0.0.0 to 239.255.255.255 could be reserved for "local use", and could be treated as addresses used inside an organizational boundry. We believe this is exactly what we want. Does anyone see any problem with us using these multicast addresses for this purpose? As I mentioned, our need is immediate. Bruce Barnett Computer Scientist GE Corporate Research and Development Center From rem-conf-request@es.net Wed Jul 05 13:27:27 1995 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jul 1995 10:27:00 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id KAA10350; Wed, 5 Jul 1995 10:26:40 -0700 Message-Id: <199507051726.KAA10350@rx7.ee.lbl.gov> To: barnett@grymoire.crd.ge.com (Bruce Barnett) cc: rem-conf@es.net, idmr@cs.ucl.ac.uk Subject: Re: Need for large bank of private, static Multicast Addresses In-reply-to: Your message of Wed, 05 Jul 95 09:40:39 EDT. Date: Wed, 05 Jul 95 10:26:40 PDT From: Van Jacobson Yes, I think administratively scoped addresses are exactly what you want. Mrouted 3.5 & later have support for administrative scoping so you should make sure you're running mrouted 3.6, at least on the routers at the boundary of each scope region. The sample mrouted.conf file distributed with mrouted 3.6 contains a few examples of setting an administrative scope boundary on a link or tunnel. I believe that Steve Deering has asked IANA to allocate the 239.x.x.x region of the multicast address space for use by administrative scoping. There hasn't been a new Assigned Numbers RFC issued since he made the request so I don't know if the allocation is official yet. If not, it should be soon. - Van From rem-conf-request@es.net Wed Jul 05 16:06:30 1995 Received: from Princeton.EDU by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jul 1995 13:05:35 -0700 Received: from acupain.UUCP by Princeton.EDU (5.65b/2.122/princeton) id AA01569; Wed, 5 Jul 95 16:01:12 -0400 Received: by Accurate.COM (4.1/SMI-4.0) id AA16411; Wed, 5 Jul 95 15:14:27 EDT Message-Id: <9507051914.AA16411@Accurate.COM> To: rem-conf@es.net Reply-To: Ed Levinson Cc: Ed Levinson Subject: IETF mbone site in NJ, Phila, NYC? Organization: Accurate Information Systems, Inc. X-Org-Addr: 2 Industrial Way X-Org-Addr: Eatontown, NJ 08840 X-Org-Misc: 1.908.389.5550 (phone) 1.908.389.5556 (fax) X-Mailer: MH 6.8 Date: Wed, 05 Jul 1995 15:14:27 -0400 From: Ed Levinson Hi, Would you like company while you tune in the IETF? How 'bout an IETF "superbowl" party. I want to participate in the IETF meeting this month via the mbone but I don't have the resouces to be my own site. Is there a site, in the Phila to NYC corridor (and environs) at which I can sit in the audience and participate? I'll bring the fixin's for the traditional IETF breaks. The sessions I'm interested in are (based on the draft agenda): Stockholm time 0930 1300 1530 1930 EDT 0330 0700 0930 1330 MON gotit html TUE mimereg WED rfc1006 mimesgml Notes: - assumption is that Stockholm time is Daylight savings otherwise EDT time will be one hour later. - mimesgml has not been noted as mbone but will be. Thanks.../Ed Ed Levinson, co-chair mimesgml Working Group PS please respond directly to me, I'm not a participant on this list. From rem-conf-request@es.net Wed Jul 05 19:11:38 1995 Received: from inet-gw-2.pa.dec.com by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jul 1995 12:47:10 -0700 Received: from bigpink.pa.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA16288; Wed, 5 Jul 95 12:40:16 -0700 Received: by bigpink.pa.dec.com; id AA26532; Wed, 5 Jul 1995 12:40:20 -0700 Message-Id: <9507051940.AA26532@bigpink.pa.dec.com> To: rem-conf@es.net Cc: band@std.com Subject: Severe Tire Damage 5-Jul-95 Date: Wed, 05 Jul 95 12:40:20 -0700 From: berc@pa.dec.com X-Mts: smtp What: Severe Tire Damage Concert Date: 5-Jul-95 Time: 9pm - 9:30pm PDT From: The Fabulous SubForum (nee Garage) Systems Research Center Digital Equipment Corporation Palo Alto, California Addr: 224.2.246.152 vat: 17000 nv: 33000 Celebrate working WWW camera control and the birthday of the USofA by tuning into STD's mcast tonight (or tomorrow morning for our friends on the other side of the Pacific Rim). Lance Berc berc@src.dec.com Camera control and still image grabbing: http://chocolate.research.digital.com/std/control.html http://chocolate.research.digital.com/std/grab.html STD info: http://www.ubiq.com/std/band.html http://www.std.com/homepages/band mailto:band@std.com MBone tools for Alpha workstation: http://chocolate.research.digital.com/mbone From rem-conf-request@es.net Wed Jul 05 22:17:28 1995 Received: from cavebear.com (actually pax.cavebear.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jul 1995 19:17:04 -0700 Received: by cavebear.com (4.1/SMI-4.1) id AA02980; Wed, 5 Jul 95 19:16:46 PDT Date: Wed, 5 Jul 1995 19:16:45 -0700 (PDT) From: Stephen Casner X-Sender: casner@pax.cavebear.com To: rem-conf@es.net, h32z2-list@mtgbcs.mt.att.com Subject: Re: Re[2]: AVT and ITU-T SG15 coordination In-Reply-To: <9505298044.AA804451386@mailgate1.insoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Subject: Re: AVT and ITU-T SG15 coordination > Author: tgl@mtgbcs.mt.att.com (Terry G Lyons) > Date: 6/28/95 10:12 PM > > Murray Cantor is right that the IETF and ITU should coordinate their efforts > to have a single set of standards for real-time audio and video in IP networks. > > A reasonable way to achieve this is through the IETF process of moving RTP, > RTCP, AV profile, and H.261 payload toward the status of Internet standards. > The ITU can assume a successful outcome and has no need of its own H.22Z. Thanks for the useful comments several of you have provided in this discussion. I would certainly have no objection if the ITU folks decided to use RTP and the A/V profile as they are published. I mentioned separate profiles because Dale Skran felt that the existing profile would not be acceptable to ITU, and this is something he knows better than I. A single profile would be preferred if possible. How many of the people participating in this discussion plan to attend the IETF meeting in Stockholm? Would it be useful to schedule a meeting of the AVT working group to talk about ITU requirements for a profile? There are control protocol issues to be discussed as well, but I believe there is an item on the MMUSIC agenda for this. -- Steve From rem-conf-request@es.net Thu Jul 06 02:57:11 1995 Received: from pec.etri.re.kr by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jul 1995 23:53:35 -0700 Original-Received: by pec.etri.re.kr (8.6.9H1/8.6.4) id PAA19557 PP-warning: Illegal Received field on preceding line From: Myung Soon Kim Posted-Date: Thu, 6 Jul 1995 15:02:09 +1000 Message-Id: <199507060502.PAA19557@pec.etri.re.kr> Subject: ICCC'95 To: larovere@omega.Incc.br, puges@TRANSPAC.atlas.fr, jhpark@einstein.postech.ac.kr, hvisage@rkw-risc.cs.up.ac.za, hvisage@dos-lan.cs.up.ac.za, shlee@cbucc.chungbuk.ac.kr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, ipng@sunroof.eng.sun.com, osimcast@B Date: Thu, 6 Jul 1995 15:02:07 +0900 (GMT+9:00) Cc: osimcast@BBN.COM, sigmedia@bellcore.com, ietf@ISI.edu, sc6wg4@ntd.comsat.com, rem-conf@es.net, ilka@prz.tu-berlin.de, kathie@katmandu.svi.org, az@prz.tu-berlin.de, thomas@priz.tu-berlin.de, g.carle@ieee.org, mckim@case.kotel.co.kr, hf@hugo.int-evry.fr, fou@pec.etri.re.kr X-Mailer: ELM [version 2.4 PL21-h4] Content-Type: text Content-Length: 40798 -------------------------------------------------------------------------------- Information about ICCC'95 is now available on the World Wide Web at the following address : * http://most.etri.re.kr/iccc/ -------------------------------------------------------------------------------- Following is the second announcement of Call For Participation of ICCC'95 which will be held 21-24 of August 1995, in Seoul, Korea. -------------------------------------------------------------------------------- ICCC'95 CALL FOR PARTICIPATION *********************************************************** * 12th International Conference On Computer Communication * *********************************************************** ******************************************* * August 21-24, 1995 * * Hotel Intercontinental, Seoul, Korea * ******************************************* Sponsored by ICCC - International Council for Computer Communication Hosted by ETRI - Electronics and Telecommunications Research Institute KISS - Korea Information Science Society Under the patronage of Ministry of Information and Communication, Republic of Korea Conference Site Hotel Intercontinental Trade Center, P.O.Box 87 159-8 samsung-dong, kangnam-Ku, Seoul, Korea 135-732 Tel:+82-2-555-5656, Telex:K33970 ,Fax:+82-2-559-7990 ADVANCE PROGRAM --------------------- Conference Governor Honorary Conference Chairman ------------------- ---------------------------- Dr. Ronald P. Uhlig Dr. Kyong Sang Hyon Qualcomm, USA Minister, MIC, Korea Conference Chairman Conference Co-chairman --------------------- ----------------------- Prof. Chongsun Hwang Dr. Seungtaik Yang President,KISS,Korea President,ETRI,Korea Technical Program ----------------------- Chair:Dr. Seonjong Chung ETRI,Korea Co-chairs:Dr.Roger Needham Dr. Otto Spaniol Univ. of Cambridge, UK Achen Tech. Univ. Prof. Sergio Fdida Dr. Nicolas Georganas MASI, France Univ. of Ottawa, Canada Dr. Pramode Verma Dr. Hideyoshi Tominaga AT&T,USA Waseda Univ. Japan Publication ------------- Mr. Keosang Lee DACOM,Korea Publicity ----------- Prof. Jaiyong Lee Yonsei Univ.,Korea Registration -------------- Dr. Samyoung Seuh N.C.A.,Korea Treasurer ---------- Dr. Seungkyu Park Ajou Univ.,Korea Social Program ---------------- Dr.Noshik Kim Korea Telecom,Korea Secretary Co-Secretary ----------- -------------- Prof. Yangheei Choi Dr. Younghee Lee Seoul National Univ.,Korea ETRI, Korea Tutorial ---------- Prof. Sunshin An Korea Univ.,Korea Local Arrangements ------------------ Prof. Dongho Lee Kwangwon Univ.,Korea ******************* Keynote Addresses ******************* Tuesday, August 22 10:55 - 12:20 =============================== 1. "Network Intelligence for Information Superhighway" Dr. Louis Pouzin, THESEUS, France 2. "Information & Communication Policy in Korea" Mr. Hongshik Jung Ministry of Information and Communication(MIC), Korea 3. "The Telecommunications Policy Debate in the US - Where is it headed and what will be the effects on NII and GII development." Mr. Tomas J. Sugrue National Telecommunications and Information Administration(NTIA), USA *********** TUTORIALS *********** Monday, August 21, 1995 ======================= T1. "Multimedia Networking: Applications Requirements, Network Infrastructures, Protocols and Servers" Instructor: Fouad A. Tobagi, Stanford University; tobagi@bodega.stanford.edu T2. "Physical and MAC Layers in Cellular Wireless Communication Networks (With Special Emphasis on CDMA Standards)" Instructor: Arogyaswami Paulraj, Stanford University; paulraj@sprite.stanford.edu T3. "Distributed Multimedia Systems and Applications" Instructor: Borko Furht, Florida Atalantic University; borko@cse.fau.edu T4. "Broadband Networking with ATM" Instructor: Anujan Varma, University of California; varma@cse.ucsc.edu ******************** Technical Sessions ******************** Tuesday, August 22 14:00 - 15:30 ================================= Session 1A Information Superhighway ------------------------ 1A.1 R&D Strategy for Technologies for an Integrated Ultra-high Speed Network and Computer System Masahiro Taka, Ultra-high Speed Network and Computer Technology Laboratories(UNCL), Japan 1A.2 A Comprehensive Plan for the Korea Information Infrastructure Joun Cheon, MIC, Korea 1A.3 Information Highways and Competitiveness of Telecommunication Services Firms in Brazil Renata Lebre La Rovere, Universidade Federal do Rio de Janeiro, Jorge Fagundes, Faculdades Integradas Candido Mendes, Brazil Invited Paper: NII Project in R.O.C. - Deployment and Applications of Broadband Trial Network Dr. Jin-Tuu Wang, Telecommunication Laboratories(TL), Taiwan Session 1B Multimedia Communication 1 -------------------------- 1B.1 Statistical Real-Time Channels on Multiaccess Networks Chih-Che Chou, Kang G.Shin, University of Michigan, USA 1B.2 A Multimedia-on-Demand System with End-to-End Quality of Service Guarantees Lek Heng Ngoh, Huanxu Pan, National University of Singapore, Singapore, Aurel Lazar, Columbia University, USA 1B.3 Controlling Agent Interactions in a Tightly Coupled Multiagent Framework Joongmin Choi, Sangkyu Park, Myeongwuk Jang, Sooncheol Baeg, Gwanglo Lee, Younghwan Lim, ETRI, Korea 1B.4 Interactive Multimedia - Services, Success Factors and End-to-End Network Solutions Manfred Gand, Siemens AG, Germany Session 1C ATM Switching 1 --------------- 1C.1 Performance Analysis for ATM Switching of Mixed Continuous-Bit-Rate and Bursty Traffic with Smoothing Function Liao Jianxin, Li Lemin, Lai Guangming, University of Electronic Science and Technology of China, China 1C.2 Design of Network of ATM Switch with Simple Fault Detection Method Jongin Jung, Sungchun Kim, Seogang University, Korea 1C.3 A Novel Architecture for Priority Handling in an ATM Multicast Switch Young C.Oh, Suresh Rai, Lousiana State University, U.S.A 1C.4 Cut Through Routing in Shared Buffered Banyan Networks Seong Leong Ng, Bill Dewar, University of New South Wales, Australia Session 1D High-speed Protocols 1 ---------------------- 1D.1 Modeling of Function-Based Communication Protocol Entities for Performance Assessment, Application to XTP Atika Cohen, Radouane Mrabet, Universite Libre de Bruxelles, Belgium 1D.2 Performance Analysis of a k-Reliable Multicast ARQ Protocol Bongtae Kim, Harry G Perros, Arne A Nilsson, North Carolina State University, USA 1D.3 A Fair and Efficient Access Control Method for High Speed Multimedia LAN and MAN Tadao Saito, Hitoshi Aida, Onur Altintas, Byungsuk Kim,Terumasa Aoki, University of Tokyo, Japan 1D.4 A New Ring Protocol for ATM-MAN Cheul Shim, Keehyun Park, Junho Lee, Jaiyong Lee, Sangbae Lee, Yonsei University, Korea Tuesday, August 22 15:50 - 17:20 ================================= Session 2A Network Architecture -------------------- 2A.1 Design of a Modular and Efficient Communication Subsystem Torsten Braun, Jochen Schiller, Claudia Schmidt, Martina Zitterbart, University of Karlsruhe, Germany 2A.2 Open Platform for Group-working in ODP Environments Changwook Lee, Yongjin Park, Hanyang University, Korea 2A.3 The Design of A Fault-Tolerant ATM Network Chi-Chun Lo, Chen-Yu Chiou, National Chiao-Tung University, Taiwan 2A.4 Architecture of a European-wide Backbone Network A.Hyron, P.Louazel, P.Puges, France Telecom, France Session 2B Multimedia Communication 2 -------------------------- 2B.1 How Smart Valley, Inc. is Creating an Electronic Community in the San Francisco Bay Area Harry J. Saal, Smart Valley. Inc., USA 2B.2 Multi-Carrier Modulation for Multimedia Communications: Symbol Timing and Carrier Phase Synchronization Issues Thierry Pollet, Marc Moeneclaey, University of Ghent, Belgium 2B.3 Performance Analysis of Leaky Bucket Algorithm with Bursty Traffic Input in ATM Networks Sun Hairong, Li Lemin, University of Electronic Science & Technology of China, China 2B.4 Proposal of Architecture for Video on Demand System over ATM Network Keigo Ihara, Yasuhiko Yasuda, Waseda University, Kinji Ono, NCSIS, Japan Session 2C Computer Communication 1 ------------------------ 2C.1 Sojourn Time Analysis of Prioritized DQDB (IEEE802.6) MAN with Bursty Traffic Input Sun Hairong, Li Lemin, University of Electronic Science & Technology of China, China 2C.2 FADM : A New Access Control Method for Distributed Access Subscriber Network Tadao Saito, Hitoshi Aida, Byungsuk Kim, University of Tokyo, Japan 2C.3 Providing Internet Email to the Campus Community at the Lahore University of Management Sciences, Lahore, Pakistan Sohail Aslam, Lahore University of Management Sciences, Pakistan 2C.4 Distributed Mutual Exclusion on Hypercubes Mohamed Naimi, Laboratoire d'Informatique de Besancon, France Session 2D Intelligent Network 1 --------------------- 2D.1 An Object-based Model of the Service Control Function Boris Makarevitch, Helsinki University of Technology, Finland 2D.2 Intelligent Networking-from Narrowband to Broadband Richard B. Robrock II, Bell Communications Research Inc., USA 2D.3 Performance Evaluation of Intelligent Networks Accommodating Various IN Services as well as Basic ISDN Services Minyoung Chung, Dankeun Sung, KAIST, Korea Invited Paper: Evolution of Intelligent Networks Dr. Ronald P. Uhlig, Qualcomm, USA Wednesday, August 23 9:00 - 10:30 ================================== Session 3A Network Management 1 -------------------- 3A.1 Tempo's Transport Quality of Service Stefan Bocking, Siemens AG, Rainer Schatzmayr, TU Berlin, Germany 3A.2 Priority Management to Improve the QOS for Shared Memory ATM Switch Sohail Ahmed, Universiti Pertanian Malaysia, Malaysia 3A.3 Modeling and Management of Distributed Applications and Services Using the OSI Management Framework James W.Hong, Michael J. Katchabaw, Michael A. Bauer, Hanan Lutfiyya, University of Western Ontario, Canada 3A.4 A Delegation Approach on an Application Gateway for Heterogeneous Network Managements Taeyeon Kim, Youngkyun Kim, Bongnam Noh, Chonnam National University, Korea Session 3B Mutimedia Communication 3 ------------------------- 3B.1 Multicast Scheduling for VOD Services Heekyoung Woo, Jichul Park, Chongkwon Kim, Seoul National University, Korea 3B.2 An Efficient Backward Compatible Video Coding Method for MPEG-1 and MPEG-2 Standards Kijin Kim, Soonkak Kwon, Jaekyoon Kim, KAIST, Korea 3B.3 Error Control Schemes for Improving the Performance of MPEG-based Video Communications over ATM Networks Taeseop Han, Luis Orozco-Barbosa, University of Ottawa, Canada 3B.4 An Object Oriented Network Simulation Testbed for Real Time Multimedia Applications Sandeep Kumar, P.Venkataram, Indian Institute of Science, India Session 3C ATM Switching 2 --------------- 3C.1 On the Performance Evaluation of an ATM Switch with Bursty Traffic and Nonindependant Routing Sabine Wittevrongel, Herwig Bruneel, University of Ghent, Belgium 3C.2 Analysis of ATM Switch with Feedback Input Queuing and Output Queuing under Bursty Traffic Ghassan Kbar, William J. Dewar University of New South Wales, Australia 3C.3 Design of a Cost-Effective Modular Architecture for Very Large ATM Switches K. H. Cho, J. H. Park, B. S. Kwon, S. Eun, H. Yoon, KAIST, Korea 3C.4 Analysis of Priority Control Mechanism with Two Thresholds in ATM Switch Network Wongi Park, Youngsun Kim, Chimoon Han, ETRI, Hyoungjin Choi, Sungkyunkwan University, Korea Session 3D Wireless Communication 1 ------------------------ 3D.1 An Improved Leader Election Protocol in Multi-hop Radio Networks Chungki Lee, NCA, Korea, Mostafa H. Ammar, Georgia Institute of Technology, James E. Burns, Bellcore, USA 3D.2 Scheduling Algorithms for Packet Radio Networks Mark L. Huson, Arunabha Sen, Arizona State University, USA 3D.3 HF Radio Prediction Services for PC Communication Kyujin Wee, Seokhee Bae, Radio Research Lab, MIC, Daejoong Kim, Seongkyeong Park, Changeon Kang, Yonsei University, Korea 3D.4 Voice and Packet Data Integration over GSM Networks Giuseppe Bianchi, Antonio Capone, Luigi Fratta, Luigi Musumeci, Politecnico di Milano, Italy Wednesday, August 23 10:50 - 12:20 =================================== Session 4A Network Planning ---------------- 4A.1 Modular Network Planning of Peruvian University Eduardo Gorritti Castro, Aurora Ruiz Rosado, Antenor Orrego University, Peru 4A.2 Communication by Computer : A Proposal of Development to Peru Esteban Rafael Estrada Hora, Cesar Angusto Ramires Luna Victoria, Antenor Orrego University, Peru 4A.3 Differences in Network Planning for Wireless Local Loop and Mobile Wireless Systems Bracha Epstein, Moshe Levin, Tadiran Telecommunications, Israel 4A.4 Use of Conjoint Measurements for an Optimal Design of International Telephone Services Christian Eggenberger, Christof Hauser, University of St. Gallen, Switzerland Session 4B Broadband Communication 1 ------------------------- 4B.1 A Modular Transport Network Node Gerald Lebizay, IBM Lab., France 4B.2 Design Method for Virtual Path Based ATM Networks with Multiple Traffic Classes Byunghan Ryu, Hiroyuki Ohsaki, Masayuki Murata, Hideo Miyahara, Osaka University, Japan 4B.3 A Compatible ATM-DQDB Interconnection in a Broadband Multi-Internetworking Unit Xavier Hesselbach, Sebasti Sallent, Politechnic University of Catalonia, Spain 4B.4 Dynamic Virtual Path Bandwidth Control over Multiple Transmission Links in an ATM Network Eunjoo Ha, Jaehyuk Do, Jongtae Park, Kyungbuk National University, Chimoon Han, ETRI, Korea Session 4C Computer Communication 2 ------------------------ 4C.1 Performance Evaluation of A Deferred Write Technique as a Recovery Technique in Client-Server DBMS Y. Jeon, F.Lombardi, Texas A & M University, USA 4C.2 ATM Switches in Computer Networks, A Proposal for the LAN Environment Hendrik Visage, University of Pretoria, South Africa 4C.3 An Application Configuration for Information Delivery Systems in a Distributed Processing Environment Junichi Kikuchi, Takeya Mukaigaito, Hiroshi Masamoto, Manabu Tsukuda, NTT, Japan 4C.4 Practical Performance Analysis of UDP/IP and TCP/IP over ATM with Special Regard to Protocol-, Operating System- and ATM Layer Limitations Andree Zehl, Thomas P.Kusch Technical University of Berlin, Germany Session 4D Performance Analysis -------------------- 4D.1 MMBP[X]/G/1 Queues and Their Application to the Approximation of the Performance of ATM Switches Mowcheng Lee, ITRI, Taiwan, C. Y. Roger Chen, Syracuse University, USA 4D.2 On the Prediction of the Stochastic Behavior of Time Series by Use of Neural Networks - an Application to Source Modelling $)C Markus D. EbersplAher, University of Stuttgart, Germany 4D.3 Analysis of Optimal Scheduling in Distributed Parallel Queueing Systems Mark S. Squillante, IBM, Konstantinos P. Tsoukatos, University of Maryland, USA 4D.4 Modeling of SONET Links for Per-Session Study of an ATM Multiplexer Rajesh I. Balay, Arne A. Nilsson, North Carolina State University, USA Wednesday, August 23 14:00 - 15:30 =================================== Session 5A Security and Privacy 1 --------------------- 5A.1 Intrusion Detection : A Survey Mansour Esmaili, Reihaneh Safavi-Naini, Josef Pieprzyk, University of Wollongong, Australia 5A.2 Fast Software Encryption Systems for Secure & Private Communication Moldovyan A. A., Institute of Modeling and Intellectualization of Complex Systems, Moldovyan N. A., Academy of Sciences of Moldova Republic, Russia, Moldova 5A.3 A Secure Communication Scheme Using Chaotic Signals Chungyong Lee, Jaejin Lee, Douglas B. Williams, Georgia Institute of Technology, U.S.A 5A.4 A Secure Multiway Election Scheme Sungjun Park, Dongho Won, Sungkyunkwan University, Korea Session 5B Protocol Engineering 1 ---------------------- 5B.1 Automated Verification in an Integrated Protocol Development Environment Ajin Jirachiefpattana, Richard Lai, La Trobe University, Australia 5B.2 High Performance ASN.1/BER Decoder Sunwan Choi, ETRI, Korea 5B.3 Test Generation from SDL Specifications and Input/Output Finite State Machines Byungmoon Chin, ETRI, Korea, Anna R.Cavalli, Toma Macavei, Institut National des Telecommunications, France 5B.4 Designing Tests for Time Dependant Systems Ousamane Konmh Universit Bordeaux I, France Session 5C ATM Traffic 1 ------------- 5C.1 Flow Control of ABR Traffic in ATM Networks Using a Two-level Scheme Wales Kin Fai Wong, Danny H.K.Tsang, Hong Kong University of Science and Technology, Hong Kong 5C.2 Effective Bandwidth Techniques in Bufferless and Buffered ATM Multiplexers B. G. Kim, I. G. Niemegeers, University of Twente, The Netherlands 5C.3 On an Extension of Leaky Bucket Algorithm: Leaky Bucket Algorithm with Multiple Token Rates Dirceu Cavendish, Yuji Oie, Kyushu Institute of Technology, Tetsuya Takine, Osaka University, Japan 5C.4 On GA-based Optimal Dimensioning of Three-Level Traffic Shaper for Statistical Multiplexing in ATM Networks Kyeongsoo Kim, Byeonggi Lee, Seoul National University, Korea Session 5D High-speed Protocols 2 ---------------------- 5D.1 An Integrated Packet Scheduling Algorithm for Highspeed Packet-Switched Wide-Area Networks Jaechang Kwak, Seokyeong University, Korea 5D.2 Robust Communication Protocols for Run-Time Fault Detection G.Noubir, K.Vijayananda, Swiss Federal Institute of Technology, Switzerland 5D.3 A New Presentation Layer Protocol for Partitioned Syntax Transformation Model Guy Berthet, Swiss Federal Institute of Technology, Switzerland 5D.4 Improving End-to-End Throughput for Bulk Data Transfers Tadao Saito, Hitoshi Aida, Onur Altintas, Terumasa Aoki, University of Tokyo, Japan Panels ====== Wednesday, August 23 15:50 - 17:20 =================================== Panel 1 : What does Information Superhighway stand for in your mind? What is its impact on our society? Panel 2 : What are the real issues in current multimedia communications, QOS, Standardization or Services? Panel 3 : Security / Privacy vs. Accessibility in Information Networks. Panel 4 : Will personal/wireless communications dominate over the wire communications? Thursday, August 24 9:00 - 10:30 ================================= Session 6A Network Management 2 6A.1 Multimedia Communication Management Architecture for Information Highways Wonkyu Hong, Eunho Choi, Korea Telecom, Korea 6A.2 A Model for a Time Reference Network Management System Theodore K. Apostolopoulos, Victoria Daskalou, Athens University of Economics and Business, Greece 6A.3 A Group Communication Protocol for Distributed Network Management Systems Kwanghui Lee, Changwon National University, Korea 6A.4 Using BAN logic for the proof of Network Address Integrity Yuko Murayama, Hiroshima City University, Japan Session 6B Protocol Engineering 2 ---------------------- 6B.1 An Integrated Tool for LOTOS Development Ana Cavalli, Patrick Maigron, INT, Hacene Fouchal, Universite de Reims Champagne-Ardennes, France, Sungun Kim, Korea Telecom, Korea 6B.2 Design and Implementation of CFG generator for Estelle Specification Jaehong Park, Cheeha Kim, Jaiyong Lee, POSTECH, Yonsei Univsersity, Korea 6B.3 Specification and Verification, a Unified Approach Anthony Wiles, Anders Ekman, Telia Research AB, Sweden 6B.4 DQDB Networks with a Fast Global Information Scheme Hasein I. Sigiuk, B. H. Pardoe, University of Salford, United Kingdom Session 6C Computer Communication 3 ------------------------ 6C.1 Integrated Multilevel Secure System for Information Retrieval in Distributed Computer Systems Haklin Kimm, University of Tennessee, USA, Jaeyoung Rhi, Samsung Data Systems, Korea 6C.2 On the Use of a Stochastic Estimator Learning Algorithm to the ATM Routing Problem : A Methodology Athanasios V. Vasilakos, Hellenic Air Force Academy, Greece 6C.3 Design of High Performance OSI Software over ATM Network Toshihiko Kato, Toru Hasegawa, Akira Idoue, Kenji Suzuki, Yoshiyori Urano, KDD R&D Lab., Japan 6C.4 Modeling Optimal Overload Control in Distributed Control Systems Ulf Ahlfors, Christian Nyberg, Lund Institute of Technology, Sweden Session 6D Intelligent Network 2 --------------------- 6D.1 A New Traffic Regulation Scheme for SCP Jyhi-Kong Wey, Lir-Fang Sun, Ministry of Transportation and Communications, Wei-Pang Yang, National Chiao Tung University, Taiwan 6D.2 A Petri-Nets Based Approach for Detecting Feature Interactions in Telecommunications Services Junghun Choi, ETRI, Hyeonsoo Kim, Woojin Lee, Yongrae Kwon, KAIST, Korea 6D.3 Transient and Stationary Investigations of Overload Control in Intelligent Networks Maria Kihl, Christian Nyberg, Lund Institute of Technology, Sweden 6D.4 An Implementation of VPN Service on the TDX-10 SSP Hyungik Kim, Seokhun Kim, Jeyseung Lee, Minyong Ahn, Korea Telecom, Korea Thursday, August 24 10:50 - 12:20 ================================== Session 7A Security and Privacy 2 ---------------------- 7A.1 Security for Local Area and Wide Area Networked Computer Communications Vijay Varadharajan, University of Western Sydney, Australia 7A.2 A Key Distribution and Authentication Method on the Q.931 Calling Sequence of ISDN Taekyoung Kwon, Jooseok Song, Yonsei University, Korea 7A.3 Reconfiguration for Service Growth and Self-healing in ATM Networks Based on Virtual Paths Tai H. Noh, AT&T Bell Lab.Dhadesugoor R. Vaman, Xuedao Gu, Stevens Institute of Technology, USA 7A.4 The Extended LFSRs and their Applications to the High Speed Data Protections Seungcheol Goh, Sangjin Lee, Seoungtaek Chee, Sangwoo Park, ETRI, Korea Session 7B Broadband Communication 2 ------------------------- 7B.1 Optimal Sequential Decoding Algorithm in the Land Mobile Fading Channel Jaechoong Han, Goldstar Co. Central Research Lab., Korea, Costas N. Georghiades, Texas A&M University, USA 7B.2 A Pre-negotiation Dynamic Bandwidth Management Algorithm for ATM Connectionless Service Hyunchul Cha, Kijun Han, Kyungpook National University, Korea 7B.3 QOS based Routing for High Speed Environment L. Franck, B. Sales, Brussels Universities, Belgium 7B.4 Service Multiplexing in an ATM Environment Paulo Monteiro, Augusto Casaca, Serafim Nunes, INESC, Portugal Session 7C Optical Communication & Forward Error Correction ------------------------------------------------ 7C.1 Architecture and Performance Evaluation of Future Photonic Networks Jan Spath, Ulrich Gremmelmaier, Uwe Briem, University of Stuttgart, Manfred N. Huber, Simens AG, Germany 7C.2 Limits to Optical Switch Matrices Set by Phase Noise from Semiconductor Optical Amplifiers Joao J. O. Pires, Instituto Superior Tecnico, Portugal 7C.3 Improved Algorithm of the Trace Computation on Trinomial Irreducible Polynomial for RS Code Changho Seo, Jongin Lim, Injeong Chung, Korea University, Korea 7C.4 Performance Analysis of DT-WDMA Protocol Hyun K. Kahng, Jooyoung Park, Korea University, Korea Session 7D Wireless Communication 2 ------------------------ 7D.1 A Design of a MAC Layer Protocol for CBR and VBR Data Transmission on a Single Channel in Wireless LANs P. Venkataram, S. R. Pawamana, Indian Institute of Science, India 7D.2 Performance Evaluation of Priority Packet Reservation Multiple Access and Adaptive Packet Reservation Multiple Access Wu Xiaowen, Huang Shunji, Li Lemin, University of Electronic Science and Technology of China, China 7D.3 Performance of Code Tracking Loop for a Direct-Sequence Spread-Spectrum System in a Mobile Fading Channel Jinyoung Kim, Jaehong Lee, Seoul Natioanl University, Korea Invited Paper: Modern Digital Solutions for Wireless Local Loop Using CDMA Technology Dr. Peter E. Jackson, QUALCOMM, USA Thursday, August 24 14:00 - 15:30 ================================= Session 8A Highspeed Networks ------------------ 8A.1 On Merging and Splitting of Self-Similar Traffic in High Speed Networks Yanhe Fan, Nicolas D.Georganas, University of Ottawa, Canada 8A.2 Effective Priority Control and Addressing Scheme for High Speed Ring Network Sunmoo Kang, Byungchun Jeon, ETRI, Daeyoung Kim, Chungnam National University, Korea 8A.3 CapNet-Shared Memory Distributed Computing over Wide Area High Speed Networks Ming-Chit Tam, David J.Farber, University of Pennsylvania, U.S.A Invited Paper: Fast Communications and Slow Computers Dr. Roger Needham, University of Cambridge United Kingdom Session 8B Broadband Communication 3 ------------------------- 8B.1 Fault-Tolerant ATM LAN/LAN Interworking Inter-LAN Connectionless Data Services E. T. Powner, A. Odeh, Y. Wang, University of Sussex, United Kingdom 8B.2 Simulation Study of CAP in High Bit Rate Asymmetrical Digital Subscriber Line (ADSL) Envirnment Ajit Reddy, Syed V. Ahamed, CUNY, U.S.A 8B.3 Towards Scalable Error Control for Reliable Multipoint Services in ATM Networks Georg Carle, University of Karlsruhe, Germany 8B.4 Relationships among Inter-Dependant Real-Time Streams Luca Delgrossi, Sibylle Schaller, Lars Wolf, IBM European Networking Center, Germany Session 8C ATM Traffic 2 ------------- 8C.1 The Use of Learning Algorithms in ATM Networks Call Admission Control Problem : A Methodology Athanasios V.Vasilakos, Hellenic Air Force Academy, Greece 8C.2 Characterizing Variation of Traffic Parameters in ATM Networks Using Neural Networks Ibrahim Khalil, Borhanuddin Mohd Ali, M.R.Mukerjee, Universiti Pertanian Malaysia, Malaysia 8C.3 A Simple Dynamic Bandwidth Allocation Scheme for ATM Networks Han Zhou, C. H. Chang, Tufts University, USA, D. T. Han, Beijing Steel College, China 8C.4 A Rate Based Flow Control Switch Design for ABR Service in an ATM Network Yoon Chang, Nada Golmie, David Su, NIST, USA Session 8D Satellite Communication ----------------------- 8D.1 Object-Oriented B-ISDN Service Modeling Juhyun Ryu, Cheong Youn, Chungnam National University, Jaeil Jung, Jiyoung Kim,Korea Telecom Korea 8D.2 A Comparison of Satellite and Terrestrial Implementaions of the National Research and Education Network Junghwan Kim, R. M. Buehrer, Mark Keaton, Subash C. Kwatra, William Curry, University of Toledo, USA 8D.3 Multibeam-Switched Demand-Assigned Multiple Access for On Board the Satellite with Data Buffer Doug N. Kim, ETRI, Korea Invited Paper: Dr. K.M.S. Murthy, VISTAR Telecom, Canada Thursday, August 24 15:50 - 16:50 ================================== Session 9A Evolution toward the Highspeed Networks --------------------------------------- 9A.1 A Network Architecture for Multimedia Multiparty Services and the Impact on B-ISDN Control Evolution Luigi Ronchetti, Luca Cipriani, Stefano Salsano Ericsson Telecomunicazioni SpA, Italy 9A.2 Transition to High Speed Network-Super JANET Experience Kicheon Kim, Steven Simpson, David Hutchison Lancaster University, United Kingdom 9A.3 The Evolution of Packet Data Networks : The ATM Opportunity F. Perardi, F.Ferrero, CSELT, R. Pietroiusti, F. Cataldi, Telecom Italia, Italy Session 9B Distance Learning ----------------- 9B.1 An Internet Based Collaborative Distance Learning System : CODILESS Kazuo Watabe, University of Shizuoka, Japan, Matti Hamalainen, Espoo-Vantaa Institute of Technology, Finland, Andrew B. Whinston, University of Texas at Austin, USA 9B.2 Designing Mulitmedia Learning Environments for Anesthetic Methods in Medical Practice Jorn Nilsson, Lund University, Sweden 9B.3 Frame Rate Control in a Multimedia Distance Learning System Lj. Josifovski, S. Gievska, D. Davcev, St. Kiril & Metodij University, Skopje R. of Macedonia Session 9C Computer Communication 4 ------------------------ 9C.1 A Framework on the Design of Communication Gateways Zhong Ping Tao, University of Montreal, Canada 9C.2 A Delay Constrained Distributed Multicast Routing Algorithm Sunjoo Wi, Yanghee Choi, Seoul National University, Korea 9C.3 A Ring Network with Two Tokens Rashid Al-Naami, Doha, Qutar Session 9D Personal Communication Systems ------------------------------ 9D.1 Dynamic Channel Assignment Using Channel Interleaving in the One Dimensional Reuse Partitioning System Kwangmoon Cho, Taiyun Kim, Korea University, Korea 9D.2 SCAI: Integration of Computer and Telecommunications Switches in North American Intelligent Networks for Universal Personal Communications and Multimedia Communications Hazem El-Gendy, EPEC Inc., Canada 9D.3 Performance Analysis of Cellular Mobile Communications under Multipath Interference Jyh-Horng Wen, National Chung Cheng University, Taiwan *************** Social Events *************** Welcome Reception(Cocktail) ----------------------------- A welcome Cocktail Party will be held at p.m. 7 Monday evening, August 21 at Hotel Intercontinental. All conference attendees and spouses are invited. Dinner -------- A Hosted Dinner Party is also scheduled for Tuesday evening, August 22. The place for the party will be announced during the conference. All conference attendees and spouses are invited. Conference Banquet ------------------- Banquet will be held on Tuesday Evening, August 23 Hotel Intercontinental. You Can buy tickets when you register for ICCC'95 on site. Participants who register in advance can also get the tickets from the receptionists by showing the receipt of your pre-registration during the conference. The Banquet ticket is $50. Luncheon ---------- A Luncheon hosted by one of the major telecommunication company in Korea will be on 24th. The schedule is subject to change. The exact date and place for that will be posted during the conference. Industrial Tour ---------------- A free technical visit hosted by four major Korean Telecommunications Indistries - Samsung Electronics Co. Ltd., Hyundai Electronics Co., Daewoo Telecom Ltd., LG Information and Communication Ltd. - is scheduled on 25th, August, the following day of the conference. More detailed information will be available later at Information Desk. Registration for Technical Visit will be accepted during the conference at ICCC'95 Information Desk. ============================< CUT HERE >================================= ****************************** * ADVANCE REGISTRATION * * (Deadline : July 25) * ****************************** PLEASE MAIL OR FAX TO : Korea Information Science Society TEL:+82-2-588-9246 KPO BOX 1205 Seoul, Korea FAX:+82-2-521-1352 OR EMAIL TO : ICCC'95 Email:iccc-reg@krnic.net Name:(last/family)_________________________(first)______________(Mr./Mrs./Ms.) Company:______________________________________________________________________ Address/Mailstop:_____________________________________________________________ City/State/Zip/Country:_______________________________________________________ Daytime Number:_____________________________FAX Number:_______________________ E-mail:_____________________________________ Name of Spouse(Guest):_____________________________ PLEASE CHECK APPROPRIATE FEES: -- CONFERENCE REGISTRATION: Reglar Student --------- --------- Advance Registration(Until July 25, 1995) $450(w360,000) $50(w40,000) Late/On-site Registration(August 21, 1995) $500(w400,000) $100(w80,000) -- TUTORIAL REGISTRATION: Regular Student --------- --------- Advance Registration(Until July 25, 1995) $200(w160,000) $100(w80,000) Late/On-site Registration(August 21, 1995) $250(w200,000) $150(w120,000) -- BANQUET TICKET: Per-person $50(w40,000) TOTAL ENCLOSED:$___________________ METHOD OF PAYMENT: ____Moneyorder ____Mastercard ____Visa ____Other Credit Card Number:_________________ EXP. Date:__________________ Cardholder Name:______________________ Signature:____________________________ ................................................................................ -In case you want cancel your pre-registration, please notify to Korean Information Science Society before July 25. If you do so by July 25, you will receive a 90% refund. If you do so between July 25 and August 14, you will receive a 70% refund. ===========================< CUT HERE >================================== ********************************** * HOTEL RESERVATION FORM * * (deadline : July 20, 1995) * ICCC'95 ********************************** Please Mail or FAX to : LISTED HOTELS BELOW. Name:(Last/Family)______________________(first)_________________(Mr./Mrs./Ms.) Address:_____________________________________________________________________ City/State/Zip/Country:______________________________________________________ Phone Number:____________________________FAX Number:_________________________ Sharing Room with:___________________________________________________________ Check-in___________(Fl. No. ) Check-out________________(Fl. No. ) HOTEL REFERENCE : ICCC'95 Secretariat offically recommend 5 hotels which offer special group rates for ICCC'95 participants. -------------------------------------------------------------------------------- Hotel Distance(by taxi) Rate(Unit: Won) Tel Fax -------------------------------------------------------------------------------- Intercontinental 0 Deluxe Room 127,000 +82-2-559-7777 +82-2-559-7995 ***** Jr. Suite 165,000 -------------------------------------------------------------------------------- Riviera 5 min Double 93,750 +82-2-541-3111 +82-2-546-6111 **** Twin 101,250 -------------------------------------------------------------------------------- Novotel 10 min 1 person 105,000 +82-2-531-6522 +82-2-562-0120 **** 2 persons -------------------------------------------------------------------------------- New World 5 min 93,800 +82-2-557-0111 +82-2-557-0141 **** -------------------------------------------------------------------------------- Clover 15 min 42,000 +82-2-546-1414 +82-2-544-1340 ** -------------------------------------------------------------------------------- * 10% service charge and 10% tax will be added on the above rates. * Hotel International has a double occupancy rate which is 20,000 Won, and Jr. Suite includes breakfast. * 1 US$ is about 800 Won. Name of Hotel:______________________________ Number of Room Required ____Single ____Double ____Twin ____Suite No. of nights___________________ Indicate Special Request and Comments:_________________________________________ _______________________________________________________________________________ Method of Payment: ____American Express ____JCB ____Visa ____Mastercard ____Diners Club Credit Card Number:____________________Exp. Date:___________________________ Cardholder Name:_______________________ Signature:__________________________ ================================================================================ Please return this form to the corresponding hotel. Hotel Address: Riviera: 53-7, Chongdam-dong, Kangnam-gu, Seoul, Korea Novotel: 603, Yoksam-dong, kangnam-gu, Seoul, Korea New World: 112-5, Samsung-dong, kangnam-gu, Seoul, korea Clover: 129-7, Chongdam-dong, kangnam-gu, seoul, Korea ------------------------------------------- ICCC'95 Secretariat Protocol Engineering Center, ETRI Yusong P.O.Box 106,Taejon,Korea Tel:+82-42-860-6598 Fax:+82-42-860-6597 e-mail: mskim@pec.etri.re.kr From rem-conf-request@es.net Thu Jul 06 11:41:47 1995 Received: from VNET.IBM.COM by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jul 1995 08:41:18 -0700 Received: from RALVM6.VNET.IBM.COM by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1481; Thu, 06 Jul 95 11:41:03 EDT Date: Thu, 06 Jul 95 11:41:03 EDT From: ellesson@VNET.IBM.COM To: casner@pax.cavebear.com, rem-conf@es.net Subject: Re: Re[2]: AVT and ITU-T SG15 coordination FROM: ED ELLESSON, RALVM6(ELLESSON) / ellesson@vnet.ibm.com Networking Systems Architecture, C70/B664 P.O. 12195, Research Triangle Park, NC 27709 Subject: Re: Re[2]: AVT and ITU-T SG15 coordination I vote for an avt meeting at Stockholm to discuss the ITU profile requirements. I will be in Stockholm. Regards, Ed Ellesson Emerging Technologies, Networking Architecture T-444-4115, 919-254-4115 / FAX Number: T-444-5410, 919-254-5410 *** Forwarding note from SMTP2 --IINUS1 07/06/95 11:21 *** ========================================================================= Received: from osi-west.es.net by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP; Wed, 05 Jul 95 23:08:51 EDT Received: from cavebear.com (actually pax.cavebear.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jul 1995 19:17:04 -0700 Received: by cavebear.com (4.1/SMI-4.1) id AA02980; Wed, 5 Jul 95 19:16:46 PDT Date: Wed, 5 Jul 1995 19:16:45 -0700 (PDT) From: Stephen Casner X-Sender: casner@pax.cavebear.com To: rem-conf@es.net, h32z2-list@mtgbcs.mt.att.com Subject: Re: Re[2]: AVT and ITU-T SG15 coordination In-Reply-To: <9505298044.AA804451386@mailgate1.insoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Subject: Re: AVT and ITU-T SG15 coordination > Author: tgl@mtgbcs.mt.att.com (Terry G Lyons) > Date: 6/28/95 10:12 PM > > Murray Cantor is right that the IETF and ITU should coordinate their efforts > to have a single set of standards for real-time audio and video in IP networks. > > A reasonable way to achieve this is through the IETF process of moving RTP, > RTCP, AV profile, and H.261 payload toward the status of Internet standards. > The ITU can assume a successful outcome and has no need of its own H.22Z. Thanks for the useful comments several of you have provided in this discussion. I would certainly have no objection if the ITU folks decided to use RTP and the A/V profile as they are published. I mentioned separate profiles because Dale Skran felt that the existing profile would not be acceptable to ITU, and this is something he knows better than I. A single profile would be preferred if possible. How many of the people participating in this discussion plan to attend the IETF meeting in Stockholm? Would it be useful to schedule a meeting of the AVT working group to talk about ITU requirements for a profile? There are control protocol issues to be discussed as well, but I believe there is an item on the MMUSIC agenda for this. -- Steve From rem-conf-request@es.net Thu Jul 06 13:36:22 1995 Received: from danpost.uni-c.dk by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jul 1995 10:35:37 -0700 Received: from ithp10.it.dtu.dk (ithp10.it.dtu.dk [130.225.77.140]) by danpost.uni-c.dk (8.6.4/8.6) with ESMTP id TAA00558 for ; Thu, 6 Jul 1995 19:35:24 +0200 Message-Id: <199507061735.TAA00558@danpost.uni-c.dk> Received: by ithp10.it.dtu.dk (1.37.109.11/16.2) id AA010482190; Thu, 6 Jul 1995 19:36:30 +0200 Date: Thu, 6 Jul 1995 19:36:30 +0200 To: rem-conf@es.net Subject: IFIP TC6 IN Workshop From: "Villy B. Iversen" X-Mailer: The Server System Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Enclosed please find information on an IFIP TC-6 Working Conference to be held in Copenhagen end August. The full program will be distributed this month. For further information please contact me or Joergen Noergaard (see bottom) or the www-server given at the bottom Villy b. Iversen (vbi@it.dtu.dk) ************************************************************************ IFIP IN '95 Working Conference Program August 28-29, 1995: Tutorials August 30-31, 1995: Workshop The coming of the Information Super Highway may dramatically change our = lives in the future. On-line shopping and information search & retrieval = >from the home or office at the click of a button and publishing just as = easily. Distance learning and distance working are other possibilities = just to mention a few. But common for all of these visions is that they = require powerful networks and powerful services in order to meet the goal= s. = The common denominator for the tutorials and the conference is the = technological means to pursue new, advanced services. = Tutorials progam overview Monday Tuesday 900-1030 Introduction to IN IN and Mobility 1030-1100 Coffee & Tea Coffee & Tea 1100-1230 B-ISDN and IN OMG CORBA 1230-1330 Lunch Lunch 1330-1500 Advanced IN platform TINA Service Architecture 1500-1530 Coffee & Tea Coffee & Tea 1530-1700 A Service Creation TINA Connection Management Environment Model = Evening Welcome reception = In conjunction with the conference a series of tutorial session are being= = organised. The purpose of the tutorials will be to introduce a number of = themes that are related to IN, not to give very detailed knowledge about = the individual topics. Instead the selected topics will give an understan= - ding of developments in related but still diverse fields of modern tele- communication. Components from all these fields must be brought together = in a tight integration in order to support Information Super Highways, bu= t = without sacrificing the reliability of today's telecommunication networks= =2E Introduction to IN Olli Martikainen, Telecom Finland A thorough introduction to the Intelligent Network and related concepts.= = Forms the background for the following presentations. B-ISDN Jens Fischer, Tele Danmark Research = Advanced Concepts in an IN platform Joergen Dyst, LM Ericsson Denmark An IN platform based on ETSI INAP and implementing CS-1 and parts of CS-2= = will be presented. This is an example of the use of open standards in a = commercial product. The P103 Service Creation Environment Model Carla Capellmann, Deutsche Telekom A comprehensive and general model for a service creation environment is = described. The general model can be mapped onto any specific environment = and helps focus attention on tasks to be performed or considered during = service creation. IN and Mobility Terje Jensen, Telenor Research Aspects of IN, UPT and wireless will be treated as well as a discussion = about functionality and implementation in the network. OMG CORBA Richard Soley, OMG An introduction to object oriented distributed computing and the Object = Management Group Common Object Request Broker Architecture. = CORBA is a particular interest as it is the technological base for the = TINA Distributed Processing Environment (DPE). TINA-C Service Architecture nn1, TINA-C The core of the TINA work is probably the Service Architecture that = supports the construction of new services, rapidly, efficiently and = manageably. But services are not understood in isolation, so the Service = Architecture is also the general principles for relating to other concept= s = in the architecture, such as DPE, Connection Management, management syste= m. = The tutorial will give an overview of this. TINA-C Connection Management Architecture nn2, TINA-C In the TINA architecture, one of the central concepts is Connection = Management. The concept and its model will be described in the tutorial = as well as the use within the service architecture and the relation to = the network. Conference The IFIP IN '95 Working Conference on August 30-31, 1995 in Copenhagen (the final program is available about July 20) Wednesday Thursday 900-1030 Welcome & Opening ? 1030-1100 Coffee & Tea Coffee & Tea 1100-1230 ? ? 1230-1330 Lunch Lunch 1330-1500 ? ? 1500-1530 Coffee & Tea Coffee & Tea 1530-1700 ? ? = = Registration Form Family Name = Given Name(s) = Company = Address = Telephone = Fax = e-mail = Participation Price (DKK) = Tutorial 2 days 1500 = Conference 2 days 1500 = Total payable (DKK) = = = Accomodation Reserved hotels (further information provided in next mail) = Other hotels = = = -- = Joergen Noergaard | e-mail: jnp@tdr.dk = Tele Danmark Research | Phone: +45 4576 6444 = > Lyngs=F8 Alle 2 | Fax: +45 4576 6336 = > DK-2970 H=F8rsholm, Denmark |URL: http://www.tdr.dk/~jnp/ From rem-conf-request@es.net Thu Jul 06 16:04:21 1995 Received: from cyclops.ece.ncsu.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jul 1995 13:03:46 -0700 Received: by cyclops.ece.ncsu.edu (8.6.11/EC06jan95) id QAA02657; Thu, 6 Jul 1995 16:03:43 -0400 From: Leigh Anne Rettinger Message-Id: <9507061603.ZM2655@eos.ncsu.edu> Date: Thu, 6 Jul 1995 16:03:42 -0400 X-Mailer: Z-Mail (3.2.1 15feb95) To: rem-conf@es.net Subject: Re: AVT and ITU-T SG15 coordination Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I have read with interest this thread about the collaborative effort between IETF and ITU-T to define standards for videoconferencing. However, I'm still a little confused about what exactly is going on. Can someone give me a brief summary of what is happening in the area of packet-switched videoconferencing standards and how it relates to the H.320 (ISDN) and H.324 (POTS) set of standards? I've heard mention of H.322/H.323, but I'm not clear exactly how all these standards are related. In the interest of not cluttering up this mailing list, please reply directly to me. I'll be glad to summarize the results to any interested parties. Is there another mailing list that would be more appropriate for this question? Thanks, Leigh Anne Rettinger larettin@eos.ncsu.edu From rem-conf-request@es.net Thu Jul 06 18:30:38 1995 Received: from cbt.cyberteam.com by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jul 1995 15:29:53 -0700 Received: (from fulcrum@localhost) by cbt.cyberteam.com (8.6.9/8.6.9) id AAA00350 for rem-conf@es.net; Fri, 7 Jul 1995 00:30:57 -0400 From: fulcrum@cyberteam.com Message-Id: <199507070430.AAA00350@cbt.cyberteam.com> Subject: Announcement (the orb concert) To: rem-conf@es.net Date: Fri, 7 Jul 1995 00:30:57 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 577 Hi... I'd like to announce that we probably will broadcast a concert of UK ambient project "the orb", live from the Berlin Loveparade. Unfortunately we didn't had much time to prepare everything, so we have all the neccessary equipment, but no MBONE link yet. Our nearest MBONE site is UUNET, I hope they answer fast enough. If they should, we will broadcast: Date: Sat 7/8/95, 22:00-24:00 MEST (20:00-22:00 GMT) Type: vat PCM audio, 64k Unfortunately we can't broadcast video, we didn't get permission. I hope I can mail further details tomorrow. Andreas Bogk CyberTeam From rem-conf-request@es.net Thu Jul 06 19:31:41 1995 Received: from hplms26.hpl.hp.com by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jul 1995 16:31:03 -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 AA230733484; Thu, 6 Jul 1995 16:31:25 -0700 Received: by hplabsz.hpl.hp.com (1.37.109.15/15.5+ECS 3.3+HPL1.1) id AA061133465; Thu, 6 Jul 1995 16:31:05 -0700 From: Laura de Leon Message-Id: <9507061631.ZM6111@hplabsz.hpl.hp.com> Date: Thu, 6 Jul 1995 16:31:05 -0700 X-Mailer: Z-Mail (3.0.0 15dec93) To: baylisa@baylisa.org, sage-announce@usenix.org, rem-conf@es.net Subject: BayLISA: Glen Kohler on Ergonomics 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 -------- July 20: Glen Kohler on Ergonomics Ergonomic safety depends on performance skills fully as much as environmental safety. While the literature contains many references to posture & body mechanics, this theme is woefully underdeveloped compared to furniture, chairs, and wrist rests. The Chinese martial and medical arts offer tools and methods to correct this bias. August 17: Brent Chapman on firewalls ***NOTE the date for the September meeting is the 2nd Thursday, not 3rd*** September 14: Mike Dixon, Xerox PARC (Schedule subject to revision) 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 Fri Jul 07 08:09:43 1995 Received: from odin.UU.NET by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jul 1995 05:08:54 -0700 Received: by odin.UU.NET (maildrop) id QQyxgw00314; Thu, 6 Jul 1995 19:42:24 -0400 Date: Thu, 6 Jul 1995 19:42:24 -0400 Message-Id: From: Henry Kilmer To: fulcrum@cyberteam.com Cc: rem-conf@es.net Subject: Announcement (the orb concert) In-Reply-To: <199507070430.AAA00350@cbt.cyberteam.com> References: <199507070430.AAA00350@cbt.cyberteam.com> fulcrum@cyberteam.com writes: >Hi... > >I'd like to announce that we probably will broadcast a concert of >UK ambient project "the orb", live from the Berlin Loveparade. > >Unfortunately we didn't had much time to prepare everything, so we have >all the neccessary equipment, but no MBONE link yet. Our nearest >MBONE site is UUNET, I hope they answer fast enough. If they should, >we will broadcast: > >Date: Sat 7/8/95, 22:00-24:00 MEST (20:00-22:00 GMT) >Type: vat PCM audio, 64k > >Unfortunately we can't broadcast video, we didn't get permission. > >I hope I can mail further details tomorrow. > >Andreas Bogk >CyberTeam Your tunnel would be setup right now if you had your mrouter setup. I need to know the ip address of your mrouter. In addition, I need MAZ Hamburg's permission so you can use their link for this since it eats up bandwidth. Henry W. Kilmer hank@alter.net Sr. Network Engineer uunet!hank AlterNet / UUNET Technologies, Inc. From rem-conf-request@es.net Fri Jul 07 17:03:22 1995 Received: from mail.cs.tu-berlin.de by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jul 1995 14:02:33 -0700 Received: from kolbmais.cs.tu-berlin.de (jo@kolbmais.cs.tu-berlin.de [130.149.25.97]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id XAA09047; Fri, 7 Jul 1995 23:00:28 +0200 From: Joerg Ott Received: (jo@localhost) by kolbmais.cs.tu-berlin.de (8.6.12/8.6.6) id XAA25927; Fri, 7 Jul 1995 23:00:24 +0200 Message-Id: <199507072100.XAA25927@kolbmais.cs.tu-berlin.de> Subject: Re: Re[2]: AVT and ITU-T SG15 coordination To: casner@cavebear.com (Stephen Casner) Date: Fri, 7 Jul 1995 23:00:22 +0200 (MET DST) Cc: rem-conf@es.net, h32z2-list@mtgbcs.mt.att.com In-Reply-To: from "Stephen Casner" at Jul 5, 95 07:16:45 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII > > > Subject: Re: AVT and ITU-T SG15 coordination > > Author: tgl@mtgbcs.mt.att.com (Terry G Lyons) > > Date: 6/28/95 10:12 PM > > > > Murray Cantor is right that the IETF and ITU should coordinate their efforts > > to have a single set of standards for real-time audio and video in IP networks. > > > > A reasonable way to achieve this is through the IETF process of moving RTP, > > RTCP, AV profile, and H.261 payload toward the status of Internet standards. > > The ITU can assume a successful outcome and has no need of its own H.22Z. > > > Thanks for the useful comments several of you have provided in this > discussion. I would certainly have no objection if the ITU folks > decided to use RTP and the A/V profile as they are published. I > mentioned separate profiles because Dale Skran felt that the existing > profile would not be acceptable to ITU, and this is something he knows > better than I. A single profile would be preferred if possible. > > How many of the people participating in this discussion plan to > attend the IETF meeting in Stockholm? Would it be useful to schedule > a meeting of the AVT working group to talk about ITU requirements for > a profile? There are control protocol issues to be discussed as > well, but I believe there is an item on the MMUSIC agenda for this. > > -- Steve I will be in Stockholm, and I like the idea of having a meeting for this purpose. I would like to point out that not only the AVT working group is affected when talking about "joint" efforts of IETF and ITU-T. As soon as we get to conference control (and maybe other than real-time applications, such as whiteboards, for example), interoperability issues are to be addressed in a much broader sense than AVT would deal with; in particular, the work of the MMUSIC working group is relevant here. Gruesse, Joerg From rem-conf-request@es.net Fri Jul 07 18:40:04 1995 Received: from navel.ucr.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jul 1995 15:38:33 -0700 Received: from [138.23.203.126] by 138.23.203.126 with SMTP; Fri, 7 Jul 1995 15:38:46 -0700 (PDT) X-NUPop-Charset: English Date: Fri, 7 Jul 95 15:36:16 PDT From: "Gary Croll, (KE6GHS) U.C. Riverside" Sender: croll@pop.ucr.edu Reply-To: croll@ucrac1.ucr.edu Message-Id: <56177.croll@ucrac1.ucr.edu> To: rem-conf@es.net Subject: unsubscribe unsubscribe From rem-conf-request@es.net Sat Jul 08 13:17:58 1995 Received: from linc.cis.upenn.edu by osi-west.es.net with ESnet SMTP (PP); Sat, 8 Jul 1995 10:17:22 -0700 Received: from gradient.cis.upenn.edu (GRADIENT.CIS.UPENN.EDU [158.130.4.2]) by linc.cis.upenn.edu (8.6.10/UPenn 1.4) with SMTP id NAA03048; Sat, 8 Jul 1995 13:17:09 -0400 Received: by gradient.cis.upenn.edu id AA18283; Sat, 8 Jul 1995 13:17:01 -0400 Date: Sat, 8 Jul 1995 13:17:01 -0400 From: mercuri@gradient.cis.upenn.edu (Rebecca Mercuri) Posted-Date: Sat, 8 Jul 1995 13:17:01 -0400 Message-Id: <9507081717.AA18283@gradient.cis.upenn.edu> To: bau@ccrma.stanford.edu, brooks@dance.fsu.edu, brooks@xi.cs.fsu.edu, cyberoid@milton.u.washington.edu, glinert@cs.washington.edu, kaugust@caip.rutgers.edu, lwyse@iss.nus.sg, mercuri@gradient.cis.upenn.edu, mikemosh@well.sf.ca.us, panayi@tiger.asel.udel.edu, rem-conf@es.net, roy@asel.udel.edu, scaletti@cerl.uiuc.edu, smoliar@iss.nus.sg, sound@acm.ord Subject: Virtual Arts Therapies Conf 8/5/95 ANNOUNCING: The 9th Annual Institute for Music & Healing August 3-5, 1995 The purpose of the Institute is to foster a better understanding of the inner music with each person possesses, and to capture, maintain and generate that music for wholistic and spiritual well-being. The Institute, held at Immaculata College, a suburb of Philadelphia (easily accessible by car or public transit) brings together a wide range of therapists, artists, physicians, educators and others interested in the healing aspects of music. Performers and lecturers include composer David Darling, and the oboe and guitar duo of Jill Haley and David Cullen. One of the features of the Institute is its focus on music technology in healing. Using interactive multimedia it is now possible to construct immersive virtual environments tailored specifically to an individual's therapeutic needs. Clients and therapists can work to incorporate imagery and sounds from the real world into a wide variety of customized computer simulations. In this way, a client could wander through a reconstruction of his or her childhood home, re-examine a stressful encounter at work, or even use virtual realities to aid in desensitizing phobias and neuroses. This year, a new conference will be held within the Institute: VIRTUAL ARTS THERAPIES(TM) IN MUSIC THERAPY Sr. Jean Anthony Gileno, Ph.D., will introduce the concept of Virtual Arts Therapies in music therapy, and discuss the use of cyberspace technology in the healing process. The Soundbeam as a virtual expression device will be examined, along with other types of virtual arts, the application of such to the training of teachers and therapists, as well as the use of these arts at home, in the workplace, and other settings. David M. Roy and Marilyn Panayi, of the A.I. duPont Institute and the University of Delaware Applied Science and Engineering Laboratories will discuss their research in gestural human-machine interaction for people with severe speech and motor impairment using neural networks. Joseph Reilly will review his use of the Lightning MIDI device with psychiatric patients at the Albert Einstein Medical Center. Rebecca Mercuri will examine some of the computer software tools and hardware components for implementation of virtual arts therapies. Her student interns in cyberspace music therapy will demonstrate and exhibit some of their research. Prices for the Institute are quite reasonable, with individual concert and session breakdowns. For example, the Virtual Arts Therapies portion on Saturday, August 5 costs only $60.00. The entire conference may be taken for academic credit for $603.00. Inexpensive campus housing is available during the Institute. For a complete brochure, send an email request to Rebecca Mercuri: mercuri@gradient.cis.upenn.edu Or telephone Immaculata College Department of Music Therapy: 610/647-4400 x3490 Upcoming Music Therapy programs at Immaculata College include: Depth Psychology and Music Centered Therapies, JoEllyn Beck, Sept 12-Dec 12. Biofeedback Music Research, Sr. Jean Anthony, Sept 7 - Dec 7. Pulmonary and Cardiovascular Aspects of Music Making, Fawzi P. Habboushe, M.D., F.A.C.S., October 11 & 12. Technology and the Creative Arts Therapies, Rebecca Mercuri, Mike Mosher, Sr. Jean Anthony, in conjunction with the Small Computers in the Arts Network at the Franklin Institute Science Museum, Nov. 4 & 11. For further information on these courses and events, or to be placed on the mailing list, call 610/647-4400 x3490. From rem-conf-request@es.net Sun Jul 09 09:21:35 1995 Received: from mail.cs.tu-berlin.de by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Jul 1995 06:21:01 -0700 Received: from reggae.cs.tu-berlin.de (okp@reggae.cs.tu-berlin.de [130.149.27.30]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id PAA21263 for ; Sun, 9 Jul 1995 15:20:56 +0200 From: Oli Kai Paulus Received: (okp@localhost) by reggae.cs.tu-berlin.de (8.6.12/8.6.9) id PAA22030; Sun, 9 Jul 1995 15:20:49 +0200 Date: Sun, 9 Jul 1995 15:20:49 +0200 Message-Id: <199507091320.PAA22030@reggae.cs.tu-berlin.de> To: rem-conf@es.net Subject: mrouted-3.x for Solaris 2.4 Hi, is there a pruning mrouted for Solaris 2.4 ? If it exists, can someone please provide the URL ? Thank you. Oli From rem-conf-request@es.net Sun Jul 09 10:22:48 1995 Received: from mail.cs.tu-berlin.de by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Jul 1995 07:22:19 -0700 Received: from escudo.cs.tu-berlin.de (toolahjj@escudo.cs.tu-berlin.de [130.149.22.27]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id QAA22180 for ; Sun, 9 Jul 1995 16:22:17 +0200 From: Budy Setiawan Received: (toolahjj@localhost) by escudo.cs.tu-berlin.de (8.6.12/8.6.6) id QAA13797 for rem-conf@es.net; Sun, 9 Jul 1995 16:22:14 +0200 Date: Sun, 9 Jul 1995 16:22:14 +0200 Message-Id: <199507091422.QAA13797@escudo.cs.tu-berlin.de> To: rem-conf@es.net Subject: unsubscribe unsubscribe From rem-conf-request@es.net Sun Jul 09 11:20:09 1995 Received: from cancer.ucs.ed.ac.uk by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Jul 1995 08:19:41 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id QAA05324; Sun, 9 Jul 1995 16:19:37 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id QAA26361; Sun, 9 Jul 1995 16:20:08 +0100 Date: Sun, 9 Jul 1995 16:20:08 +0100 Message-Id: <199507091520.QAA26361@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: mrouted-3.x for Solaris 2.4 To: Oli Kai Paulus In-Reply-To: Oli Kai Paulus's message of Sun, 9 Jul 1995 15:20:49 +0200 Reply-To: Graeme.Wood@ucs.ed.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-URL: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 Cc: rem-conf@es.net > Hi, > > is there a pruning mrouted for Solaris 2.4 ? If it exists, can someone > please provide the URL ? > > Thank you. Oli Yes it exists. You will find a copy of it at the German MICE National Support Centre in Stuttgart. The URL is ftp://www-ks.rus.uni-stuttgart.de/pub/mice/ipmulticast/Solaris_mc33.2.4.tar.Z. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Sun Jul 09 12:39:18 1995 Received: from coral.bucknell.edu by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Jul 1995 09:38:20 -0700 Received: from uvite02.bucknell.edu by coral.bucknell.edu; (5.65/1.1.8.2/29Aug94-0956AM) id AA23670; Sun, 9 Jul 1995 12:37:56 -0400 Message-Id: <9507091637.AA23670@coral.bucknell.edu> X-Sender: droms@mail.bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 9 Jul 1995 12:38:08 -0400 To: Oli Kai Paulus , rem-conf@es.net From: droms@bucknell.edu (Ralph Droms) Subject: Re: mrouted-3.x for Solaris 2.4 At 3:20 PM 7/9/95 +0200, Oli Kai Paulus wrote: >is there a pruning mrouted for Solaris 2.4 ? If it exists, can someone >please provide the URL ? I, too, am interested in a pruning mrouted for Solaris 2.4. Would you please forward any information you might receive in response to your query? Thanks... - Ralph Droms droms@bucknell.edu Associate Professor of Computer Science (717) 524-1394 Bucknell University (717) 524-1790 (fax) Lewisburg, PA 17837 From rem-conf-request@es.net Sun Jul 09 14:34:10 1995 Received: from cosmos.kaist.ac.kr by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Jul 1995 11:31:57 -0700 Received: from violet.kaist.ac.kr (violet [143.248.195.12]) by cosmos.kaist.ac.kr (8.6.9H1/8.6.9) with ESMTP id DAA08119 for ; Mon, 10 Jul 1995 03:32:10 +0900 Received: (from whchoi@localhost) by violet.kaist.ac.kr (8.6.9H1/8.6.9) id DAA01811; Mon, 10 Jul 1995 03:30:11 -0900 From: Woohyung Choi Message-Id: <199507101230.DAA01811@violet.kaist.ac.kr> Subject: Re: mrouted-3.x for Solaris 2.4 To: okp@cs.tu-berlin.de (Oli Kai Paulus) Date: Mon, 10 Jul 1995 03:30:10 -0900 (GMT) Cc: rem-conf@es.net In-Reply-To: <199507091320.PAA22030@reggae.cs.tu-berlin.de> from "Oli Kai Paulus" at Jul 9, 95 03:20:49 pm 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: 367 playground.sun.com has a rich collection of experimental softwares for solaris including rsvp, mrouted, ipv6, etc. mrouted for solaris 2.x could be found at the following URL. ftp://playground.sun.com/multicast/Solaris_mc33.2.4.tar.Z -whchoi > is there a pruning mrouted for Solaris 2.4 ? If it exists, can someone > please provide the URL ? > > Thank you. Oli From rem-conf-request@es.net Mon Jul 10 03:38:21 1995 Received: from mail.cs.tu-berlin.de by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 00:37:44 -0700 Received: from reggae.cs.tu-berlin.de (okp@reggae.cs.tu-berlin.de [130.149.27.30]) by mail.cs.tu-berlin.de (8.6.12/8.6.12) with ESMTP id JAA11332; Mon, 10 Jul 1995 09:36:35 +0200 From: Oli Kai Paulus Received: (okp@localhost) by reggae.cs.tu-berlin.de (8.6.12/8.6.9) id JAA25065; Mon, 10 Jul 1995 09:36:26 +0200 Date: Mon, 10 Jul 1995 09:36:26 +0200 Message-Id: <199507100736.JAA25065@reggae.cs.tu-berlin.de> To: droms@bucknell.edu CC: rem-conf@es.net In-reply-to: <9507091637.AA23670@coral.bucknell.edu> (droms@bucknell.edu) Subject: Re: mrouted-3.x for Solaris 2.4 Ralph, I received no replies by email, only the two sent to the list. Regards, Oli From rem-conf-request@es.net Mon Jul 10 03:52:38 1995 Received: from cavebear.com (actually pax.cavebear.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 00:52:05 -0700 Received: by cavebear.com (4.1/SMI-4.1) id AA00781; Mon, 10 Jul 95 00:52:00 PDT Date: Mon, 10 Jul 1995 00:51:59 -0700 (PDT) From: Stephen Casner X-Sender: casner@pax.cavebear.com To: rem-conf@es.net Subject: AVT meeting at IETF Stockholm Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Several people expressed interest in having a meeting of the Audio/Video Transport working group at IETF in Stockholm next week to discuss coordination with ITU-T Study Group 15, so a session has been scheduled for Wednesday 1300-1500. Sorry, no multicast. Now, I need to figure out an agenda for this meeting, beyond free-form discussion. Can one or more of the folks who have participated in SG15 meetings or in the recent discussions on this list give a brief presentation on: - the problem SG15 wants to solve - what aspects of RTP were seen as problems - the specific issue of ITU control of a payload format codespace - other? Also, are there other AVT topics that anyone would like to discuss? I would be happy to hear any feedback about points in the RTP spec that might not be clear, but I will exercise Chairman's prerogative to preclude re-opening RTP design issues that have already been settled for the Proposed Standard stage. -- Steve From rem-conf-request@es.net Mon Jul 10 07:31:26 1995 Received: from enst.enst.fr by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 04:30:54 -0700 Received: from ulysse.enst.fr (root@inf.enst.fr [137.194.2.81]) by enst.enst.fr (8.6.10/8.6.10) with ESMTP id NAA02264 for ; Mon, 10 Jul 1995 13:30:44 +0200 Received: from argos.enst.fr (alioto@argos.enst.fr [137.194.160.87]) by ulysse.enst.fr (8.6.10/8.6.10) with ESMTP id NAA00245 for ; Mon, 10 Jul 1995 13:28:11 +0200 From: Salvatore Alioto Received: (alioto@localhost) by argos.enst.fr (8.6.10/8.6.10) id NAA00275 for rem-conf@es.net; Mon, 10 Jul 1995 13:28:04 +0200 Message-Id: <199507101128.NAA00275@argos.enst.fr> Subject: unscribe To: rem-conf@es.net Date: Mon, 10 Jul 1995 13:28:03 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 177 Please unscribe me thanks --Salvatore Alioto -- E-mail: alioto@inf.enst.fr || Salvatore.Alioto@enst.fr P-mail: Telecom Paris 46, rue Barrault - 75634 Paris cedex 13 From rem-conf-request@es.net Mon Jul 10 10:48:41 1995 Received: from venus.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 07:48:13 -0700 Received: from Eng.Sun.COM by venus.Sun.COM (Sun.COM) id HAA29752; Mon, 10 Jul 1995 07:48:07 -0700 Received: from jadeite.eng.sun.com (jadeite-93.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07851; Mon, 10 Jul 1995 07:48:04 -0700 Received: from valathar by jadeite.eng.sun.com (5.x/SMI-SVR4) id AA04833; Mon, 10 Jul 1995 07:49:43 -0700 Date: Mon, 10 Jul 1995 07:47:43 -0800 (PDT) From: "Michael F. Speer" Reply-To: "Michael F. Speer" Subject: Sunergy #15 Broadcast To: rem-conf@es.net Cc: Michael.Speer@Eng.Sun.COM, hoffman@valathar.Eng.Sun.COM Message-Id: Content-Type: text X-Sun-Text-Type: ascii To be broadcast via the Mbone tomorrow at 8:00am PDT Regards, Michael Speer ----------------------------- "Internet: The Next Wave" July 11th 15:00 - 16:00 GMT 11:00 - 12:00 Eastern Daylight Time. Recent advancements with regard to access, security, and interactivity on the net have created a new definition of cyberspace. It is a definition which allows the boundaries between learning, commerce and entertainment to dissolve. On a network of fluid realtime connections, the next wave is applied in all the field and "gold rush" of new business opportunites. Sunerg #15 explores these opportunities by dicussing the latest developments in security, access and interactivity. Please join John Gage (Director, Sicence Office, Sum Microsystems) and his guests: Geoff Baehr - Cheif Networking Officer, Sun Labs Patrick Naughton - Vice President of Technology, Starwave, Inc. Karl Jacob - CEO, Dimension X Arthur Van Hoff - Staff Engineer, Sun Microsystems. For more information, please visit the Sun Microsystems Home page(http://www.sun.com). From rem-conf-request@es.net Mon Jul 10 10:51:04 1995 Received: from enforcer.gsfc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 07:50:34 -0700 Received: (from bennett@localhost) by enforcer.gsfc.nasa.gov (8.6.10/8.6.9) id KAA12210 for rem-conf@es.net; Mon, 10 Jul 1995 10:51:48 -0400 Date: Mon, 10 Jul 1995 10:51:48 -0400 From: bennett@enforcer.gsfc.nasa.gov Message-Id: <199507101451.KAA12210@enforcer.gsfc.nasa.gov> To: rem-conf@es.net Subject: unsubscribe X-Sun-Charset: US-ASCII unsubscribe From rem-conf-request@es.net Mon Jul 10 12:49:08 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 09:48:46 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03719; 10 Jul 95 10:11 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-profile-05.txt, .ps Date: Mon, 10 Jul 95 10:11:52 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9507101011.aa03719@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 Profile for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne Filename : draft-ietf-avt-profile-05.txt, .ps Pages : 13 Date : 07/07/1995 This note describes a profile for the use of the real-time transport protocol (RTP) and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. 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-profile-05.txt". Or "get draft-ietf-avt-profile-05.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-profile-05.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-profile-05.txt". Or "FILE /internet-drafts/draft-ietf-avt-profile-05.ps". 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: <19950707160905.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950707160905.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Mon Jul 10 12:52:32 1995 Received: from rho.wev.twc.com by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 09:52:09 -0700 Received: from wev56208.wev.twc.com by rho.wev.twc.com with SMTP (1.37.109.15/16.2) id AA259035824; Mon, 10 Jul 1995 12:03:44 -0500 Date: Mon, 10 Jul 95 11:53:33 PDT From: Jack Biery Subject: unsubscribe To: rem-conf@es.net X-Mailer: Chameleon ARM_55, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please unsubcribe me.. Thanks, Jack From rem-conf-request@es.net Mon Jul 10 14:08:20 1995 Received: from gateway.gtech.com by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 11:07:21 -0700 Received: from ops.soft.gtech.com ([156.24.33.7]) by gateway.gtech.com with SMTP id <25608>; Mon, 10 Jul 1995 14:07:12 -0400 Received: from sunsrv1 by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA1366126788; Mon, 10 Jul 1995 13:51:32 -0400 Received: (from root@localhost) by sunsrv1.soft.gtech.com (8.6.12/8.6.12) id MAA06425; Mon, 10 Jul 1995 12:38:19 -0500 Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA024258701; Thu, 6 Jul 1995 13:48:45 -0400 Received: from osi-west.es.net ([128.55.32.32]) by gateway.gtech.com with SMTP id <25624>; Thu, 6 Jul 1995 14:02:38 -0400 Received: from VNET.IBM.COM by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jul 1995 08:41:18 -0700 Received: from RALVM6.VNET.IBM.COM by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1481; Thu, 06 Jul 95 11:41:03 EDT Date: Thu, 6 Jul 1995 11:41:03 -0400 From: ellesson@VNET.IBM.COM To: casner@pax.cavebear.com, rem-conf@es.net Subject: Re: Re[2]: AVT and ITU-T SG15 coordination Message-Id: <95Jul6.140238edt.25624@gateway.gtech.com> FROM: ED ELLESSON, RALVM6(ELLESSON) / ellesson@vnet.ibm.com Networking Systems Architecture, C70/B664 P.O. 12195, Research Triangle Park, NC 27709 Subject: Re: Re[2]: AVT and ITU-T SG15 coordination I vote for an avt meeting at Stockholm to discuss the ITU profile requirements. I will be in Stockholm. Regards, Ed Ellesson Emerging Technologies, Networking Architecture T-444-4115, 919-254-4115 / FAX Number: T-444-5410, 919-254-5410 *** Forwarding note from SMTP2 --IINUS1 07/06/95 11:21 *** ========================================================================= Received: from osi-west.es.net by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP; Wed, 05 Jul 95 23:08:51 EDT Received: from cavebear.com (actually pax.cavebear.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jul 1995 19:17:04 -0700 Received: by cavebear.com (4.1/SMI-4.1) id AA02980; Wed, 5 Jul 95 19:16:46 PDT Date: Wed, 5 Jul 1995 19:16:45 -0700 (PDT) From: Stephen Casner X-Sender: casner@pax.cavebear.com To: rem-conf@es.net, h32z2-list@mtgbcs.mt.att.com Subject: Re: Re[2]: AVT and ITU-T SG15 coordination In-Reply-To: <9505298044.AA804451386@mailgate1.insoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Subject: Re: AVT and ITU-T SG15 coordination > Author: tgl@mtgbcs.mt.att.com (Terry G Lyons) > Date: 6/28/95 10:12 PM > > Murray Cantor is right that the IETF and ITU should coordinate their efforts > to have a single set of standards for real-time audio and video in IP networks. > > A reasonable way to achieve this is through the IETF process of moving RTP, > RTCP, AV profile, and H.261 payload toward the status of Internet standards. > The ITU can assume a successful outcome and has no need of its own H.22Z. Thanks for the useful comments several of you have provided in this discussion. I would certainly have no objection if the ITU folks decided to use RTP and the A/V profile as they are published. I mentioned separate profiles because Dale Skran felt that the existing profile would not be acceptable to ITU, and this is something he knows better than I. A single profile would be preferred if possible. How many of the people participating in this discussion plan to attend the IETF meeting in Stockholm? Would it be useful to schedule a meeting of the AVT working group to talk about ITU requirements for a profile? There are control protocol issues to be discussed as well, but I believe there is an item on the MMUSIC agenda for this. -- Steve From rem-conf-request@es.net Mon Jul 10 14:09:03 1995 Received: from gateway.gtech.com by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 11:07:46 -0700 Received: from ops.soft.gtech.com ([156.24.33.7]) by gateway.gtech.com with SMTP id <25613>; Mon, 10 Jul 1995 14:07:17 -0400 Received: from sunsrv1 by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA1365026786; Mon, 10 Jul 1995 13:51:30 -0400 Received: (from root@localhost) by sunsrv1.soft.gtech.com (8.6.12/8.6.12) id MAA06419; Mon, 10 Jul 1995 12:38:17 -0500 Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA024218691; Thu, 6 Jul 1995 13:48:35 -0400 Received: from osi-west.es.net ([128.55.32.32]) by gateway.gtech.com with SMTP id <25623>; Thu, 6 Jul 1995 14:02:21 -0400 Received: from danpost.uni-c.dk by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jul 1995 10:35:37 -0700 Received: from ithp10.it.dtu.dk (ithp10.it.dtu.dk [130.225.77.140]) by danpost.uni-c.dk (8.6.4/8.6) with ESMTP id TAA00558 for ; Thu, 6 Jul 1995 19:35:24 +0200 Message-Id: <199507061735.TAA00558@danpost.uni-c.dk> Received: by ithp10.it.dtu.dk (1.37.109.11/16.2) id AA010482190; Thu, 6 Jul 1995 19:36:30 +0200 Date: Thu, 6 Jul 1995 13:36:30 -0400 To: rem-conf@es.net Subject: IFIP TC6 IN Workshop From: "Villy B. Iversen" X-Mailer: The Server System Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Enclosed please find information on an IFIP TC-6 Working Conference to be held in Copenhagen end August. The full program will be distributed this month. For further information please contact me or Joergen Noergaard (see bottom) or the www-server given at the bottom Villy b. Iversen (vbi@it.dtu.dk) ************************************************************************ IFIP IN '95 Working Conference Program August 28-29, 1995: Tutorials August 30-31, 1995: Workshop The coming of the Information Super Highway may dramatically change our = lives in the future. On-line shopping and information search & retrieval = >from the home or office at the click of a button and publishing just as = easily. Distance learning and distance working are other possibilities = just to mention a few. But common for all of these visions is that they = require powerful networks and powerful services in order to meet the goal= s. = The common denominator for the tutorials and the conference is the = technological means to pursue new, advanced services. = Tutorials progam overview Monday Tuesday 900-1030 Introduction to IN IN and Mobility 1030-1100 Coffee & Tea Coffee & Tea 1100-1230 B-ISDN and IN OMG CORBA 1230-1330 Lunch Lunch 1330-1500 Advanced IN platform TINA Service Architecture 1500-1530 Coffee & Tea Coffee & Tea 1530-1700 A Service Creation TINA Connection Management Environment Model = Evening Welcome reception = In conjunction with the conference a series of tutorial session are being= = organised. The purpose of the tutorials will be to introduce a number of = themes that are related to IN, not to give very detailed knowledge about = the individual topics. Instead the selected topics will give an understan= - ding of developments in related but still diverse fields of modern tele- communication. Components from all these fields must be brought together = in a tight integration in order to support Information Super Highways, bu= t = without sacrificing the reliability of today's telecommunication networks= =2E Introduction to IN Olli Martikainen, Telecom Finland A thorough introduction to the Intelligent Network and related concepts.= = Forms the background for the following presentations. B-ISDN Jens Fischer, Tele Danmark Research = Advanced Concepts in an IN platform Joergen Dyst, LM Ericsson Denmark An IN platform based on ETSI INAP and implementing CS-1 and parts of CS-2= = will be presented. This is an example of the use of open standards in a = commercial product. The P103 Service Creation Environment Model Carla Capellmann, Deutsche Telekom A comprehensive and general model for a service creation environment is = described. The general model can be mapped onto any specific environment = and helps focus attention on tasks to be performed or considered during = service creation. IN and Mobility Terje Jensen, Telenor Research Aspects of IN, UPT and wireless will be treated as well as a discussion = about functionality and implementation in the network. OMG CORBA Richard Soley, OMG An introduction to object oriented distributed computing and the Object = Management Group Common Object Request Broker Architecture. = CORBA is a particular interest as it is the technological base for the = TINA Distributed Processing Environment (DPE). TINA-C Service Architecture nn1, TINA-C The core of the TINA work is probably the Service Architecture that = supports the construction of new services, rapidly, efficiently and = manageably. But services are not understood in isolation, so the Service = Architecture is also the general principles for relating to other concept= s = in the architecture, such as DPE, Connection Management, management syste= m. = The tutorial will give an overview of this. TINA-C Connection Management Architecture nn2, TINA-C In the TINA architecture, one of the central concepts is Connection = Management. The concept and its model will be described in the tutorial = as well as the use within the service architecture and the relation to = the network. Conference The IFIP IN '95 Working Conference on August 30-31, 1995 in Copenhagen (the final program is available about July 20) Wednesday Thursday 900-1030 Welcome & Opening ? 1030-1100 Coffee & Tea Coffee & Tea 1100-1230 ? ? 1230-1330 Lunch Lunch 1330-1500 ? ? 1500-1530 Coffee & Tea Coffee & Tea 1530-1700 ? ? = = Registration Form Family Name = Given Name(s) = Company = Address = Telephone = Fax = e-mail = Participation Price (DKK) = Tutorial 2 days 1500 = Conference 2 days 1500 = Total payable (DKK) = = = Accomodation Reserved hotels (further information provided in next mail) = Other hotels = = = -- = Joergen Noergaard | e-mail: jnp@tdr.dk = Tele Danmark Research | Phone: +45 4576 6444 = > Lyngs=F8 Alle 2 | Fax: +45 4576 6336 = > DK-2970 H=F8rsholm, Denmark |URL: http://www.tdr.dk/~jnp/ From rem-conf-request@es.net Mon Jul 10 14:10:34 1995 Received: from gateway.gtech.com by osi-east.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 11:09:57 -0700 Received: from ops.soft.gtech.com ([156.24.33.7]) by gateway.gtech.com with SMTP id <25606>; Mon, 10 Jul 1995 14:08:38 -0400 Received: from sunsrv1 by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA1397926910; Mon, 10 Jul 1995 13:53:34 -0400 Received: (from root@localhost) by sunsrv1.soft.gtech.com (8.6.12/8.6.12) id MAA06737; Mon, 10 Jul 1995 12:40:21 -0500 Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA0309021660; Thu, 6 Jul 1995 17:24:44 -0400 Received: from osi-west.es.net ([128.55.32.32]) by gateway.gtech.com with SMTP id <25623>; Thu, 6 Jul 1995 17:38:30 -0400 Received: from cyclops.ece.ncsu.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jul 1995 13:03:46 -0700 Received: by cyclops.ece.ncsu.edu (8.6.11/EC06jan95) id QAA02657; Thu, 6 Jul 1995 16:03:43 -0400 From: Leigh Anne Rettinger Message-Id: <9507061603.ZM2655@eos.ncsu.edu> Date: Thu, 6 Jul 1995 16:03:42 -0400 X-Mailer: Z-Mail (3.2.1 15feb95) To: rem-conf@es.net Subject: Re: AVT and ITU-T SG15 coordination Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I have read with interest this thread about the collaborative effort between IETF and ITU-T to define standards for videoconferencing. However, I'm still a little confused about what exactly is going on. Can someone give me a brief summary of what is happening in the area of packet-switched videoconferencing standards and how it relates to the H.320 (ISDN) and H.324 (POTS) set of standards? I've heard mention of H.322/H.323, but I'm not clear exactly how all these standards are related. In the interest of not cluttering up this mailing list, please reply directly to me. I'll be glad to summarize the results to any interested parties. Is there another mailing list that would be more appropriate for this question? Thanks, Leigh Anne Rettinger larettin@eos.ncsu.edu >From Mailer-Daemon Thu Jul 6 17:24:49 1995 Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA0309021660; Thu, 6 Jul 1995 17:24:44 -0400 Return-Path: <@gateway.gtech.com:rem-conf-request@es.net> Received: from osi-west.es.net ([128.55.32.32]) by gateway.gtech.com with SMTP id <25623>; Thu, 6 Jul 1995 17:38:30 -0400 Received: from cyclops.ece.ncsu.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jul 1995 13:03:46 -0700 Received: by cyclops.ece.ncsu.edu (8.6.11/EC06jan95) id QAA02657; Thu, 6 Jul 1995 16:03:43 -0400 From: Leigh Anne Rettinger Message-Id: <9507061603.ZM2655@eos.ncsu.edu> Date: Thu, 6 Jul 1995 16:03:42 -0400 X-Mailer: Z-Mail (3.2.1 15feb95) To: rem-conf@es.net Subject: Re: AVT and ITU-T SG15 coordination Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I have read with interest this thread about the collaborative effort between IETF and ITU-T to define standards for videoconferencing. However, I'm still a little confused about what exactly is going on. Can someone give me a brief summary of what is happening in the area of packet-switched videoconferencing standards and how it relates to the H.320 (ISDN) and H.324 (POTS) set of standards? I've heard mention of H.322/H.323, but I'm not clear exactly how all these standards are related. In the interest of not cluttering up this mailing list, please reply directly to me. I'll be glad to summarize the results to any interested parties. Is there another mailing list that would be more appropriate for this question? Thanks, Leigh Anne Rettinger larettin@eos.ncsu.edu From rem-conf-request@es.net Mon Jul 10 14:11:35 1995 Received: from gateway.gtech.com by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 11:10:42 -0700 Received: from ops.soft.gtech.com ([156.24.33.7]) by gateway.gtech.com with SMTP id <25704>; Mon, 10 Jul 1995 14:10:24 -0400 Received: from sunsrv1 by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA1411426959; Mon, 10 Jul 1995 13:54:23 -0400 Received: (from root@localhost) by sunsrv1.soft.gtech.com (8.6.12/8.6.12) id MAA06869; Mon, 10 Jul 1995 12:41:10 -0500 Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA0344030437; Thu, 6 Jul 1995 19:51:01 -0400 Received: from osi-west.es.net ([128.55.32.32]) by gateway.gtech.com with SMTP id <25623>; Thu, 6 Jul 1995 20:04:49 -0400 Received: from hplms26.hpl.hp.com by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jul 1995 16:31:03 -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 AA230733484; Thu, 6 Jul 1995 16:31:25 -0700 Received: by hplabsz.hpl.hp.com (1.37.109.15/15.5+ECS 3.3+HPL1.1) id AA061133465; Thu, 6 Jul 1995 16:31:05 -0700 From: Laura de Leon Message-Id: <9507061631.ZM6111@hplabsz.hpl.hp.com> Date: Thu, 6 Jul 1995 19:31:05 -0400 X-Mailer: Z-Mail (3.0.0 15dec93) To: baylisa@baylisa.org, sage-announce@usenix.org, rem-conf@es.net Subject: BayLISA: Glen Kohler on Ergonomics 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 -------- July 20: Glen Kohler on Ergonomics Ergonomic safety depends on performance skills fully as much as environmental safety. While the literature contains many references to posture & body mechanics, this theme is woefully underdeveloped compared to furniture, chairs, and wrist rests. The Chinese martial and medical arts offer tools and methods to correct this bias. August 17: Brent Chapman on firewalls ***NOTE the date for the September meeting is the 2nd Thursday, not 3rd*** September 14: Mike Dixon, Xerox PARC (Schedule subject to revision) 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 Mon Jul 10 15:24:12 1995 Received: from gateway.gtech.com by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 11:29:39 -0700 Received: from ops.soft.gtech.com ([156.24.33.7]) by gateway.gtech.com with SMTP id <25674>; Mon, 10 Jul 1995 14:13:56 -0400 Received: from sunsrv1 by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA1411726960; Mon, 10 Jul 1995 13:54:24 -0400 Received: (from root@localhost) by sunsrv1.soft.gtech.com (8.6.12/8.6.12) id MAA06872; Mon, 10 Jul 1995 12:41:11 -0500 Received: from gateway by ops.soft.gtech.com ($Revision: 1.37.109.9 $/2.21-R) via SMTP; id AA0344330447; Thu, 6 Jul 1995 19:51:11 -0400 Received: from osi-west.es.net ([128.55.32.32]) by gateway.gtech.com with SMTP id <25623>; Thu, 6 Jul 1995 20:05:04 -0400 Received: from cbt.cyberteam.com by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jul 1995 15:29:53 -0700 Received: (from fulcrum@localhost) by cbt.cyberteam.com (8.6.9/8.6.9) id AAA00350 for rem-conf@es.net; Fri, 7 Jul 1995 00:30:57 -0400 From: fulcrum@cyberteam.com Message-Id: <199507070430.AAA00350@cbt.cyberteam.com> Subject: Announcement (the orb concert) To: rem-conf@es.net Date: Fri, 7 Jul 1995 00:30:57 -0400 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 577 Hi... I'd like to announce that we probably will broadcast a concert of UK ambient project "the orb", live from the Berlin Loveparade. Unfortunately we didn't had much time to prepare everything, so we have all the neccessary equipment, but no MBONE link yet. Our nearest MBONE site is UUNET, I hope they answer fast enough. If they should, we will broadcast: Date: Sat 7/8/95, 22:00-24:00 MEST (20:00-22:00 GMT) Type: vat PCM audio, 64k Unfortunately we can't broadcast video, we didn't get permission. I hope I can mail further details tomorrow. Andreas Bogk CyberTeam From rem-conf-request@es.net Mon Jul 10 17:14:25 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 14:13:01 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03100; 10 Jul 95 10:02 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-mpeg-00.txt Date: Mon, 10 Jul 95 10:02:41 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9507101002.aa03100@IETF.CNRI.Reston.VA.US> --NextPart A New 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 for MPEG1/MPEG2 Video Author(s) : D. Hoffman, G. Fernando, V. Goyal Filename : draft-ietf-avt-mpeg-00.txt Pages : 11 Date : 07/07/1995 This draft describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG2 System environments. The second is designed to maximize simplicity of implementation, and provide maximum compatibilty with other RTP-encapsulated media streams and future conference control work of the IETF. 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-mpeg-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-mpeg-00.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-mpeg-00.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: <19950707134136.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mpeg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-mpeg-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950707134136.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Mon Jul 10 20:15:57 1995 Received: from cantva.canterbury.ac.nz by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 17:15:28 -0700 Received: from cantua.canterbury.ac.nz (busa057@cantua.canterbury.ac.nz) by csc.canterbury.ac.nz (PMDF V4.3-13 #7295) id <01HSQS37SYFKJF9OA6@csc.canterbury.ac.nz>; Tue, 11 Jul 1995 12:14:45 +1300 Received: by cantua.canterbury.ac.nz (5.x/SMI-4.1) id AA15674; Tue, 11 Jul 1995 12:14:36 +1200 Date: Tue, 11 Jul 1995 12:14:36 +1200 From: busa057@cantua.canterbury.ac.nz (Tristram Scott) Subject: What has happened to the GMS satellite images? To: rem-conf@es.net Message-id: <9507110014.AA15674@cantua.canterbury.ac.nz> X-Envelope-to: rem-conf@es.net Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII Hi, Does anyone know what has happened to the GMS satellite images that were broadcasted over the Mbone until recently? I haven't seen an sd entry for months, but the images were still broadcast on 224.2.170.143, port 41224 until a couple of weeks ago. I can't remember the IP address they were sent from, and I can't get it back now they aren't being sent! Regards, Tristram --- Tristram Scott, Dept of Management| E-Mail t.scott@cantua.canterbury.ac.nz University of Canterbury | or busa057@cantua.canterbury.ac.nz Christchurch, New Zealand | Phone +64 3 364-2656 Fax +64 3 364-2020 From rem-conf-request@es.net Mon Jul 10 20:58:51 1995 Received: from viipuri.nersc.gov by osi-east.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 17:58:19 -0700 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA27795; Mon, 10 Jul 95 17:58:18 PDT Date: Mon, 10 Jul 95 17:58:18 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9507110058.AA27795@viipuri.nersc.gov> To: rem-conf@es.net Subject: Re: AVT meeting at IETF Stockholm Misaddressed... ----- Begin Included Message ----- >From Vineet_Kumar@ccm.jf.intel.com Mon Jul 10 12:43:35 1995 Original-Received: by ccm.jf.intel.com (ccmgate 3.2 #1) Mon, 10 Jul 95 12:43:31 PDT Pp-Warning: Illegal Received field on preceding line Date: Mon, 10 Jul 95 12:40:00 PDT From: Vineet Kumar To: rem-conf-request@es.net Subject: Re: AVT meeting at IETF Stockholm Content-Length: 2630 Text item: Even though I will not be present at the meeting, there will be someone from here representing at the Wednesday 1300-1500 meeting. There are two RTP topics that are of interest for discussion: 1. Is there a way to synchronize the video with the mixed audio if the video does not go through the same mixer. There are advantages in not having video traverse an unnecessary path to the mixer. 2. Is there a standard way to resolve SSRC collision without the use of RTCP BYE packet. Some RTP implementations may not use RTCP. Vineet Kumar Intel Corporation email: vineet_kumar@ccm.jf.intel.com ------------------------------------ Several people expressed interest in having a meeting of the Audio/Video Transport working group at IETF in Stockholm next week to discuss coordination with ITU-T Study Group 15, so a session has been scheduled for Wednesday 1300-1500. Sorry, no multicast. Now, I need to figure out an agenda for this meeting, beyond free-form discussion. Can one or more of the folks who have participated in SG15 meetings or in the recent discussions on this list give a brief presentation on: - the problem SG15 wants to solve - what aspects of RTP were seen as problems - the specific issue of ITU control of a payload format codespace - other? Also, are there other AVT topics that anyone would like to discuss? I would be happy to hear any feedback about points in the RTP spec that might not be clear, but I will exercise Chairman's prerogative to preclude re-opening RTP design issues that have already been settled for the Proposed Standard stage. -- Steve Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 Message-Id: Subject: AVT meeting at IETF Stockholm To: rem-conf@es.net X-Sender: casner@pax.cavebear.com From: Stephen Casner Date: Mon, 10 Jul 1995 00:51:59 -0700 (PDT) Received: by cavebear.com (4.1/SMI-4.1) id AA00781; Mon, 10 Jul 95 00:52:00 PDT Received: from cavebear.com (actually pax.cavebear.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jul 1995 00:52:05 -0700 Received: from osi-west.es.net by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0sVGdm-000UflC; Mon, 10 Jul 95 04:04 PDT Received: from ormail.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0sVGdr-000twpC; Mon, 10 Jul 95 04:04 PDT ----- End Included Message ----- From rem-conf-request@es.net Tue Jul 11 03:52:18 1995 Received: from aohakobe.ipc.chiba-u.ac.jp by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jul 1995 00:51:39 -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 QAA15430 for ; Tue, 11 Jul 1995 16:52:20 +0900 Message-Id: <199507110752.QAA15430@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: Re: What has happened to the GMS satellite images? In-reply-to: Your message of "Tue, 11 Jul 1995 12:14:36 +1200." <9507110014.AA15674@cantua.canterbury.ac.nz> Date: Tue, 11 Jul 1995 16:52:19 +0900 From: Yozo Toda (TELEPHONE +81-43-290-3539) > Does anyone know what has happened to the GMS satellite images that > were broadcasted over the Mbone until recently? I haven't seen an sd As I remember correctly, this session was sent from NASA. (I don't remember the IP address or where to send a mail, sorry.) I love this image, and usually displayed it on the root window. The STS-71 session is over now, and I hope the broadcasting of satellite images start again, if possible. Whom should we say this kind of request?? -- yozo. From rem-conf-request@es.net Tue Jul 11 11:54:16 1995 Received: from venus.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jul 1995 08:53:49 -0700 Received: from Eng.Sun.COM by venus.Sun.COM (Sun.COM) id IAA23468; Tue, 11 Jul 1995 08:53:47 -0700 Received: from jadeite.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3) id AA17064; Tue, 11 Jul 1995 08:53:44 -0700 Received: from valathar by jadeite.eng.sun.com (5.x/SMI-SVR4) id AA12252; Tue, 11 Jul 1995 08:55:22 -0700 Date: Tue, 11 Jul 1995 08:53:20 -0800 (PDT) From: "Michael F. Speer" Reply-To: "Michael F. Speer" Subject: Sunergy 15 Broadcast To: rem-conf@es.net Cc: Michael.Speer@Eng.Sun.COM Message-Id: Content-Type: text X-Sun-Text-Type: ascii Folks: I would like to apologize for the poor quality of the audio signal for the Sunergy Broadcast. We are traced the problem to the satellite signal we are receiving. Is there interest in a re-broadcast of the program, once a production tape becomes available? Regards, Michael Speer Sun Microsystems From rem-conf-request@es.net Tue Jul 11 12:18:41 1995 Received: from posaune.tamu.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jul 1995 09:18:14 -0700 Received: by posaune.tamu.edu (NX5.67e/NX3.0M) id AA26668; Tue, 11 Jul 95 11:18:24 -0500 Message-Id: <9507111618.AA26668@posaune.tamu.edu> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Original-Received: by NeXT.Mailer (1.118.2) PP-warning: Illegal Received field on preceding line From: dhess Date: Tue, 11 Jul 95 11:18:22 -0500 To: rem-conf@es.net Subject: Re: Sunergy #15 Broadcast References: So can anybody explain what happened to Sun's transmission of this and why we could only receive it by ISI rebroadcasting it from 140.173.8.4? Is this standard practice? Whatever the reason, kudos to ISI for setting that up. Too bad they didn't do it for Sunergy #13 however. We never got anything on that one. Thanks. Dave --- David K. Hess Network Analyst David-Hess@tamu.edu Computing and Information Services - Network Group (409) 845-0372 (work) Texas A&M University From rem-conf-request@es.net Tue Jul 11 14:17:54 1995 Received: from darwin.pacom.mil (actually 192.91.7.70) by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jul 1995 11:17:18 -0700 Received: by darwin.pacom.mil (5.x/SMI-SVR4) id AA10638; Tue, 11 Jul 1995 08:14:04 -1000 Date: Tue, 11 Jul 1995 08:14:04 -1000 (HST) From: Winston KC Dang Subject: Re: What has happened to the GMS satellite images? To: Yozo Toda Cc: rem-conf@es.net In-Reply-To: <199507110752.QAA15430@aohakobe.ipc.chiba-u.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I used to be in charge of delivering these images. I will probably be starting it up again next month when I change jobs. Winston On Mon, 10 Jul 1995, Yozo Toda wrote: > > > Does anyone know what has happened to the GMS satellite images that > > were broadcasted over the Mbone until recently? I haven't seen an sd > > As I remember correctly, this session was sent from NASA. > (I don't remember the IP address or where to send a mail, sorry.) > > I love this image, and usually displayed it on the root window. > The STS-71 session is over now, and I hope > the broadcasting of satellite images start again, if possible. > > Whom should we say this kind of request?? > > -- yozo. > From rem-conf-request@es.net Tue Jul 11 17:43:37 1995 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jul 1995 14:43:12 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14609(4)>; Tue, 11 Jul 1995 14:43:02 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <49860>; Tue, 11 Jul 1995 14:42:58 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: dhess cc: rem-conf@es.net Subject: Re: Sunergy #15 Broadcast In-reply-to: Your message of "Tue, 11 Jul 95 09:18:22 PDT." <9507111618.AA26668@posaune.tamu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jul 1995 14:42:46 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <95Jul11.144258pdt.49860@crevenia.parc.xerox.com> In message <9507111618.AA26668@posaune.tamu.edu> you write: >So can anybody explain what happened to Sun's transmission of this and >why we could only receive it by ISI rebroadcasting it from 140.173.8.4? Uh, 140.173.8.4 is Sun. (Well, at least, the 140.173.8 subnet is an ethernet hanging off of the Sun DARTNet router...) Bill From rem-conf-request@es.net Tue Jul 11 22:21:10 1995 Received: from cavebear.com (actually pax.cavebear.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jul 1995 19:20:39 -0700 Received: by cavebear.com (4.1/SMI-4.1) id AA06705; Tue, 11 Jul 95 19:20:26 PDT Date: Tue, 11 Jul 1995 19:20:26 -0700 (PDT) From: Stephen Casner X-Sender: casner@pax.cavebear.com To: rem-conf@es.net Subject: RTP Profile to Last Call Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To the Audio/Video Transport WG: A new version of the RTP Audio/Video Profile has been posted as draft-ietf-avt-profile.ps,txt. I have also submitted a request for IESG Last Call on publication of the profile as a Proposed Standard. This is a key step because the IESG has deferred action on the main RTP spec until the profile spec was available so the two could be processed together. Based on comments on the previous profile draft, the new profile draft retains the DVI encoding spec currently in use on the MBone, but changes the name from IDVI to DVI4 (4 bits) to distinguish it >from the IMA recommendation for DVI. There is one change of significance in this profile that I want to point out because it has not yet been discussed on this list. In a recent email discussion among the authors and implementors of the RTP payload format spec for H.261 video, it was decided that the clock rate for the RTP timestamps in that payload format should be a multiple of the frame rate for H.261 (30000/1001, or about 29.97) so that RTP timestamps can be calculated exactly from the sampling rate. This parallels the use of the sampling clock directly for audio payload formats. Previous H.261 format specs used a 65536Hz clock for RTP timestamps as did most video formats. This is convenient for calculation of the RTP timestamp in RTCP sender reports, but may result in +/-1 errors in translating between timestamps and frame numbers. The MPEG encoding uses a 90kHz clock since it is a common multiple of 24, 25, ~29.97 and 30 frames/second, and this clock is also used as the RTP timestamp clock rate for the MPEG payload format. To keep the clock rate common across all video payload formats as much as possible, 90kHz was chosen for the new H.261 payload format spec as well. Unfortunately, this spec was not completed in time for the pre-IETF cutoff, so it won't be posted until after IETF. The change of significance to the profile is to specify 90kHz as the timestamp for all the video payload formats. Ron Frederick has agreed to this change for nv, but this may come as a surprise to the authors of other video payload formats. It may seem presumptuous to submit for Last Call a spec that contains this change without a WG discussion first, but I feel that it is critical to release the RTP spec from its holding pattern ASAP. If would be best if all video payload formats can adopt the 90kHz clock rate, but if some cannot, it is a simple matter during the RFC editing process to change the table entry in the profile spec back to 65536 for those formats. Comments on this change, or any other Last Call responses, are welcome. -- Steve From rem-conf-request@es.net Wed Jul 12 04:29:06 1995 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jul 1995 01:28:29 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Jul 1995 09:28:14 +0100 To: rem-conf@es.net Subject: Mbone misrepresentation and providers - ComunciationsWeek Date: Wed, 12 Jul 95 09:28:04 +0100 Message-ID: <1264.805537684@cs.ucl.ac.uk> From: Jon Crowcroft there are tow articles in Communications Week Intl thuis week (10th july issue which again misrepresent the mbone 1/ claims that audio and video are trashing the internet (true, but only because of HTTP and non-multicast traffic) - a provider is quoted )probably out of context, since i knw them to be a smart outfit) again makes the weird requerst for people to "cooperate" - this showqs a profound misunderstaniding of the dfifference between a commercial and the academic internet: if a provider is making money out of subscribvers, their cooperation consists of maximising utilisation - unlike a set of users in a shared resource (the "commons") - it is the providers job to protext themselves the way to protect a commercial net against CuSeeMe and Web traffic (and mbone traffic for that matter) is not to ban it - it is to place CuSeeMe reflectors _of the providers own_ and Web proxy/cache servers _of the providers own_ and mbone routers _of the povders own_ inside the providers net - that way , they offer both more AND better services....so long as you point all your subscribvers at the proxys/mbone routers/reflectors... 2/ The solution proposed by vint cerf is ATM!!! (no comment) sorry to rant again.... jon From rem-conf-request@es.net Wed Jul 12 08:10:54 1995 Received: from uu7.psi.com by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jul 1995 05:10:15 -0700 Received: by uu7.psi.com (5.65b/4.0.940727-PSI/PSINet) via UUCP; id AA01286 for ; Wed, 12 Jul 95 08:02:19 -0400 Received: from mailgate1.insoft.com by insoft.com (4.1/InSoftMail-1.4) id AA28133; Wed, 12 Jul 95 07:57:20 EDT Original-Received: from cc:Mail by mailgate1.insoft.com id AA805560551 Wed, 12 Jul 95 07:49:11 EDT PP-warning: Illegal Received field on preceding line Date: Wed, 12 Jul 95 07:49:11 EDT From: mrc@insoft.com (Murray R. Cantor) Message-Id: <9506128055.AA805560551@mailgate1.insoft.com> To: rem-conf@es.net Subject: Re: unsubscribe unsubscribe From rem-conf-request@es.net Wed Jul 12 12:27:42 1995 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jul 1995 09:27:07 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Jul 1995 17:26:49 +0100 From: Mark Handley Organisation: Computer Science, University College London Phone: +44 71 387 7050 ext 3666 To: rem-conf@es.net Subject: Session Description Protocol pre-draft (1.4) Date: Wed, 12 Jul 95 17:26:46 +0100 Message-ID: <13787.805566406@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk Unfortunately I missed the I-D deadline for the Stockholm IETF (spent too much time re-configuring the European Mbone in time for the IETF!) There is a new SDP draft, but as I've already missed the deadline, I thought I'd just release it to confctrl and remconf for now, and then amend it and release it properly after the IETF along with a draft desribing the announcement protocol, which has now been removed from the SDP draft. Quite a bit has changed - though almost all of the changes have been discussed either in Danvers or on the confctrl list. You can get a copy from: http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps Mark From rem-conf-request@es.net Wed Jul 12 15:51:43 1995 Received: from edina.xenologics.com by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jul 1995 12:51:08 -0700 Received: from [194.77.7.96] (slip-96.xenologics.com [194.77.7.96]) by edina.xenologics.com (8.6.8.1/8.6.6) with SMTP id VAA02531; Wed, 12 Jul 1995 21:52:39 +0200 Message-Id: <199507121952.VAA02531@edina.xenologics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Jul 1995 21:52:03 +0100 To: rem-conf@es.net From: m.niederberger@edina.xenologics.com (Michael Niederberger) Subject: subscribe subscribe From rem-conf-request@es.net Wed Jul 12 16:33:10 1995 Received: from fenris.hiof.no by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jul 1995 13:32:36 -0700 Received: from abdallah.hiof.no by fenris.hiof.no with SMTP (PP) id <03329-0@fenris.hiof.no>; Wed, 12 Jul 1995 22:31:43 +0200 Received: by abdallah.hiof.no (940816.SGI.8.6.9/940406.SGI.AUTO) id UAA12525; Wed, 12 Jul 1995 20:30:29 GMT Date: Wed, 12 Jul 1995 20:30:27 +0000 From: Borre Ludvigsen To: rem-conf@es.net Subject: unsubscribe In-Reply-To: <13787.805566406@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE unsuscribe B=F8rre Ludvigsen - http://www.hiof.no/~borrel=20 finger: borrel@abdallah.hiof.no From rem-conf-request@es.net Wed Jul 12 18:42:19 1995 Received: from postoffice3.mail.cornell.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jul 1995 15:41:37 -0700 Received: from [132.236.199.121] (TIM-DORCEY.CIT.CORNELL.EDU [132.236.199.121]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id SAA08504; Wed, 12 Jul 1995 18:40:58 -0400 Date: Wed, 12 Jul 1995 18:40:58 -0400 From: Tim_Dorcey@cornell.edu Message-Id: <199507122240.SAA08504@postoffice3.mail.cornell.edu> To: Jon Crowcroft X-Sender: td11@postoffice3.mail.cornell.edu Subject: Re: Mbone misrepresentation and providers - ComunciationsWeek Cc: rem-conf@es.net Jon-- I am in firm agreement with your characterization of the roles of network providers and consumers. But, I would like to correct what I think may be a common misunderstanding of CU-SeeMe: that its impact on the Internet would be a lot different if it were to use multicast. It's not so much that there are a lot of people receiving replications of the same source; there are just a lot of people receiving a lot of different sources (since it only costs $100 + Mac + Internet service to become a video source). As far as I can tell, it is being used more like the phone system than like a television broadcast, though the popular press does seem to find the notion of an underground television network more exciting, so they further the misconception that lots of people are watching "events" on the Internet with CU-SeeMe (is it any surprise that everything looks like mass media to the mass media?). I think there is a bit of irony in the fact that much of the problem with current versions of CU-SeeMe results from our original aim toward a multicast environment. In particular, one of our design objectives was that we should be able to replace the reflector functionality with multicast without dramatically changing protocols. This precluded the reflector from participating in any kind of flow control, when, in fact, it could have easily done individualized rate control and congestion avoidance on each point-to-point link. Instead, we tried to do only what could also be done in a multicast environment, and so have the case of someone with a 28.8 modem connecting to a reflector and getting an unmoderated 300 kbps blasted their way. One could argue that if 2 people in the same region did that same thing at the same time, then a problem that was twice as bad could have been made half as bad by using multicast, but that doesn't really address the original problem. Is it worse to send 2 packets along some link when 1 would have been sufficient than to send 1 packet along some link when none should have been sent? How is this situation addressed in a multicast world? Of course, it is not so hard to solve in a unicast setting. Designing a real time protocol that would compete "fairly" with TCP streams on a congested link is, I think, a tough problem to approach only from the end points, but adjusting transmission rates to find a fixed capacity limit is not. So, for the immediate future with CU-SeeMe we are going to abandon the requirement that protocols generalize to a multicast setting, and focus on individualized flow control. That seems to be where we can do the most good the most quickly, and we worry about generalizing to multicast when it becomes more readily available. I am not arguing whether CU-SeeMe is a "good" thing for the Internet; just that its impact on the net has little to do with its lack of multicast capability. CU-SeeMe would be more *useful* if it supported multicast so that people could indeed "televise" large scale events, but that doesn't mean they would decrease what they are doing now. The more significant issue with CU-SeeMe is its widespread accessibility, and that is an issue that the mbone will hopefully soon face. For what size conference do the gains in efficiency achieved by multicast outweigh the loss of flow control? For what conferencing scenarios would a single replicator, located in the network core, and performing individualized flow control, work better than a more efficient replication strategy, but without flow control? If the network is provisioned to support a lot of point-to-point flows anyway, how much is gained by reducing replicates in the core? Or, does most of this become a non-issue with more sophisticated queue management? Tim __________________________________________________________________ Tim Dorcey Tim_Dorcey@cornell.edu Sr. Programmer/Analyst (607) 255-5715 Advanced Technologies & Planning CIT Network Resources Cornell University Ithaca, NY 14850 __________________________________________________________________ From rem-conf-request@es.net Wed Jul 12 19:47:41 1995 Received: from cavebear.com (actually pax.cavebear.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jul 1995 16:46:47 -0700 Received: by cavebear.com (4.1/SMI-4.1) id AA11014; Wed, 12 Jul 95 16:46:35 PDT Date: Wed, 12 Jul 1995 16:46:35 -0700 (PDT) From: Stephen Casner X-Sender: casner@pax.cavebear.com To: rem-conf@es.net Subject: RTP timestamp rate change for nv encoding Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Valdis Kletnieks asked me a good question in response to my message about using a 90kHz clock for the RTP timestamps in video payload formats. His concern was that the change from 65536 to 90000 would cause an incompatibility for all the copies of nv that are out there on the MBone. This is not a problem because the released version of nv (3.3) implements RTP version 1. In that version of RTP, all media used a 65536 clock for the RTP timestamps, and that version of nv will continue to operate as it has before. The new profile document is for RTP version 2, the current version of the RTP spec. I hope there will be a new version of nv released that implements RTPv2, and then that one will use the 90kHz clock. The incompatibility introduced by the clock change is not an issue because the RTP versions are already incompatible. This issue is more significant for vic which already implements RTP as specified in the draft just before the current one. vic already has an incompatibility hurdle to cross to implement the last few changes in RTP and the other changes in the H.261 payload format. The difference in clock rate will just be another incompatibility in that mix. This transition isn't going to be easy (getting rid of all the old copies of vic), but it needs to be done. I assume Steve McCanne plans to do it as soon as the current specs are settled. Note that vic also implements RTP version 1 for backward compatibility with nv and ivs, and in those modes vic will need to continue using the 65536 Hz clock. This will all be much cleaner once we get RTPv2 published and can leave the older versions behind. There may be other implementations of video tools using RTPv2 that would be affected by this change, but I have not heard comments from those quarters yet. -- Steve From rem-conf-request@es.net Thu Jul 13 02:15:23 1995 Received: from aohakobe.ipc.chiba-u.ac.jp by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jul 1995 23:14:57 -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 PAA19413 for ; Thu, 13 Jul 1995 15:15:47 +0900 Message-Id: <199507130615.PAA19413@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: Re: Session Description Protocol pre-draft (1.4) In-reply-to: Your message of "Wed, 12 Jul 1995 17:26:46 +0100." <13787.805566406@cs.ucl.ac.uk> Date: Thu, 13 Jul 1995 15:15:47 +0900 From: Yozo Toda (TELEPHONE +81-43-290-3539) question from a novice user: > You can get a copy from: > http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps I glanced at this draft, and I just understood the contents of .sd_cache. but I find "n=" field (for each session) in .sd_cache. what is this?? No explanation of this field (in the explanation of SDPv1) in the draft. -- yozo. From rem-conf-request@es.net Thu Jul 13 04:09:34 1995 Received: from ulysse.enst.fr (actually inf.enst.fr) by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 01:08:45 -0700 Received: from argos.enst.fr (alioto@argos.enst.fr [137.194.160.87]) by ulysse.enst.fr (8.6.10/8.6.10) with ESMTP id KAA24379 for ; Thu, 13 Jul 1995 10:08:41 +0200 From: Salvatore Alioto Received: (alioto@localhost) by argos.enst.fr (8.6.10/8.6.10) id KAA03185 for rem-conf@es.net; Thu, 13 Jul 1995 10:08:34 +0200 Message-Id: <199507130808.KAA03185@argos.enst.fr> Subject: unsubscribe To: rem-conf@es.net Date: Thu, 13 Jul 1995 10:08:32 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 154 Please unsubscribe me -- E-mail: alioto@inf.enst.fr || Salvatore.Alioto@enst.fr P-mail: Telecom Paris 46, rue Barrault - 75634 Paris cedex 13 From rem-conf-request@es.net Thu Jul 13 04:33:40 1995 Received: from mailhost.lut.ac.uk (actually bgate.lut.ac.uk) by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 01:32:51 -0700 Received: (jon@localhost) by weeble.lut.ac.uk (8.6.12/8.6.9) id JAA07151; Thu, 13 Jul 1995 09:31:59 +0100 Date: Thu, 13 Jul 1995 09:31:59 +0100 (BST) From: Jon Knight To: Tim_Dorcey@cornell.edu cc: Jon Crowcroft , rem-conf@es.net Subject: Re: Mbone misrepresentation and providers - ComunciationsWeek In-Reply-To: <199507122240.SAA08504@postoffice3.mail.cornell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 12 Jul 1995 Tim_Dorcey@cornell.edu wrote: > [...] This precluded the > reflector from participating in any kind of flow control, when, in fact, it > could have easily done individualized rate control and congestion avoidance > on each point-to-point link. Instead, we tried to do only what could also > be done in a multicast environment, and so have the case of someone with a > 28.8 modem connecting to a reflector and getting an unmoderated 300 kbps > blasted their way. I might be missing something here, but doesn't the mrouted have rate limiting thresholds? It certainly seems to be mentioned in our mrouted.conf file (mrouted.conf,v 3.5.1.1 1995/05/09 05:48:48 fenner). We've got it set to something like 500kbps (the default) but then we're on the SuperJANET SMDS service. If we had a tunnel over a 28.8K modem I guess we'd rate limit that to something like 20-25K (to give a bit of room for other traffic and allow for PPP overhead). So it looks like the reflector could legitimately impose rate limits to stop ISP links from being flooded with packets that nobody will ever see and still be multicast-ready. Or am I completely out of line here? 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 Thu Jul 13 05:27:56 1995 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 02:27:22 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jul 1995 10:26:12 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 171 419 3666 To: Yozo Toda (TELEPHONE +81-43-290-3539) cc: rem-conf@es.net Subject: Re: Session Description Protocol pre-draft (1.4) In-reply-to: Your message of "Thu, 13 Jul 95 15:15:47 +0800." <199507130615.PAA19413@aohakobe.ipc.chiba-u.ac.jp> Date: Thu, 13 Jul 95 10:26:03 +0100 Message-ID: <16515.805627563@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk > >question from a novice user: > >> You can get a copy from: >> http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps > >I glanced at this draft, and I just understood the contents of .sd_cache. >but I find "n=" field (for each session) in .sd_cache. what is this?? >No explanation of this field (in the explanation of SDPv1) in the draft. First, bear in mind that SDP 01.4 in the draft is not what sd does today (see Appendix 1 for the main differences). The draft describes the session description protocol. This is what SDP clients should exchange to communicate session information. What your particular client decides to store locally as a cache is entirely up to it. However, given an SDP client has an SDP parser, storing SDP as a cache is sensible. Now, there's a little information that the SDP message didn't contain that you might wish to store in a cache - where you first heard the announcement from, where you last heard the announcement from, when you last heard it - that's what the "n=" field in .sd_cache stores. Does that clarify things? Mark From rem-conf-request@es.net Thu Jul 13 07:40:58 1995 Received: from aohakobe.ipc.chiba-u.ac.jp by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 04:40:13 -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 UAA20503 for ; Thu, 13 Jul 1995 20:41:02 +0900 Message-Id: <199507131141.UAA20503@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: Re: Session Description Protocol pre-draft (1.4) In-reply-to: Your message of "Thu, 13 Jul 1995 10:26:03 +0100." <16515.805627563@cs.ucl.ac.uk> Date: Thu, 13 Jul 1995 20:41:01 +0900 From: Yozo Toda (TELEPHONE +81-43-290-3539) > as a cache is sensible. Now, there's a little information that the > SDP message didn't contain that you might wish to store in a cache - > where you first heard the announcement from, where you last heard the > announcement from, when you last heard it - that's what the "n=" field > in .sd_cache stores. Thanks! now I can decode all information of "n" field using strtoul(), ctime(), inet_ntoa() (-: -- yozo. From REM-CONF-request@es.net Thu Jul 13 09:24:52 1995 Received: from pppl.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 06:24:17 -0700 Received: from RAX (rax.pppl.gov [192.55.106.12]) by pppl.gov (8.6.12/8.6.10) with SMTP id JAA26867 for ; Thu, 13 Jul 1995 09:24:14 -0400 From: schechtm@rax.pppl.gov Date: Thu, 13 Jul 1995 09:18:24 -0400 Message-Id: <95071309182410@rax.pppl.gov> To: REM-CONF@es.net Subject: solaris audio problem X-VMS-To: REM-CONF@ES.NET X-VMS-Cc: SCHECHTM Hi, I get the following message from vat 3.4 on a Sparc5 running Solaris 5.4 audio write: Operation would block Is this the previously mentioned solaris audio problem that is fixed with patch 102125-02? Are there other patches that I should know about? Thanks in advance, Nathan Nathan Schechtman email: nschechtman@pppl.gov Princeton Plasma Physics Lab phone: 609-243-3465 PO Box 451 fax: 609-243-3086 Princeton, NJ 08543-0451 From REM-CONF-request@es.net Thu Jul 13 09:35:40 1995 Received: from pppl.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 06:35:15 -0700 Received: from RAX (rax.pppl.gov [192.55.106.12]) by pppl.gov (8.6.12/8.6.10) with SMTP id JAA27534 for ; Thu, 13 Jul 1995 09:35:14 -0400 From: schechtm@rax.pppl.gov Date: Thu, 13 Jul 1995 09:27:30 -0400 Message-Id: <95071309273030@rax.pppl.gov> To: REM-CONF@es.net Subject: ethernet hardware-multicast question X-VMS-To: REM-CONF@ES.NET X-VMS-Cc: SCHECHTM Perhaps someone who is familiar with multicast protocols and issues can shed some light on an issue which has come up here at our site and is affecting how we are thinking about implementing Multicast in support of MBone on our local networks. In our recent work with bringing up Mbone capability, the question arose as to whether all (or many) devices on our network are being affected by Multicast traffic. The issue appears to be that some devices (an unknown number) are configured so that the multicast passes through the ethernet hardware and is handled within the CPU, thus slowing up the node(s) in question. One of us claims that this is simply an improperly configured board(s) and that in the properly configured case, an ethernet board should be able to reject unwanted multicasts at the hardware level. Do you know whether this is the case with all boards, some boards, a few boards? Is there perhaps a better place to ask this question? We've worked ourselves around this issue temporarily, but with increased use of desktop A/V the issue will become more and more important. Thanks in advance for any help, Nathan Schechtman email: nschechtman@pppl.gov Princeton Plasma Physics Lab phone: 609-243-3465 PO Box 451 fax: 609-243-3086 Princeton, NJ 08543-0451 From REM-CONF-request@es.net Thu Jul 13 10:30:58 1995 Received: from puli.cisco.com by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 07:30:28 -0700 Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id HAA23135; Thu, 13 Jul 1995 07:30:16 -0700 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Jul 1995 10:30:18 -0400 To: schechtm@rax.pppl.gov From: bstewart@cisco.com (Bob Stewart) Subject: Re: ethernet hardware-multicast question Cc: REM-CONF@es.net At 9:27 AM 7/13/95, schechtm@rax.pppl.gov wrote: >The issue appears to be that some >devices (an unknown number) are configured so that the multicast passes >through the ethernet hardware and is handled within the CPU, thus >slowing up the node(s) in question. That's going to vary from one hardware implementation to another. The last time I noticed, most Ethernet controller chips weren't capable of doing perfect multicast filtering (for example the AMD LANCE). Even so, a smart board wrapped around it might add the capability at some cost, or probably more commonly, pass some multicast up to the driver software. All multicast filtering requires checking against a list of enabled multicast addresses at some point in the path. Although that can happen at higher levels, it will mostly happen no higher than driver level. It would be a pretty sad implementation that let unwanted multicast get all the way to application process level. So you can get any of: 1. No hardware filter -- all multicast comes up and bothers the CPU. 2. Partial hardware filter -- the controller chip uses some sort of hash or such to enable multicast "buckets". The LANCE, for example, has 64 buckets with a hash that determines what bucket a particular multicast address is in. To allow one in, you enable the entire 1/64 of multicast addresses in the same bucket. 3. Perfect hardware filter -- either the controller chip has an exhaustive list or some firmware or other added hardware on the controller board covers any imperfection. Armed with that you can at least ask pointed questions of your controller supplier. Bob From rem-conf-request@es.net Thu Jul 13 12:25:58 1995 Received: from scorpio.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 09:25:19 -0700 Received: by scorpio.arc.nasa.gov (940816.SGI.8.6.9/1.35) id HAA01842; Thu, 13 Jul 1995 07:12:21 -0700 Date: Thu, 13 Jul 1995 07:12:21 -0700 From: garyp@scorpio.arc.nasa.gov (Gary Paden) Message-Id: <199507131412.HAA01842@scorpio.arc.nasa.gov> To: rem-conf@es.net Subject: NASA Shuttle Mission STS-70 Mbone presentation. The primary mission is the launch and deployment of the 7th Tracking Data and Relay Satellite (TDRS) and will be the 6th placed in operational use. Secondary objectives of the mission are to fulfill the requirements of the Physiological and Anatomical Rodent Experiment/National Institites of Health-Rodents (PARE/NIH-R);Bioreactor Demonstration System (BDS), Commerical Protein Crystal Growth (CPCG); Amateur Radio Experiment-II and many other useful experiments. The mission will be approximately 8days in duration with the shuttle landing at Kennedy Space Flight Center July 21,1995 at 7:51a.m. (estimated). I apologize for the late posting of this broadcast. I was caught off guard with how soon the STS-70 lunached after the STS-71 mission. Gary Paden NASA-Ames/Sterling Video Technician garyp@scorpio.arc.nasa.gov (415)604-0082 From REM-CONF-request@es.net Thu Jul 13 12:57:42 1995 Received: from cavebear.com (actually pax.cavebear.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 09:56:43 -0700 Received: by cavebear.com (4.1/SMI-4.1) id AA12469; Thu, 13 Jul 95 09:56:36 PDT Date: Thu, 13 Jul 1995 09:56:36 -0700 (PDT) From: Stephen Casner X-Sender: casner@pax.cavebear.com To: Bob Stewart Cc: schechtm@rax.pppl.gov, REM-CONF@es.net Subject: Re: ethernet hardware-multicast question In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII It should be the case that most or all ethernet boards have a control to turn off receipt of all multicast packets at the hardware level. Therefore hosts that have no need for multicast should not see extra load. However, a host which does make some use of ethernet-level multicast (that is, it might not be IP multicast) must have multicast reception enabled, and the limitations of the filters that Bob Stewart explained would apply. -- Steve From rem-conf-request@es.net Thu Jul 13 17:26:15 1995 Received: from cavebear.com (actually pax.cavebear.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 14:25:47 -0700 Received: by cavebear.com (4.1/SMI-4.1) id AA13328; Thu, 13 Jul 95 14:23:00 PDT Date: Thu, 13 Jul 1995 14:22:59 -0700 (PDT) From: Stephen Casner X-Sender: casner@pax.cavebear.com To: vineet_kumar@ccm.jf.intel.com Cc: rem-conf@es.net Subject: Re: AVT meeting at IETF Stockholm In-Reply-To: <9507110058.AA27795@viipuri.nersc.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Vineet, Thank you for the questions you posed as discussion topics for the AVT meeting. Although I would be happy to discuss the questions further at the meeting if someone from your group will be attending, I think I can answer them now: > 1. Is there a way to synchronize the video with the mixed audio if the video > does not go through the same mixer. There are advantages in not having video > traverse an unnecessary path to the mixer. In general, synchronizing a video stream and an audio stream may be accomplished by calculating what timestamp for each stream represents a given point in time by relating the two through the pairs of RTP and NTP timestamps in the RTCP sender report. If there is a collection of audio streams going through a mixer and then to be synchronized with video at a downstream receiver, that mixer must participate in the synchronization. It could synchronize all the audio streams (assuming all their NTP timestamps are all referenced to the same clock such as absolute time) and then pass on the mixed stream with the new RTP timestamps that it generates. In the RTCP sender reports that the mixer generates, it would relate its own RTP timestamp for a given sample to the same point in time that the incoming RTP timestamps represented for the samples that were mixed to produce that sample. That is, even though the mixer will have to introduce some delay to accomplish the synchronization and mixing, it will pretend that it did not (the delay gets lumped in with the network propagation time). If the downstream receiver synchronizes the mixed stream with the video, each of the contributing audio streams will also be synchronized with the video. If one of the audio streams is primary, and it is not desired to synchronize the other audio streams, then the mixer could just copy through the timing relationship of the primary stream. > 2. Is there a standard way to resolve SSRC collision without the > use of RTCP BYE packet. Some RTP implementations may not use RTCP. The SSRC collision mechanism cannot rely on the BYE packets getting through because these are unreliable datagrams. If an implementation does not send the BYE, the mechanism should still work. However, it will mean the state information for the old SSRC will have to time out instead. Note that it is only reasonable to omit RTCP for applications where no back channel is available, for example in a one-way cable distribution plant. In that scenario, there may no possibility of an SSRC collision if there is only one source per session. If RTCP were omitted in an implementation, then sources might not even attempt to receive any packets. If such an implementation were used with a network that allowed multiple sources to send data to receivers, you could have a situation where two sources were sending to a session using the same SSRC. This would be observed by the recievers, but it would never be corrected. The receivers would cope by discarding packets from one of the sources, but it would be a matter of chance for each receiver which source was discarded. Applications that need more sophisticated control mechanisms than the minimal control provided by SDES information in RTCP may use some additional control protocol. However, the functions of RTCP that support monitoring of the data distribution should still be implemented. -- Steve From rem-conf-request@es.net Thu Jul 13 17:40:08 1995 Received: from xenon.ee.mcgill.ca by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 14:39:42 -0700 Received: from batman.ee.mcgill.ca by xenon.ee.mcgill.ca (4.1/SMI-4.1) id AA01644; Thu, 13 Jul 95 17:39:36 EDT Received: by batman.ee.mcgill.ca (4.1/SMI-4.1) id AA02257; Thu, 13 Jul 95 17:39:35 EDT Date: Thu, 13 Jul 1995 17:39:33 -0400 (EDT) From: "Wong Kerwin Yan Ming Mr." To: rem-conf@es.net Subject: unsubscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From rem-conf-request@es.net Fri Jul 14 00:28:34 1995 Received: from hydra (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jul 1995 21:28:10 -0700 Received: by hydra (5.x/SMI-SVR4) id AA01341; Thu, 13 Jul 1995 21:28:42 -0700 Date: Thu, 13 Jul 1995 21:28:42 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Cc: Megan Davies Walnut Subject: Agenda for AVT meeting Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Audio/Video Transport Working Group: Several people expressed interest in having a meeting of the Audio/Video Transport working group at IETF in Stockholm next week to discuss coordination with ITU-T Study Group 15, so a session has been scheduled for Wednesday 1300-1500. Sorry, no multicast of this session. Besides this topic, there are a few other issues we may want to discuss. Additional suggestions are welcome. -- Steve Casner Audio/Video Transport WG A G E N D A Wednesday, July 19, 13:00-15:00 - Joerg Ott will give a brief survey of the concepts and problems discussed at the ITU-T SG15 meeting in Stockholm in May - Discussion of these issues: - The problem SG15 wants to solve (but avoid overlapping MMUSIC discussion of ITU interaction on control protocols) - What aspects of RTP were seen as problems - The specific issue of ITU control of a payload format codespace - Other topics: - Solicitation of comments on the change to 90kHz clock for RTP timestamps for video media in the latest RTP Profile draft, or any other comments on the Profile. - The latest MPEG draft proposes that the RTP marker bit mark the start (not end) of a "payload unit" for the MPEG Transport Systems format -- is this a problem? - Vineet Kumar asked about synchronizing video with mixed audio, and resolving SSRC collisions without the use of RTCP BYE - Solicitation of feedback on points where the RTP spec is not clear From rem-conf-request@es.net Fri Jul 14 11:40:58 1995 Received: from turner.ecn.purdue.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jul 1995 08:40:29 -0700 Received: from turner.ecn.purdue.edu (salama@localhost) by turner.ecn.purdue.edu (8.6.12/3.7davy) id KAA00389; Fri, 14 Jul 1995 10:40:26 -0500 Message-Id: <199507141540.KAA00389@turner.ecn.purdue.edu> Date: Fri, 14 Jul 1995 10:40:26 -0500 From: Paul Salama To: rem-conf@es.net Subject: CSTP PI Meeting X-Sun-Charset: US-ASCII Hi, I'm having trouble receiving the CSTO PI meeting, can any one send me the addresses. Thanks Paul From rem-conf-request@es.net Fri Jul 14 13:26:26 1995 Received: from cerc.wvu.edu (actually cathedral.cerc.wvu.edu) by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jul 1995 10:25:58 -0700 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA25554; Fri, 14 Jul 95 13:23:48 EDT Received: by elk (5.x//ident-1.0) id AA01713; Fri, 14 Jul 1995 13:23:44 -0400 Date: Fri, 14 Jul 1995 13:23:42 -0400 (EDT) From: "Todd L. Montgomery" Subject: RMP Beta 1.2 available To: RMP Discussion Mailing List , rem-conf@es.net, cerc@es.net, all@cs.wvu.edu, frank@research.att.com, sabolish@ivv.nasa.gov Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII (I apologize to everyone who receives this multiple times) It is my pleasure to announce the availability of the Reliable Multicast Protocol C++ Library (RMP) Beta 1.2 for downloading. I believe this is the most stable version yet! Mostly due to the tireless efforts of our formal verification team! Included in this distribution are examples of RMP operation integrated with Embedded Tk, an RMP Tk shell, Xt interoperation, an MRP module for Python 1.2, and a basic naming service for RMP to enhance group manegement. Also, full updated, and _current_ specifications for RMP are included! The changes since Beta 1.1 are: Slight change to the packet formats (incompatible with 1.1b) Numerous bugs addressed Better WAN/MBone performance Better Configuration Management of library (more general) Much more resilient Fault Recovery operation Full protocol specification documents (Packets formats and operation) RMP Ping and RMP Ping Response packets supported Better error checking Less headers to be installed Cleaner compilations using RMP Library Dynamic RMP object (eliminates 99.9% of static information) Major fixes to resilient message handling Fixes to handlers so they work more consistently Several new RMPEvent types: QOS_MET, REFORM_DROPPED, JOIN_REJECTED Enhanced and addressed C interface Version, Release, and Patchlevel information compiled into library Better memory management Supported Platforms: Sun SunOS 4.1.3 Sun SunOS 5.3 (Solaris 2.3) Sun SunOS 5.4 (Solaris 2.4) SGI Irix 5.2 SGI Irix 5.3 DEC Ultrix 4.2, 4.3, 4.4 Linux 1.1.94+ Soon: DEC AXP The RMP distribution can be retrieved from: RMP WWW Home Page: http://research.ivv.nasa.gov/projects/RMP/RMP.html RMP FTP Site: ftp://research.ivv.nasa.gov/pub/src/RMP/Beta RMP is being brought to you by the NASA IV&V Facility, West Virginia University, and the Concurrent Engineering Research Center (CERC). The protocol development, design, and verification team are: Todd Montgomery tmont@cerc.wvu.edu Brian Whetten whetten@tenet.icsi.berkeley.edu John R. Callahan callahan@cerc.wvu.edu Jeff Morrison morrison@cerc.wvu.edu Yunqing Wu ywu@cerc.wvu.edu We look forward to everyones comments. Comments, Suggestions, and Bug Reports can be sent to: -- Todd Montgomery tmont@cerc.wvu.edu http://research.ivv.nasa.gov/~tmont/index.html From rem-conf-request@es.net Fri Jul 14 16:09:12 1995 Received: from posaune.tamu.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jul 1995 13:08:48 -0700 Received: by posaune.tamu.edu (NX5.67e/NX3.0M) id AA29487; Fri, 14 Jul 95 15:08:59 -0500 Message-Id: <9507142008.AA29487@posaune.tamu.edu> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Original-Received: by NeXT.Mailer (1.118.2) PP-warning: Illegal Received field on preceding line From: dhess Date: Fri, 14 Jul 95 15:08:57 -0500 To: rem-conf@es.net Subject: Re: Sunergy #15 Broadcast References: <95Jul11.144258pdt.49860@crevenia.parc.xerox.com> > Uh, is Sun. (Well, at least, the 140.173.8 subnet is an ethernet > hanging off of the Sun DARTNet router...) Strange. I can't traceroute to that address (and couldn't that day either), I can't inverse resolve it, and whois 140.173.0.0 says: DARPA ISTO (NET-DARTNET) Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Netname: DARTNET Netnumber: 140.173.0.0 Coordinator: Prue, Walt (WP8) PRUE@ISI.EDU (310) 822-1511 Record last updated on 03-Jan-91. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. So I assumed ISI was responsible. Anybody care to shed more light on this? Dave --- David K. Hess Network Analyst David-Hess@tamu.edu Computing and Information Services - Network Group (409) 845-0372 (work) Texas A&M University From rem-conf-request@es.net Fri Jul 14 19:05:52 1995 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jul 1995 16:04:37 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id QAA20868; Fri, 14 Jul 1995 16:04:37 -0700 Message-Id: <199507142304.QAA20868@rx7.ee.lbl.gov> To: dhess cc: rem-conf@es.net Subject: Re: Sunergy #15 Broadcast In-reply-to: Your message of Fri, 14 Jul 95 15:08:57 CDT. Date: Fri, 14 Jul 95 16:04:36 PDT From: Van Jacobson ISI is responsible for administering Dartnet but Dartnet is a national, limited access, research testbed. It has no default routes & isn't known to any of the national backbones so you can't ping it or traceroute to it unless you're one of the sites directly connected to it. Dartnet can originate multicast because DVMRP is a routing protocol & 140.173 multicast routes are injected into the MBone even though 140.173 unicast routes are not. - Van From rem-conf-request@es.net Sat Jul 15 06:21:21 1995 Received: from eagle.rvs.uni-hannover.de by osi-west.es.net with ESnet SMTP (PP); Sat, 15 Jul 1995 03:20:47 -0700 Received: from borneo.rvs.uni-hannover.de by eagle.rvs.uni-hannover.de with smtp (Smail3.1.28.1 #6) id m0sX4Kz-0000pEC; Sat, 15 Jul 95 12:20 METDST Received: by borneo.rvs.uni-hannover.de (Smail3.1.28.1 #8) id m0sX4Kx-0001QoC; Sat, 15 Jul 95 12:20 MET DST Date: Sat, 15 Jul 1995 12:20:42 +0200 (MET DST) From: Michael Fromme X-Sender: fromme@borneo To: rem-conf@es.net Subject: nv driver for Parallax (Solaris 2.4) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We recently upgraded a Parallax equipped workstation to Solaris 2.4. Does anybody know, if there is a patch for nv to support the Parallax Video Card under Solaris 2.4? Michael --- Michael Fromme Lehrgebiet Rechnernetze und Verteilte Systeme fromme@rvs.uni-hannover.de Universit"at Hannover, Germany Tel: +49 0511 / 762 3977 std/disclaimer: Die ge"au\3erten Meinungen sind meine eigenen! My opinions are my own. From rem-conf-request@es.net Sun Jul 16 06:55:27 1995 Received: from ki1.chemie.fu-berlin.de by osi-west.es.net with ESnet SMTP (PP); Sun, 16 Jul 1995 03:54:51 -0700 Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from inf.fu-berlin.de (160.45.110.10) with smtp id ; Sun, 16 Jul 95 12:54 MEST Received: by inf.fu-berlin.de (/\oo/\ Smail3.1.29.1) from inf.fu-berlin.de [160.45.110.58] with smtp id ; Sun, 16 Jul 95 12:54 MET DST Received: by inf.fu-berlin.de (/\oo/\ Smail3.1.29.1) id ; Sun, 16 Jul 95 12:54 MET DST Message-Id: Date: Sun, 16 Jul 95 12:54 MET DST From: arnulf@inf.fu-berlin.de (Arnulf Guenther) To: rem-conf@es.net Subject: Re: NASA Shuttle Mission STS-70 Mbone presentation. Sorry, to bother you all with this: But could someone please tell me how to watch this event on MBone? I tried to locate this on my SD tool. But there're always the same entries. Nothing about NASA or the like. I'd be glad if some helpful soul can lift this mystery to me. Thank you and again I apologize if I disturbed this list, -Arnulf From rem-conf-request@es.net Mon Jul 17 09:44:14 1995 Received: from piraya.electrum.kth.se by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jul 1995 06:43:48 -0700 Received: from localhost.electrum.kth.se (cwe@localhost.electrum.kth.se [127.0.0.1]) by piraya.electrum.kth.se (8.6.10/8.6.9) with SMTP id PAA28059; Mon, 17 Jul 1995 15:43:36 +0200 Message-Id: <199507171343.PAA28059@piraya.electrum.kth.se> To: mbone@isi.edu, rem-conf@es.net cc: mbone@ietf33.nordu.net Subject: IETF transmission... Date: Mon, 17 Jul 95 15:43:35 +0200 From: Christian Wettergren Hi! The IETF Multicast Production Team (tm :-)) wants to know how people have received the IETF transmissions during the first day. Loss percentage, what channels, how you would like to ask questions etc. We have so far receieved two problem reports; 1/ Bad reception at certain sites in the UK. This may be due to ATM-tunnel transitions, this is being investigated. Brunel.ac.uk had the following path; * mrouter.ietf33.nordu.net - stockholm.mbone.ebone.net - broodjeham.surfnet.nl - noc.ulcc.ja.net - - noc2.ulcc.ja.net - babbage.brunel.ac.uk ... We should have good quality at least as far as to broodjeham. 2/ Bad reception in Finland (goose.sms.fi) We believe this is also due to that ATM tunnels went down. Some of the tunnels between sauce.uio.no and somewhere at datanet.tele.fi are down. Route to goose.sms.fi (?) * mrouter.ietf33.nordu.net - stockholm.mbone.ebone.net - - directory.funet.fi This is strange, NORDUnet should copy with it. Could people at sauce.uio.no investigate if there is an ATM- problem at all? We are currently sending with PCM-encoded audio, and nv-video at 100 kbps. There are experimental video sent at 200-250 kbps with vic/jpeg, but that is restricted to the Nordic region so far. If people want to adjust thresholds according to the available bandwidth at other places, we could enlarge the region of higher broadcasts. -Christian Wettergren IETF Multicast Mission Control (IMMC :-)) From rem-conf-request@es.net Mon Jul 17 11:28:17 1995 Received: from piraya.electrum.kth.se by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jul 1995 08:27:48 -0700 Received: from localhost.electrum.kth.se (cwe@localhost.electrum.kth.se [127.0.0.1]) by piraya.electrum.kth.se (8.6.10/8.6.9) with SMTP id RAA29612; Mon, 17 Jul 1995 17:27:41 +0200 Message-Id: <199507171527.RAA29612@piraya.electrum.kth.se> To: mbone@isi.edu, rem-conf@es.net cc: bc@sunet.se, mbone@ietf33.nordu.net Subject: Retransmission of IETF sessions... In-reply-to: Your message of Mon, 17 Jul 95 17:15:52 +0100. <199507171515.RAA04709@tuborg.pilsnet.sunet.se> Date: Mon, 17 Jul 95 17:27:40 +0200 From: Christian Wettergren Today's IETF sessions will be retransmitted at 16:00 UTC. We had some problems recording this, so unfortunately only the last sessions will be rebroadcast (HTML and POISED'95). We hope to do better tomorrow. /The Multicast Production Team From rem-conf-request@es.net Mon Jul 17 11:51:48 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jul 1995 08:51:21 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05305; 17 Jul 95 11:47 EDT To: IETF-Announce:; cc: mwalnut@CNRI.Reston.VA.US, rem-conf@es.net Subject: 33rd IETF: ON-SITE UPDATE: MMUSIC/AVT Date: Mon, 17 Jul 95 11:47:41 -0400 From: Megan Davies Walnut Message-ID: <9507171147.aa05305@IETF.CNRI.Reston.VA.US> Group Name: Multiparty Multimedia Session Control (mmusic) Date/Time : Tuesday, 18 July : 0900-1130 (mbone coverage) Status : The first half 0900-1000 will be devoted to wrapping up mmusic issues. The second portion 1000-1130 will be devoted to ITU Coordination and will include AVT folks. This group will still meet in the Royale Room From rem-conf-request@es.net Mon Jul 17 12:23:36 1995 Received: from hill.msri.org (actually msri.org) by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jul 1995 09:22:48 -0700 Received: from whitney.msri.org by hill.msri.org (8.6.10/MSRI) id JAA07649; Mon, 17 Jul 1995 09:22:44 -0700 From: Dave Wright Received: by whitney.msri.org (940816.SGI.8.6.9/DW.6) id JAA03014; Mon, 17 Jul 1995 09:22:43 -0700 Date: Mon, 17 Jul 1995 09:22:43 -0700 Message-Id: <199507171622.JAA03014@whitney.msri.org> To: rem-conf@es.net Subject: Announcement of Random Walk and Geometry Random Walk and Geometry Lectures by Persi Diaconis, Harvard University and Laurent Saloff-Coste, CNRS July 24 - August 4, 1995 10:00 to 12:00 PST89PDT Random Walk is a classical subject with applications in physics, statistics, and mathematics. A typical question is, "How many times should a deck of cards be shuffled to mix it up?" Recently, new tools >from group theory, Riemannian geometry, and differential equations have allowed very sharp answers to these questions (e.g. 52 cards need to be shuffled seven times). We will develop the probability and geometry background from first principles. http://www.msri.org dw From rem-conf-request@es.net Mon Jul 17 12:25:06 1995 Received: from photon.magnus.acs.ohio-state.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jul 1995 09:24:24 -0700 Received: by photon.magnus.acs.ohio-state.edu (8.6.10/4.940426) id MAA27021; Mon, 17 Jul 1995 12:24:22 -0400 Date: Mon, 17 Jul 1995 12:24:22 -0400 From: Harpal Chohan Message-Id: <199507171624.MAA27021@photon.magnus.acs.ohio-state.edu> To: rem-conf@es.net Subject: Sparc5/Sunvideo/nv I have a symptom here which I'd appreciate any help on from someone who might have the same setup. Here's what I have... Sun Sparc5 Solaris 2.4 SunVideo Card nv-3.3beta for sunos5 The nv-3.3 binary finds the SunVideo card allright (i.e., it shows up in the Grabber controls as an active option). I can succesfully send out video if I chose the encoding type as "Sun CellB". However, if I select encoding types "Native NV" or "CU-SeeMe", all "nv" sends out is "snow". Anyone encounter this, or has this setup working? Had no problem when I was using SunOS 4.x/SunVideoPix/nv-3.3. Many thanks for any help... -h From rem-conf-request@es.net Mon Jul 17 15:17:40 1995 Received: from uhura.cc.rochester.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jul 1995 12:17:13 -0700 Received: from [128.151.24.34] (joel.psychiatry.rochester.edu [128.151.24.34]) by uhura.cc.rochester.edu (8.6.12/8.6.4) with SMTP id PAA14706 for ; Mon, 17 Jul 1995 15:17:09 -0400 Date: Mon, 17 Jul 1995 15:17:09 -0400 Message-Id: <199507171917.PAA14706@uhura.cc.rochester.edu> To: rem-conf@es.net From: jorr@uhura.cc.rochester.edu (Joel Richter) Subject: unsubscribe unsubscribe From rem-conf-request@es.net Mon Jul 17 15:57:59 1995 Received: from umr.edu (actually hermes.cc.umr.edu) by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jul 1995 12:57:33 -0700 Received: from saucer.cc.umr.edu (saucer.cc.umr.edu [131.151.1.58]) via ESMTP by hermes.cc.umr.edu (8.6.12/E.3.07) id OAA05892; Mon, 17 Jul 1995 14:57:30 -0500 From: Andrew Sears Received: from (sears@localhost) by saucer.cc.umr.edu (8.6.12/M.3.01) id OAA07054; Mon, 17 Jul 1995 14:57:30 -0500 Message-Id: <199507171957.OAA07054@saucer.cc.umr.edu> To: rem-conf@es.net Date: Mon, 17 Jul 1995 14:57:30 -0600 (CDT) X-Mailer: ELM [version 2.4 PL20] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 12 unsubscribe From rem-conf-request@es.net Mon Jul 17 21:58:53 1995 Received: from adelbert1.Stanford.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jul 1995 18:58:27 -0700 Received: (from mandami@localhost) by adelbert1.Stanford.EDU (8.6.8/8.6.12) id SAA02485 for rem-conf@es.net; Mon, 17 Jul 1995 18:57:08 -0700 From: Meng-Day Yu Message-Id: <199507180157.SAA02485@adelbert1.Stanford.EDU> Subject: IP_ADD_MEMBERSHIP prbs To: rem-conf@es.net Date: Mon, 17 Jul 1995 18:57:08 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 372 Hi, I am currently using a DECAlpha3000/700 running OSF1v3.1. I am having problems getting VAT and VIC to work. I receive the following message when I tried to execute the VIC binaries: vic: IP_ADD_MEMBERSHIP: Can't assign requested address. VAT has a similar error. Similar results were seen on a SunOS4.1.3 system as well. Any ideas? Thanks in advance. Mandel Yu From rem-conf-request@es.net Tue Jul 18 13:52:22 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jul 1995 10:51:54 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11975; 18 Jul 95 13:45 EDT To: IETF-Announce:; cc: mwalnut@CNRI.Reston.VA.US, rem-conf@es.net Subject: 33rd IETF: ON-SITE AGENDA: AVT CANCELLATION Date: Tue, 18 Jul 95 13:45:47 -0400 From: Megan Davies Walnut Message-ID: <9507181345.aa11975@IETF.CNRI.Reston.VA.US> Group Name: Audio/Video Transport WG Date/Time : Wed. 1300-1500 Status : CANCELLED The group finished its work during the second half of the second MMUSIC session. From rem-conf-request@es.net Tue Jul 18 15:26:19 1995 Received: from nautique.epm.ornl.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jul 1995 12:25:55 -0700 Received: (from lpz@localhost) by nautique.epm.ornl.gov (8.6.10/8.6.10) id PAA30048; Tue, 18 Jul 1995 15:25:54 -0400 Date: Tue, 18 Jul 1995 15:25:53 -0400 (EDT) From: "Lawrence MacIntyre - 615.576.0824" To: rem-conf mailing list Subject: possible problem with VAT on OSF/1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi: Has anyone noticed that sometimes when you run vat on DEC OSF/1, the machine remains in the multicast group after VAT exits? This seems to happen sporadically, and has been noticed on DEC OSF/1 versions 2.0, 3.0, and 3.2. We've not seen it on Suns or SGIs. Since nobody has the source, it's hard to figure out the problem. The only guesses that I have are: 1) vat uses the ioctl SIOCADDMULTI to add itself to the group and can sometimes not ioctl SIOCDELMULTI to leave the group. 2) DEC OSF/1 has a bug which allows the kernel to think it's still in a group after a socket which added itself with setsockopt(IP_ADD_MEMBERSHIP) goes away. Any clues? Lawrence ~ ------------------------------------------------------------------------------- lpz@nautique.epm.ornl.gov Lawrence MacIntyre lpz@ornl.gov Oak Ridge National Laboratory 615.574.8696 From rem-conf-request@es.net Tue Jul 18 21:39:01 1995 Received: from inet-gw-1.pa.dec.com by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jul 1995 18:38:35 -0700 Received: from bigpink.pa.dec.com by inet-gw-1.pa.dec.com (5.65/24Feb95) id AA05677; Tue, 18 Jul 95 18:31:23 -0700 Received: by bigpink.pa.dec.com; id AA09924; Tue, 18 Jul 1995 18:31:21 -0700 Message-Id: <9507190131.AA09924@bigpink.pa.dec.com> To: rem-conf@es.net Cc: band@std.com Subject: Severe Tire Damage 19-Jul-95 Date: Tue, 18 Jul 95 18:31:21 -0700 From: berc@pa.dec.com X-Mts: smtp The 19-Jul-1995 Severe Tire Damage mcast has been cancelled. STD is in the studio recording an album. Now there's a scary thought! The studio is getting ISDN service, so we may be able to transmit >from up there in the near future. Those waiting for STD t-shirts are going to have to wait another week or two. STD - not just any old 8-kHz mu-law encoded rock & roll band. Lance Berc berc@src.dec.com STD live image grabbing: http://chocolate.research.digital.com/std/control.html STD info: http://www.ubiq.com/std/band.html http://www.std.com/homepages/band mailto:band@std.com MBone tools for Alpha workstation: http://chocolate.research.digital.com/mbone From rem-conf-request@es.net Tue Jul 18 21:56:15 1995 Received: from VMULSA.ULSA.MX by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jul 1995 18:55:52 -0700 Received: from sunulsa.ulsa.mx by VMULSA.ULSA.MX (IBM VM SMTP V2R2) with TCP; Tue, 18 Jul 95 20:01:08 MEX Received: by sunulsa.ulsa.mx (5.0/SMI-SVR4) id AA00267; Tue, 18 Jul 1995 19:55:44 +0600 Date: Tue, 18 Jul 1995 19:55:43 -0600 (CST) From: "Octavio Bautista Zenil." X-Sender: root@sunulsa To: rem-conf@es.net Subject: unsubscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII content-length: 24 Please, unsubscribe me From rem-conf-request@es.net Wed Jul 19 04:10:04 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jul 1995 01:09:37 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06514; 19 Jul 95 4:08 EDT To: IETF-Announce:; cc: mwalnut@CNRI.Reston.VA.US, rem-conf@es.net Subject: 33rd IETF: ON-SITE AGENDA: RTL-BOF Room Change Date: Wed, 19 Jul 95 04:07:59 -0400 From: Megan Davies Walnut Message-ID: <9507190408.aa06514@IETF.CNRI.Reston.VA.US> Group Name: Read the Label BOF Date/Time : Wed., 19 July: 1530-1730 Status : Was in Carl Larsson, NOW in Winter Garden (mbone coverage) From rem-conf-request@es.net Wed Jul 19 04:12:52 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jul 1995 01:12:11 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06565; 19 Jul 95 4:10 EDT To: IETF-Announce:; cc: mwalnut@CNRI.Reston.VA.US, rem-conf@es.net Subject: 33rd IETF: ON-SITE AGENDA: RFC1006 Room Change Date: Wed, 19 Jul 95 04:10:47 -0400 From: Megan Davies Walnut Message-ID: <9507190410.aa06565@IETF.CNRI.Reston.VA.US> Group Name: RFC1006bis/ISO TP over IPv6 Date/Time : Wed. 19 July: 1530-1730 Status : Was in Winter Garden with mbone coverage Will now meet in Carl Larsson (no mbone coverage) From rem-conf-request@es.net Wed Jul 19 06:20:57 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jul 1995 03:20:22 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07772; 19 Jul 95 6:16 EDT To: IETF-Announce:; cc: mwalnut@CNRI.Reston.VA.US, rem-conf@es.net Subject: 33rd IETF: Read the Label BOF Date: Wed, 19 Jul 95 06:16:40 -0400 From: Megan Davies Walnut Message-ID: <9507190616.aa07772@IETF.CNRI.Reston.VA.US> Group Name: Read the Label BOF Date/Time : Wed., 19 July: 1530-1730 Status : Was in Carl Larsson, NOW in Winter Garden (mbone coverage) Chair : Vinton G. Cerf ========== This BOF is in response to the IETF community's recent flurry of discussions on the IETF email list regarding the "Kidcode" Internet-Draft and other "content-filtering" proposals. The USV and APPs Area Directors (JKRey, John Klensin, and Harald Alvestrand) feel that: * This issue is a problem that falls between the user services area (service, interface, and appropriateness aspects) and the applications area (protocol aspects, whichever of the three or four possible pieces are tampered with). * It is clear to us for a number of reasons that this should NOT be assigned to any existing WG, especially not to the RUN or to the HTTP WGs. The end result in further discussions with the IESG on this subject was to squeeze a BOF into the Stockholm meeting to discuss this topic further, and also to see if the IETF has an appropriate role in resolving this issue. From rem-conf-request@es.net Wed Jul 19 09:18:19 1995 Received: from insanus.matematik.su.se by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jul 1995 06:17:56 -0700 Received: from localhost (wizkids.matematik.su.se [130.237.198.20]) by insanus.matematik.su.se (8.6.10/8.6.9) with ESMTP id NAA28815 for ; Wed, 19 Jul 1995 13:17:52 GMT Message-Id: <199507191317.NAA28815@insanus.matematik.su.se> X-Address: Department of Mathematics, Stockholm University S-106 91 Stockholm SWEDEN X-Phone: int+8162000 X-Fax: int+86126717 X-Url: http://www.matematik.su.se To: rem-conf@es.net Subject: Subscribe me please. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22849.806159871.1@wizkids.matematik.su.se> Date: Wed, 19 Jul 1995 15:17:51 +0200 From: Leif Johansson Please subscribe me: leifj@matematik.su.se Best Regards Leif Johansson Leif Johansson Phone: +46 8 164541 Department of Mathematics Fax : +46 8 6126717 Stockholm University email: leifj@matematik.su.se From rem-conf-request@es.net Wed Jul 19 13:13:59 1995 Received: from kentfm.wksu.kent.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jul 1995 10:13:34 -0700 Received: from netware.wksu.kent.edu by kentfm.wksu.kent.edu (8.6.10/wksu.95.02.23) id NAA15115; Wed, 19 Jul 1995 13:15:46 -0400 Received: from WKSU/MAILQUEUE by netware.wksu.kent.edu (Mercury 1.20); 19 Jul 95 13:13:31 -0500 Received: from MAILQUEUE by WKSU (Mercury 1.20); 19 Jul 95 13:13:23 -0500 From: Chuck Poulton Organization: WKSU Radio / Kent State University To: rem-conf@es.net Date: Wed, 19 Jul 1995 13:13:18 EST -0500 Subject: Marilyn vos Savant to Speak / Inventors Hall Induction Ceremony Priority: normal X-mailer: Pegasus Mail v3.22 Message-ID: <3AB8136DF5@netware.wksu.kent.edu> Noted lecturer, researcher, and Parade Magazine columnist Marilyn vos Savant will speak on the relationship of government and scientific invention in modern times at the monthly meeting of the Akron Roundtable in Akron, Ohio. We plan to carry this feed live from Akron's Tangier restaurant on the MBONE this Thursday, July 20th at 12:30 pm EDT (1630 GMT). The session will be announced in sd. Questions for the speaker can be mailed to roundtable@wksu.kent.edu, and further information can be found at http://www.wksu.kent.edu/rt.html . A RealAudio version of the speech will also be available at the above URL soon after the event has concluded. The speaker will also be discussing the grand opening of Inventure Place, the National Inventors Hall of Fame. Audio from the Induction Ceremony itself will also be fed on the MBONE Saturday, July 22nd at 6:00 pm EDT (2200 GMT). See http://www.wksu.kent.edu/ for more information on this event as well. These events have been booked into the MBONE Broadcast Schedule page. From rem-conf-request@es.net Wed Jul 19 16:37:40 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jul 1995 13:36:49 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14051; 19 Jul 95 16:33 EDT To: IETF-Announce:; cc: mwalnut@CNRI.Reston.VA.US, rem-conf@es.net Subject: 33rd IETF: ON-SITE AGENDA: ADDRCONF CANCELLED Date: Wed, 19 Jul 95 16:33:50 -0400 From: Megan Davies Walnut Message-ID: <9507191633.aa14051@IETF.CNRI.Reston.VA.US> Group Name: Address Autoconfiguration WG Date/Time : Thu. 20 July: 0900-1130 Status : CANCELLED replaced with POISED95 for mbone coverage From rem-conf-request@es.net Wed Jul 19 16:42:31 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jul 1995 13:42:01 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14127; 19 Jul 95 16:36 EDT To: IETF-Announce:; cc: mwalnut@CNRI.Reston.VA.US, rem-conf@es.net Subject: 33rd IETF: ON-SITE AGENDA: POISED95 Room Change Date: Wed, 19 Jul 95 16:36:14 -0400 From: Megan Davies Walnut Message-ID: <9507191636.aa14127@IETF.CNRI.Reston.VA.US> Group Name: Process for Organization of Internet Standards Date/Time : Thu. 20 July: 0900-1130 Status : Relocated to Winter Garden (w/mbone coverage) From rem-conf-request@es.net Thu Jul 20 13:16:32 1995 Received: from piraya.electrum.kth.se by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jul 1995 10:15:59 -0700 Received: from localhost.electrum.kth.se (cwe@localhost.electrum.kth.se [127.0.0.1]) by piraya.electrum.kth.se (8.6.10/8.6.9) with SMTP id TAA06617; Thu, 20 Jul 1995 19:15:44 +0200 Message-Id: <199507201715.TAA06617@piraya.electrum.kth.se> To: mbone@isi.edu cc: rem-conf@es.net Subject: IETF transmission quality... Date: Thu, 20 Jul 95 19:15:43 +0200 From: Christian Wettergren Hi! The Multicast Production Team at the 33rd IETF would like to get reports on perceived quality in different corners of the world. All comments and suggestions on improvements etc are most welcome. We wish to thank you all and we hope that you enjoyed the transmissions. Christian Wettergren (and the rest of the MBone crew) cwe@it.kth.se KTH/Teleinformatics Stockholm, Sweden From rem-conf-request@es.net Thu Jul 20 14:20:25 1995 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jul 1995 11:19:54 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id LAA26657; Thu, 20 Jul 1995 11:19:25 -0700 Message-Id: <199507201819.LAA26657@rx7.ee.lbl.gov> To: "Lawrence MacIntyre - 615.576.0824" cc: rem-conf mailing list Subject: Re: possible problem with VAT on OSF/1 In-reply-to: Your message of Tue, 18 Jul 95 15:25:53 EDT. Date: Thu, 20 Jul 95 11:19:24 PDT From: Van Jacobson > The only guesses that I have are: > > 1) vat uses the ioctl SIOCADDMULTI to add itself to the group and can > sometimes not ioctl SIOCDELMULTI to leave the group. > > 2) DEC OSF/1 has a bug which allows the kernel to think it's still in a > group after a socket which added itself with > setsockopt(IP_ADD_MEMBERSHIP) goes away. In all the versions of IP multicast I'm familiar with, closing a socket causes an implicit SIOCDELMULTI (in systems based on Deering's code, this happens because in_pcbdetach() is called on every inet socket close & in_pcbdetach() calls ip_freemoptions() which calls in_delmulti()). Since the only time vat would want to exit the multicast group is when it exits, it lets the close on exit do the delmulti rather than wasting time by doing it explicitly. It's possible that DEC screwed up this part of the kernel but it seems like they would have noticed it (very few multicast apps do an explicit SIOCDELMULTI so an OSF system would essentially never leave any group it joined). Another possibility is that there's a child of the vat process keeping the multicast socket open (ie., if you middle-click on a name to get a unicast session -- for religious reasons John Ousterhout refuses to close open fd's in the tcl exec code & we got tired of fixing the same bug in every tcl distribution so sd & vat children inherit the parent's open fds). > Since nobody has the source, it's hard to figure out the problem. Yes, it would be nice if DEC made the source of OSF/1 publically available so we could fix problems like this. - Van From rem-conf-request@es.net Thu Jul 20 16:22:33 1995 Received: from hep.net (actually utah.hep.net) by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jul 1995 13:21:54 -0700 Received: from nhmxw0.fnal.gov by hep.net (5.x/SMI-SVR4) id AA12808; Thu, 20 Jul 1995 15:21:49 -0500 Received: from nhmxw2.fnal.gov.fnal.gov by nhmxw0.fnal.gov (4.1/SMI-4.1-DNI) id AA05055; Thu, 20 Jul 95 15:21:50 CDT Date: Thu, 20 Jul 95 15:21:50 CDT From: roediger@hep.net (Gary Roediger) Message-Id: <9507202021.AA05055@nhmxw0.fnal.gov> To: rem-conf@es.net Subject: Re: possible problem with VAT on OSF/1 Vat, I agree with you. -- > Since nobody has the source, it's hard to figure out the problem. -- -- Yes, it would be nice if DEC made the source of OSF/1 publically -- available so we could fix problems like this. -- -- - Van Gary From rem-conf-request@es.net Thu Jul 20 17:13:35 1995 Received: from portal.netedge.com by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jul 1995 14:13:04 -0700 Received: from NetEdge.COM by portal.netedge.com id AA01218; Thu, 20 Jul 95 17:09:50 EDT Received: from suicidesix.NetEdge.COM by NetEdge.COM id AA23333; Thu, 20 Jul 95 17:08:27 EDT Return-Path: Received: from localhost by suicidesix.NetEdge.COM (4.1/NECL-6.14) id AA05572; Thu, 20 Jul 95 17:05:17 EDT Message-Id: <9507202105.AA05572@NetEdge.COM> To: Christian Wettergren Cc: mbone@isi.edu, rem-conf@es.net Subject: Re: IETF transmission quality... In-Reply-To: Your message of "Thu, 20 Jul 1995 19:15:43 +0200." <199507201715.TAA06617@piraya.electrum.kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <5569.806274315.1@suicidesix.netedge.com> Date: Thu, 20 Jul 1995 17:05:16 -0400 From: Thomas Pusateri In message <199507201715.TAA06617@piraya.electrum.kth.se> you write: > >Hi! > >The Multicast Production Team at the 33rd IETF would like >to get reports on perceived quality in different corners >of the world. I listened in from chron.jcmax.com connected to a tunnel at interpath.net which connects to MAE EAST and gets its MBONE service from sprintlink. It is T1 speeds to MAE EAST. I almost constantly saw losses of 10% which made the audio useless. There was too much breaking up to understand the speech. Is it possible to use an audio coding format that is less susceptable to packet loss? Thanks for the effort though, Tom From rem-conf-request@es.net Thu Jul 20 18:32:11 1995 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jul 1995 15:31:16 -0700 Received: by precept.com (5.x/SMI-4.1) id AA13637; Thu, 20 Jul 1995 15:30:36 -0700 Date: Thu, 20 Jul 1995 15:30:36 -0700 (PDT) From: Stephen Casner To: Christian Wettergren Cc: mbone@ISI.EDU, rem-conf@es.net Subject: Re: IETF transmission quality... In-Reply-To: <199507201715.TAA06617@piraya.electrum.kth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 20 Jul 1995, Christian Wettergren wrote: > The Multicast Production Team at the 33rd IETF would like > to get reports on perceived quality in different corners > of the world. I was attending on-site, so I don't know what the remote reception was like. However, I was very impressed by the sophistication of the video production setup and the extra effort you folks put in to make available wb displays and graphics tablets for input. You've raised the standards for IETF Multicasts another notch or several. Bravo! -- Steve From rem-conf-request@es.net Thu Jul 20 18:47:43 1995 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jul 1995 15:46:43 -0700 Received: by precept.com (5.x/SMI-4.1) id AA13689; Thu, 20 Jul 1995 15:46:38 -0700 Date: Thu, 20 Jul 1995 15:46:37 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Minutes of AVT meeting at Stockholm IETF Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Enclosed below are the minutes of the AVT meeting held at the Stockholm IETF. Please send any comments you may have, in particular any corrections or additions that local or remote participants may have. Thanks. -- Steve Reported by Steve Casner/Precept Software Minutes of Audio/Video Transport Working Group (AVT) 1. Overview A meeting of the AVT Working Group was a late addition to the schedule at IETF in Stockholm to allow a face-to-face discussion following the recent email exchanges about coordination with ITU-T Study Group 15 on the use of RTP. The second half of the second MMUSIC session was used for this purpose. In addition to this primary topic, a few other questions, listed below, were discussed. 2. Coordination with ITU Joerg Ott gave a brief summary of the discussion at the SG-15 meeting held in Stockholm in May to discuss the H.323 and H.22Z recommendations for interworking LAN-based audio/video terminals with H.320 ISDN terminals. The scenario involves a gateway to provide address and protocol translations at several levels, with audio/video data transfer and multiplexing being only one. At that meeting several viewpoints were expressed with regard to RTP, ranging from defining a new protocol (H.22Z) that was only "inspired" by RTP, to using RTP as-is and defining a new setup protocol to go with it. At that time, SG-15 decided not to use RTP because of several problems they perceived. However, at a subsequent meeting organized by Rich Baker at PictureTel and in email discussion, this decision was reversed. It appears that the current position is to pursue use of RTP and the RTP A/V Profile as defined unless it turns out that this scheme will not work. There remain many questions about how connection setup will be done, but the specific problems regarding the use of RTP seem readily answerable: - RTP's presentation timestamp is not sufficient; a transport timestamp should be available for QoS measurement. A: The RTP timestamp was intended to be useful for QoS measurement (via the jitter field in the RTCP reception report). We believe it will work; if it does not work for ITU purposes it will not work for ours either. The mechanism needs to be demonstrated in practice during the Proposed Standard stage. Further details on use of the jitter measure with video formats are given in the next section. - H.323 needs to work over protocols other than IP (e.g., IPX). A: This is not a problem. RTP has no specific dependencies on IP; it requires only framing and multiplexing of RTP/RTCP from the layers below. - Provision of lip-sync if audio and video streams do not originate from the same source. A: RTCP includes timestamps that allow playing in synchrony any sources that can reference a common clock. It is suggested that absolute (wallclock) time be used as that reference when possible, and that the Network Time Protocol may be used to provide synchronization of the system clock to absolute time. If some system has no notion of absolute time, it can use elapsed time instead if all the sources to be synchronized can count the same elapsed time. If no reference clock is available, it seems unlikely that any alternative transport protocol could provide synchronization either. - Lack of stability in the RTP, profile and payload data format documents which are only in draft form. A: While there have been a number of changes during the time RTP has been designed, these documents have now reached a stable state. The main RTP spec and RTP profile have been submitted for IESG Last Call already, and the H.261 payload format spec will be submitted for Last Call immediately after IETF. These should be published as Proposed Standard RFCs by September. - Distinguishing multiple streams from the same source. A: Each "RTP session" is intended to carry only one medium. Multiple media should not be multiplexed in one RTP session based on the payload format code. Multiple streams from the same source may be sent in separate RTP sessions (destination transport addresses), in which case the SSRC may or may not be the same for each session (it is not required because the linkage is provided through the RTP CNAME). It is also possible for one host to send multiple SSRCs in one RTP session, for example to transmit video from two different cameras. - RTCP is insufficient for H.323 call setup. A: True. The RTP spec says that the use of additional control protocols may be required. - Lack of ITU control over payload format codes in the RTP Audio/Video Profile. A: The current plan is to proceed with the RTP profile as specified, which includes the additional code points that were requested for ITU-T standard encodings. There should be no problem adding new ITU-T standard encodings in the future since we will also want to use them. Interoperability will be maximized if this profile is found to be sufficient for H.323 purposes as well, but if not, another profile could be defined to provide a payload format code space dedicated to the ITU. It seems most important to get the RTP specs published first to establish them as a stable base. During the Proposed Standard stage of the IETF standardization process, if the current specifications are found to be inadequate either for general use on the Internet as planned or more specifically for the interoperation planned by H.323, then those changes may be introduced before going to the Draft Standard stage. However, it is not expected that any substantial changes will be required. 1.1 Jitter measurements for video formats It is valid to ask about measurements on video formats where the same timestamp is used for all packets in a frame. In some sense, it is the network that imposes the variation in delay implied when transmission of the video packets is spread over the frame interval rather than occurring all at once, so it is reasonable to include it in the jitter calculation. On the other hand, it is expected that the jitter measure will be primarily used to compare the behavior observed by different receivers. The jitter measure can also be calculated by the sender for the traffic as transmitted and then compared to the jitter reported by a receiver. This allows cancelling out the jitter introduced by using the same timestamp for all packets of a video frame. If the first packet of a frame were marked in some payload format independent way, then it would be possible to calculate the jitter using only those packets, which are sent with minimum delay after the frame is sampled. However, since the packets of a frame may represent a burst, later packets in the frame may experience more delay, so measuring only the first might not be accurate. For the MPEG video format, the transmission order of I, P and B frames is not the same as the presentation order. This introduces significant additional noise into the jitter calculation. It is possible to correct for this by observing the I, P and B bits in the MPEG header at the receiver and adjusting the timestamps accordingly before doing the jitter calculation. Don Hoffman at Sun reports that they have prototyped this scheme. This works fine for receivers, but a profile- and payload format-intependent monitor would not have this information. 2. Other RTP questions In addition to the ITU coordination questions, there were a few questions brought up recently on the working group mailing list that were discussed in this meeting. - The latest RTP profile draft specifies a 90000 Hz clock for the RTP timestamp in all video payload formats to replace the 65536 Hz clock rate used previously. This matches the choice made by the designers of the MPEG encoding to be a multiple of all of the video frame rates in common use, and is the choice recently made by the authors and implementers of the RTP payload format for H.261 video. It is requested that the authors of the other video payload format specifications update those specifications to reflect the new clock rate unless there is some reason that the old clock rate must be used. No objections were voiced and no other comments on the RTP profile were offered. - The RTP payload format for MPEG video specifies two formats, one of which encapsulates MPEG Transport Systems format. In that format, the position of video frame boundaries is not known to the process doing the RTP encapsulation. Instead, the RTP marker bit is used to indicate the start of a "payload unit". Note that choosing the start rather than end is at odds with the convention for other video formats, but is more convenient. There is no advantage to marking the end as there is with the other video formats. No objections were raised. - Vineet Kumar asked how multiple audio streams fed through a mixer could be synchronized with a video stream that was not sent through the mixer. The answer is that the audio streams can all be synchronized and the mixed output emitted with the same timing if the sources all have synchronized clocks. If not, then RTP does not solve this problem. - Feedback was invited on points where the RTP spec may not be as clear or explicit as is needed. These should be sent to the authors or to the working group mailing list (rem-conf). 3. Future activities As mentioned above, the main RTP spec and RTP profile should be published as Proposed Standard RFCs in September. All video payload formats should be posted for Last Call as soon as possible and then published as RFCs as well. This will complete the working group's charter. Acknowledgements Thanks to Joerg Ott and Carsten Bormann for their notes on the discussion which served as input for these minutes. From rem-conf-request@es.net Thu Jul 20 18:58:07 1995 Received: from darwin.cesup.ufrgs.br by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jul 1995 15:57:16 -0700 Received: from UPF.tche.BR ([200.17.166.1]) by darwin.cesup.ufrgs.br (051895/8.6.11) with SMTP id JAA16525 for ; Tue, 18 Jul 1995 09:04:22 -0300 Received: by UPF.tche.BR (5.x/SMI-SVR4) id AA10159; Tue, 18 Jul 1995 09:20:22 -0300 Date: Tue, 18 Jul 1995 09:20:22 -0300 From: trentin@vitoria.UPF.tche.BR (Marco Trentin) Message-Id: <9507181220.AA10159@UPF.tche.BR> To: rem-conf@es.net Subject: test VAT in a LAN I would like to test VAT in a Lan, with two workstaations (Sun). What parameters I need to use? I already have the program (VAT), but I don't know how test it between two workstations. Thanks in advance. From rem-conf-request@es.net Thu Jul 20 19:13:51 1995 Received: from noc.belwue.de by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jul 1995 16:12:57 -0700 X400-Received: by mta pp-belwue in /PRMD=BelWue/ADMD=d400/C=DE/; Relayed; Fri, 21 Jul 1995 01:09:45 +0200 X400-Received: by mta kssun-mta in /PRMD=BelWue/ADMD=d400/C=DE/; Relayed; Fri, 21 Jul 1995 01:09:19 +0200 X400-Received: by /PRMD=uni-stuttgart/ADMD=d400/C=de/; Relayed; Fri, 21 Jul 1995 01:09:19 +0200 Date: Fri, 21 Jul 1995 01:09:19 +0200 X400-Originator: feil@rus.uni-stuttgart.d400.de X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=uni-stuttgart/ADMD=d400/C=de/;950721010919] X400-Content-Type: P2-1984 (2) Content-Identifier: 2136 Alternate-Recipient: Allowed From: Peter Feil Message-ID: <2136*/S=feil/OU=rus/PRMD=uni-stuttgart/ADMD=d400/C=de/@MHS> To: Christian Wettergren Cc: mbone@ISI.edu, rem-conf@es.net In-Reply-To: <199507201715.TAA06617@piraya.electrum.kth.se> Subject: Re: IETF transmission quality... > >Hi! > >The Multicast Production Team at the 33rd IETF would like >to get reports on perceived quality in different corners >of the world. Well, maybe it's interesting for other people to get an idea of how simple it is to join the MBONE: This morning I was busy configuring a new Sun SparcStation 20SX. With my colleagues already actively contributing to the IETF-MBONE sessions I had the idea to integrate this new machine into this scenario. And this is what I did: - install multicast capability: 5 min. (see ftp://www-ks.rus.uni-stuttgart.de/pub/mice/mrouted) - install SunVideo board and video camera: 5 min - install MBONE-tools: 2 min. (in Stuttgart a simple mount via NFS) - start the MBONE applications and get used to them: 30 min It took me less than 1 hour to have my new workstation connected to the MBONE and to the IETF sessions. Transmission quality: We were connected to the IETF via a 2 Mbit/s SMDS link to UCL (London) and then via the European ATM-Pilot directly to IETF in Stockholm. The transmission quality was good (listening at suntrec.rus.uni-stuttgart.de) with an average loss rate of 10%. Our main problem was the LAN configuration (Ethernet) contributing to this overall loss rate with app. 90%. In the near future we will solve this problem by using ATM-LAN connections A highlight was the participation in an international secure conferencing session using the "upgraded" MBONE tools with new keyword capabilities. Peter --------------------------------------------------------------- Peter Feil University of Stuttgart Computing Center phone : ++49-711-685 5735 Allmandring 30 fax : ++49-711-678 7626 70550 Stuttgart e-mail: feil@rus.uni-stuttgart.de Germany --------------------------------------------------------------- From rem-conf-request@es.net Thu Jul 20 19:40:16 1995 Received: from adept.PRPA.Philips.COM by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jul 1995 16:38:37 -0700 Received: from runner.PRPA.Philips.COM by adept.PRPA.Philips.COM (4.1/SMI-4.1) id AA09362; Thu, 20 Jul 95 16:39:39 PDT Received: by runner.PRPA.Philips.COM (4.1/SMI-4.1) id AA28571; Thu, 20 Jul 95 16:40:27 PDT Date: Thu, 20 Jul 95 16:40:27 PDT From: banerjea@PRPA.Philips.COM (Anindo Banerjea) Message-Id: <9507202340.AA28571@runner.PRPA.Philips.COM> To: rem-conf@es.net Subject: Video capture hardware for x86 I am interested in finding out about existing ports of MBone video tools (nv, vic, ivs) to video capture cards for x86 machines. Linux ports would be most interesting, but Solaris x86 or any x86 unix would be interesting as well. Please send mail directly to banerjea@prpa.philips.com and I will post the compiled answers to this list. Anindo From rem-conf-request@es.net Thu Jul 20 20:40:15 1995 Received: from MVS.OAC.UCLA.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jul 1995 17:39:07 -0700 Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 4556; Thu, 20 Jul 95 17:39:25 PST Date: Thu, 20 Jul 95 17:38 PDT To: mbone@ISI.EDU, rem-conf@ES.NET From: Denis DeLaRoca (310) 825-4580 Subject: Sparc 4 and MBONE Tools ??? Can anyone report on experiences running the MBONE tools on the fairly new Sparc 4 platforms? Is the audio hardware like the one on the Sparc 5 or like the one in the Sparc 20, and does it work without problems? How do VIC and the SunVideo card perform on this platform? -- Denis From rem-conf-request@es.net Thu Jul 20 23:14:40 1995 Received: from mail.ncku.edu.tw by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jul 1995 19:23:56 -0700 Received: (from ckwen@localhost) by mail.ncku.edu.tw (8.6.12/8.6.12) id KAA28588; Fri, 21 Jul 1995 10:26:24 +0800 From: Cheng-Kang Wen Message-Id: <199507210226.KAA28588@mail.ncku.edu.tw> Subject: Re: test VAT in a LAN To: trentin@vitoria.UPF.tche.BR (Marco Trentin) Date: Fri, 21 Jul 1995 10:26:24 +0800 (WST) Cc: rem-conf@es.net In-Reply-To: <9507181220.AA10159@UPF.tche.BR> from "Marco Trentin" at Jul 18, 95 09:20:22 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 618 To test the VAT, you have two options: unicast or multicast. But it seems that you want to test it in unicast mode. Just type this: vat your-partner-ip-address/port-number Both you and your partner should use the same port number( this number should greater than 1024 if you are not the root). After connected, both of you may talk through the vat window. Enjoy it. Cheng-Kang Wen > > I would like to test VAT in a Lan, with two workstaations (Sun). > What parameters I need to use? > I already have the program (VAT), but I don't know how test it > between two workstations. > Thanks in advance. > From rem-conf-request@es.net Fri Jul 21 03:54:36 1995 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jul 1995 00:53:40 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 21 Jul 1995 08:52:38 +0100 To: Peter Feil cc: Christian Wettergren , mbone@ISI.EDU, rem-conf@es.net Subject: Re: IETF transmission quality... In-reply-to: Your message of "Fri, 21 Jul 95 01:09:19 +0100." <2136*/S=feil/OU=rus/PRMD=uni-stuttgart/ADMD=d400/C=de/@MHS> Date: Fri, 21 Jul 95 08:52:33 +0100 Message-ID: <5702.806313153@cs.ucl.ac.uk> From: Jon Crowcroft >Transmission quality: >We were connected to the IETF via a 2 Mbit/s SMDS link >to UCL (London) and then via the European ATM-Pilot >directly to IETF in Stockholm. >The transmission quality was good (listening at >suntrec.rus.uni-stuttgart.de) with an average loss >rate of 10%. Our main problem was the LAN configuration >(Ethernet) contributing to this overall loss rate with >app. 90%. In the near future we will solve this problem >by using ATM-LAN connections how can traffic that fits on a 2Mbps link swamp a 10Mbps ethernet? we were receiving perfectly ok from the ATM net onto our local ethernets, even the 2 high bandwidth video streams, without any trouble..... do you have an overlaoded mrotued at the last hop maybe? or a stressed out LAN? ATM LAN will NOT help you deliver to lots of hosts very easily...by the way..since there is no easy mapping fro mIP multipoint to ATM multipoint calls (except in Fore kit...), and i nany case, you wont get this across the WAN, so you'll still have to go via an IP router between the WAN ATM and your LAN ATM....and take the WAN IP tunnel feed, then have a router make a local ATM multipoint call... cheers jon From rem-conf-request@es.net Fri Jul 21 04:30:24 1995 Received: from cancer.ucs.ed.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jul 1995 01:29:47 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.9) with ESMTP id JAA09115; Fri, 21 Jul 1995 09:27:38 +0100 Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id JAA01699; Fri, 21 Jul 1995 09:28:52 +0100 Date: Fri, 21 Jul 1995 09:28:52 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Jon Crowcroft cc: Peter Feil , Christian Wettergren , mbone@ISI.EDU, rem-conf@es.net Subject: Re: IETF transmission quality... In-Reply-To: <5702.806313153@cs.ucl.ac.uk> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 21 Jul 1995, Jon Crowcroft wrote: > > >Transmission quality: > >We were connected to the IETF via a 2 Mbit/s SMDS link > >to UCL (London) and then via the European ATM-Pilot > >directly to IETF in Stockholm. > >The transmission quality was good (listening at > >suntrec.rus.uni-stuttgart.de) with an average loss > >rate of 10%. Our main problem was the LAN configuration > >(Ethernet) contributing to this overall loss rate with > >app. 90%. In the near future we will solve this problem > >by using ATM-LAN connections > > how can traffic that fits on a 2Mbps link swamp a 10Mbps ethernet? Perhaps he meant it the other way round? That the traffic he already had on the 10Mbps ethernet was swamping the <2Mbps MBONE traffic. > we were receiving perfectly ok from the ATM net onto our local > ethernets, even the 2 high bandwidth video streams, without any > trouble..... And when the ATM was up and one of the main UK Mbone routers was up the loss at Edinburgh was about 0%. During some of the evening transmissions the high bandwidth video was fantastic. Unfortunately, we had two problems one of the main UK mrouteds collapsed during the first day and didn't get fixed until the second. And then on Thursday the ATM tunnels to UCL went down and we were then routing over the old tunnels through broodjeham. This was bareable but up to 30% loss was noticed. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Fri Jul 21 07:19:45 1995 Received: from unb.ca (actually hermes.csd.unb.ca) by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jul 1995 04:19:09 -0700 Received: from cythera.unb.ca by unb.ca (8.6.12/950414-15:35) id IAA17241; Fri, 21 Jul 1995 08:19:02 -0300 Date: Fri, 21 Jul 1995 08:15:30 -0300 (ADT) From: "Dwight E. Spencer" To: "Denis DeLaRoca (310) 825-4580" cc: mbone@ISI.EDU, rem-conf@es.net Subject: Re: Sparc 4 and MBONE Tools ??? In-Reply-To: <199507210039.AA02000@venera.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 20 Jul 1995, Denis DeLaRoca (310) 825-4580 wrote: > Can anyone report on experiences running the MBONE tools on the fairly > new Sparc 4 platforms? Is the audio hardware like the one on the Sparc 5 > or like the one in the Sparc 20, and does it work without problems? How > do VIC and the SunVideo card perform on this platform? I've used vic, nv, sd and wb without -any- problems on my sparc 4 running solaris 2.4. I have not tried to use vat, but I have started it, because I haven't recieved my (optional) sound card yet. The order just went in this last week. I'm not sure if it will have the same driver problems that the sparc 5's did, but I'll respond on it's activity after I try it. dwight s. ---------------------------------------------------------------------------- Dwight E. Spencer University of New Brunswick Mail: spencer@unb.ca Community Access Canada Phone: +1 506 447 3060 "C-Net" Server Administrator Url: http://cnet.unb.ca/staff/dspencer/ From rem-conf-request@es.net Fri Jul 21 11:34:29 1995 Received: from titan.sprintlink.net by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jul 1995 08:33:53 -0700 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id LAA15941; Fri, 21 Jul 1995 11:31:32 -0400 Date: Fri, 21 Jul 1995 11:31:32 -0400 From: Vadim Antonov Message-Id: <199507211531.LAA15941@titan.sprintlink.net> To: J.Crowcroft@cs.ucl.ac.uk, feil@rus.uni-stuttgart.d400.de Subject: Re: IETF transmission quality... Cc: cwe@it.kth.se, mbone@ISI.EDU, rem-conf@es.net >how can traffic that fits on a 2Mbps link swamp a 10Mbps ethernet? A typical ethernet breaks down at about 3Mbps *total*, and the E-1 pipe can easily run at 4Mbps (it's full duplex). >ATM LAN will NOT help you deliver to lots of hosts very easily... Unless you have wads of money to burn. If you do, go buy a DEC's FDDI switch, and off-the-shelf FDDI cards (better full-duplex ones). Sure beats any ATM you can find. --vadim From rem-conf-request@es.net Fri Jul 21 11:58:38 1995 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jul 1995 08:58:13 -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 LAA19015; Fri, 21 Jul 1995 11:58:09 -0400 Received: (from kevin@localhost) by flora.cc.gatech.edu (8.6.10/8.6.9) id LAA24018; Fri, 21 Jul 1995 11:57:49 -0400 Date: Fri, 21 Jul 1995 11:57:49 -0400 From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199507211557.LAA24018@flora.cc.gatech.edu> To: kevin@cc.gatech.edu Subject: Mail to both mbone and rem-conf lists After all the duplicate mail on both the mbone and rem-conf lists lately, I'm going to re-send a message originally sent to both lists on Jan 11, 1994. It is a good explanation of the two lists, and describes the type of mail appropriate for each. -Kevin Almeroth P.S. The original authors names have been removed in case their opinion on the subject have changed. So I take no credit. ------------------------------------------------------------------------ REM-CONF: - technical discussions that are related to all the pieces of the puzzle involved in accomplishing remote conferencing (one-one, one-to-many, many-to-many), including software, hardware, and protocols - participants are developers and end-users of remote conferencing, therefore it is the preferred list for: - release notes for new applications, such as audio/video tools - announcements of events on the MBONE that can be received by the people who run these tools, since rem-conf should reach most/many of the potential viewers MBONE: - purpose is to manage the engineering and operation of the MBONE itself - participants are those who run MBONE nodes (i.e., a narrower audience than rem-conf), therefore is is the preferred list for: - requests for MBONE tunnels to be set up or changed - questions about the multicast kernel software, since the person who builds multicast kernels for a site is likely to be the same one who runs the MBONE node for that site - release notes for new MBONE monitoring tools From rem-conf-request@es.net Fri Jul 21 13:46:33 1995 Received: from hillfoot.cent.gla.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jul 1995 10:45:45 -0700 Received: from hillhead.cent.gla.ac.uk by hillfoot.cent.gla.ac.uk with SMTP-GLA (PP); Fri, 21 Jul 1995 18:16:47 +0100 Received: from kite.psy.gla.ac.uk by hillhead.cent.gla.ac.uk with SMTP (PP); Fri, 21 Jul 1995 18:16:39 +0100 From: Anne Marie Date: Fri, 21 Jul 95 18:19:06 BST Message-Id: <12245.9507211719@swan.psy.gla.ac.uk.psy.gla.ac.uk> To: mbone@ISI.EDU, rem-conf@es.net Subject: Stormy Waters - Tonight !! Stormy Waters Tonight and tomorrow night between approx 9 pm to 11.30 (GMT+1) Stormy Waters will be transmitted on the mbone on 224.2.17.150 with a CU-SeeMe reflector on 224.2.17.151. the event is advertised in 'sd'. We will be using Vic and Vat. As this event involves many fast moving video images we are broadcasting video in jpeg mode at 250kb/s. If this proves to be a problem for anyone or any network or if you have any suggestions for improvement please email annemari@psy.gla.ac.uk ============================================================================= Anne Marie Fleming Tel: +44 41 330 5424 University of Glasgow Fax: +44 41 339 8889 56 Hillhead St Telex: 777070 UNIGLA Glasgow G12 8QB, U.K. email: annemari@psy.gla.ac.uk www url: http://www.psy.gla.ac.uk/staff/annemari.html ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Fri Jul 21 14:55:30 1995 Received: from ptavv.nersc.gov by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jul 1995 11:54:56 -0700 Received: from localhost by ptavv.nersc.gov; (5.65/1.1.8.2/08Feb94-0649PM) id AA19085; Fri, 21 Jul 1995 11:53:45 -0700 Message-Id: <9507211853.AA19085@ptavv.nersc.gov> To: Vadim Antonov Cc: J.Crowcroft@cs.ucl.ac.uk, feil@rus.uni-stuttgart.d400.de, cwe@it.kth.se, mbone@ISI.EDU, rem-conf@es.net, oberman@nersc.gov Subject: Re: IETF transmission quality... In-Reply-To: Your message of "Fri, 21 Jul 95 11:31:32 EDT." <199507211531.LAA15941@titan.sprintlink.net> Date: Fri, 21 Jul 95 11:53:44 -0700 From: Kevin Oberman X-Mts: smtp > Date: Fri, 21 Jul 1995 11:31:32 -0400 > From: Vadim Antonov > > >how can traffic that fits on a 2Mbps link swamp a 10Mbps ethernet? > > A typical ethernet breaks down at about 3Mbps *total*, and the > E-1 pipe can easily run at 4Mbps (it's full duplex). This is total bilge as anyone who has spent much time with Ethernet knows. But it refuses to die because people who should know better keep repeating it. For some facts, see "Measured Capacity of an Ethernet: Myths and Reality" by Boggs, Mogul, and Kent. It's available from http://www.research.digital.com/wrl/publications/abstracts/88.4.html In the IP world, Van Jacobson has documented actual, measured throughput of > 1MB (or 8Mbps) on an Ethernet, although this is NOT feasible in typical cases. But 6 Mbps is easily attainable on a typical Ethernet and 7 Mbps is not unusual. I can't find a reference for this right now, but it's fairly well known. While the Ethernet in question may be congested, it is not congested because of traffic from the E-1 or any 4 Mbps pipe. Please stop this foolishness before someone else is stuck with a token ring or Ethernet switch they don't really need. R. Kevin Oberman Energy Sciences Network (ESnet) National Energy Research Supercomputer Center (NERSC) Lawrence Livermore National Laboratory (LLNL) EMAIL: koberman@llnl.gov Phone: +1 510 422-6955 From rem-conf-request@es.net Fri Jul 21 16:37:46 1995 Received: from cerc.wvu.edu (actually cathedral.cerc.wvu.edu) by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jul 1995 13:37:18 -0700 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA29093; Fri, 21 Jul 95 16:33:26 EDT Received: by elk (5.x//ident-1.0) id AA07575; Fri, 21 Jul 1995 16:33:17 -0400 Date: Fri, 21 Jul 1995 16:33:16 -0400 (EDT) From: "Todd L. Montgomery" Subject: Re: IETF transmission quality... To: Kevin Oberman Cc: Vadim Antonov , J.Crowcroft@cs.ucl.ac.uk, feil@rus.uni-stuttgart.d400.de, cwe@it.kth.se, mbone@isi.edu, rem-conf@es.net In-Reply-To: <9507211853.AA19085@ptavv.nersc.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 21 Jul 1995, Kevin Oberman wrote: > For some facts, see "Measured Capacity of an Ethernet: Myths and > Reality" by Boggs, Mogul, and Kent. It's available from > http://www.research.digital.com/wrl/publications/abstracts/88.4.html > > In the IP world, Van Jacobson has documented actual, measured > throughput of > 1MB (or 8Mbps) on an Ethernet, although this is NOT > feasible in typical cases. But 6 Mbps is easily attainable on a > typical Ethernet and 7 Mbps is not unusual. I can't find a reference > for this right now, but it's fairly well known. Also, I have documented throughput of > 1100 KBps on an ethernet using RMP. http://research.ivv.nasa.gov/projects/RMP/Docs/RMPdocs.html under Performance Graphs. > While the Ethernet in question may be congested, it is not congested > because of traffic from the E-1 or any 4 Mbps pipe. Definitely. However, packet starvation effect does do quite a bit of harm if large numbers of senders are blasting away at the same time. For some other examinations of CSMA/CD and the packet starvation effect that makes several senders on an ethernet drop ethernet to about 60% utilization, ftp://tenet.cs.berkeley.edu/pub/users/whetten/FDDQ Thanks to Brian Whetten! -- Todd From rem-conf-request@es.net Fri Jul 21 22:17:16 1995 Received: from titan.sprintlink.net by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jul 1995 19:16:48 -0700 Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id WAA16366; Fri, 21 Jul 1995 22:15:06 -0400 Date: Fri, 21 Jul 1995 22:15:06 -0400 From: Vadim Antonov Message-Id: <199507220215.WAA16366@titan.sprintlink.net> To: avg@sprint.net, oberman@nersc.gov Subject: Re: IETF transmission quality... Cc: J.Crowcroft@cs.ucl.ac.uk, cwe@it.kth.se, feil@rus.uni-stuttgart.d400.de, mbone@ISI.EDU, rem-conf@es.net >> A typical ethernet breaks down at about 3Mbps *total*, and the >> E-1 pipe can easily run at 4Mbps (it's full duplex). >This is total bilge as anyone who has spent much time with Ethernet >knows. But it refuses to die because people who should know better >keep repeating it. >For some facts, see "Measured Capacity of an Ethernet: Myths and >Reality" by Boggs, Mogul, and Kent. It's available from >http://www.research.digital.com/wrl/publications/abstracts/88.4.html That study has explicit disclaimers to the effect that it does not represent "typical" cases. The reality is that the performance of Ethernet depends quite a lot on very subtle factors like self-synchronization and how well carrier/collision detection works. Most of PC Ethernet adapters are simply broken as designed (you can't argue with that, not with me :) and i saw may "solid" equipment like bridges which was doing completely insane things (time to remember old MAE-East?) In the IP world, Van Jacobson has documented actual, measured throughput of > 1MB (or 8Mbps) on an Ethernet, although this is NOT feasible in typical cases. >But 6 Mbps is easily attainable on a >typical Ethernet and 7 Mbps is not unusual. I can't find a reference >for this right now, but it's fairly well known. In my practice congestion collapses on Ethernets at 500Kbps are as common as Ethernets running at 6Mbps. You are also forgetting that point-to-point pipes tend to deliver more-less constant-rate traffic, which does not fit very well into the stochastic Ethernet model. I.e. you end up with D/M/1 kind of situation, with performance quite worse than M/M/1 model of Ethernet with end hosts and no gateways to WAN. (Well, for the purists, M is really not M but something self-similar). The fact is neither of studies you mentioned is directly applicable, as even the crude queueing theory models behave quite differently for LAN-with-hosts and LAN-with-WAN-gateway. >Please stop this foolishness before someone else is stuck with a token >ring or Ethernet switch they don't really need. Ethernet switch is useful for other reasons (like security and fault isolation). >R. Kevin Oberman >Energy Sciences Network (ESnet) Regards, --vadim From rem-conf-request@es.net Sun Jul 23 05:54:00 1995 Received: from icsia.ICSI.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Sun, 23 Jul 1995 02:53:29 -0700 Received: from icsib67.ICSI.Berkeley.EDU (whetten@icsib67.ICSI.Berkeley.EDU [128.32.201.167]) by icsia.ICSI.Berkeley.EDU (8.6.12/HUB+V8$Revision: 1.23 $) with ESMTP id CAA24499; Sun, 23 Jul 1995 02:46:57 -0700 Received: (whetten@localhost) by icsib67.ICSI.Berkeley.EDU (8.6.12/1.8) id CAA21558; Sun, 23 Jul 1995 02:46:52 -0700 Date: Sun, 23 Jul 1995 02:46:50 -0700 (PDT) From: Brian Whetten To: Kevin Oberman cc: Vadim Antonov , J.Crowcroft@cs.ucl.ac.uk, feil@rus.uni-stuttgart.d400.de, cwe@it.kth.se, mbone@ISI.EDU, rem-conf@es.net, oberman@nersc.gov Subject: Re: IETF transmission quality... In-Reply-To: <9507211853.AA19085@ptavv.nersc.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes...an ethernet can handle 6-7 Mbps of realistic traffic. While very good, the Boggs&Mogul paper does not deal with the problem of starved packets. For a detailed analysis on the real capacity of an Ethernet, please see: B. Whetten, S. Steinberg, and D. Ferrari, "The Packet Starvation Effect in CSMA/CD LANs and a Solution", Proc. of IEEE Local Computer Networks Minneapolis, MN, pp. 206-217, October 1994. On Fri, 21 Jul 1995, Kevin Oberman wrote: > > Date: Fri, 21 Jul 1995 11:31:32 -0400 > > From: Vadim Antonov > > > > >how can traffic that fits on a 2Mbps link swamp a 10Mbps ethernet? > > > > A typical ethernet breaks down at about 3Mbps *total*, and the > > E-1 pipe can easily run at 4Mbps (it's full duplex). > > This is total bilge as anyone who has spent much time with Ethernet > knows. But it refuses to die because people who should know better > keep repeating it. > > For some facts, see "Measured Capacity of an Ethernet: Myths and > Reality" by Boggs, Mogul, and Kent. It's available from > http://www.research.digital.com/wrl/publications/abstracts/88.4.html > > In the IP world, Van Jacobson has documented actual, measured > throughput of > 1MB (or 8Mbps) on an Ethernet, although this is NOT > feasible in typical cases. But 6 Mbps is easily attainable on a > typical Ethernet and 7 Mbps is not unusual. I can't find a reference > for this right now, but it's fairly well known. > > While the Ethernet in question may be congested, it is not congested > because of traffic from the E-1 or any 4 Mbps pipe. > > Please stop this foolishness before someone else is stuck with a token > ring or Ethernet switch they don't really need. > > R. Kevin Oberman > Energy Sciences Network (ESnet) > National Energy Research Supercomputer Center (NERSC) > Lawrence Livermore National Laboratory (LLNL) > EMAIL: koberman@llnl.gov Phone: +1 510 422-6955 > From rem-conf-request@es.net Sun Jul 23 10:17:03 1995 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Sun, 23 Jul 1995 07:16:32 -0700 Received: from mortimer.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 23 Jul 1995 15:15:28 +0100 To: Vadim Antonov cc: oberman@nersc.gov, cwe@it.kth.se, feil@rus.uni-stuttgart.d400.de, mbone@ISI.EDU, rem-conf@es.net Subject: Re: IETF transmission quality... In-reply-to: Your message of "Fri, 21 Jul 95 22:15:06 EDT." <199507220215.WAA16366@titan.sprintlink.net> Date: Sun, 23 Jul 95 15:15:19 +0100 Message-ID: <1921.806508919@cs.ucl.ac.uk> From: Jon Crowcroft >>> A typical ethernet breaks down at about 3Mbps *total*, and the >>> E-1 pipe can easily run at 4Mbps (it's full duplex). >>This is total bilge as anyone who has spent much time with Ethernet >>knows. But it refuses to die because people who should know better >>keep repeating it. >>For some facts, see "Measured Capacity of an Ethernet: Myths and >>Reality" by Boggs, Mogul, and Kent. It's available from >>http://www.research.digital.com/wrl/publications/abstracts/88.4.html btw, its availaible in the latest ACM CCR as a reprint as [part of the 254th anniversay issue... >That study has explicit disclaimers to the effect that it does >not represent "typical" cases. in our expeirence of using ethernets as mbone "FIXes" (now being replaced by atm boxes as Mbone "NAPs"), the 3Mbps figure is sort of right but in general, we run a lot of our ethernets at 60-70% load quite happily - a lot of ethernets do not have "poisson arrtival" traffic (in fact, i've never seen a measurement of a study that showed a real erther that did the classic mythical figure (near 4Mbps, not 3) was the trivial undergrad result of maximum utilisation before the congestion knee for CSMA/CD >The reality is that the performance of Ethernet depends quite >a lot on very subtle factors like self-synchronization and >how well carrier/collision detection works. Most of PC Ethernet >adapters are simply broken as designed (you can't argue with that, >not with me :) and i saw may "solid" equipment like bridges which >was doing completely insane things (time to remember old MAE-East?) true, true, all sadly true.... >In the IP world, Van Jacobson has documented actual, measured >throughput of > 1MB (or 8Mbps) on an Ethernet, although this is NOT >feasible in typical cases. >>But 6 Mbps is easily attainable on a >>typical Ethernet and 7 Mbps is not unusual. I can't find a reference >>for this right now, but it's fairly well known. >In my practice congestion collapses on Ethernets at 500Kbps are as >common as Ethernets running at 6Mbps. yes, but this is often in overextended, badly tapped sites... >You are also forgetting that point-to-point pipes tend to deliver >more-less constant-rate traffic, which does not fit very well into >the stochastic Ethernet model. I.e. you end up with D/M/1 kind of >situation, with performance quite worse than M/M/1 model of Ethernet >with end hosts and no gateways to WAN. (Well, for the purists, M >is really not M but something self-similar). if you have a number of these, yes (we had 5 mrouteds at one point:-) but if you simply have a stuv ether with the mrouted (so basically, you have D/M/! from tow sources, inbound and outbound) then the utilisation ought to be ok up to around 7Mbps... [of course, this all assumes no other host traffic - if that exists, you will die badly well before this - this happens everynow and then when our multicast routing goes astray betwenn the 5 mrouted and the traffic in all directions starts traversing the ether that also has all our student machines on....) >The fact is neither of studies you mentioned is directly applicable, >as even the crude queueing theory models behave quite differently >for LAN-with-hosts and LAN-with-WAN-gateway. >>Please stop this foolishness before someone else is stuck with a token >>ring or Ethernet switch they don't really need. >Ethernet switch is useful for other reasons (like security and fault >isolation). but make sure your ether switch is good at emulating old fashioned bus multicast! some of them arent! actually, a good study of the use of bus and switched ethers for typical real mbone traffic (say a trace driven simulation or analysis based on some of this discussion) would be a useful thing to do... cheers jon From rem-conf-request@es.net Mon Jul 24 03:57:00 1995 X400-Received: by mta osi-west.es.net in /PRMD=ESnet/ADMD= /C=US/; Relayed; Mon, 24 Jul 1995 00:25:57 -0700 X400-Received: by /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Mon, 24 Jul 1995 00:22:26 -0700 X400-Received: by /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Mon, 24 Jul 1995 02:19:26 -0700 X400-Received: by /PRMD=iihe/ADMD=rtt/C=be/; Relayed; Mon, 24 Jul 1995 02:19:26 -0700 Date: Mon, 24 Jul 1995 02:19:26 -0700 X400-Originator: colin@helios.iihe.rtt.be X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=iihe/ADMD=rtt/C=be/;950724091926] X400-Content-Type: P2-1984 (2) Content-Identifier: 13030001 From: Michel Colin Message-ID: <13030001*/G=michel/S=colin/O=helios/PRMD=iihe/ADMD=rtt/C=be/@MHS> To: "Denis DeLaRoca 825-4580 (310)" (Non Receipt Notification Requested) Cc: mbone@ISI.EDU (Non Receipt Notification Requested), rem-conf@es.net (Non Receipt Notification Requested) In-Reply-To: <199507210039.AA02000@venera.isi.edu> Subject: Sparc 4 and MBONE Tools ??? ------------------------------ Start of body part 1 As far as I know audio is not provided by default on Sparc 4 ! Michel ------------------------------ Start of body part 2 =============================================================================== Michel Colin Tel. +32-2-650 57 03 Fax: +32-2-629 38 16 Universite Libre de Bruxelles Faculte des Sciences Service Telematique et Communication CP 230, Boulevard du triomphe B-1050 Bruxelles BELGIUM RFC822: colin@helios.iihe.rtt.be X.400 : C=be;ADMD=rtt;PRMD=iihe;O=helios;S=colin; X.500 : @c=be@o=Universite Libre de Bruxelles@ou=Faculte des Sciences@ou=Service Telematique et Communication@cn=Michel Colin ------------------------------------------------------------------------------- ------------------------------ End of body part 2 From rem-conf-request@es.net Mon Jul 24 21:36:48 1995 Received: from gw2.att.com by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Jul 1995 18:36:17 -0700 Received: from mtgbcs.mt.att.com (mtgzfs3-bgate.mt.att.com) by ig1.att.att.com id AA07994; Mon, 24 Jul 95 11:40:57 EDT Received: from mtpcs979 (mtrod) by mtgbcs.mt.att.com (5.x/EMS-1.2 sol2) id AA26662; Mon, 24 Jul 1995 11:41:02 -0400 From: Rod Brathwaite Message-Id: <9507241141.ZM21799@mtpcs979> Date: Mon, 24 Jul 1995 11:41:14 -0400 X-Mailer: ZM-Win (3.2.1 09Sep94) To: rem-conf@es.net Subject: Multimedia over the net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I have been monitoring this newsgroup for just under a month now, and I have a few newbie questions that I hope someone can answer. Q: Is it possible to guarantee a certain quality of service (QOS) from an internet service provider (ISP) if you wanted to have a video conference between 2 or more ppl over the internet? Q: Would you have to "tunnel" dynamically to make this work? Q: Since bandwidth is the major issue for multimedia over the net, will IP over ATM solve this bandwidth crunch? Thanks in advance for your responses. Rod Brathwaite rod@mtgbcs.mt.att.com From rem-conf-request@es.net Mon Jul 24 23:50:20 1995 Received: from black-ice.cc.vt.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Jul 1995 20:49:54 -0700 Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.Beta.10/8.7.Beta.10) with ESMTP id XAA21376; Mon, 24 Jul 1995 23:49:48 -0400 Message-Id: <199507250349.XAA21376@black-ice.cc.vt.edu> To: Rod Brathwaite cc: rem-conf@es.net Subject: Re: Multimedia over the net In-reply-to: Your message of "Mon, 24 Jul 1995 11:41:14 EDT." <9507241141.ZM21799@mtpcs979> From: Valdis.Kletnieks@vt.edu Date: Mon, 24 Jul 1995 23:49:47 -0400 On Mon, 24 Jul 1995 11:41:14 EDT, you said: > Q: Since bandwidth is the major issue for multimedia over the net, > will IP over ATM solve this bandwidth crunch? Nope. Let's say you're connected via a T-1, and can support 1 or 2 video streams. If you go to a T3, what will happen is you can support 20 or 25, so people will START 20 or 25. You move to 622mbits/sec ATM in the far future, and what will happen is *everybody* in your organization will use it. The instant the users notice that bandwidth is available, it will be consumed. They'll push up the frames/sec knob, they'll flip from greyscale to 24-bit color, they'l.... ;) Valdis Kletnieks Computer Systems Engineer Virginia Tech From rem-conf-request@es.net Tue Jul 25 04:26:41 1995 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jul 1995 01:26:05 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Jul 1995 09:23:00 +0100 To: Rod Brathwaite cc: rem-conf@es.net, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Multimedia over the net In-reply-to: Your message of "Mon, 24 Jul 95 11:41:14 EDT." <9507241141.ZM21799@mtpcs979> Date: Tue, 25 Jul 95 09:22:53 +0100 Message-ID: <6392.806660573@cs.ucl.ac.uk> From: Jon Crowcroft >Q: Is it possible to guarantee a certain quality of service (QOS) from > an internet service provider (ISP) if you wanted to have a video > conference between 2 or more ppl over the internet? depends on the provider....and their a) choice of routers b) underlying link technology we have a provider who can switch SMDS net bandwidth between rotuers, and we can contro lthe routes so that in principle, between subscribers on the university nets we could guarantee bandwidth to cerytain paths (though the routers we use only have simple priority queueing, so we couldn;t do anything very fancy about relative jitter between flows on the same routes) - this is not the "ultimately" manageable way of doing thins though! >Q: Would you have to "tunnel" dynamically to make this work? maybe...rsvp will help... >Q: Since bandwidth is the major issue for multimedia over the net, > will IP over ATM solve this bandwidth crunch? ATM is not particularly helpful yet, except that it is sometimes the only way a carrier will give you access to higher rates than E3/T3.... IP over ATM doesn't go far to solving things til you have RSVP to q.2931 and a few other things.... jon From rem-conf-request@es.net Tue Jul 25 12:32:45 1995 Received: from Csli.Stanford.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jul 1995 09:32:19 -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 JAA03479; Tue, 25 Jul 1995 09:32:07 -0700 Message-Id: <199507251632.JAA03479@Csli.Stanford.EDU> To: Valdis.Kletnieks@vt.edu cc: Rod Brathwaite , rem-conf@es.net Subject: Re: Multimedia over the net In-reply-to: Your message of Mon, 24 Jul 1995 23:49:47 EDT. <199507250349.XAA21376@black-ice.cc.vt.edu> Date: Tue, 25 Jul 1995 09:32:06 -0700 From: Christian Wettergren | Nope. Let's say you're connected via a T-1, and can support 1 or 2 video | streams. If you go to a T3, what will happen is you can support 20 or 25, | so people will START 20 or 25. You move to 622mbits/sec ATM in the far | future, and what will happen is *everybody* in your organization | will use it. | | The instant the users notice that bandwidth is available, it will be | consumed. I would like to rephrase that somewhat. I would say that bandwidth soon wont be a problem locally. I would estimate that about 10 Mbps (of private bandwidth) is all a user can use with the current generation of computers. One needs to ensure that the computer can take it as well. This bandwidth estimate discounts if a user starts doing lots of process-to-process communication (loosely defined). Processes that doesn't have to present more that a very small fraction of its communication/computation to the user can consume indefinite amounts of bandwidth. I believe however that everything from regional all the way up global distance carriers will start experiencing problems with bandwidth demands running rampant real soon now. I've seen IPhone being marketed as a way to reduce or eliminate your long-distance phone bill. (This was i San Jose Mercury New, I believe.) It is all in the pattern of usage. If people only use IPhone, CuSeeMe, the MBone tools etc locally, we wont have a problem. As soon as they discover that they can communicate over longer distances, they will do so. They will then come across a link somewhere that is overly congested, and decide that "this was the maximum distance". ("This week.") There is a definite risk, as I see it, that enough people will keep on trying to extend the distance they can use IPhone or whatever. This will result in broken services for everyone. (Imminent death of Internet! ;-)) I believe that it is important that we start to regularly measure QoS, congestion etc on all individual links, so that links can be upgraded appropriately. Who should pay for it? Isn't this the information society? Hand him a cyberbuck! :-) /Christian Wettergren From rem-conf-request@es.net Tue Jul 25 12:39:07 1995 Received: from Csli.Stanford.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jul 1995 09:38:42 -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 JAA03682; Tue, 25 Jul 1995 09:38:34 -0700 Message-Id: <199507251638.JAA03682@Csli.Stanford.EDU> To: Rod Brathwaite cc: rem-conf@es.net Subject: Re: Multimedia over the net In-reply-to: Your message of Mon, 24 Jul 1995 11:41:14 EDT. <9507241141.ZM21799@mtpcs979> Date: Tue, 25 Jul 1995 09:38:33 -0700 From: Christian Wettergren | Q: Would you have to "tunnel" dynamically to make this work? DON'T tunnel dynamically, that will only worsen the situation. Until the pruning really works, you could use "mixer", mixing unicast connections into local multicast groups. But this would still not guarantee you any QoS. For guarantees to work, you have to empty your pocket. You can however get forecasts, similar to weather forecasts. "The netweather next week should be rather good, since it is vacation." "That region usually has rather dry (non-lossy) environment, since the geography (links) are good." Silly, but a rather good picture. /Christian Wettergren From rem-conf-request@es.net Tue Jul 25 13:44:34 1995 Received: from black-ice.cc.vt.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jul 1995 10:44:01 -0700 Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.Beta.10/8.7.Beta.10) with ESMTP id NAA14406; Tue, 25 Jul 1995 13:43:56 -0400 Message-Id: <199507251743.NAA14406@black-ice.cc.vt.edu> To: Christian Wettergren cc: rem-conf@es.net Subject: Re: Multimedia over the net In-reply-to: Your message of "Tue, 25 Jul 1995 09:32:06 PDT." <199507251632.JAA03479@Csli.Stanford.EDU> From: Valdis.Kletnieks@vt.edu Date: Tue, 25 Jul 1995 13:43:55 -0400 On Tue, 25 Jul 1995 09:32:06 PDT, you said: > I would say that bandwidth soon wont be a problem locally. I would > estimate that about 10 Mbps (of private bandwidth) is all a user can > use with the current generation of computers. One needs to ensure that > the computer can take it as well. Well, here at Virginia Tech, we've got enough machines that if everybody asked for their 10Mbps at the same time, we'd be in DEEP trouble.. > This bandwidth estimate discounts if a user starts doing lots of > process-to-process communication (loosely defined). Processes that > doesn't have to present more that a very small fraction of its > communication/computation to the user can consume indefinite amounts > of bandwidth. The real problem is that for some things, such as video, a modern CPU can blit it onto the monitor and display it essentially as fast as the bit pipe can deliver it (modulo decompression time, etc - there are quite enough Macintosh-based real-time full-motion video capture boards out there to prove the point). > I believe however that everything from regional all the way up global > distance carriers will start experiencing problems with bandwidth > demands running rampant real soon now. I've seen IPhone being marketed > as a way to reduce or eliminate your long-distance phone bill. (This > was i San Jose Mercury New, I believe.) Our MBone feed was turned off for several days last week because it was causing packet loss to some VERNet sites upstream of us. Now if we could only resolve the argument with ANS regarding the price of a T3 ;) I'm told the argument has to do with the fact that ANS considers us a 'competitor' IP reseller and wants to charge a higher rate because we provide Internet access to essentially the whole county. Now, pay careful attention here - at the current time, over 35% of the 74,000 people in Montgomery County, Virginia are now Internet-connected, thanks to the Blacksburg Electronic Village (details are at http://www.bev.net/ ). I'll keep you posted, I suspect that we're about to start seeing the sorts of problems that everybody else will be looking at in 3-5 years.... Valdis Kletnieks Computer Systems Engineer Virginia Tech From rem-conf-request@es.net Tue Jul 25 15:14:20 1995 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jul 1995 12:13:43 -0700 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with SMTP id MAA21934; Tue, 25 Jul 1995 12:13:29 -0700 Message-Id: <199507251913.MAA21934@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Christian Wettergren cc: Valdis.Kletnieks@vt.edu, Rod Brathwaite , rem-conf@es.net Subject: Re: Multimedia over the net In-reply-to: Your message of "Tue, 25 Jul 1995 09:32:06 PDT." <199507251632.JAA03479@Csli.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jul 1995 12:13:29 -0700 From: "Amancio Hasty Jr." >>> Christian Wettergren said: > > | Nope. Let's say you're connected via a T-1, and can support 1 or 2 video > | streams. If you go to a T3, what will happen is you can support 20 or 25, > | so people will START 20 or 25. You move to 622mbits/sec ATM in the far > | future, and what will happen is *everybody* in your organization > | will use it. > | > | The instant the users notice that bandwidth is available, it will be > | consumed. > > I would like to rephrase that somewhat. > > I would say that bandwidth soon wont be a problem locally. I would > estimate that about 10 Mbps (of private bandwidth) is all a user can > use with the current generation of computers. One needs to ensure that > the computer can take it as well. Well, a good PCI video capture board can easily exceed that and you are hoping that people will not try to dump raw video on the Internet :) Real soon we will start seeing H.261 solutions for less than $700 (I know of one vendor with a *working* prototype which intends to sell his board for less than $700) and with the increased popularity of the Internet and ISDN lines is not too hard to envisioned the current internet flooded with video streams. Amancio From rem-conf-request@es.net Tue Jul 25 15:23:27 1995 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jul 1995 12:22:32 -0700 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with SMTP id MAA21988 for ; Tue, 25 Jul 1995 12:22:30 -0700 Message-Id: <199507251922.MAA21988@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: rem-conf@es.net Subject: How to identify a source? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jul 1995 12:22:29 -0700 From: "Amancio Hasty Jr." With RTPv2 , if an application is re-started how can I identify that is the same application ? The background is that I wrote a simple program, "bat", to send and transmit audio . I use rtp_testbed as my starting point. When an application starts it generates a unique ssrc everytime that it starts and the only way that I see to determine that is the same application showing up on other bat sessions is to use the ip address of the sender combine with the ssrc;however, this solution has a draw back because I can interface "bat" to NAS and multiple users can show up with the same ip address but with different ssrc. Tnks, Amancio From rem-conf-request@es.net Tue Jul 25 15:36:04 1995 Received: from Csli.Stanford.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jul 1995 12:34:50 -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 MAA08709; Tue, 25 Jul 1995 12:34:32 -0700 Message-Id: <199507251934.MAA08709@Csli.Stanford.EDU> To: "Amancio Hasty Jr." cc: Christian Wettergren , Valdis.Kletnieks@vt.edu, Rod Brathwaite , rem-conf@es.net Subject: Re: Multimedia over the net In-reply-to: Your message of Tue, 25 Jul 1995 12:13:29 PDT. <199507251913.MAA21934@rah.star-gate.com> Date: Tue, 25 Jul 1995 12:34:31 -0700 From: Christian Wettergren | > I would say that bandwidth soon wont be a problem locally. I would | > estimate that about 10 Mbps (of private bandwidth) is all a user can | > use with the current generation of computers. One needs to ensure that | > the computer can take it as well. | | Well, a good PCI video capture board can easily exceed that and you are | hoping that people will not try to dump raw video on the Internet :) | | Real soon we will start seeing H.261 solutions for less than $700 | (I know of one vendor with a *working* prototype which intends | to sell his board for less than $700) and with the increased popularity | of the Internet and ISDN lines is not too hard to envisioned the current | internet flooded with video streams. I guess I didn't explain what I meant clearly enough. I believe that _most_ users will not use much more than 10 Mbps with current computer technology. This is an average estimate, and it is based on the idea that with today's computers you cannot do a lot of useful things with the computer if it is receiving traffic in excess of 10 Mbps. _Most_ users wont use this much, even with new PCI video boards coming out. (They figure 10 Mbps is approximate, I guess within a factor of 3 right. Being scientific here you know! :-)) (Crashing the Internet is usually easy. It the part of getting away with it that will become more tricky. ;-) ) The part about coping with this traffic locally indicated that I believe that, as soon as the ISP start seeing this as a potential income source and not only as a hassle, they will be able to invest into an appropriate infrastructure. This infrastructure can deal with local or maybe even regional traffic. I don't see how they will be able to deal with long-haul call though. It is everything from charging for it, reserving bandwidth, having routers being able to do fair queuing and cope with the number of packets etc. These problems will certainly resolve themselves in the long run (or rather be resolved). But I wonder whether the longhaul Internet providers are mentally prepared for the coming explosion? I guess that it might be a rough ride. :-) /Christian Wettergren KTH/Teleinformatics, Sweden From rem-conf-request@es.net Tue Jul 25 15:58:19 1995 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jul 1995 12:56:39 -0700 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with SMTP id MAA22236; Tue, 25 Jul 1995 12:55:42 -0700 Message-Id: <199507251955.MAA22236@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Christian Wettergren cc: Valdis.Kletnieks@vt.edu, Rod Brathwaite , rem-conf@es.net Subject: Re: Multimedia over the net In-reply-to: Your message of "Tue, 25 Jul 1995 12:34:31 PDT." <199507251934.MAA08709@Csli.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jul 1995 12:55:41 -0700 From: "Amancio Hasty Jr." >>> Christian Wettergren said: > > | > I would say that bandwidth soon wont be a problem locally. I would > | > estimate that about 10 Mbps (of private bandwidth) is all a user can > | > use with the current generation of computers. One needs to ensure that > | > the computer can take it as well. > | > | Well, a good PCI video capture board can easily exceed that and you are > | hoping that people will not try to dump raw video on the Internet :) > | > | Real soon we will start seeing H.261 solutions for less than $700 > | (I know of one vendor with a *working* prototype which intends > | to sell his board for less than $700) and with the increased popularity > | of the Internet and ISDN lines is not too hard to envisioned the current > | internet flooded with video streams. > > I guess I didn't explain what I meant clearly enough. > > I believe that _most_ users will not use much more than 10 Mbps with > current computer technology. This is an average estimate, and it is > based on the idea that with today's computers you cannot do a lot of > useful things with the computer if it is receiving traffic in excess > of 10 Mbps. _Most_ users wont use this much, even with new PCI video > boards coming out. (They figure 10 Mbps is approximate, I guess within > a factor of 3 right. Being scientific here you know! :-)) > I don't mean to sound argumentative the 10Mbps figure or there abouts is more of a limitation of the network rather than on cpu or bus bandwidth. It all depends what the 10Mpbs stream is if it is mpeg you can bet that CPU is not going to be able to cope with decompressing in real time the video streams;however, if it has a couple of mpeg hardware assist mpeg decompressors it will be able to handle the video stream with todays PCI architecture with something like a pentium. Just about any decent fast-wide scsi-2 or fast scsi-2 disk drive can pump out more than 40Mbs streams. If I am not mistaken the current PCI specification calls for a 128Mbytes/sec bus bandwith. A Dec Alpha class machine can flood the PCI bus however the Pentiums can probably use only about 1/2 of the PCI bus bandwith. I would characterize "_most_ users" as those connected to the internet and with fast access to the net. Perhaps in that group you will find that your typical user will probably tend to have high-end PCs or workstation class machines. Regards, Amancio From rem-conf-request@es.net Tue Jul 25 17:14:27 1995 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jul 1995 14:13:34 -0700 Received: from parcbox2.parc.xerox.com ([13.2.116.222]) by alpha.xerox.com with SMTP id <15736(2)>; Tue, 25 Jul 1995 14:13:10 PDT Received: from localhost by parcbox2.parc.xerox.com with SMTP id <3469>; Tue, 25 Jul 1995 14:13:03 -0700 X-Mailer: exmh version 1.6.1 5/23/95 To: "Amancio Hasty Jr." cc: rem-conf@es.net Subject: Re: How to identify a source? In-reply-to: Your message of "Tue, 25 Jul 95 12:22:29 PDT." <199507251922.MAA21988@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jul 1995 14:12:51 PDT Sender: Paul Stewart From: Paul Stewart Message-Id: <95Jul25.141303pdt.3469@parcbox2.parc.xerox.com> In message <199507251922.MAA21988@rah.star-gate.com> you write: > >With RTPv2 , if an application is re-started how can I identify that is the >same application ? > >The background is that I wrote a simple program, "bat", to send and transmit >audio . I use rtp_testbed as my starting point. When an application >starts it generates a unique ssrc everytime that it starts and the >only way that I see to determine that is the same application showing >up on other bat sessions is to use the ip address of the sender combine >with the ssrc;however, this solution has a draw back because I can >interface "bat" to NAS and multiple users can show up with the same >ip address but with different ssrc. The "official" method is to identify the source by its CNAME SDES record. There are changes you can make to the SSRC selection code that gives a receiver a good guess as to the SSRC of the source it wishes to listen to. For example you can compute an initial SSRC based on your CNAME via a hashing algorithm, instead of using a random function. I'm not entirely certain about the "officialness" of this technique at the current time. In either case, this doesn't necessarily mean that you can unconditionally depend on the SSRC being a certain value. It may, however be used to "prime" the receiver until it is able to confirm the CNAME via SDES records it receives later. The rtp_testbed code was written before I knew about this, so it doesn't implement this. You're welcome to make such changes if you wish. At this point I'm rethinking my strategies towards APIs or "easups" for RTP/RTCP sending/receipt, so I don't think rtp_testbed in its current form will continue to be updated with the changes to the RTP drafts since June last year. I hope, however that the code is useful enough to give you a good start... -- Paul From rem-conf-request@es.net Tue Jul 25 17:41:03 1995 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jul 1995 14:40:10 -0700 Received: from localhost.v-site.net (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with SMTP id OAA23161; Tue, 25 Jul 1995 14:40:04 -0700 Message-Id: <199507252140.OAA23161@rah.star-gate.com> X-Authentication-Warning: rah.star-gate.com: Host localhost.v-site.net didn't use HELO protocol X-Mailer: exmh version 1.6.2 7/18/95 To: Paul Stewart cc: rem-conf@es.net Subject: Re: How to identify a source? In-reply-to: Your message of "Tue, 25 Jul 1995 14:12:51 PDT." <95Jul25.141303pdt.3469@parcbox2.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jul 1995 14:40:04 -0700 From: "Amancio Hasty Jr." >>> Paul Stewart said: > In message <199507251922.MAA21988@rah.star-gate.com> you write: > > > > The rtp_testbed code was written before I knew about this, so it doesn't > implement this. You're welcome to make such changes if you wish. At this > point I'm rethinking my strategies towards APIs or "easups" for RTP/RTCP An object approach will not hurt :) > sending/receipt, so I don't think rtp_testbed in its current form will > continue to be updated with the changes to the RTP drafts since June last > year. I hope, however that the code is useful enough to give you a good > start... > BTW: many thanks for rtp_testbed it made it very easy to quickly develop bat. So far using GSM, I managed to carry out a conversation using my 128kb line and the other side was a 56kb line . Hopefully, over a short period of time I expect bat to be a net answering machine, the ability to play or record sounds on the fly, handle half-dulplex audio -- currently I am doing full duplex using a Gravis Ultrasound card. Also, I should be able to update rtp_testbed or at least my version to the current RTPv2 specs. The graphical front end to bat is done with tk and blt. The primary motivation for bat is to provide an audio tool which uses RTPv2 for FreeBSD. Regards, Amancio From rem-conf-request@es.net Tue Jul 25 21:58:59 1995 Received: from viipuri.nersc.gov by osi-east.es.net with ESnet SMTP (PP); Tue, 25 Jul 1995 18:58:30 -0700 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA27773; Tue, 25 Jul 95 18:58:29 PDT Date: Tue, 25 Jul 95 18:58:29 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9507260158.AA27773@viipuri.nersc.gov> To: rem-conf@es.net Subject: FWD:Singapore National Day Parade Broadcast on Internet Reply-To: Ari@es.net Missent to the -request address... ----- Begin Included Message ----- >From kokyong@irdu.nus.sg Mon Jul 17 23:09:43 1995 Date: Tue, 18 Jul 1995 14:08:07 +0800 (WST) From: Leong Kok Yong Subject: Singapore National Day Parade Broadcast on Internet To: rem-conf-request@es.net Cc: ndp95@pluto.cc.nus.sg Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1532 MBONE Announcement Singapore 30th National Day Parade Live and delayed Audio/Video MBONE Internet broadcast jointly organized by National University of Singapore Computer Centre Technet, IRDU and TCS August 9 1995 ------------- 0900 - 1000 GMT (test transmission) 1100 - 1300 GMT (live) 1700 - 1900 GMT (rebroadcast) August 10 1995 -------------- 0000 - 0200 GMT (rebroadcast) 0500 - 0700 GMT (rebroadcast) We are planning an MBONE broadcast of our National Day Parade (NDP) 95 on the Internet bringing to you the wonderful sights and sounds of our celelebration on the above date and time. The above schedule may be subjected to change. Also any conflicts in time/date with any other ongoing broadcast on the same day/time can be resolved by contacting with the undersigned. We will be broadcasting over Technet 512kbps leased line to JvNC and making use of the CUSeeMe technolgy. Invitation wll be sent out to overseas sites like the US, UK, Australia and Canada to particapte as a reflector site. Anyone who wish to join in can contact the undersigned. Meanwhile, you can start looking out for further updates or information on our NDP Web Page specially setup for this occasion. You can find it at http://www.nus.sg/NDP30.html. Comments and questions are welcomed. Anybody is welcomed to include this URL in their WEB server home page. Feedbacks on this annoucement can be directed to ndp95@pluto.cc.nus.sg or entered at our web page. ----- End Included Message ----- From rem-conf-request@es.net Wed Jul 26 12:20:25 1995 Received: from trystero.radio.com by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jul 1995 09:19:58 -0700 Received: (bburdick@localhost) by trystero.radio.com (8.6.12/940816.06ccg) id MAA08503 for rem-conf@es.net; Wed, 26 Jul 1995 12:22:40 -0400 From: Brad Burdick Message-Id: <199507261622.MAA08503@trystero.radio.com> Subject: White House Empowerment Zones Conference To: rem-conf@es.net Date: Wed, 26 Jul 1995 12:22:40 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 492 Can be found on SD listing IMS: Internet Town Hall. I apologize for the short notice...it starts at 12:15pm Eastern Time on July 26. We just found out that this could be done on the 25th and received approval at 11:30am on the 26th. Announcements by President Clinton and Vice President Gore. -brad -- Brad Burdick bburdick@radio.com Internet Multicasting Service, NPB, Suite 1155, Washington, DC 20045 Under contract from UUcom, Inc. From rem-conf-request@es.net Wed Jul 26 20:44:02 1995 Received: from IETF.nri.reston.VA.US (actually ietf.cnri.reston.va.us) by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jul 1995 17:43:34 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15862; 26 Jul 95 17:16 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-h261-01.txt Date: Wed, 26 Jul 95 17:16:05 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9507261716.aa15862@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 for H.261 video streams Author(s) : T. Turletti, C. Huitema Filename : draft-ietf-avt-h261-01.txt Pages : 14 Date : 07/25/1995 This draft describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. 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-h261-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-h261-01.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-h261-01.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: <19950725182737.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-h261-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-h261-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950725182737.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Wed Jul 26 21:13:14 1995 Received: from graph.gsi-mc.go.jp by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jul 1995 18:12:36 -0700 Received: (from skirkby@localhost) by graph.gsi-mc.go.jp (8.6.9+2.4Wb3/3.3W) id KAA12217 for rem-conf@es.net; Thu, 27 Jul 1995 10:08:36 +0900 Date: Thu, 27 Jul 1995 10:08:36 +0900 From: Steve Kirkby Message-Id: <199507270108.KAA12217@graph.gsi-mc.go.jp> To: rem-conf@es.net Subject: beginner Content-Length: 2601 Apologies if I've sent this to the wrong group. BTW I do not subscribe to this group so can you please reply to my e-mail address listed below. I need advice re: multi-party conferencing using cu-seeme, a reflector and sd (vat/nv) on an SG. I'm an absolute beginner so please be patient. I have set up (with lots of help) a reflector (3.0b3) on a SGextreme. It is conifigured like this ; REFMON 163.xx MOTD Welcome to the reflector of the Geographical Survey Institute Japan. Be careful with bandwidth. // LOG-LIMIT 300 NV-MC-IN 224.xx NV-MC-OUT 16 224.xx NV-MC-PORT 4444 VAT-MC-IN 224.xx VAT-MC-OUT 16 224.xx VAT-MC-PORT 3456 VAT-CONF-ID 0 OK... we have 3 Mac's running cu-seeme. They connect to the reflector via the ip number (163.xx) of the sg machine. All 3 Mac's can see each other ... no problems. Unfortunately they cannot talk to each other, even though the log file looks like this; open_log file: reflect.log tsuneo@graph is speaking Time: Wed Jul 26 13:42:04 1995 Pkts in 378 Pkts out 946 bits/sec in 2 17 kbits/sec out 564 tsuneo@graph is speaking Time: Wed Jul 26 13:42:14 1995 Pkts in 326 Pkts out 831 kbits/sec in 2 23 kbits/sec out 579 T.nagayama is speaking privetly to ooi@graph Time: Wed Jul 26 13:42:24 1995 Pkts in 362 Pkts out 858 kbits/sec in 2 39 kbits/sec out 602 To me.. it seems as if it is working.... but no voices are being heard at the terminals. Additionally I have another problem. We have another sgindy (on another floor) which also wants to join the conference. We get this person to open a sd session on their machine... they send the session to the reflector (224.xx) on the other sg. (with ttl set to 16 and audio conf id set to 0 and port 3456.. video port 4444 conf = ??)... vat and nv start when the sd session is opened.... but unfortunately it seems that no video or audio is transmitted or received. Strangely if the person on the sgindy only uses nv to send video to the reflector... this works... in the sense that the cu-seeme users (all 3) recieve his picture (giving them 4 on the screen).. but unfortunately the guy on the sgindy receives no video streams in return... I hope this makes sense to you the experts... to me...its unbelievably confusing!! I'd really apreciate some advice. Thanks Steve ------------------------------------------------------- Steve Kirkby Geographical Survey Institute, Japan Ph +81 298 64 5929 Fax +81 298 64 1804 Email: skirkby@graph.gsi-mc.go.jp Smail: Kitasato-1,Tsukuba-shi, Ibaraki-pref, 305 ------------------------------------------------------- From rem-conf-request@es.net Wed Jul 26 23:18:22 1995 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jul 1995 20:17:37 -0700 Received: by precept.com (5.x/SMI-4.1) id AA25764; Wed, 26 Jul 1995 20:17:34 -0700 Date: Wed, 26 Jul 1995 20:17:33 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Last Call requested for RTP H.261 draft In-Reply-To: <9507261716.aa15862@IETF.CNRI.Reston.VA.US> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To the Audio/Video Transport Working Group: The latest draft of the RTP payload format for H.261 video streams, draft-ietf-avt-h261-01.txt, has now been posted to the I-D directories. This draft is what I believe will be the last of a recent series of updates refining the fragmentation technique to use macroblock boundaries. These drafts were produced as a result of discussions among the authors and implementors. The changes from the previous draft h261-00 from June are relatively small; specifically, the combined MBAGOB field has been broken into separate GOBN and MBAP fields for easier processing, and the RTP timestamp clock rate has been changed to 90KHz as mentioned in previous messages to this list. The technique specified in this new draft has been implemented in a not-yet-released version of the vic program by Steve McCanne, and it was found to work well. I am going to now submit a request to the IESG for Last Call on this draft and publication as a Proposed Standard RFC along with the main RTP spec and A/V Profile. Please review the document and submit any comments you may have during this Last Call period. BTW, we should be seeing the announcement of the Last Call for the A/V profile, which was requested just before the IETF meeting, any day now, too. I'm hoping these items will be reviewed by the IESG on August 3. -- Steve From rem-conf-request@es.net Thu Jul 27 08:50:25 1995 Received: from VTBIT.CC.VT.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Jul 1995 05:49:59 -0700 Received: from VTBIT.CC.VT.EDU by VTBIT.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 3604; Thu, 27 Jul 95 08:49:10 EDT Received: from VCCSCENT.BITNET (NJE origin MAILER@VCCSCENT) by VTBIT.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 0990; Thu, 27 Jul 1995 08:49:10 -0400 Received: from VCCSCENT (SORICHD) by VCCSCENT.BITNET (Mailer R2.07) with BSMTP id 8176; Thu, 27 Jul 95 08:50:11 EST Comments: Converted from PROFS to RFC822 format by PUMP V2.2X Date: Thu, 27 Jul 95 08:49:31 EST From: David Richardson Subject: Cu-SeeMe To: David Richardson Read email from Steve Kirdby made me realize that I am not even a beginner about Cu-SeeMe. I am one of the instructional technology systems planners for the Virginia Community College System. I would like to know more about Cu-SeeMe and how it works. Could someone please send me the ABC basics of what equipment I would need to get started using Cu-SeeMe. Currently I have a WIN 486, 66hz with a CD-ROM, 1 gig hardrive, 16meg RAM, connected to an OS2 LAN, I have a 56K line for communications with a VGA monitor. Any assistance would be appreciated. David Richardson, VCCS Instructional Technology Systems Planner Academic Services and Research 101 N, fourteeenth street Monroe building, 15th floor Richmond, Virginia 23219 804 692 0363 tel 804 692 0299 fax From rem-conf-request@es.net Thu Jul 27 12:33:51 1995 Received: from prom.engin.umich.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Jul 1995 09:33:23 -0700 Received: (dschluss@localhost) by prom.engin.umich.edu (8.6.12/8.6.4) id MAA04937; Thu, 27 Jul 1995 12:33:12 -0400 Date: Thu, 27 Jul 1995 12:32:10 -0400 (EDT) From: "david a. schlussel" Subject: Re: Cu-SeeMe To: David Richardson cc: David Richardson In-Reply-To: <199507271419.KAA26744@truelies.rs.itd.umich.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII assuming you have web access: http://CU-SeeMe.cornell.edu/ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + David Schlussel + + dschluss@umich.edu + + MCIT-Special Projects + + http://www.umich.edu/~dschluss/ + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ On Thu, 27 Jul 1995, David Richardson wrote: > > Read email from Steve Kirdby made me realize that I am not even a beginner > about Cu-SeeMe. > > I am one of the instructional technology systems planners for the Virginia > Community College System. I would like to know more about Cu-SeeMe and how it > works. Could someone please send me the ABC basics of what equipment I would > need to get started using Cu-SeeMe. > > Currently I have a WIN 486, 66hz with a CD-ROM, 1 gig hardrive, 16meg RAM, > connected to an OS2 LAN, I have a 56K line for communications with a VGA > monitor. > > Any assistance would be appreciated. > > David Richardson, VCCS Instructional Technology Systems Planner > Academic Services and Research > 101 N, fourteeenth street > Monroe building, 15th floor > Richmond, Virginia 23219 > 804 692 0363 tel > 804 692 0299 fax > From rem-conf-request@es.net Thu Jul 27 18:44:37 1995 Received: from scorpio.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Jul 1995 15:44:03 -0700 Received: by scorpio.arc.nasa.gov (940816.SGI.8.6.9/1.35) id NAA08050; Thu, 27 Jul 1995 13:17:10 -0700 Date: Thu, 27 Jul 1995 13:17:10 -0700 From: garyp@scorpio.arc.nasa.gov (Gary Paden) Message-Id: <199507272017.NAA08050@scorpio.arc.nasa.gov> To: rem-conf@es.net Subject: STS-69 Shuttle Broadcast We are planing an Mbone presentation August 5, 1995. We will be transmitting via nv at TTL 127. The 11-day mission will feature the second flight of the Wake Shield Facility (WSF), a saucer-shaped satellite that will fly free of the Shuttle for several days. The crew also will deploy and retrieve the Spartan 201 astronomy satellite. Also flying aboard Endeavour will be the combined Capillary Pumped Loop-2/Gas Bridge Assembly (CAPL-2/GBA) payload. Another payload being flown with a connection to the development of the Space Station is the Electrolysis Performance Improvement Concept Study (EPICS). The presentation will be 12 days in duration. The Shuttle will launch August 5,1995 no earlier than 10:45a.m. (estimated). The Shuttle landing will take place at Kennedy Space Center August 16,1995 at about 7:14a.m. (estimated). If this presentation creates a conflict with any previously scheduled broadcasts, please contact me. Thanks Gary Gary Paden NASA-Ames/Sterling Video Technician garyp@scorpio.arc.nasa.gov (415)604-0082 From rem-conf-request@es.net Fri Jul 28 13:15:20 1995 Received: from ctrvx1.Vanderbilt.Edu by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Jul 1995 10:14:15 -0700 Received: from ctrvax.Vanderbilt.Edu by ctrvax.Vanderbilt.Edu (PMDF V4.2-15 #7190) id <01HTEIQJG5AS8XVE5B@ctrvax.Vanderbilt.Edu>; Fri, 28 Jul 1995 12:06:45 CDT Date: Fri, 28 Jul 1995 12:06:45 -0500 (CDT) From: BEZALEL GAVISH Subject: CFP 4th Int. Conf. on Telecommunication Systems To: listoflists:; Message-id: <01HTEIQJG5AU8XVE5B@ctrvax.Vanderbilt.Edu> X-VMS-To: IN%"listoflists" X-VMS-Cc: GAVISHB MIME-version: 1.0 Content-transfer-encoding: 7BIT TSMCFP96 This is a revised and updated call for papers for the 4th conference The organizing committee received many requests from international participants, to move the conference one week so that they could combine it with the INFOCOM meeting. The conference has been moved one week to March 21-24, 1996. We look forward for your participation. ======================================================================== C A L L for P A P E R S 4th International Conference on Telecommunication Systems Modelling and Analysis March 21-24, 1996 Nashville, TN The 4th International Conference on Telecommunication Systems - Modelling and Analysis will be held in Nashville, Tennessee on March 21-24, 1996. The conference location will be the Bell South Tower in downtown Nashville. The conference will build on the tradition of the earlier conferences with a few changes in format due to the new conference location. The general idea is to limit the number of participants, concentrate on a few topics, present new problems and problem areas, encouraging informal interaction and exchanges of ideas. The objective is to advance the state of the modelling and analysis in telecommunications by stimulating research activity on new and important problems. The conference will be divided into segments with each segment devoted to a specific topic. This will allow for little conflict between segments. All papers will be screened by the program committee to ensure the quality of presentations. A decentralized paper handling process will be used, the Program Committee has been divided along geographical areas with a separate Program Subcommittee assigned to each area. Abstracts and papers should be submitted directly to Program Committee Chair of the appropriate area. It is expected that this will expedite the paper review process. In response to suggestions made by last year's participants, social and cultural activities will be included in the 1996 agenda. Lead Speakers and Keynote speakers include: Leonard Kleinrock, Alan Konheim, Bezalel Gavish, Paul Kuehn. The Chairmen of the geographic Program Committees are: ---Australia, New Zealand and South East Asia: Prof. Richard Harris Department of Communication and Electronic Engineering Royal Melbourne Institute of Technology GPO Box 2476V Tel: 61 3660 2457 Melbourne, 3001 FAX: 61 3660 1060 Australia Email: richard@catt.citri.edu.au ---Europe: Prof. Guy Pujolle Laboratoire PRiSM Universite de Versailles - Saint-Quentin 45, avenue des Etats-Unis Tel: 33 1 39 25 40 61 78 035 Versailles Cedex FAX: 33 1 39 25 40 57 France Email: guy.pujolle@prism.uvsq.fr ---North America: Prof. Andre Girard INRS-Telecommunications 16, place du Commerce Tel: 514-765-7832 Verdun, Quebec FAX: 514-765-8785 Canada H3E 1H6 Email: andre@inrs-telecom.uquebec.ca ---North East Asia: Prof. Yutaka Takahashi Department of Applied Mathematics and Physics Faculty of Engineering Kyoto University Tel: 81 757535493 Yoshida-Honmachi, Sakyo-ku, Kyoto 606 FAX: Japan Email: yutaka@kuamp.kyoto-u.ac.jp ---South and Central America: Dr. Ernesto Santibanez-Gonzalez School of Industrial Engineering Catholic University of Valparaiso Tel: 56 32 257331 Av. Brasil 2147 FAX: 56 32 214823 Chile Email: esantiba@aix1.ucv.cl and Prof. Henrique Pacca L. Luna Department of Computer Science Federal University of Minas Gerais Tel: 31270-901 Belo Horizonte - MG FAX: Brazil Email: pacca@dcc.ufmg.br ---Chairman of the Economics track: Prof. Jeffrey Mackie-Mason Department of Economics Tel: 313-764-7438 University of Michigan FAX: 313-763-9181 Ann Arbor, MI 48109-1220 Email: jmm@umich.edu and Prof. William W. Sharkey ---All other geographic areas: Prof. Bezalel Gavish Owen Graduate School of Management Vanderbilt University Tel: 615-322-3659 401 21st Avenue South FAX: 615-343-7177 Nashville, TN 37203 Email: gavishb@ctrvax.vanderbilt.edu Listed below are some of the potential segments: -- Configuration of ATM networks -- Internet and its impact on commerce -- Topological Design and Network Configuration Problems -- Design and Analysis of Local Access Networks and Outside Plant Problems -- Low Earth Orbit Satellite communication systems -- Cellular Systems and PCS Modelling and Configuration -- Time Dependent Expansion of Telecommunication Systems -- Designing Networks for Reliability and Availability -- Network Design Problems in Gigabit and Terabit Networks -- LAN, WAN Global Network Interconnection -- ATM, ISDN, BISDN Modeling and Analysis Issues -- Artificial Intelligence/Heuristics in Telecommunication Systems -- Quantitative Methods in Network Management -- Pricing and Economic Analysis of Telecommunications -- Impact of Telecommunications on Industrial Organization -- Performance Evaluation of Telecommunication Systems -- Distributed Computing and Distributed Data Bases -- Security and Privacy issues in Telecommunications -- Virtual reality, Multimedia and their impact The Program Committee is open to any ideas you might have regarding additional topics or format of the conference. The intention is to limit the number of parallel sessions to two. The conference is scheduled over a weekend so as to reduce teaching conflicts for academic participants, take advantage of weekend hotel and airfare rates and of the many events that take place in the downtown area. Due to the limit on the number of participants early registration is recommended. To ensure your participation, please use the following steps: 1. Send to the appropriate Program Committee Chair by October 1, 1995, a paper (preferable), or titles and abstracts for potential presentations to be considered for the conference. Sending more than one abstract is encouraged, enabling the Program Committee to have a wider choice in terms of assigning talks to segments. Use E-mail to expedite the submission of titles and abstracts. 2. Use the form at the end of this message to preregister for the conference. Let us also know if you would like to have a formal duty during the conference as: Session Chair, or Discussant. 3. You will be notified by December 1, 1995, which abstract/s has been selected for the conference. Detailed instructions on how to prepare camera ready copies will be sent to authors of accepted presentations. January 30, 1996, is the deadline for sending a final version of the paper. Participants will receive copies of the collection of papers to be presented. All papers submitted to the conference will be considered for publication in the "Telecommunication Systems" Journal. The Program Committee looks forward to receiving your feedback/ideas. Feel free to volunteer any help you can offer. If you have suggestions for Segment Leaders (i.e., individuals who will have a longer time to give an overview/state of the art talk on their segment subject) please E-mail them to Prof Gavish. Also, if there are individuals whose participation you view as important, please send their names and E-mail addresses to the Program Committee Chairman, or forward to them a copy of this message. I look forward to a very successful conference. Sincerely yours, Bezalel Gavish ------------------------------------------------------------------------------- Cut Here ------------------------------------------------------------------------------- Fourth International Conference on Telecommunication Systems Modelling and Analysis REGISTRATION FORM Date: __________________ Location: Nashville, TN Dates: March 14, 1996 (afternoon) to March 17, 1996 Name: ________________________________________ Title: __________________ Affiliation: __________________________________________________________________ Address: __________________________________________________________________ __________________________________________________________________ Phone: ____________________________ FAX: _______________________________ E-mail: __________________________________________________________________ Potential Title of Paper(s): __________________________________________________ ____________________________________________________________________ I would like to Volunteer as Comments A Session Chair : Yes No ________________________________________________ A Discussant : Yes No ________________________________________________ Organize a Session: Yes No ________________________________________________ ________________________________________________ REGISTRATION RATES and DEADLINES Last Applicable Participant Type Date Academic Industry ---------------- -------- -------- 1. Preregistration Until Dec. 1, 1996 $ 350 $ 450 2. Registration Until Feb. 1, 1996 $ 400 $ 500 3. On Site Registration After Feb. 1, 1996 $ 450 $ 650 Mail your registration form and check to: Mrs. Dru Lundeng Owen Graduate School of Management Vanderbilt University 401 21st Avenue, South Nashville, TN 37203, USA The check should be addressed to: 4th Int'l. Telecomm Systems Conference Refund Policy: Half refund, for requests received by February 1, 1996. No refund after February 1, 1996. If you have any questions regarding the conference, please contact Dru Lundeng at 615-322-3694 or through E-mail at lundeng@ctrvax.vanderbilt.edu. ------------------------------------------------------------------------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN, 37203 Bitnet: GAVISHB@VUCTRVAX Internet: GAVISHB@CTRVAX.VANDERBILT.EDU Tel: (615) 322-3659 Home: (615) 370-0813 FAX: (615) 343-7177 ------------------------------------------------------------------------------- From rem-conf-request@es.net Mon Jul 31 05:12:08 1995 Received: from beijing2.net.edu.cn (actually cernet.edu.cn) by osi-west.es.net with ESnet SMTP (PP); Mon, 31 Jul 1995 02:11:27 -0700 Received: by beijing2.net.edu.cn (4.1/SMI-4.1) id AA13884; Mon, 31 Jul 95 17:11:46 CDT Date: Mon, 31 Jul 95 17:11:46 CDT From: cheng@cernet.edu.cn (Yan Cheng) Message-Id: <9507310811.AA13884@beijing2.net.edu.cn> Apparently-To: rem-conf@es.net From rem-conf-request@es.net Mon Jul 31 05:18:21 1995 Received: from beijing2.net.edu.cn (actually cernet.edu.cn) by osi-west.es.net with ESnet SMTP (PP); Mon, 31 Jul 1995 02:17:37 -0700 Received: by beijing2.net.edu.cn (4.1/SMI-4.1) id AA14042; Mon, 31 Jul 95 17:17:59 CDT Date: Mon, 31 Jul 95 17:17:59 CDT From: cheng@cernet.edu.cn (Yan Cheng) Message-Id: <9507310817.AA14042@beijing2.net.edu.cn> To: rem-conf@es.net Subject: ip-multicast for lynux Hello all, I have a PC which is installed lynux. Now I want setup MBone tools so I need ip multicast for lynux. Where can I get it? Thanks a lot cheng From rem-conf-request@es.net Mon Jul 31 08:47:38 1995 X400-Received: by mta osi-west.es.net in /PRMD=ESnet/ADMD= /C=US/; Relayed; Mon, 31 Jul 1995 05:09:49 -0700 X400-Received: by /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Mon, 31 Jul 1995 03:49:58 -0700 X400-Received: by /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Mon, 31 Jul 1995 05:46:02 -0700 X400-Received: by /PRMD=iihe/ADMD=rtt/C=be/; Relayed; Mon, 31 Jul 1995 05:46:02 -0700 Date: Mon, 31 Jul 1995 05:46:02 -0700 X400-Originator: colin@helios.iihe.rtt.be X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=iihe/ADMD=rtt/C=be/;950731124602] X400-Content-Type: P2-1984 (2) Content-Identifier: 13310006 From: Michel Colin Message-ID: <13310006*/G=michel/S=colin/O=helios/PRMD=iihe/ADMD=rtt/C=be/@MHS> To: " (Yan Cheng)" (Non Receipt Notification Requested) Cc: rem-conf@es.net (Non Receipt Notification Requested) In-Reply-To: <9507310817.AA14042@beijing2.net.edu.cn> Subject: ip-multicast for lynux ------------------------------ Start of body part 1 > I have a PC which is installed lynux. Now I want setup MBone tools so I need ip >multicast for lynux. Where can I get it? ip-multicast is available in latest version of Linux. You just need to enable ip multicasting during the make configure I don't know if a version of mrouted is available for linux but you just need to have one mrouted on the same subnet that your linux box and it will works Michel ------------------------------ Start of body part 2 =============================================================================== Michel Colin Tel. +32-2-650 57 03 Fax: +32-2-629 38 16 Universite Libre de Bruxelles Faculte des Sciences Service Telematique et Communication CP 230, Boulevard du triomphe B-1050 Bruxelles BELGIUM RFC822: colin@helios.iihe.rtt.be X.400 : C=be;ADMD=rtt;PRMD=iihe;O=helios;S=colin; X.500 : @c=be@o=Universite Libre de Bruxelles@ou=Faculte des Sciences@ou=Service Telematique et Communication@cn=Michel Colin ------------------------------------------------------------------------------- ------------------------------ End of body part 2 From rem-conf-request@es.net Mon Jul 31 10:05:25 1995 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Mon, 31 Jul 1995 07:05:01 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14756(2)>; Mon, 31 Jul 1995 07:04:42 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 31 Jul 1995 07:04:38 -0700 To: Rod Brathwaite Cc: rem-conf@es.net, deering@parc.xerox.com Subject: Re: Multimedia over the net In-reply-to: rod's message of Mon, 24 Jul 95 08:41:14 -0800. <9507241141.ZM21799@mtpcs979> Date: Mon, 31 Jul 1995 07:04:31 PDT Sender: Steve Deering From: Steve Deering Message-Id: <95Jul31.070438pdt.75270@digit.parc.xerox.com> Rod, > Q: Is it possible to guarantee a certain quality of service (QOS) from > an internet service provider (ISP) if you wanted to have a video > conference between 2 or more ppl over the internet? That's being worked on (by the rcvp and int-serv working groups of the IETF). However, please note that it is possible (and, some of us believe, highly preferable) to do high-quality video conferencing over the Internet *without* QOS guarantees. (Low-quality video conferencing has been occurring over the Internet for more than a decade, and has been in wide use for the past couple of years.) > Q: Would you have to "tunnel" dynamically to make this work? What do you mean by '"tunnel" dynamically'? > Q: Since bandwidth is the major issue for multimedia over the net, > will IP over ATM solve this bandwidth crunch? No, IP over higher bandwidth will solve this bandwidth crunch. Encumbering that bandwidth with ATM just reduces it. Steve From rem-conf-request@es.net Mon Jul 31 13:18:19 1995 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 31 Jul 1995 10:17:47 -0700 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 31 Jul 1995 18:17:05 +0100 X-Mailer: exmh version 1.6.2 7/18/95 From: Piers O'Hanlon Organisation: University College London, AV Dept. Phone: +44 171 636 8333 ext 3056 (Hang on in there...) To: Steve Deering cc: P.OHanlon@cs.ucl.ac.uk, rem-conf@es.net Subject: Re: Multimedia over the net In-reply-to: Your message of "Mon, 31 Jul 95 07:04:31 PDT." <95Jul31.070438pdt.75270@digit.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Jul 95 18:17:07 +0100 Sender: P.OHanlon@cs.ucl.ac.uk Steve, > > That's being worked on (by the rcvp and int-serv working groups of the IETF). > However, please note that it is possible (and, some of us believe, highly > preferable) to do high-quality video conferencing over the Internet > *without* QOS guarantees. (Low-quality video conferencing has been > occurring over the Internet for more than a decade, and has been in wide > use for the past couple of years.) > Surely some minimum network QOS has be assumed to design and use these tools? When people decide to use these tools they need some assurance of a basic service offering. I guess it depends on your view on what the Internet should offer the world. Piers O'Hanlon ______________ Audio Visual Centre University College London. From rem-conf-request@es.net Mon Jul 31 21:28:56 1995 Received: from mail.ncku.edu.tw by osi-west.es.net with ESnet SMTP (PP); Mon, 31 Jul 1995 18:28:29 -0700 Received: (from ckwen@localhost) by mail.ncku.edu.tw (8.6.12/8.6.12) id JAA24581; Tue, 1 Aug 1995 09:28:24 +0800 From: Cheng-Kang Wen Message-Id: <199508010128.JAA24581@mail.ncku.edu.tw> Subject: Re: ip-multicast for lynux To: cheng@cernet.edu.cn (Yan Cheng) Date: Tue, 1 Aug 1995 09:28:23 +0800 (WST) Cc: rem-conf@es.net In-Reply-To: <9507310817.AA14042@beijing2.net.edu.cn> from "Yan Cheng" at Jul 31, 95 05:17:59 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 445 > I have a PC which is installed lynux. Now I want setup MBone tools so I need ip > multicast for lynux. Where can I get it? > Those kernels with version 1.2.0 or newer are supported with ip multicasting. But ip multicast is disabled by default in the kernel configuration of some Linux packages, for instance, Slackware. So you need to reconfigure your linux kernel to enable ip multicast and recompile the kernel. Regards, Cheng-Kang Wen