From rem-conf Wed Apr 01 00:08:06 1998 From rem-conf-request@es.net Wed Apr 01 00:08:05 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yKIWQ-0000tD-00; Wed, 1 Apr 1998 00:05:22 -0800 Received: from aries.dif.um.es (aries.dif.um.es.) [155.54.12.152] by mail1.es.net with smtp (Exim 1.81 #2) id 0yKIWM-0000sp-00; Wed, 1 Apr 1998 00:05:21 -0800 Received: from orion by aries.dif.um.es. (SMI-8.6/SMI-SVR4) id KAA00838; Wed, 1 Apr 1998 10:02:03 +0100 Message-Id: <199804010902.KAA00838@aries.dif.um.es.> X-Sender: amateo@aries.dif.um.es X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Demo Date: Wed, 01 Apr 1998 10:07:01 +0100 To: rem-conf@es.net From: Angel Luis Mateo =?iso-8859-1?Q?Mart=EDnez?= Subject: vat and encryption Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello all: I would like to know if there is a version of vat for Windows95/NT that supports DES1 encryption. If there is, where I can found it? Thanks, Angel L. Mateo Mart=EDnez=20 From rem-conf Fri Apr 03 12:43:52 1998 From rem-conf-request@es.net Fri Apr 03 12:43:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yLD1S-0004TF-00; Fri, 3 Apr 1998 12:25:10 -0800 Received: from s2.itd.nrl.navy.mil (itd.nrl.navy.mil) [132.250.83.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yLD1R-0004T5-00; Fri, 3 Apr 1998 12:25:09 -0800 Received: from [132.250.92.132] (jeffw.itd.nrl.navy.mil [132.250.92.132]) by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id PAA13509; Fri, 3 Apr 1998 15:22:53 -0500 (EST) X-Sender: wieselth@pop.itd.nrl.navy.mil Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 1998 15:23:44 -0500 To: enternet@bbn.com, dbworld@cs.wisc.edu, end2end-interest@isi.edu, f-troup@codex.cis.upenn.edu, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, cellular@comnets.rwth-aachen.de, ieeetcpc@ccvm.sunysb.edu, cnom@maestro.bellcore.com, multicomm@cc.bellcore.com, epr@infotest.com From: Jeff Wieselthier Subject: ISCC'98 -- Athens, Greece -- Call for Participation X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Call for Participation The Third IEEE Symposium on Computers and Communications ISCC'98 Athens, Greece June 29 - July 2, 1998 Sponsored by IEEE Communications Society and IEEE Computer Society* * Technical Committee on Simulation General Chair: =20 P. A. Probst, Swiss Telecom, Switzerland Vice Chair: Prof. Hussein Mouftah, Queens University, Canada Technical Program Co-Chairs: Prof. Hussein Mouftah, Queens University, Canada Dr. Jeffrey E. Wieselthier, Naval Research Laboratory, USA The fast growing convergence between communications and computer=20 technologies is having an increasingly profound impact on information=20 and networking systems. This third annual event will provide a=20 technical forum for experts from industry and academia to exchange=20 ideas and present results of ongoing research in the areas listed below. =20 The technical program consists of 140 research papers in 4 parallel=20 sessions, a panel session, 9 tutorials, and several invited talks. The complete technical program is available at our website: http://www.cs.bu.edu/ftp/amass/ISCC/ Overview of Technical Program Monday Tutorials Tuesday Morning Plenary Session to be announced Tuesday Morning Traffic Management in ATM Networks Communication Theory I Routing I Wireless Networks Tuesday Mid-Day Resource Management in ATM Networks Communication Theory II =20 Network Management I Multicasting Tuesday Afternoon ATM Network Monitoring and Performance Testing=20 Algorithms for Network Design I Distributed and Parallel Processing I =20 Wireless DECT Networks Tuesday Evening Tutorials Wednesday Morning Plenary Session to be announced Wednesday Morning Congestion Control in ATM Networks Software Techniques Multimedia Applications=20 Network Mobility Wednesday Mid-Day ATM Interworking Integrated Switch Architectures I Electronic Commerce=20 Wireless CDMA Networks Wednesday Afternoon Optical Networks Integrated Switch Architectures II Routing II Wireless ATM Networks Wednesday Late Afternoon Panel Session Military versus Commercial Communications Thursday Morning Plenary Sessin to be announced Thursday Morning Scheduling and Flow Control in ATM Networks Methods and Tools for Networks Internet Networking Broadband Transport Systems Thursday Mid-Day Buffer Management in ATM Networks Digital Signal Processing Distributed and Parallel Processing II Wireless Routing Thursday Afternoon Fault Tolerance and Network Reliability Algorithms for Network Design II Network Management II=20 Cellular Wireless Networks The conference will be held at Hotel Armonia, in beautiful Vouliagmeni,=20 which is 16 km from downtown Athens (and 8 km south of Athens Airport). =46urther information is available at our website:=20 http://www.cs.bu.edu/ftp/amass/ISCC/ or from the Technical Program Co-Chairs: Prof. Hussein Mouftah Dr. Jeffrey E. Wieselthier Tel: +1 (613) 545-2934 Tel: +1 (202) 767-3043 =46ax: +1 (613) 545-6615 Fax: +1 (202) 767-1191 mouftah@eleceng.ee.queensu.ca wieselthier@itd.nrl.navy.mil From rem-conf Sun Apr 05 04:58:34 1998 From rem-conf-request@es.net Sun Apr 05 04:58:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yLnua-0005pK-00; Sun, 5 Apr 1998 04:48:32 -0700 Received: from houasc5-249.flash.net (dental.mail.dental.net) [209.30.64.249] by mail1.es.net with smtp (Exim 1.81 #2) id 0yLnuW-0005o3-00; Sun, 5 Apr 1998 04:48:28 -0700 From: Subject: $9 dental, vision & prescription drugs plan Message-Id: Bcc: Date: Sun, 5 Apr 1998 04:48:28 -0700 To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list **************************************************************** This is not unsolicited email. Your email address was routed to our "auto send" program stating that you wish to receive information about our dental, vision & prescription drug program. If your email address was referred to our "auto send" in error, please type "REMOVE" in the subject line and the "auto send" will remove your email address. **************************************************************** ******* DENTAL PLAN $9 per month for a single person $15 per month for entire household, (everyone at your house) **No waiting period, No limit on visits or services, Braces included, Cosmetic dentistry included, specialist included, pre-existing conditions are covered, No deductible, No age limit, No claim forms, You can change dentist whenever you want. ******* VISION CARE Free with $9/$15 dental plan **Over 12,000 optical providers nationwide, save up to 60%, save up to 60% on contact lenses, save up to 30% on eye exams and surgery, save up to 50% on all non-prescription sunglasses, 30 day unconditional money back guarantee, only national plan endorsed by the Opticians Association of America. ******* PRESCRIPTION DRUGS Free with $9/$15 dental plan **Over 35,000 retail pharmacy locations nationwide including most chain pharmacies and independent pharmacies, save up to 50% on prescription drugs, all prescription drugs are covered both at the retail pharmacy and by mail order. If you want to sign up for the dental program just follow the directions below. FAX the following to DENTAL PLAN. The fax number is 1-713-266-0390. DENTAL PLAN Name Address City, State, Zip code Day Phone # Night Phone # Fax Phone # Email address We are currently needing brokers for the $9/$15 Dental Plan. If you or someone you know is looking for an additional income PLEASE LET US KNOW when you fax the above information. The Dental Broker program has a nice up front pay cycle and a very good residual for as long as the person is in the dental plan. And there is no license required to be a broker. So let us know about the dental and if you know of someone wanting to be a broker. Tell them to contact us by faxing the same information. Thank you again for your interest. Cliff From rem-conf Sun Apr 05 04:58:34 1998 From rem-conf-request@es.net Sun Apr 05 04:58:32 1998 Received: from list by mail2.es.net with local (Exim 1.81 #2) id 0yLnuW-0002Hn-00; Sun, 5 Apr 1998 04:48:28 -0700 Received: from houasc5-249.flash.net (dental.mail.dental.net) [209.30.64.249] by mail2.es.net with smtp (Exim 1.81 #2) id 0yLnuU-0002Hd-00; Sun, 5 Apr 1998 04:48:26 -0700 To: From: Subject: $9 dental, vision & prescription drugs plan Message-Id: Date: Sun, 5 Apr 1998 04:48:26 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list **************************************************************** This is not unsolicited email. Your email address was routed to our "auto send" program stating that you wish to receive information about our dental, vision & prescription drug program. If your email address was referred to our "auto send" in error, please type "REMOVE" in the subject line and the "auto send" will remove your email address. **************************************************************** ******* DENTAL PLAN $9 per month for a single person $15 per month for entire household, (everyone at your house) **No waiting period, No limit on visits or services, Braces included, Cosmetic dentistry included, specialist included, pre-existing conditions are covered, No deductible, No age limit, No claim forms, You can change dentist whenever you want. ******* VISION CARE Free with $9/$15 dental plan **Over 12,000 optical providers nationwide, save up to 60%, save up to 60% on contact lenses, save up to 30% on eye exams and surgery, save up to 50% on all non-prescription sunglasses, 30 day unconditional money back guarantee, only national plan endorsed by the Opticians Association of America. ******* PRESCRIPTION DRUGS Free with $9/$15 dental plan **Over 35,000 retail pharmacy locations nationwide including most chain pharmacies and independent pharmacies, save up to 50% on prescription drugs, all prescription drugs are covered both at the retail pharmacy and by mail order. If you want to sign up for the dental program just follow the directions below. FAX the following to DENTAL PLAN. The fax number is 1-713-266-0390. DENTAL PLAN Name Address City, State, Zip code Day Phone # Night Phone # Fax Phone # Email address We are currently needing brokers for the $9/$15 Dental Plan. If you or someone you know is looking for an additional income PLEASE LET US KNOW when you fax the above information. The Dental Broker program has a nice up front pay cycle and a very good residual for as long as the person is in the dental plan. And there is no license required to be a broker. So let us know about the dental and if you know of someone wanting to be a broker. Tell them to contact us by faxing the same information. Thank you again for your interest. Cliff From rem-conf Tue Apr 07 14:06:10 1998 From rem-conf-request@es.net Tue Apr 07 14:06:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yMfB2-0006De-00; Tue, 7 Apr 1998 13:41:04 -0700 Received: from hofmann.cs.berkeley.edu [128.32.35.123] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yMfB1-0006DU-00; Tue, 7 Apr 1998 13:41:03 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by hofmann.CS.Berkeley.EDU (8.8.8/8.6.6.Beta11) with SMTP id NAA18909 for ; Tue, 7 Apr 1998 13:41:01 -0700 (PDT) Message-Id: <3.0.3.32.19980407134105.00c0b780@postgres.berkeley.edu> X-Sender: ireney@postgres.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 07 Apr 1998 13:41:05 -0700 To: rem-conf@es.net From: Irene Yam Subject: MIG Seminar, Wed. 4/8, " Cocoa: Children as Game-Makers " - Allen Cypher, Stagecast Software Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Cocoa: Children as Game-Makers (Wednesday April 8, 1998 12:30-2:00 PDT 405 Soda Hall) Allen Cypher Stagecast Software Cocoa is a program that allows children to create their own simulations and games, and to publish them on the World Wide Web. Children create characters and show them how to change and move. The characters can be made to do different things depending on what other objects are around them. I will demonstrate Cocoa and show a variety of "worlds" that children have created. I will also discuss the design and testing of Cocoa's user interface. Biography: Allen Cypher is one of the founders of Stagecast Software. He was a Senior Scientist in the Advanced Technology Group at Apple Computer for 9 years. His main interests are programming by demonstration and end-user programming -- giving all computer users capabilities that have traditionally belonged to programmers. At Apple, he was a co-creator of Cocoa(tm), a program that enables children to create their own games and simulations, and to publish them on the World Wide Web. Before Cocoa, he built a system called Eager. Eager constantly watches your actions on the computer, and when it detects a repetitive activity, it writes a program which will perform that activity for you. Allen also edited the book "Watch What I Do: Programming by Demonstration", which was published in 1993 by MIT Press. Before working at Apple, he was a consultant at IntelliCorp, helping various companies build expert systems. He received a B.A. in mathematics >from Princeton University in 1975, a Ph.D. in computer science from Yale University in 1980, and spent several years as a post-doc in cognitive science at the University of California, San Diego. -------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40PST (GMT - 8 hrs). See sd or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. ____________________________________________ Irene Yam Berkeley Multimedia Research Center (BMRC) 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: ireney@bmrc.berkeley.edu Url: http://bmrc.berkeley.edu/people/irene/ From rem-conf Wed Apr 08 10:16:18 1998 From rem-conf-request@es.net Wed Apr 08 10:16:17 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yMyLR-0004CL-00; Wed, 8 Apr 1998 10:09:05 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yMyLQ-0004C2-00; Wed, 8 Apr 1998 10:09:04 -0700 Received: from jackson.cs.ucsb.edu (almeroth@jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with SMTP id KAA08105; Wed, 8 Apr 1998 10:08:51 -0700 (PDT) Received: by jackson.cs.ucsb.edu (SMI-8.6/SMI-SVR4) id KAA21095 for ; Wed, 8 Apr 1998 10:08:48 -0700 Date: Wed, 8 Apr 1998 10:08:48 -0700 From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199804081708.KAA21095@jackson.cs.ucsb.edu> To: almeroth@cs.ucsb.edu Subject: 41st IETF on the IMJ X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (lists bcc'ed to prevent accidents). *** Announcing Availability of the 41st IETF Sessions on the IMJ I'm ready to announce that all the sessions from the 41st IETF in Los Angeles that were transmitted on the MBone are now available on the IMJ (http://imj.gatech.edu) for on-demand playback. You can schedule programs via the WWW page and start the MBone sessions via SDR (or the WWW page with a simple plug-in). For additional information about the MBone see http://mbone.com. The big challenge this time around was to digitally record all of the sessions. That went almost flawlessly. A big thanks go to Evi Nemeth and the MBone support staff for helping out. Now, instead of having to convert everything from VHS tape to rtpdump format we were able to record everything straight to rtpdump format. The one interesting challenge is that I don't want to replay all the RTCP data in those files... well, because those people and their reported losses, etc. aren't really part of the session. I modified the rtpplay script to not play back any RTCP from the file but this also includes RTCP packets about the source... so the IMJ source does not resolve to a name. A subtle artifact, but something to work on for next time. For the record, the plan is to have the last 3 sets of IETF meetings archived on the MBone. We've got three now so the 38th IETF will disappear after Chicago. Future plans in regard to content include making talks from conferences available as well. I'm working on some angles here. Also, A NEW SERVICE has been started for those who want access to the source files themselves. The latest batch of IETF files are available at ftp://www.cc.gatech.edu/pub/people/kevin/. Please be gentle on the ftp server since these files are around 100 MB for video and 40 MB for audio. Finally, and as usual, I've included the original IMJ e-mail announcement for those who want additional information about the IMJ. Any suggestions for improvement are welcome. -Kevin **** Announcing the Interactive Multimedia Jukebox At one point on the MBone list there was a discussion of what on-demand servers exist or are being developed. Well, I'd like to announce our version called the Interactive Multimedia Jukebox (IMJ). The IMJ web page is a request and scheduling interface for the playout of content over the MBone. CONTENT IS ENCODED SO THAT IT CAN BE RECEIVED WITH THE LATEST VERSIONS OF VIC AND VAT (ANY PLATFORM). Also check out PicPat (http://www.cc.gatech.edu/fac/Mostafa.Ammar/picpat/), a new MBone pause/play tool for real-time broadcasts. The IMJ page is located at http://imj.gatech.edu. Information about the IMJ including general info, a postscript version of a paper about the IMJ, how-to-use information, and how it was implemented can be found at http://www.cc.gatech.edu/computing/Telecomm/IMJ/. (Recent note: the paper will be appearing in the WWW7 conference in Brisbane, Australia) Some quick additional information about the IMJ is included below: IMJ Audio/Video ----------------- The IMJ uses the WWW to submit requests which are then scheduled for playout on the MBone. Right now we are offering three channels: Channels 1 and 2 are being broadcast at a TTL of 127. Channel 3 is for internal testing and has a a TTL of 15. Each channel provides DVI-2 audio and 128 Kbps H.261 video. The encoding was done using Henning Schulzrinne's rtpplay and rtpdump. Scheduling ---------- Program scheduling uses a set of criteria to decide on which channel to schedule a program. The current set of criteria are listed just below the interactive schedule. We are exploring lots of different options. Content ------- We have been working on the jukebox paradigm with Turner Broadcasting, and as a result of their interest they have agreed to let us broadcast content on the MBone. I am particularly excited about this aspect because of their help and interest in investigating new applications on the Internet. The plan is to add a new set of content about every two weeks. When this happens, the old content will be moved to the secondary request menu for two weeks. The old-old stuff will be removed. Hopefully I'll be able to advertise on the MBone list when the new stuff is available. Development Platform -------------------- As is mentioned in the paper on the IMJ information page we are using the IMJ as a platform for a variety of research issues including providing interactivity, supporting multiple heterogeneous streams, video server organization, tracking usage, program scheduling, and pricing. Acknowledgments ---------------- In addition to Turner Broadcasting, several other groups have made the IMJ possible. The GT Broadband Telecommunications Center sponsored much of the research and some of the equipment, and GT Office of Information Technology offered technical assistance and additional equipment. Please send any feedback or suggestions to almeroth@cs.ucsb.edu or kevin@cc.gatech.edu. From rem-conf Wed Apr 08 10:52:44 1998 From rem-conf-request@es.net Wed Apr 08 10:52:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yMyy5-0004tx-00; Wed, 8 Apr 1998 10:49:01 -0700 Received: from golden.net [199.166.210.183] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yMyy4-0004tn-00; Wed, 8 Apr 1998 10:49:00 -0700 Received: from AS52-19-163.cas-kitchener.golden.net (AS52-19-163.cas-kitchener.golden.net [209.183.131.163]) by golden.net (8.8.5/8.6.12) with SMTP id NAA13888 for ; Wed, 8 Apr 1998 13:48:57 -0400 (EDT) Received: by AS52-19-163.cas-kitchener.golden.net with Microsoft Mail id <01BD62F5.07A056E0@AS52-19-163.cas-kitchener.golden.net>; Wed, 8 Apr 1998 13:48:37 -0400 Message-ID: <01BD62F5.07A056E0@AS52-19-163.cas-kitchener.golden.net> From: Paul Reader To: "'rem-conf@es.net'" Subject: ISPs in Ontario Date: Wed, 8 Apr 1998 13:48:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Can anyone provide or point me to an updated list of ISPs that provide = MBone connectivity in Ontario? I am aware that Onet in Toronto is one = option. Paul Reader Consultant & Project Manager Relay Information Solutions [mailto:paul@wisys.com ] paul@wisys.com From rem-conf Wed Apr 08 14:55:19 1998 From rem-conf-request@es.net Wed Apr 08 14:55:18 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yN2d7-00072f-00; Wed, 8 Apr 1998 14:43:37 -0700 Received: from mercury.star.com.au [203.0.171.126] by mail1.es.net with smtp (Exim 1.81 #2) id 0yN2d5-00072A-00; Wed, 8 Apr 1998 14:43:35 -0700 Received: by star.com.au; id AA24615; Thu, 9 Apr 1998 07:38:44 +1000 Message-Id: From: Shane Rowatt To: "'rem-conf@es.net'" Subject: ISPs in Australia Date: Thu, 9 Apr 1998 07:41:39 +1000 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Can anyone provide or point me to an updated list of ISPs that provide > MBone connectivity in Australia? > > ____________ SHANE ROWATT ____________ CONSULTANT PROGRAMMER mailto:shane.rowatt@star.com.au Star Systems Pty Ltd 5 CRIBB STREET, MILTON QLD 4064 P.O. BOX 1511, MILTON QLD 4064 PHONE 617 3331 5555 FAX 617 3367 0181 http://www.star.com.au The views, opinions and information expressed and/or contained herein do not necessarily reflect the opinions or views of Star Systems Pty Ltd, or the organisation/s through which this communication was transmitted or any third party, unless explicitly stated so. From rem-conf Wed Apr 08 17:34:18 1998 From rem-conf-request@es.net Wed Apr 08 17:34:17 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yN5DE-0000aa-00; Wed, 8 Apr 1998 17:29:04 -0700 Received: from (goanna.cs.rmit.edu.au) [131.170.24.40] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yN5DC-0000aQ-00; Wed, 8 Apr 1998 17:29:03 -0700 Received: from goanna (zahirt@localhost [127.0.0.1]) by goanna.cs.rmit.edu.au (8.8.6/8.8.6) with SMTP id KAA08874; Thu, 9 Apr 1998 10:14:04 +1000 (EST) Sender: zahirt@cs.rmit.edu.au Message-ID: <352C12CC.1A0A@cs.rmit.edu.au> Date: Thu, 09 Apr 1998 10:14:04 +1000 From: Dr Zahir Tari Organization: Royal Melbourne Institute of Technology X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ab@omg.org, adtf@omg.org, bomsig@omg.org, dtc@omg.org, mof@omg.org, ptc@omg.org, tc@omg.org, uml-rtf@omg.org, mof-rtf@omg.org, dasig@dsto.defence.gov.au, acl@research.att.com, announce-itri@itri.brighton.ac.uk, bcs-hci@mailbase.ac.uk, ccl@dfki.uni-sb.de, cg@cs.umn.edu, colibri@let.ruu.nl, comp-phon@cogsci.ed.ac.uk, comp.at.nat-lang@ucbvax.berkeley.edu, connectionists@cs.cmu.edu, corpora@hd.uib.no, cscw-sig@mailbase.ac.uk, daarc@lists.lancs.ac.uk, diagrams@cs.swarthmore.edu, dl@dl.kr.org, ecran@thomson-lcr.fr, ectl-sub@snowhite.cis.uoguelph.ca, elsnet-list@cogsci.ed.ac.uk, elsnet-list@let.ruu.nl, fj-ai@etl.go.jp, humanist@brownvm.brown.edu, ikbsbb@inf.rl.ac.uk, jqrqc@cunyvm.cuny.edu, kr-postings@kr.org, lexical@nmsu.edu, life-users@cs.sfu.ca, linguistics@atom.brl.ntt.jp, nlp@dcs.shef.ac.uk, royfcoch@clark.net, rtss97@cs.unc.edu, rtas@cs.pitt.edu, enternet@bbn.com, tccc@cs.umass.edu, end2end-interest@isi.edu, f-troup@CODEX.CIS.upenn.edu, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@tadpole.com, cellular@comnets.rwth-aachen.de, ieeetcpc@ccvm.sunysb.edu, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, multicomm@cc.bellcore.com, kaw@swi.psy.uva.nl, ag-exp-l@vm1.nodak.edu, srkb@cs.umbc.edu, ontology@cs.umbc.edu, vki-list@dfki.uni-sb.de, ckbs-int@cs.keele.ac.uk, ml-net@swi.psy.uva.nl, odp@dstc.edu.au, chest-image@mailbase.ac.uk, image-group@mailbase.ac.uk, ir@mailbase.ac.uk, agog-mm@mailbase.ac.uk, seworld@cs.colorado.edu, cpet@cdr.stanford.edu, CAT@cdr.stanford.edu, agents@cs.umbc.edu, hazeyama@ccs.mt.nec.co.jp, c-hirai@sdl.hitachi.co.jp, cleidson@dcc.unicamp.br, Gerome.Canals@loria.fr, jameson@realcase.com, mikio@iee.niit.ac.jp, roesch@iese.fhg.de, roseanne@cs.umd.edu, rfink@oscsystems.com, sdkim@computing.soongsil.ac.kr, teshima@agusa.nuie.nagoya-u.ac.jp, konno@sdl.hitachi.co.jp, yun@deakin.edu.au, yutaka@sdl.hitachi.co.jp Subject: CFP - IFIP Conf. on "Multimedia Systems" Content-Type: text/plain; charset=us-ascii; name="cfp.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cfp.txt" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [WE APOLOGIZE IF YOU RECEIVE MULTIPLE COPIES] .--. ,--. .---. Data Semantics - 8 (DS-8): | | | | | "Semantic Issues in Multimedia Systems" | | `--. >--< IFIP TC-2 Working Conference, organized by | | | | | Working Group 2.6 (Database) ---' `---' `---' Rotorua, New Zealand, 5-8 January 1999 (http://zulu.cs.rmit.edu.au/~ds8) SCOPE ----- Multimedia technology has been capturing the popular imagination in recent times. It is clear that the success of multimedia systems is going to be dependent not only on the technology of these systems but also on the quality of the underlying databases and supporting processes. To date insufficient attention has been focussed on such issues. Whilst database studies have achieved considerable success in the wider market place, the main effort has been on tools and techniques for high volume but fairly simplistic record management. These modern advanced multimedia systems require a paradigm shift to allow the representation and manipulation of complex text, image, audio and video information. This requires the development of complex methodologies environments and tools to allow one to easily understand the underlying structure to facilitate access manipulation and modification of such information. An essential characteristic to gain understanding is a clearly defined semantics for multimedia databases. Multimedia objects are now considered unavoidable key features of such future database applications. Multimedia database technology involves the integration of different existing technologies, including classical databases, distributed computing, multimedia, and mobile computing. Therefore in this eighth Data Semantics Working Conference the focus is on those issues of multimedia systems that involve the semantics of the information represented, stored and manipulated by multimedia systems. This includes methodologies for application domain modelling, formal representations of multimedia aspects of knowledge, the role of semantics in data models, etc. but also issues in user interfacing, architectures that better enable integrity, consistency, interoperation reuse of multimedia systems, or reports on prototypes illustrating new aspects of such systems from a semantically relevant viewpoint. The purpose of the DS-8 international IFIP Working Conference, as its predecessors since 1985, is to provide an active forum for researchers and practitioners for presentation and exchange of research results and practical management of databases, this time applied to systems containing multimedia information. By organising this conference, we want to encourage researchers and practitioners to submit original contributions and case studies that elucidate semantic issues. TOPICS ------ The topics of interest include, but are not limited to: . Data modelling and query languages for databases media such as audio, video, computer image . Semantic foundations for multimedia and hypermedia . Methodological aspects of multimedia database design . Information retrieval, knowledge discovery, and data mining . Temporal and spatial issues in multimedia databases . Semantic issues in standardisation . Interoperability of multimedia databases . Relationships with high-level domain modelling approaches . Multimedia user interfaces . Industrial application challenges for multimedia databases Authors are invited to submit contributions that are directly relevant to these issues. Four copies of the submission (from 6000 to 8000 words, not including abstract and references) should be sent to Zahir Tari (DS-8 Working Conference) Royal Melbourne Institute of Technology Dept. of Computer Science Bundoora East Campus, Plenty Rd. VIC 3083, Australia (ph): +61-3-9407-6125 (fax): +61-3-9407-6139 Each copy should have a cover page with the name, title, and address (including e-mail address) of authors, and an abstract of no more than 200 words. Electronic or fax submissions will not be accepted. The proceedings will be published as a book by Chapman & Hall. Proposals for panels should include a one-page description of the subject matter and should be submitted electronically to Prof. Robert Meersman (meersman@vub.ac.be). FORMAT ------ The DS-8 conference, following the tested format of the previous successful Data Semantics conferences, will be a five-day live-in conference with limited attendance, including tutorials, keynotes stimulating discussion, and single-stream presentation of research and industrial papers. The conference will start with one day of tutorials and will continue with four days of technical presentations. Several panel discussions are planned during the conference. Special sessions will also be held which address the development of multimedia database systems and new applications and use of multimedia database systems in industry. A highlight of the event will be three invited talks by the leading figures in multimedia systems - Prof. Ramesh Jain (University of California at San Diego, USA) - Prof. Hermann Maurer (University of Graz, Austria) - Prof. Masao Sakauchi (Tokyo University, Japan), and DATES ----- June 30, 1998: Deadline for arrival of submissions August 28, 1998: Notification of acceptance September 30, 1998: Camera ready for final version to be published by Chapman & Hall January 5--8, 1999: Conference ORGANISATION ------------ CONFERENCE CHAIR Tharam Dillon Dept. of Computer Science and Computer Engineering LaTrobe University, Bundoora VIC 3083 Australia (Fax) +61 3 9479 3060 (E-mail) tharam@latcs1.cs.latrobe.edu.au PROGRAM CO-CHAIRS (Europe) Robert Meersman Dept. of Computer Science VUB, Building F-G 10, Pleinlaan 2 B-1050 Brussels, Belgium meersman@vub.ac.be (Far-East Asia) Zahir Tari Dept. of Computer Science RMIT, Bundoora East Campus Plenty Rd, VIC 3083 Australia zahirt@cs.rmit.edu.au (America) Scott Stevens School of Computer Science Carnegie Mellon Univ. Wean Hall, Pittsburgh PA 15213 USA sms@cs.cmu.edu TUTORIAL CHAIR Omran Bukhres Purdue University Computer Science Department 723 W. Michigan St. SL 280, Indianapolis Indiana 46202 bukhres@cs.iupui.edu ORGANISING CHAIR Justo Diaz Dept. of Management Science and Information Systems University of Auckland Private Bag 92019 New Zealand (Fax) +64-9-373- 7430 j.diaz@auckland.ac.nz PUBLICITY CHAIR Arkady Zaslavsky Monash University School of Computer Science and Software Engineering 900 Dandenong Road, Caulfield East, Vic 3145, Australia A.Zaslavsky@monash.edu.au PROGRAM COMMITTEE Amr El Abbadi (UC Santa Barbara, USA) Rakesh Agrawal (IBM San Jose, USA) Peter Apers (Univ. of Twente, Netherland) Elisa Bertino (Univ. of Milano, Italy) Tiziana Catarci (Univ. of Rome, Italy) Elizabeth Chang (LaTrobe Univ., Australia) Stavros Christodoulakis (Univ. of Crete, Greece) Michael Christel (Carnegie Mellon Univ., USA) Alex Delis (Polytechnic Univ., USA) Simon Gibbs (GMD-VMSD, Germany) Forouzan Golshani (Arizona Univ., USA) William Grosky (Wayne St. Univ., USA) Tadao Ichikawa (Hiroshima Univ., Japan) Ramesh Jain (UCSD, USA) Moon Kim (Konkuk Univ., Korea) Roger King (Univ. of Colorado, USA) Wolfgang Klas (Univ. of Ulm, Germany) Peiya Liu (Siemens Corporate Research, USA) Jim McGovern (RMIT, Australia) Erich Neuhold (GMD-IPSI, Germany) Tamer Ozsu (Univ. of Alberta, Canada) Mike Papazoglou (Tilburg Univ., Netherland) Edwige Pissaloux (Univ. of Rouen, France) Calton Pu (Oregon Graduate Inst., USA) Ron Sacks-Davis (RMIT, Australia) Hanan Samet (Univ. of Maryland, USA) Timos Sellis (National Technical Univ., Greece) Amit Sheth (Univ. of Georgia, USA) Stefano Spaccapietra (EPFL, Switzerland) V.S. Subrahmanian (Univ. of Maryland, USA) Makota Takizawa (Tokyo Denki Univ., Japan) A Min Tjoa (Vienna Univ. of Techn., Austria) Michalis Vazirgiannis (Nat. Univ. of Athens, Greece) Gerhard Weikum (Univ. of Saarland, Germany) OTHER DETAILS ------------- VENUE Rotorua is the world famous hot springs area of New Zealand, with geysers, mineral springs, mud pools, and volcanoes. It is a unique opportunity to visit this extraordinary tourist attraction during the summer of the southern hemisphere. It is timed to be a welcome relief from the winter of the northern hemisphere. Rotorua is a scenic two hour drive from Auckland. ACCOMMODATION It is in the hotel that overlooks Thermal Geyserland and is relatively cheap. (around US$70 per night including breakfast). SECRETARIAT We will be happy to answer any question and provide you with additional information about the conference. Please contact: Sue Labe Dept. of Computer Science and Computer Engineering LaTrobe University, Bundoora VIC 3083 Australia (phone) +61 3 9479 2598 (fax) +61 3 9479 3060 (e-mail) sue@cs.latrobe.edu.au More information about the conference and about IFIP WG2.6 can be found at URL: http://www.informatik.uni-ulm.de/dbis/IFIP-WG2.6. From rem-conf Wed Apr 08 23:22:51 1998 From rem-conf-request@es.net Wed Apr 08 23:22:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yNAeE-0002Um-00; Wed, 8 Apr 1998 23:17:18 -0700 Received: from sirius.ctr.columbia.edu [128.59.64.60] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yNAeC-0002Uc-00; Wed, 8 Apr 1998 23:17:16 -0700 Received: from comet.columbia.edu (argo.comet.columbia.edu [128.59.68.36]) by sirius.ctr.columbia.edu (8.8.7/8.6.4.287) with ESMTP id CAA21253; Thu, 9 Apr 1998 02:16:59 -0400 (EDT) Received: from localhost (mk@localhost) by comet.columbia.edu (8.8.7/8.8.7/COMET) with SMTP id CAA10618; Thu, 9 Apr 1998 02:16:58 -0400 (EDT) X-Authentication-Warning: argo.comet.columbia.edu: mk owned process doing -bs Date: Thu, 9 Apr 1998 02:16:58 -0400 (EDT) From: Michael Kounavis To: rem-conf@es.net cc: mnl@comet.columbia.edu Subject: MBone Broadcast Announcement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement Title: Applying Packet Technology to Cellular Radio Speaker: Nicholas F. Maxemchuk AT&T Laboratories Date: Thursday, Apr. 09, 1998 Time: 11:00 AM - 13:00 AM EST Multicast Address: audio: DVI, RTP, 224.2.172.100/23518 , ttl=127 Contact: Michael E. Kounavis URL: http://comet.ctr.columbia.edu/activities/seminars/ Place: Multimedia Network Laboratory 8LE1 Schapiro Research Building Center for Telecommunications Research Columbia University New York City, USA Abstract: The cell size in mobile networks is decreasing to accommodate more users in the same bandwidth. Smaller cell sizes increase the number of hand offs between cells and the probability of encountering a cell with more users than the bandwidth can accommodate. In this presentation I will describe packet techniques that reduce both the work that is performed in a hand off and the probability of losing a connection in an over populated cell. In order to obtain these advantages, the mobile network must consist of both a wired and wireless segment and different packet techniques must be used for the inbound and outbound traffic on each of these segments. Packet techniques are also used to construct a single control channel that mobile units can use independent of their location. The network we consider is primarily designed to connect mobile units to the current communications infrastructure. This constraint makes it possible to reduce the bandwidth and simplify the operation of the access protocol in a cell. The access protocol is a modified version of MSTDM, which is a variant of CSMA/CD. This protocol provides very stringent quality of service guarantees for voice within the framework of Ethernet access technologies. By using a two frequency approach, that was originally applied to CATV networks, the area between cells that can reuse a frequency is reduced by a factor of four below the CSMA approach that is used in military packet radio networks. By reducing the quality of service slightly, the bandwidth that is required is cut by an additional factor of two below a TASI system on the CATV network. The packet techniques make it possible to use overlapping service areas to perform soft hand offs between cells and redistribute the number of mobile units that are assigned to overcrowded cells. When overloads do occur, it is possible to reduce the QoS to specific users, in a controlled manner, rather than denying service to any users. ----------------------------------------------------------------------- Michael E. Kounavis e-mail : mk@comet.columbia.edu Room 801, CEPSR www : http://www.comet.columbia.edu/~mk/ Columbia University office : (212) 854-6900 New York, NY 10025 lab : (212) 854-5599 ----------------------------------------------------------------------- From rem-conf Thu Apr 09 09:08:20 1998 From rem-conf-request@es.net Thu Apr 09 09:08:19 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yNJlL-0005zv-00; Thu, 9 Apr 1998 09:01:15 -0700 Received: from gkb.gic.ch (mail.gic.ch) [194.235.1.10] by mail1.es.net with smtp (Exim 1.81 #2) id 0yNJlH-0005zT-00; Thu, 9 Apr 1998 09:01:14 -0700 Received: from gkb [194.235.1.10] by mail.gic.ch (SMTPD32-4.03) id A06FC4D0128; Thu, 09 Apr 1998 17:59:43 +03d00 From: GIC To: Date: Thu, 09 Apr 1998 15:59:42 "GMT" X-MSMail-Priority: Normal X-mailer: AspMail 2.4 (SMTP669585) Subject: GKB FREE SERVICES UPDATE (4/98) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Update on Global KnowledgeBase (http://gkb.com) free internet services. (4/98) Dear gkb user, Thanks to you, our campaign for Global KnowledgeBase (http://gkb.com) is continues to be a great success attracting more than 4000 unique users/daily. Continue to Explore and Contribute to create the accumulated knowledge in gkb.com, for the benefit of all. To login to the GKB applications please use the gkb login as follows: Your login ID : rem-conf@es.net GKB User Code : 3342 New features ============ Global Journal - The newest and most dynamic meduim to exchange internet knowledge, in Global Journal, you, the GKB user, have the opportunity to express your opinion, provide newsworthy internet links, or cite facts. GlobalShop - best source of information on over 60,000 products listed, giving direct access to the price lists of the best known, compare prices, look for new models and benefit from special offers. Build your e-commerce, integrate your own catalog in Global Shop for free. Global Free - Explore and Contribute to the free Internet services knowledgebase Web messaging - if you have an email address @gkb.com (which is free), explore your Email directly on the web. Personal&Email KB - If you are looking for users sharing the your area of interests, or simply email of users in your area. GlobalChat - web based chat for all The old and successful free features are always there. ===================================================== Interactive Classifieds - Free interactive classifieds segmented by marketplace and criteria (more than 8000 ads in Geneva area only) Press Releases - Free press release publication. Business Guide - Free business internet site application GlobalJob - Free job listing for companies, and free CV listing for individuals. Business Opportunities - Free business opporrtunities publication by marketplace/industry Free email addresses at gkb.com are always available. Global Finance - gkb financial knowledgebase Global Events - free events listing in the events knowledgeBase We hope you will find the new and old feature useful. Regards Gkb team From rem-conf Thu Apr 09 13:59:33 1998 From rem-conf-request@es.net Thu Apr 09 13:59:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yNOJW-0000ZP-00; Thu, 9 Apr 1998 13:52:50 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yNOJU-0000ZF-00; Thu, 9 Apr 1998 13:52:49 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.7/8.8.7) with SMTP id QAA06180; Thu, 9 Apr 1998 16:52:47 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id QAA00801; Thu, 9 Apr 1998 16:49:11 -0400 Date: Thu, 9 Apr 1998 16:49:11 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199804092049.QAA00801@billings.csb> To: mbone@isi.edu, rem-conf@es.net Subject: problem with vic 2.8 under Solari s2.6 on Ultra 2 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Netizens, I'm experiencing an odd problem on my Ultra 2/200 under Solaris 2.6 when I try to run vic 2.8 in unicast mode. I select the sunvideo card as the Device, throttle down the bandwidth, and as soon as I hit "Transmit," the tool blows up with the following message in the window from which it was invoked: /opt/SUNWits/Graphics-sw/xil/lib/pipelines/xilSUNWrtvc_ucode.a: No such file or directory now .../xilSUNWrtvc_ucode.a is present, so I assume that it is complaining about something it can not find. The only patch I've installed thus far is 105795-01, which supposedly fixes a problem with the hme0 interface. The patch has no effect on the problem I've described here. Anyone else having this problem? Any suggestions? Thanks in advance... Cheerio, Rick Rodgers From rem-conf Thu Apr 09 14:10:39 1998 From rem-conf-request@es.net Thu Apr 09 14:10:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yNOXf-0000zY-00; Thu, 9 Apr 1998 14:07:27 -0700 Received: from basil.cdt.luth.se [130.240.64.67] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yNOXe-0000zK-00; Thu, 9 Apr 1998 14:07:26 -0700 Received: from salt (peppar@salt.cdt.luth.se [130.240.194.242]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id XAA18344; Thu, 9 Apr 1998 23:07:18 +0200 (MET DST) Message-Id: <199804092107.XAA18344@basil.cdt.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 To: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) cc: mbone@isi.edu, rem-conf@es.net Subject: Re: problem with vic 2.8 under Solari s2.6 on Ultra 2 In-reply-to: Your message of "Thu, 09 Apr 1998 16:49:11 EDT." <199804092049.QAA00801@billings.csb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Apr 1998 23:07:17 +0200 From: Peter Parnes X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, This should solve your problem: # mkdir /opt/SUNWits/Graphics-sw/xil/lib/pipelines/ # ln -s /usr/openwin/lib/xil/devhandlers/xilIO_SUNWrtvc_ucode.a /opt/SUNWits/Graphics-sw/xil/lib/pipelines/xilSUNWrtvc_ucode.a /P From rem-conf Fri Apr 10 00:38:32 1998 From rem-conf-request@es.net Fri Apr 10 00:38:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yNYAh-0004AV-00; Fri, 10 Apr 1998 00:24:23 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yNYAg-0004AF-00; Fri, 10 Apr 1998 00:24:22 -0700 Received: from revelstoke.precept.com (port6.precept.com [204.162.119.56]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id AAA10531; Fri, 10 Apr 1998 00:23:20 -0700 (PDT) Date: Fri, 10 Apr 1998 00:25:05 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Summary of AVT meeting at IETF41 in LA Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Here is a short summary of the AVT meeting last week in Los Angeles. Full minutes yet to come. The AVT working group met for two very full sessions. The group agreed that WG last call should be issued on the drafts for "Options for Repair of Streaming Media" and H.263+ payload format, though it is not entirely clear if the latter should obsolete the earlier H.263 payload format in RFC 2190. The biggest topic was a continuation of the discussion that began at the previous IETF regarding a generic payload format for the hundreds of existing codecs. Two proposals were presented and several refinements and enhancements were suggested in the discussion that followed. The authors of the two proposals agreed to work together to produce one merged proposal also incorporating the ideas from the discussion. Two presentations were also given on an RTP payload format and RTCP usage for MPEG4. There are a number of questions still to be resolved regarding conflicts between the RTP and MPEG4 architectures; these are to be discussed further on the mailing list. Three topics from the mailing list were discussed: 1) a request was made for a means to add application-specific extensions to the RTCP RR packet, but the sentiment was that a new RTCP packet type should be used instead; 2) there were a number of suggestions for redefining the interval over which the RTCP RR "loss fraction" is calculated, but not a consensus for changing it; and 3) it was agreed that the RTP Profile draft should be revised to say no more static payload types would be assigned, but in the meantime a request for an assignment for Qclp should be allowed. A revision of the generic FEC payload format draft was favorably received given one or two small changes. However, a proposal that RTP should be defined as its own IP protocol received a primarily negative response due to concerns about interoperability problems. The following presentation slides are available: http://www.cs.ucl.ac.uk/staff/c.perkins/slides/IETF-LA.ps.gz http://drogo.cselt.it/mpeg/documents/dmif-avt.zip ftp://hydra.precept.com/pub/rtp/ietf41-avt-casner.ppt ftp://hydra.precept.com/pub/rtp/ietf41-avt-periyannan.ps -- Steve From rem-conf Fri Apr 10 11:30:49 1998 From rem-conf-request@es.net Fri Apr 10 11:30:49 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yNiSY-0007TK-00; Fri, 10 Apr 1998 11:23:30 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yNiSX-0007S2-00; Fri, 10 Apr 1998 11:23:29 -0700 Received: from oak.precept.com (oak.precept.com [204.162.116.21]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id LAA18094; Fri, 10 Apr 1998 11:22:28 -0700 (PDT) Date: Fri, 10 Apr 1998 11:22:44 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: AVT WG last call on two drafts Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: As agreed at the IETF meeting last week, I'm issuing "working group last call for comments" on two drafts: "Options for Repair of Streaming Media" draft-ietf-avt-info-repair-03.txt Informational RFC "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)" draft-ietf-avt-rtp-h263-video-01.txt Proposed Standard RFC If there are no unresolvable concerns raised in the next two weeks, then I will request IESG Last Call. Regarding the H.263 draft, I have two issues to mention myself which I expect can be addressed along with any others made in this last call: 1. The draft says that rounding may be required in the calculation of RTP timestamps, but I believe that should not be true. (We chose the 90kHz clock rate precisely because we wanted the calculations to be exact for all reasonable frame rates.) In separate discussions, the authors have already agreed to fix this. 2. As we discussed in the meeting last week, putting forth this draft as a Proposed Standard calls into question the status of RFC 2190, "RTP Payload Format for H.263 Video Streams", which is based on the 1996 version of H.263. In my opinion, the right thing to do is to let both stand, and just distinguish the new draft as corresponding to the 1998 version of H.263. The title already mentions this. Rather than marking the new RFC as obsoleting 2190, it should have a paragraph explaining its relationship to 2190. This paragraph might say that the 2190 format continues to be used by existing implementations, and may be required for backward compatibility in new implementations, but that implementations using the new features of 1988 H.263 need to use the format of the new payload format. The only question is whether the IESG or RFC editor will have any concerns about advancing 2190 beyond Proposed Standard. I will ask our Area Directors for an opinion. I recall statements that the ITU would have a problem if 2190 were to be reclassified as Historical. In any case, static payload type 34, which is assigned to the RFC 2190 payload format, will NOT be reassigned to the new H.263+ format. The new format will use a dynamic payload type. Comments on this issue are welcome. -- Steve From rem-conf Fri Apr 10 13:37:13 1998 From rem-conf-request@es.net Fri Apr 10 13:37:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yNkSv-0000rU-00; Fri, 10 Apr 1998 13:32:01 -0700 Received: from hofmann.cs.berkeley.edu [128.32.35.123] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yNkSu-0000rK-00; Fri, 10 Apr 1998 13:32:00 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by hofmann.CS.Berkeley.EDU (8.8.8/8.6.6.Beta11) with SMTP id NAA11168; Fri, 10 Apr 1998 13:31:59 -0700 (PDT) Message-Id: <3.0.3.32.19980410133205.00b3ad80@postgres.berkeley.edu> X-Sender: ireney@postgres.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 10 Apr 1998 13:32:05 -0700 To: rem-conf@es.net, 298-list@bmrc.Berkeley.EDU From: Irene Yam Subject: Reminder: UCB MIG Seminar 4/15/98 "Models of Human Motion: Tracking, Learning, and Animating People " Chris Bregler, UC Berkeley Cc: ireney@cs.Berkeley.EDU Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Models of Human Motion: Tracking, Learning, and Animating People PhD Dissertation Talk (Wednesday April 15, 1998 12:30-2:00 PDT 405 Soda Hall) Chris Bregler U.C. Berkeley Modeling, analysis, and animation of people has many potential applications. Examples are new paradigms in human computer interaction, visual surveillance, video database annotation, graphics, and special effects. In almost all interesting scenarios the subjects are in motion. During talking, complex configurations and subtle lip motions are generated. During gesturing, walking, and other actions, coarse articulated limb and body movements are generated. Depending on the kind of motion and application, different abstractions and resolutions are required. Some motions are very constrained, like speaking lips or walk styles; these can be learned from data. Other actions only satisfy very general constraints. Such constraints can be coded a-priori. Recognition tasks require extracting and modeling only a few discriminating features. Animation tasks require capturing every subtle detail. The core techniques that we developed for this domain include linear subspace and nonlinear mixture models applied to learning of shape and dynamics, Hidden Markov Models for classification of visual phonetic units and gait categories, and articulated body motion estimation techniques based on product of exponential maps and twist representations. The talk will survey these techniques and their application to automatic lip-reading, photo-realistic facial animation (Video Rewrite), gait classification, and 3D articulated motion capture. The main focus will be the description of the new kinematic tracking technique, its mathematical foundation, and its application to capturing and animating the famous photo-plate sequences of Edweard Muybridge from the last century. This work was done at U.C. Berkeley, ICSI, and Interval Research jointly with Jitendra Malik, Jerome Feldman, Steve Omohundro, Yochai Konig, Michele Covell, and Malcolm Slaney. -------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40PST (GMT - 8 hrs). See sd or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. ____________________________________________ Irene Yam Berkeley Multimedia Research Center (BMRC) 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: ireney@bmrc.berkeley.edu Url: http://bmrc.berkeley.edu/people/irene/ From rem-conf Fri Apr 10 22:35:01 1998 From rem-conf-request@es.net Fri Apr 10 22:35:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yNso2-0002vk-00; Fri, 10 Apr 1998 22:26:22 -0700 Received: from isb.worldwerx.com.pk [194.133.48.216] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yNsnz-0002va-00; Fri, 10 Apr 1998 22:26:20 -0700 Received: from riqbal (pc34.isb.worldwerx.com.pk [192.168.5.34]) by isb.worldwerx.com.pk (8.8.8/8.8.5) with SMTP id KAA23587; Sat, 11 Apr 1998 10:24:57 +0500 Message-Id: <199804110524.KAA23587@isb.worldwerx.com.pk> Comments: Authenticated sender is From: "Rashed Iqbal" Organization: Worldwerx, Islamabad To: Stephen Casner Date: Sat, 11 Apr 1998 10:28:50 PKT MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: AVT WG last call on two drafts CC: rem-conf@es.net X-Confirm-Reading-To: "Rashed Iqbal" Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v2.54) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Steve, AVT WG, > 2. As we discussed in the meeting last week, putting forth this draft > as a Proposed Standard calls into question the status of RFC 2190, > "RTP Payload Format for H.263 Video Streams", which is based on > the 1996 version of H.263. > > In my opinion, the right thing to do is to let both stand, and > just distinguish the new draft as corresponding to the 1998 > version of H.263. The title already mentions this. Rather than > marking the new RFC as obsoleting 2190, it should have a paragraph > explaining its relationship to 2190. This paragraph might say > that the 2190 format continues to be used by existing > implementations, and may be required for backward compatibility in > new implementations, but that implementations using the new > features of 1988 H.263 need to use the format of the new payload > format. I understand that the 1998 version of H.263 has improved the functionality of this ITU-T video codec greatly. However, still it is H.263 video codec and decoder of this newer version must be able to decode bitstream of the earlier versions. Similarly, encoder of the newer version should be able to generate a bitstream that is decodable by the decoder of the older version. This ensure complete inter-operability between these version possibly after some negotiations (for example using H.245). Steve, therefore, I fully support the idea to keep 2190 instead of obsoleting it in additon to he newer one. Otherwise, interoperability between newer and existing codec may be hampered. Nevertheless, in my (personal) view, it will take some good time before H.263 Version 1998 dominates!! Rashed Dr. Rashed Iqbal Networked Multimedia Systems WorldWerx (pvt) Ltd. H. 326, St. 15, F-10/2, Islamabad, PAKISTAN Phone:92-51-282192 Fax: 92-51-282192 From rem-conf Sat Apr 11 04:04:17 1998 From rem-conf-request@es.net Sat Apr 11 04:04:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yNxxG-0004Hd-00; Sat, 11 Apr 1998 03:56:14 -0700 Received: from mr.tuwien.ac.at [128.130.2.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yNxxF-0004HF-00; Sat, 11 Apr 1998 03:56:13 -0700 Received: from logo (actually logo.ikn.tuwien.ac.at) by mr.tuwien.ac.at with SMTP (PP); Sat, 11 Apr 1998 12:55:03 +0200 Message-Id: <3.0.3.32.19980411124759.009f12e0@mail.zserv.tuwien.ac.at> X-Sender: vanas@mail.zserv.tuwien.ac.at X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 11 Apr 1998 12:47:59 +0200 To: rem-conf@es.net From: "Harmen R. van As" Subject: 8th IFIP Conference on High Performance Networking (HPN'98) Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear member of the Internet Audio/Video Transport community We still are looking for some papers for the HPN'98 Conference in Vienna. Would there be any change that you or somebody else would be able to submit a contribution within the next two weeks? Please notify coming submission With best regards Harmen R. van As
CALL FOR TUTORIALS CALL FOR PAPERS DEADLINE EXTENDED BUT NOTIFY COMING SUBMISSION ----------------------------------------------------------- 8th IFIP Conference on High Performance Networking (HPN'98) The Millennium Push of Internet =20 Vienna University of Technology, Vienna, Austria September 21-25, 1998 ------------------------------------------------------------ http://www.ikn.tuwien.ac.at/IKN/events/hpn-cfp.html March 15, 1998: Tutorial proposal March 15, 1998: Paper submission April 15, 1998: Notification May 15, 1998: Camera-ready paper =20 Conference book published by Chapman & Hall
Paper submission: preferably postscript file attached to email=20 otherwise 5 copies of paper by postal mail Topics of interest:=20 - Trends of Internet/Intranet Technologies=20 - Next Generation Internet, Evolutionary approaches=20 - Fast Internet (ADSL, HDSL, VHDSL, PONs)=20 - Cable Network, Wireless and Satellite Access=20 - Next Generation Routers, Tag Switching=20 - Bypass Tunneling (SDH, Photonics) =20 - Network/System Architecture and Design=20 - Cache Server Allocation and Interconnection=20 - Network Availability, Automatic Reconfiguration=20 - Coporate Networks, Global Networking =20 - Security in Internet, Network/System Security=20 - Network Management using Internet=20 - WWW and Java Network Service Management=20 - Distributed Systems Management in Internet=20 - Interworking with ATM, ISDN, and LANs=20 - System Interoperability =20 - Internet Mobility Support, Mobility Management=20 - Mobile-IP, Mobile-IPv6=20 - Mobile Agents, Intelligent/Smart Agents=20 - Flow Control, Traffic Monitoring and Control=20 - Adressing and Routing =20 - Advanced Internet Protocols (RTP, RSVP)=20 - Multicast Protocols=20 - Protocol Design, Combined ATM and IP=20 - Secure Protocols (S-HTTP, SSL, SET)=20 - Internet Tunneling =20 - Quality of Service, Service Level Guarantees=20 - Resource Management=20 - Real-Time Services over Internet=20 - IP Telephony, Voice over Internet=20 - Teleconferencing, Broadband Internet=20 - Integrated Services Internet=20 - Internet in Multimedia Environments=20 - Heterogenous Distributed Environments =20 - Internet Groupware and Cooperative Work=20 - Information Management over Internet=20 - Electronic Commerce, Online-Marketing=20 - Internet Payment Systems, Webcasting=20 - WWW Servers, Tele-Service-Systems=20 - Internet Servers (Data-Base, Cache, Archive)=20 - High-Performance Tele-Activities=20 - Social Impacts, Opportunities and Threats=20 INTERNATIONAL PROGRAM COMMITTEE:=20 General Chair:=20 Harmen R. van As, Vienna University of Technology, Austria=20 Ian Akyildiz, Georgia Tech, USA=20 Torsten Braun, Univ. of Berne, CH=20 Augusto Casaca, INESC, Portugal=20 Andre Danthine, Univ. Liege, Belgium=20 Michel Diaz, Univ. Toulouse, France=20 Christophe Diot, INRIA, France=20 Otto Duarte, Univ. Fed. Rio de Janeiro, Brazil=20 J=F6rg Ebersp=E4cher, Techn. Univ. Munich, Germany=20 Serge Fdida, Univ. Paris VI, France=20 Zygmunt Haas, Cornell University, USA=20 Marjory Johnson, NASA-RIACS, USA=20 Paul K=FChn, Univ. Stuttgart, Germany=20 Ralf Lehnert, Dresden Univ. of Technology, Germany=20 Helmut Leopold, Alcatel, Austria=20 Kurt Maly, Old Dominion Univ., USA=20 Olli Martikainen, Helsinki Univ. of Technology, Finland=20 Georg Mittenecker, Vienna Univ. of Technology, Austria=20 Hussein Mouftah, Queens Univ., Canada=20 Ignas Niemegeers, Univ. of Twente, The Netherlands=20 Guru Parulkar, Washington U. St. Louis, USA=20 Stephen Pink, SICS, Sweden=20 Radu Popescu-Zeletin, GMD Fokus, Germany=20 Ramon Puigjanier, Univ. Illes Balears, Spain=20 Guy Pujolle, Univ. Versailles, France=20 Doug Shepherd, Univ. Lancaster, UK=20 Thomas Sommer, Vienna Univ. of Technology, Austria=20 Otto Spaniol, Univ. Aachen, Germany=20 Ralf Steinmetz, Techn. Univ. Darmstadt, Germany=20 Ahmed Tantawi, IBM Res., Yorktown Heights, USA=20 Fouad Tobagi, Stanford Univ., USA=20 Samir Tohm=E9, ENST, France=20 Giorgio Ventre, Univ. Napoli, Italy=20 Martina Zitterbart, Univ. Braunschweig, Germany=20 ---------------------------------------------------------------------------- Prof.Dr. Harmen R. van As Institute of Communication Networks Vienna University of Technology Tel +43-1-58801-5246 Gusshausstrasse 25/388 Fax +43-1-5870583 A-1040 Vienna, Austria email: Harmen.R.van-As@tuwien.ac.at http://www.ikn.tuwien.ac.at=20 ---------------------------------------------------------------------------- From rem-conf Sat Apr 11 10:18:45 1998 From rem-conf-request@es.net Sat Apr 11 10:18:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yO3m1-0006FM-00; Sat, 11 Apr 1998 10:09:01 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yO3m0-0006FB-00; Sat, 11 Apr 1998 10:09:00 -0700 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id NAA24489 for ; Sat, 11 Apr 1998 13:08:58 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id NAA21357 for ; Sat, 11 Apr 1998 13:08:52 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <352FA3A4.705DA078@cs.columbia.edu> Date: Sat, 11 Apr 1998 13:08:52 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: rem-conf@es.net Subject: Cameras with Ethernet adaptor Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is anybody aware of a video camera with a built-in/attached Ethernet network interface? (I'm aware of the various research and commercial ATM cameras or adaptors, but don't have/want ATM...) Thanks. From rem-conf Sat Apr 11 11:06:54 1998 From rem-conf-request@es.net Sat Apr 11 11:06:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yO4cN-00070m-00; Sat, 11 Apr 1998 11:03:07 -0700 Received: from thalia.fm.intel.com [132.233.247.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yO4cM-00070c-00; Sat, 11 Apr 1998 11:03:06 -0700 Received: from fmsmsx26.fm.intel.com (fmsmsx26.fm.intel.com [132.233.42.26]) by thalia.fm.intel.com (8.8.6/8.8.5) with ESMTP id SAA18886; Sat, 11 Apr 1998 18:02:28 GMT Received: by FMSMSX26 with Internet Mail Service (5.5.1960.3) id <2V90WB99>; Sat, 11 Apr 1998 11:02:32 -0700 Message-ID: <514BE2EDEAB2D111AC3F00A0C9692EC606D624@FMSMSX38> From: "Zhu, Chad" To: "'Rashed Iqbal'" , Stephen Casner Cc: rem-conf@es.net Subject: RE: AVT WG last call on two drafts Date: Sat, 11 Apr 1998 11:02:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I support Steve's propose to let both stand. I think in the long run, the new draft probably would obsolete RFC 2190 if the new options added in H.263+ prove to be effective and people have motivations to go extra miles to implement them. However, it is premature to FORCE it now. The primary reason is that there are still codecs there, and probably more, implementing 1996 version of H.263 and rfc 2190. 1998 H.263+ is backward compatible with 1996 H.263, and it is not required to implement the new additional options for ITU compatibility. If a codec is allowed to only implement those that are covered by 1996 H.263, and continue to inter-operate with RFC2190, why should they be required to change? >From ITU standpoint, both 1996 H.263 and 1998 H.263+ are acceptable implementations, and 1998 has merely added more OPTIONAL features. Not every h.263 codec will be required to implement the new options. In my opinion, they should be allowed to use RFC2190 for RTP, especially they already shipped their products. We could encourage NEW implementations for either version of H.263 to use new H.263+ payload, but we should give them time to migrate, rather than force them to do it now. In fact, for those that have released products with 1996 H.263 and RFC 2190, this would create inter-operability problems. I also talked to other folks at Intel, Linda S. Cline, Tom Gardos, etc. We all agree that it's critical that the H.263 payload based on RFC 2190 is allowed to exist. --Chad > -----Original Message----- > From: Rashed Iqbal [mailto:rashed.iqbal@isb.worldwerx.com.pk] > Sent: Saturday, April 11, 1998 3:29 AM > To: Stephen Casner > Cc: rem-conf@es.net > Subject: Re: AVT WG last call on two drafts > > > Hello Steve, AVT WG, > > > 2. As we discussed in the meeting last week, putting forth > this draft > > as a Proposed Standard calls into question the status > of RFC 2190, > > "RTP Payload Format for H.263 Video Streams", which is based on > > the 1996 version of H.263. > > > > In my opinion, the right thing to do is to let both stand, and > > just distinguish the new draft as corresponding to the 1998 > > version of H.263. The title already mentions this. Rather than > > marking the new RFC as obsoleting 2190, it should have > a paragraph > > explaining its relationship to 2190. This paragraph might say > > that the 2190 format continues to be used by existing > > implementations, and may be required for backward > compatibility in > > new implementations, but that implementations using the new > > features of 1988 H.263 need to use the format of the new payload > > format. > > I understand that the 1998 version of H.263 has improved the > functionality of this ITU-T video codec greatly. However, still it is > H.263 video codec and decoder of this newer version must be able > to decode bitstream of the earlier versions. Similarly, encoder > of the newer version should be able to generate a bitstream that > is decodable by the decoder of the older version. This ensure > complete inter-operability between these version possibly after some > negotiations (for example using H.245). > > Steve, therefore, I fully support the idea to keep 2190 instead of > obsoleting it in additon to he newer one. Otherwise, interoperability > between newer and existing codec may be hampered. Nevertheless, in my > (personal) view, it will take some good time before H.263 Version > 1998 dominates!! > > Rashed > > > Dr. Rashed Iqbal > Networked Multimedia Systems > WorldWerx (pvt) Ltd. > H. 326, St. 15, F-10/2, Islamabad, PAKISTAN > Phone:92-51-282192 Fax: 92-51-282192 > From rem-conf Sat Apr 11 15:22:27 1998 From rem-conf-request@es.net Sat Apr 11 15:22:27 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yO8TS-0000ch-00; Sat, 11 Apr 1998 15:10:10 -0700 Received: from unknown-197-226.nextel.com (alcsnmx1.nextel.com) [167.20.197.226] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yO8TR-0000cX-00; Sat, 11 Apr 1998 15:10:09 -0700 Received: from sparhawk (alcc7rt1.dialcall.com [170.206.40.10]) by alcsnmx1.nextel.com (8.8.8/8.8.6) with SMTP id SAA11392; Sat, 11 Apr 1998 18:08:23 -0400 (EDT) From: "Bryan W. Tye" To: "'Henning Schulzrinne'" , Subject: RE: Cameras with Ethernet adaptor Date: Sat, 11 Apr 1998 18:07:15 -0400 Message-ID: <000301bd6596$301b30b0$06feceaa@sparhawk.ens.nextel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <352FA3A4.705DA078@cs.columbia.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Axis Communications makes just such a product with a built-in web server to serve the pictures. Check them out at: http://www.axis.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Bryan W. Tye Tel: 770-825-9754 Research & Development Fax: 770-825-9775 Enterprise Network Services (ENS) Cell: 404-557-2066 Nextel Communications, Inc. Email: Bryan.Tye@ens.nextel.com Mission: To identify, research, develop and design value-added solutions that enable the advancement of the enterprise infrastructure. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- From: hgs@cs.columbia.edu [mailto:hgs@cs.columbia.edu]On Behalf Of Henning Schulzrinne Sent: Saturday, April 11, 1998 1:09 PM To: rem-conf@es.net Subject: Cameras with Ethernet adaptor Is anybody aware of a video camera with a built-in/attached Ethernet network interface? (I'm aware of the various research and commercial ATM cameras or adaptors, but don't have/want ATM...) Thanks. From rem-conf Sun Apr 12 02:27:00 1998 From rem-conf-request@es.net Sun Apr 12 02:26:59 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOIwY-0003kf-00; Sun, 12 Apr 1998 02:20:54 -0700 Received: from flash.eunet.fi [193.64.224.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOIwX-0003k9-00; Sun, 12 Apr 1998 02:20:53 -0700 Received: from localhost (huopio@localhost) by flash.eunet.fi (8.8.8/8.8.8) with SMTP id MAA10707 for ; Sun, 12 Apr 1998 12:19:49 +0300 Date: Sun, 12 Apr 1998 12:19:48 +0300 (EET DST) From: Kauto Huopio X-Sender: huopio@flash.eunet.fi To: rem-conf@es.net Subject: RE: Cameras with Ethernet adaptor In-Reply-To: <000301bd6596$301b30b0$06feceaa@sparhawk.ens.nextel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list While the Axis cameras are nice, they might not be the noes meant here. Axis boxes talk only HTTP/FTP/SMTP as the picture transfer method, they won't be able to do more than >5 fps with present CPU (I think). I'd really like to see a full-speed solution. --Kauto From rem-conf Sun Apr 12 16:28:01 1998 From rem-conf-request@es.net Sun Apr 12 16:28:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOVym-0000PB-00; Sun, 12 Apr 1998 16:16:04 -0700 Received: from gateway-gw.pictel.com [140.242.1.1] by mail1.es.net with smtp (Exim 1.81 #2) id 0yOVyl-0000Op-00; Sun, 12 Apr 1998 16:16:03 -0700 Received: from pictel.com (roadrunner.pictel.com) by gateway-gw.pictel.com (4.1/cf.gw.970707.rdw) id AA21921; Sun, 12 Apr 98 18:56:52 EDT Received: from madawaska.pictel.com by pictel.com (4.1/SMI-4.1) id AA11323; Sun, 12 Apr 98 19:13:25 EDT Message-Id: X-Sender: webber@cactus.pictel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 12 Apr 1998 19:14:29 -0700 To: "Rashed Iqbal" , Stephen Casner From: Robert Webber Subject: status of RFC 2190 (old H.263 over IP) Cc: rem-conf@es.net In-Reply-To: <199804110524.KAA23587@isb.worldwerx.com.pk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Just so we're clear on this, here is what I understand would be the main reasons to Obsolete RFC 2190: * The 1996 version of H.263 can be put into packets using the scheme provided in the new draft. Under some circumstances, using the new scheme will mean adding less overhead per packet than using the old scheme. * H.323 systems use RFC 2190 as one scheme for putting H.263 in packets and will continue to do so regardless of the fate of RFC 2190. * Having two ways to do H.263 over IP with no expressed preference between them on the part of the people who advanced the documents will make it needlessly confusing for new implementors. If there were some other way to indicate a preference for the new scheme over the old scheme I'd be all for it, but in the absence of another way to indicate deprecation of RFC 2190, I'd like to see it Obsoleted. The document still exists, the default payload type value can still exist, but a person retrieving the document will be told that there's a newer and better approach. I don't think that this will break anything that Mr Iqbal doesn't want broken, but it will send a clear message for the guidance of implementors. Thanks, Bob At 10:28 AM 4/11/98 +0000, Rashed Iqbal wrote: >Hello Steve, AVT WG, > >> 2. As we discussed in the meeting last week, putting forth this draft >> as a Proposed Standard calls into question the status of RFC 2190, >> "RTP Payload Format for H.263 Video Streams", which is based on >> the 1996 version of H.263. >> >> In my opinion, the right thing to do is to let both stand, and >> just distinguish the new draft as corresponding to the 1998 >> version of H.263. The title already mentions this. Rather than >> marking the new RFC as obsoleting 2190, it should have a paragraph >> explaining its relationship to 2190. This paragraph might say >> that the 2190 format continues to be used by existing >> implementations, and may be required for backward compatibility in >> new implementations, but that implementations using the new >> features of 1988 H.263 need to use the format of the new payload >> format. > >I understand that the 1998 version of H.263 has improved the >functionality of this ITU-T video codec greatly. However, still it is >H.263 video codec and decoder of this newer version must be able >to decode bitstream of the earlier versions. Similarly, encoder >of the newer version should be able to generate a bitstream that >is decodable by the decoder of the older version. This ensure >complete inter-operability between these version possibly after some >negotiations (for example using H.245). > >Steve, therefore, I fully support the idea to keep 2190 instead of >obsoleting it in additon to he newer one. Otherwise, interoperability >between newer and existing codec may be hampered. Nevertheless, in my >(personal) view, it will take some good time before H.263 Version >1998 dominates!! > >Rashed > > >Dr. Rashed Iqbal >Networked Multimedia Systems >WorldWerx (pvt) Ltd. >H. 326, St. 15, F-10/2, Islamabad, PAKISTAN >Phone:92-51-282192 Fax: 92-51-282192 > From rem-conf Sun Apr 12 17:01:40 1998 From rem-conf-request@es.net Sun Apr 12 17:01:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOWdW-000159-00; Sun, 12 Apr 1998 16:58:10 -0700 Received: from gateway-gw.pictel.com [140.242.1.1] by mail1.es.net with smtp (Exim 1.81 #2) id 0yOWdV-00014f-00; Sun, 12 Apr 1998 16:58:09 -0700 Received: from pictel.com (roadrunner.pictel.com) by gateway-gw.pictel.com (4.1/cf.gw.970707.rdw) id AA22177; Sun, 12 Apr 98 19:38:58 EDT Received: from madawaska.pictel.com by pictel.com (4.1/SMI-4.1) id AA11565; Sun, 12 Apr 98 19:55:31 EDT Message-Id: <9804122355.AA11565@pictel.com> X-Sender: webber@cactus.pictel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 12 Apr 1998 19:48:12 -0700 To: "Rashed Iqbal" , Stephen Casner From: Robert Webber Subject: status of RFC 2190 (old H.263 over IP) Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Just so we're clear on this, here is what I understand would be the main reasons to Obsolete RFC 2190: * The 1996 version of H.263 can be put into packets using the scheme provided in the new draft. Under some circumstances, using the new scheme will mean adding less overhead per packet than using the old scheme. * H.323 systems use RFC 2190 as one scheme for putting H.263 in packets and will continue to do so regardless of the fate of RFC 2190. * Having two ways to do H.263 over IP with no expressed preference between them on the part of the people who advanced the documents will make it needlessly confusing for new implementors. If there were some other way to indicate a preference for the new scheme over the old scheme I'd be all for it, but in the absence of another way to indicate deprecation of RFC 2190, I'd like to see it Obsoleted. The document still exists, the default payload type value can still exist, but a person retrieving the document will be told that there's a newer and better approach. I don't think that this will break anything that Dr Iqbal doesn't want broken, but it will send a clear message for the guidance of implementors. Thanks, Bob At 10:28 AM 4/11/98 +0000, Rashed Iqbal wrote: >I understand that the 1998 version of H.263 has improved the >functionality of this ITU-T video codec greatly. However, still it is >H.263 video codec and decoder of this newer version must be able >to decode bitstream of the earlier versions. Similarly, encoder >of the newer version should be able to generate a bitstream that >is decodable by the decoder of the older version. This ensure >complete inter-operability between these version possibly after some >negotiations (for example using H.245). > >Steve, therefore, I fully support the idea to keep 2190 instead of >obsoleting it in additon to he newer one. Otherwise, interoperability >between newer and existing codec may be hampered. Nevertheless, in my >(personal) view, it will take some good time before H.263 Version >1998 dominates!! > >Rashed From rem-conf Sun Apr 12 17:05:06 1998 From rem-conf-request@es.net Sun Apr 12 17:05:05 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOWgA-000187-00; Sun, 12 Apr 1998 17:00:54 -0700 Received: from newdev.harvard.edu [128.103.65.15] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOWg9-00017x-00; Sun, 12 Apr 1998 17:00:54 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id UAA11792; Sun, 12 Apr 1998 20:00:31 -0400 (EDT) Date: Sun, 12 Apr 1998 20:00:31 -0400 (EDT) From: Scott Bradner Message-Id: <199804130000.UAA11792@newdev.harvard.edu> To: casner@precept.com, rashed.iqbal@isb.worldwerx.com.pk, webber@cactus.pictel.com Subject: Re: status of RFC 2190 (old H.263 over IP) Cc: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -- If there were some other way to indicate a preference for the new scheme over the old scheme I'd be all for it, but in the absence of another way to indicate deprecation of RFC 2190, I'd like to see it Obsoleted. -- there is another way, text can be put in the new document that says it updates 2190 and the "updates" tag can be put into the RFC index next to the new RFC and "updated by" tag can be put next to 2190 Scott From rem-conf Sun Apr 12 17:27:53 1998 From rem-conf-request@es.net Sun Apr 12 17:27:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOX2n-0002Je-00; Sun, 12 Apr 1998 17:24:17 -0700 Received: from gateway-gw.pictel.com [140.242.1.1] by mail1.es.net with smtp (Exim 1.81 #2) id 0yOX2m-0002JD-00; Sun, 12 Apr 1998 17:24:16 -0700 Received: from pictel.com (roadrunner.pictel.com) by gateway-gw.pictel.com (4.1/cf.gw.970707.rdw) id AA22302; Sun, 12 Apr 98 20:05:05 EDT Received: from madawaska.pictel.com by pictel.com (4.1/SMI-4.1) id AA11709; Sun, 12 Apr 98 20:21:39 EDT Message-Id: <9804130021.AA11709@pictel.com> X-Sender: webber@cactus.pictel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Sun, 12 Apr 1998 20:21:47 -0700 To: Scott Bradner , casner@precept.com From: Robert Webber Subject: Re: status of RFC 2190 (old H.263 over IP) Cc: rem-conf@es.net In-Reply-To: <199804130000.UAA11792@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 08:00 PM 4/12/98 -0400, Scott Bradner wrote: >-- >If there were some other way to indicate a preference for the new scheme >over the old scheme ... >-- > >there is another way, text can be put in the new document that says >it updates 2190 and the "updates" tag can be put into the RFC index >next to the new RFC and "updated by" tag can be put next to 2190 That would answer my concern fairly completely, because the "updated by" tag would be visible in the RFC index. Is "updated by" acceptable to people who don't like "obsoleted by?" Btw, some of the authors of the new H.263 over IP draft are at an ITU-T SG 16 meeting in Yokosuka, Japan, this week and might have some trouble participating in this discussion. Next week. the ITU-T SG 16 H.263 experts will be meeting in Tampere, Finland and again might have some trouble participating. I think all the main groups overlapping (so to speak) in this area should be home and as fully connected as they get by about 27 April, 1998, in case anybody wants to be sure that all the main interested groups have had a chance to participate in this discussion. Bob From rem-conf Sun Apr 12 17:31:03 1998 From rem-conf-request@es.net Sun Apr 12 17:31:03 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOX6Q-0002Li-00; Sun, 12 Apr 1998 17:28:02 -0700 Received: from unknown-197-226.nextel.com (alcsnmx1.nextel.com) [167.20.197.226] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOX6P-0002LR-00; Sun, 12 Apr 1998 17:28:01 -0700 Received: from sparhawk (sparhawk-home.dialcall.com [170.206.254.6]) by alcsnmx1.nextel.com (8.8.8/8.8.6) with SMTP id UAA03109; Sun, 12 Apr 1998 20:26:07 -0400 (EDT) From: "Bryan W. Tye" To: "'Kauto Huopio'" , Subject: RE: Cameras with Ethernet adaptor Date: Sun, 12 Apr 1998 20:25:05 -0400 Message-ID: <000001bd6672$9c0107a0$06feceaa@sparhawk.ens.nextel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Agreed, so would I. At the time this solution works for us and eliminates having a host system for the camera. I would be very interested if anyone can find a full-speed solution. -Bryan -----Original Message----- From: Kauto Huopio [mailto:huopio@iki.fi] Sent: Sunday, April 12, 1998 5:20 AM To: rem-conf@es.net Subject: RE: Cameras with Ethernet adaptor While the Axis cameras are nice, they might not be the noes meant here. Axis boxes talk only HTTP/FTP/SMTP as the picture transfer method, they won't be able to do more than >5 fps with present CPU (I think). I'd really like to see a full-speed solution. --Kauto From rem-conf Sun Apr 12 22:48:13 1998 From rem-conf-request@es.net Sun Apr 12 22:48:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOc20-0006GU-00; Sun, 12 Apr 1998 22:43:48 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOc1y-0006Fs-00; Sun, 12 Apr 1998 22:43:46 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id WAA20033; Sun, 12 Apr 1998 22:38:16 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804130538.WAA20033@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Bryan W. Tye" cc: "'Kauto Huopio'" , rem-conf@es.net Subject: Re: Cameras with Ethernet adaptor In-reply-to: Your message of "Sun, 12 Apr 1998 20:25:05 EDT." <000001bd6672$9c0107a0$06feceaa@sparhawk.ens.nextel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Apr 1998 22:38:15 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Personally, I don't see what the big deal is with loading up an OS like FreeBSD . Packaging is an issue however if you shop around you will find something that is very close to your needs. There are PCs that come in credit card size .... Amancio > Agreed, so would I. At the time this solution works for us and > eliminates having a host system for the camera. > > I would be very interested if anyone can find a full-speed solution. > > -Bryan > > -----Original Message----- > From: Kauto Huopio [mailto:huopio@iki.fi] > Sent: Sunday, April 12, 1998 5:20 AM > To: rem-conf@es.net > Subject: RE: Cameras with Ethernet adaptor > > > While the Axis cameras are nice, they might not be the noes meant here. > Axis boxes talk only HTTP/FTP/SMTP as the picture transfer method, they > won't be able to do more than >5 fps with present CPU (I think). > > I'd really like to see a full-speed solution. > > --Kauto > > > > From rem-conf Mon Apr 13 05:03:04 1998 From rem-conf-request@es.net Mon Apr 13 05:03:03 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOhq9-0003CF-00; Mon, 13 Apr 1998 04:55:57 -0700 Received: from isb.worldwerx.com.pk [194.133.48.216] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOhq6-0003C5-00; Mon, 13 Apr 1998 04:55:55 -0700 Received: from riqbal (pc34.isb.worldwerx.com.pk [192.168.5.34]) by isb.worldwerx.com.pk (8.8.8/8.8.5) with SMTP id QAA06816; Mon, 13 Apr 1998 16:54:51 +0500 Message-Id: <199804131154.QAA06816@isb.worldwerx.com.pk> Comments: Authenticated sender is From: "Rashed Iqbal" Organization: Worldwerx, Islamabad To: Robert Webber Date: Mon, 13 Apr 1998 16:58:39 PKT MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Status of RFC 2190 CC: rem-conf@es.net X-Confirm-Reading-To: "Rashed Iqbal" Priority: normal In-reply-to: References: <199804110524.KAA23587@isb.worldwerx.com.pk> X-mailer: Pegasus Mail for Win32 (v2.54) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Bob, AVT Group, I am sorry if I gave an impression of unduly pressing for keeping RFC 2190. My major point in keeping the RFC is interoperability. Although, I completely agree to giving a preference to the newer version, I strictly beleive on de fecto adaptation rather than de jure one of standards (Perhaps for the same reason the technical specs by ITU-T are not called standards but recommendations). As Chad Zhu pointed out, the adoptation of new RFC will be decided by how manufactures and users responds to H.263 Version 98. Let the market decide it!! Regards, Rashed > If there were some other way to indicate a preference for the new scheme > over the old scheme I'd be all for it, but in the absence of another way to > indicate deprecation of RFC 2190, I'd like to see it Obsoleted. The > document still exists, the default payload type value can still exist, but > a person retrieving the document will be told that there's a newer and > better approach. I don't think that this will break anything that Mr Iqbal > doesn't want broken, but it will send a clear message for the guidance of > implementors. Dr. Rashed Iqbal Networked Multimedia Systems WorldWerx (pvt) Ltd. H. 326, St. 15, F-10/2, Islamabad, PAKISTAN Phone:92-51-282192 Fax: 92-51-282192 From rem-conf Mon Apr 13 09:57:15 1998 From rem-conf-request@es.net Mon Apr 13 09:57:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOmSd-0000kv-00; Mon, 13 Apr 1998 09:51:59 -0700 Received: from calliope1.fm.intel.com [132.233.247.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOmSc-0000kl-00; Mon, 13 Apr 1998 09:51:58 -0700 Received: from fmsmsx27.fm.intel.com (fmsmsx27.fm.intel.com [132.233.42.27]) by calliope1.fm.intel.com (8.8.6/8.8.5) with ESMTP id QAA02150; Mon, 13 Apr 1998 16:51:19 GMT Message-Id: <199804131651.QAA02150@calliope1.fm.intel.com> Received: by FMSMSX27 with Internet Mail Service (5.5.1960.3) id <2V0CC2WK>; Mon, 13 Apr 1998 09:51:18 -0700 From: "Deisher, Gim L" To: Rashed Iqbal , Stephen Casner , Robert Webber Cc: "rem-conf@es.net " , "Zhu, Chad" , "Gardos, Thomas R" , "Cline, Linda S" Subject: RE: status of RFC 2190 (old H.263 over IP) Date: Mon, 13 Apr 1998 09:49:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >* The 1996 version of H.263 can be put into packets using the scheme >provided in the new draft. Under some circumstances, using the new scheme >will mean adding less overhead per packet than using the old scheme. > True. However, there are also circumstances in which the rfc 2190 packetization scheme can provide less overhead and better resiliency. >* H.323 systems use RFC 2190 as one scheme for putting H.263 in packets >and will continue to do so regardless of the fate of RFC 2190. > >* Having two ways to do H.263 over IP with no expressed preference between >them on the part of the people who advanced the documents will make it >needlessly confusing for new implementors. > I agree with Steve that we can add a paragraph in the H.263+ payload spec explaining its relationship to rfc 2190. We can clarify that the new scheme is recommended over rfc 2190. However, the rfc 2190 document with complete payload format specification should remain to exist for implementors who desire backward compatibility with any existing applications using rfc 2190. --Gim >If there were some other way to indicate a preference for the new scheme >over the old scheme I'd be all for it, but in the absence of another way >to indicate deprecation of RFC 2190, I'd like to see it Obsoleted. The >document still exists, the default payload type value can still exist, but >a person retrieving the document will be told that there's a newer and >better approach. I don't think that this will break anything that Mr >Iqbal doesn't want broken, but it will send a clear message for the >guidance of implementors. > >Thanks, >Bob > >At 10:28 AM 4/11/98 +0000, Rashed Iqbal wrote: >>Hello Steve, AVT WG, >> >>> 2. As we discussed in the meeting last week, putting forth this draft >>> as a Proposed Standard calls into question the status of RFC 2190, >>> "RTP Payload Format for H.263 Video Streams", which is based on >>> the 1996 version of H.263. >>> >>> In my opinion, the right thing to do is to let both stand, and >>> just distinguish the new draft as corresponding to the 1998 >>> version of H.263. The title already mentions this. Rather than >>> marking the new RFC as obsoleting 2190, it should have a paragraph >>> explaining its relationship to 2190. This paragraph might say >>> that the 2190 format continues to be used by existing >>> implementations, and may be required for backward compatibility in >>> new implementations, but that implementations using the new >>> features of 1988 H.263 need to use the format of the new payload >>> format. >> >>I understand that the 1998 version of H.263 has improved the >>functionality of this ITU-T video codec greatly. However, still it is >>H.263 video codec and decoder of this newer version must be able >>to decode bitstream of the earlier versions. Similarly, encoder >>of the newer version should be able to generate a bitstream that >>is decodable by the decoder of the older version. This ensure >>complete inter-operability between these version possibly after some >>negotiations (for example using H.245). >> >>Steve, therefore, I fully support the idea to keep 2190 instead of >>obsoleting it in additon to he newer one. Otherwise, interoperability >>between newer and existing codec may be hampered. Nevertheless, in my >>(personal) view, it will take some good time before H.263 Version >>1998 dominates!! >> >>Rashed From rem-conf Mon Apr 13 10:12:43 1998 From rem-conf-request@es.net Mon Apr 13 10:12:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOmjS-0001NC-00; Mon, 13 Apr 1998 10:09:22 -0700 Received: from ganymede.or.intel.com [134.134.248.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOmjR-0001N1-00; Mon, 13 Apr 1998 10:09:21 -0700 Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id KAA19331; Mon, 13 Apr 1998 10:20:51 -0700 (PDT) Received: from ishark.jf.intel.com (ishark.jf.intel.com [134.134.210.2]) by ideal.jf.intel.com (8.8.7/8.8.7) with SMTP id KAA07388; Mon, 13 Apr 1998 10:01:36 -0700 (PDT) Message-Id: <199804131701.KAA07388@ideal.jf.intel.com> X-Authentication-Warning: ideal.jf.intel.com: ishark.jf.intel.com [134.134.210.2] didn't use HELO protocol X-Mailer: exmh version 1.6 4/21/95 To: Robert Webber cc: rem-conf@es.net Subject: Re: status of RFC 2190 (old H.263 over IP) In-reply-to: Your message of Sun, 12 Apr 98 19:14:29 -0700. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Apr 98 10:04:54 PDT From: Linda Cline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bob, > Just so we're clear on this, here is what I understand would be the main > reasons to Obsolete RFC 2190: > > * The 1996 version of H.263 can be put into packets using the scheme > provided in the new draft. Under some circumstances, using the new scheme > will mean adding less overhead per packet than using the old scheme. Yes, and in some circumstances, using the old scheme will mean adding less overhead per packet than using the new scheme. There are also cases where you can get better packet level recovery using the old scheme. However, I feel these differences are minimal. To me, the main reason to move to the new payload is that it is simpler to implement and is flexible (hence the two situations listed above). My main concern is backward compatibility. If RFC 2190 is obsoleted (or labeled "updated" by the new payload, it is essentially no longer a valid RTP payload. You then require existing implementations to implement a new payload to stay conformant. This seems unreasonable to me. > * H.323 systems use RFC 2190 as one scheme for putting H.263 in packets and > will continue to do so regardless of the fate of RFC 2190. It is not clear that they will be able to continue to do this if the payload type has been obsoleted. There is some H.245 wording which prohibits the use of obsoleted payload types. I have not verified this, or examined any other H.323 ramifications. > * Having two ways to do H.263 over IP with no expressed preference between > them on the part of the people who advanced the documents will make it > needlessly confusing for new implementors. If we use Steve's suggestion to include text in the new payload draft that describes the relationship to RFC 2190, I don't see what the problem would be. Linda From rem-conf Mon Apr 13 11:51:46 1998 From rem-conf-request@es.net Mon Apr 13 11:51:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOoHu-0002z7-00; Mon, 13 Apr 1998 11:49:02 -0700 Received: from yosemite.main.gnac.com [198.151.248.221] (firewall-user) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOoHt-0002yx-00; Mon, 13 Apr 1998 11:49:01 -0700 Received: by yosemite.main.gnac.com; id LAA06330; Mon, 13 Apr 1998 11:48:57 -0700 (PDT) From: Received: from dhcp-225.main.gnac.com(192.168.1.225) by yosemite.main.gnac.com via smap (4.1) id xma006311; Mon, 13 Apr 98 11:48:00 -0700 Received: (from greg@localhost) by localhost.main.gnac.com (8.8.7/8.8.8) id LAA01238; Mon, 13 Apr 1998 11:47:58 -0700 Message-Id: <199804131847.LAA01238@localhost.main.gnac.com> Subject: BayLISA meeting: Samba futures To: baylisa@baylisa.org, blw@baylisa.org, sage-members@usenix.org, rem-conf@es.net Date: Mon, 13 Apr 1998 11:47:58 -0700 (PDT) Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 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 Cisco Systems in San Jose, California. Directions can be found on our web page at http://www.baylisa.org/events/cisco.html The meetings are also broadcast via MBONE. Schedule -------- Thursday, 16 April, 1998: Samba Futures, Jeremy Alison Samba is arguably the most successful UNIX SMB server software product in use today. Currently, Samba has implemented nearly all of the public SMB specifications Microsoft has made publicly available. Samba is now going where no publicly available code has gone before, in attempting to implement the non-published parts of Microsoft's Windows NT Domain controller protocols. In this talk I will cover the areas of SMB that Samba currently implements, and the difficulties encountered in implementing such a foreign protocol on UNIX, and then will attempt to give an idea of where Samba will be going in the next year or so of coding efforts. The ultimate aim is to be able to fully support Microsoft Windows NT servers and clients without needing to implement a Domain Controller purchased >from Microsoft, and to use as much as possible of an existing UNIX authentication infrastructure. The talk will also cover Microsoft's attempts to move the protocol forward with their NT5 code, and how the Samba developers are trying to cope with a rapidly changing target. [Schedule subject to change] For further information on BayLISA, check out our 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 the info alias listed above. -- Greg A. Kulosa | "The avalanche has already started, it is too Systems Administrator | late for the pebbles to vote." - Ambassador Kosh GNAC, Inc. |___________________________________________________ greg@gnac.com 999 Main Street - Redwood City, CA 94063 From rem-conf Mon Apr 13 11:54:20 1998 From rem-conf-request@es.net Mon Apr 13 11:54:19 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOoMR-00037X-00; Mon, 13 Apr 1998 11:53:43 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOoMQ-000341-00; Mon, 13 Apr 1998 11:53:42 -0700 Received: from oak.precept.com (oak.precept.com [204.162.116.21]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id LAA16014; Mon, 13 Apr 1998 11:52:41 -0700 (PDT) Date: Mon, 13 Apr 1998 11:53:02 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: Re: Summary of AVT meeting at IETF41 in LA In-Reply-To: <352E2316.84ABD79B@dnrc.bell-labs.com> Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list When I sent the short summary of the AVT meeting in Los Angeles, I inadvertently omitted Jonathan Rosenberg's slides. I've also added a ps.gz version of mine: > The following presentation slides are available: > > http://www.cs.ucl.ac.uk/staff/c.perkins/slides/IETF-LA.ps.gz > http://drogo.cselt.it/mpeg/documents/dmif-avt.zip > ftp://hydra.precept.com/pub/rtp/ietf41-avt-casner.ppt > ftp://hydra.precept.com/pub/rtp/ietf41-avt-periyannan.ps New ones: ftp://hydra.precept.com/pub/rtp/ietf41-avt-casner-6up.ps.gz RTP as protocol: http://www.cs.columbia.edu/~jdrosen/papers/ietf_rtpasproto_mar98.ppt http://www.cs.columbia.edu/~jdrosen/papers/ietf_rtpasproto_mar98.pdf FEC: http://www.cs.columbia.edu/~jdrosen/papers/ietf_fec_mar98.ppt http://www.cs.columbia.edu/~jdrosen/papers/ietf_fec_mar98.pdf -- Steve From rem-conf Mon Apr 13 14:51:29 1998 From rem-conf-request@es.net Mon Apr 13 14:51:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOr65-00063v-00; Mon, 13 Apr 1998 14:49:01 -0700 Received: from gateway-gw.pictel.com [140.242.1.1] by mail1.es.net with smtp (Exim 1.81 #2) id 0yOr64-00063L-00; Mon, 13 Apr 1998 14:49:00 -0700 Received: from pictel.com (roadrunner.pictel.com) by gateway-gw.pictel.com (4.1/cf.gw.970707.rdw) id AA14686; Mon, 13 Apr 98 17:47:57 EDT Received: from madawaska.pictel.com by pictel.com (4.1/SMI-4.1) id AA02232; Mon, 13 Apr 98 17:46:21 EDT Message-Id: <9804132146.AA02232@pictel.com> X-Sender: webber@cactus.pictel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 13 Apr 1998 17:31:36 -0700 To: Linda Cline From: Robert Webber Subject: Re: status of RFC 2190 (old H.263 over IP) Cc: rem-conf@es.net In-Reply-To: <199804131701.KAA07388@ideal.jf.intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 10:04 AM 4/13/98 -0700, Linda Cline wrote: >My main concern is backward compatibility. If RFC 2190 is obsoleted (or >labeled "updated" by the new payload, it is essentially no longer a valid >RTP payload. You then require existing implementations to implement a >new payload to stay conformant. This seems unreasonable to me. I disagree that "updated" (or even "obsoleted") attached to RFC 2190 result in the requirements you describe. >> * H.323 systems use RFC 2190 as one scheme for putting H.263 in packets and >> will continue to do so regardless of the fate of RFC 2190. > >It is not clear that they will be able to continue to do this if the >payload type has been obsoleted. There is some H.245 wording which >prohibits the use of obsoleted payload types. I have not verified >this, or examined any other H.323 ramifications. If it's NOT clear, then it's in spite of my best efforts to get somebody to make it clear. I specifically asked this question over and over before the last SG 16 meeting, the one at which H.323 v2 was Decided with RFC 2190 support. The answer I got back was that even Obsoleting RFC 2190 was not a problem. I think you are thinking of the ITU-T rules for including work of the IETF by reference. These specify that you can't include an Obsoleted RFC by reference. The answer I got to my questions about what would happen if RFC 2190 were subsequently Obsoleted was, "It doesn't matter so long as it's not Obsolete at the time the ITU-T Recommendation is Decided." If you disagree with this assessment, I'd appreciate it if you'd document your concern with a more specific reference. >> * Having two ways to do H.263 over IP with no expressed preference between >> them on the part of the people who advanced the documents will make it >> needlessly confusing for new implementors. > >If we use Steve's suggestion to include text in the new payload draft that >describes the relationship to RFC 2190, I don't see what the problem would >be. The specific problem I have is that if you only look at the index and RFC 2190 you won't learn about the new version. The approach doesn't make the preference clear enough for me to like it. "Updated by" in the index AND a paragraph of explanation in the (hoped for) new RFC would fix this problem and not even raise any issues in the relationship between ITU-T and IETF. At one point I was hearing some persistent mutterings about RFC 2190 being broken, which made me really want to Obsolete RFC 2190, but since nobody has mentioned those problems to me for a couple of months I assume they worked out the problems. There's still the problem of people wanting to know whether to implement RFC 2190, the new RFC, or both. If the new RFC gives guidance on that, great, but it would be even better if RFC 2190 were marked so that people knew to look for the guidance. As noted above, it would appear than neither Obsoleted nor Updated would actually make RFC 2190 inaccessible or invalid. H.323 (actually H.225.0) provides codepoints for RFC 2190 and the (unspecified) new RFC, the RFC 2190 document will always remain available, and the new scheme is better than the old one. For me, that adds up to a need to indicate preference for the new scheme and a lack of problems with the fate of the old one. Bob From rem-conf Mon Apr 13 14:51:32 1998 From rem-conf-request@es.net Mon Apr 13 14:51:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOr68-000649-00; Mon, 13 Apr 1998 14:49:04 -0700 Received: from gateway-gw.pictel.com [140.242.1.1] by mail1.es.net with smtp (Exim 1.81 #2) id 0yOr67-00063M-00; Mon, 13 Apr 1998 14:49:03 -0700 Received: from pictel.com (roadrunner.pictel.com) by gateway-gw.pictel.com (4.1/cf.gw.970707.rdw) id AA14689; Mon, 13 Apr 98 17:47:58 EDT Received: from by pictel.com (4.1/SMI-4.1) id AB02232; Mon, 13 Apr 98 17:46:23 EDT Message-Id: <9804132146.AB02232@pictel.com> X-Sender: webber@cactus.pictel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 13 Apr 1998 17:40:29 -0700 To: "Deisher, Gim L" From: Robert Webber Subject: RE: status of RFC 2190 (old H.263 over IP) Cc: "rem-conf@es.net " , "Gardos, Thomas R" In-Reply-To: <199804131654.QAA12962@thalia.fm.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 09:49 AM 4/13/98 -0700, Deisher, Gim L wrote: >I agree with Steve that we can add a paragraph in the H.263+ payload spec >explaining its relationship to rfc 2190. We can clarify that the new >scheme is recommended over rfc 2190. However, the rfc 2190 document with >complete payload format specification should remain to exist for >implementors who desire backward compatibility with any existing >applications using rfc 2190. > >--Gim I absolutely agree with you that the RFC 2190 document needs to continue to exist. This isn't at issue, though: only the way the document is listed in the index (and in headers in the document?) would change through it's being marked "updated by... ." Bob From rem-conf Mon Apr 13 17:00:46 1998 From rem-conf-request@es.net Mon Apr 13 17:00:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOt3R-000098-00; Mon, 13 Apr 1998 16:54:25 -0700 Received: from newdev.harvard.edu [128.103.65.15] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOt3Q-00008s-00; Mon, 13 Apr 1998 16:54:24 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id TAA14603; Mon, 13 Apr 1998 19:53:29 -0400 (EDT) Date: Mon, 13 Apr 1998 19:53:29 -0400 (EDT) From: Scott Bradner Message-Id: <199804132353.TAA14603@newdev.harvard.edu> To: lscline@jf.intel.com, webber@cactus.pictel.com Subject: Re: status of RFC 2190 (old H.263 over IP) Cc: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -- My main concern is backward compatibility. If RFC 2190 is obsoleted (or labeled "updated" by the new payload, it is essentially no longer a valid RTP payload. You then require existing implementations to implement a new payload to stay conformant. This seems unreasonable to me. -- I'd say that depends on the words in the new doc - the index can say updated by and not mean that 2190 is void Scott From rem-conf Mon Apr 13 17:53:38 1998 From rem-conf-request@es.net Mon Apr 13 17:53:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOtuZ-000114-00; Mon, 13 Apr 1998 17:49:19 -0700 Received: from ganymede.or.intel.com [134.134.248.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOtuY-00010u-00; Mon, 13 Apr 1998 17:49:18 -0700 Received: from ideal.jf.intel.com (ideal.jf.intel.com [134.134.130.5]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id SAA25780; Mon, 13 Apr 1998 18:00:51 -0700 (PDT) Received: from ishark.jf.intel.com (ishark.jf.intel.com [134.134.210.2]) by ideal.jf.intel.com (8.8.7/8.8.7) with SMTP id RAA28240; Mon, 13 Apr 1998 17:41:26 -0700 (PDT) Message-Id: <199804140041.RAA28240@ideal.jf.intel.com> X-Authentication-Warning: ideal.jf.intel.com: ishark.jf.intel.com [134.134.210.2] didn't use HELO protocol X-Mailer: exmh version 1.6 4/21/95 To: Robert Webber cc: rem-conf@es.net Subject: Re: status of RFC 2190 (old H.263 over IP) In-reply-to: Your message of Mon, 13 Apr 98 17:31:36 -0700. <9804132146.AA02232@pictel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Apr 98 17:44:45 PDT From: Linda Cline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bob, > >My main concern is backward compatibility. If RFC 2190 is obsoleted (or > >labeled "updated" by the new payload, it is essentially no longer a valid > >RTP payload. You then require existing implementations to implement a > >new payload to stay conformant. This seems unreasonable to me. > > I disagree that "updated" (or even "obsoleted") attached to RFC 2190 result > in the requirements you describe. I would like to have some clarification on updated vs. obsoleted and what exact change in status these bring to an RFC. Can someone provide a reference for this? I did a brief search, but couldn't find it. > >> * H.323 systems use RFC 2190 as one scheme for putting H.263 in packets and > >> will continue to do so regardless of the fate of RFC 2190. > > > >It is not clear that they will be able to continue to do this if the > >payload type has been obsoleted. There is some H.245 wording which > >prohibits the use of obsoleted payload types. I have not verified > >this, or examined any other H.323 ramifications. > ... > > I think you are thinking of the ITU-T rules for including work of the IETF > by reference. These specify that you can't include an Obsoleted RFC by > reference. The answer I got to my questions about what would happen if RFC > 2190 were subsequently Obsoleted was, "It doesn't matter so long as it's > not Obsolete at the time the ITU-T Recommendation is Decided." > If you disagree with this assessment, I'd appreciate it if you'd document > your concern with a more specific reference. I don't disagree with your assessment; I certainly hope you are correct. However, this is helpful only for ITU endpoints. Does this apply to using obsoleted RFCs for payload descriptors during H.245 exchange? I did take a quick look at this, and it doesn't look to be a real problem. The wording is not strict, and just says that obsolete RFCs should not be referenced in the payload descriptor. > The specific problem I have is that if you only look at the index and RFC > 2190 you won't learn about the new version. The approach doesn't make the > preference clear enough for me to like it. "Updated by" in the index AND a > paragraph of explanation in the (hoped for) new RFC would fix this problem > and not even raise any issues in the relationship between ITU-T and IETF. It may be that updated is a satisfactory solution for my concerns. Linda From rem-conf Mon Apr 13 17:53:38 1998 From rem-conf-request@es.net Mon Apr 13 17:53:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOtw3-00011q-00; Mon, 13 Apr 1998 17:50:51 -0700 Received: from newdev.harvard.edu [128.103.65.15] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOtw2-00011g-00; Mon, 13 Apr 1998 17:50:50 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id UAA14882; Mon, 13 Apr 1998 20:50:46 -0400 (EDT) Date: Mon, 13 Apr 1998 20:50:46 -0400 (EDT) From: Scott Bradner Message-Id: <199804140050.UAA14882@newdev.harvard.edu> To: gim.l.deisher@intel.com, webber@cactus.pictel.com Subject: RE: status of RFC 2190 (old H.263 over IP) Cc: rem-conf@es.net, thomas.r.gardos@intel.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -- I absolutely agree with you that the RFC 2190 document needs to continue to exist. This isn't at issue, though: only the way the document is listed in the index (and in headers in the document?) would change through it's being marked "updated by... ." -- once an RFC is published it does not change - i.e. the headers of 2190 will not change even if it were to be listed as updated, moved to full standard or made obsolete Scott From rem-conf Mon Apr 13 18:22:24 1998 From rem-conf-request@es.net Mon Apr 13 18:22:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOuMm-0002GM-00; Mon, 13 Apr 1998 18:18:29 -0700 Received: from iris.ctd.comsat.com [134.133.40.12] (exim) by mail1.es.net with smtp (Exim 1.81 #2) id 0yOuMm-0002GC-00; Mon, 13 Apr 1998 18:18:28 -0700 Received: from simao by iris.ctd.comsat.com with local (Exim 1.82 #1) id 0yOuMH-0006uK-00; Mon, 13 Apr 1998 21:17:57 -0400 From: Simao Campos To: "Deisher, Gim L" Cc: Rashed Iqbal , Stephen Casner , Robert Webber , "rem-conf@es.net " , "Zhu, Chad" , "Gardos, Thomas R" , "Cline, Linda S" Subject: RE: status of RFC 2190 (old H.263 over IP) In-Reply-To: <199804131651.QAA02150@calliope1.fm.intel.com> References: <199804131651.QAA02150@calliope1.fm.intel.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid cc: X-Face: "$ryF/ne$oms9n}#TY|W5Ttjbp-6/u4j'7c:%-aq2IAf'&DjuvII4wvr:eU{h=GMPcVTP,p XgCPnk{Qu:7P=jH00Q?B(*bZ\7#x_&KD=%hU1VhP'`hy'PF01*tU9DAoK7QXTGzL%fe!lIj,0Ds,P: GV_YPd*4GO?ClJAPRa=iB\PuIQmM=Q>qo87lJh-N2PQL-2QaM>}LdWI<} Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Message-Id: Date: Mon, 13 Apr 1998 21:17:57 -0400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, >from the formal point of view, an obsolete or historical RFC should not be referenced in an ITU standard, and currently RFC2190 is quoted in H.225.0. Since the feeling, as I see from the discussions, is that there may be advantages in keeping the RFC 2190 packetization alive although encouraging the use of the new packetization, probably it would be a good approach NOT to obsolete RFC2190 at this time, and to explain the relationship of it with the new H.263 packetization in the new RFC. Regards, Simao Campos From rem-conf Mon Apr 13 18:49:38 1998 From rem-conf-request@es.net Mon Apr 13 18:49:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yOupa-0002wT-00; Mon, 13 Apr 1998 18:48:14 -0700 Received: from newdev.harvard.edu [128.103.65.15] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yOupZ-0002wJ-00; Mon, 13 Apr 1998 18:48:13 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id VAA15064; Mon, 13 Apr 1998 21:47:24 -0400 (EDT) Date: Mon, 13 Apr 1998 21:47:24 -0400 (EDT) From: Scott Bradner Message-Id: <199804140147.VAA15064@newdev.harvard.edu> To: lscline@jf.intel.com, webber@cactus.pictel.com Subject: Re: status of RFC 2190 (old H.263 over IP) Cc: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --- I would like to have some clarification on updated vs. obsoleted and what exact change in status these bring to an RFC. Can someone provide a reference for this? I did a brief search, but couldn't find it. -- it is just tradition - normally if a old document is to be replaced totally by a new one then it is listed as being Obsoleted if the old document is still relevent in some way (in part or in whole) then Updated is the traditional term this decision is normally made by the working group and there are no specific rules Scott From rem-conf Tue Apr 14 08:33:27 1998 From rem-conf-request@es.net Tue Apr 14 08:33:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yP7UC-00002E-00; Tue, 14 Apr 1998 08:19:00 -0700 Received: from helix.nih.gov [128.231.2.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yP7UA-00001k-00; Tue, 14 Apr 1998 08:18:58 -0700 Received: from 128.231.82.178 ([128.231.82.178]) by helix.nih.gov (8.8.5/8.8.5) with SMTP id LAA05675 for ; Tue, 14 Apr 1998 11:18:13 -0400 (EDT) Message-ID: <35337F1C.6CC0@helix.nih.gov> Date: Tue, 14 Apr 1998 11:22:08 -0400 From: Martin Garraffo X-Mailer: Mozilla 3.0Gold (Macintosh; I; PPC) MIME-Version: 1.0 To: rem-conf@es.net Subject: Master Prep on internet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I am interested in the internet Master Preparation Class. I have a PowerMac with QuickTime TV (software for video and audio conferencing), and I am connected to the internet via Ethernet. How can I receive the multicast that starts on April 24th from UMBC? Thanks for any info, Martin Garraffo From rem-conf Wed Apr 15 07:09:59 1998 From rem-conf-request@es.net Wed Apr 15 07:09:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPSc2-00043m-00; Wed, 15 Apr 1998 06:52:30 -0700 Received: from send1e.yahoomail.com [205.180.60.64] by mail1.es.net with smtp (Exim 1.81 #2) id 0yPSc1-00043c-00; Wed, 15 Apr 1998 06:52:29 -0700 Message-ID: <19980415135311.20501.rocketmail@send1e.yahoomail.com> Received: from [202.41.72.13] by send1e; Wed, 15 Apr 1998 06:53:11 PDT Date: Wed, 15 Apr 1998 06:53:11 -0700 (PDT) From: Arkesh Kumar Subject: Re : Video Codecs To: Marie-annick_Riel@nt.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi I work in Centre for Development of Telematics (C-DOT), an R & D organization. For a project of ours "Distance learning through VSAT", we are interested in the following Video Equipment : 1. Digital Video Transmission unit with Integrated Receiver Decoder (IRD) for monitoring (MPEG - 2, 2 Mbps compatible) : a. Video Coding/Decoding : Aggregate data rate : Fixed bit rate at 2 Mbps (Video+Audio+data) (ITU-T Rec. G.703) Input Format : a)ITU R.601 standard 4:2:2 digital component (Serial Digital component) b) Analog Composite (PAL) Fixed Video Resolution : PAL 704X576,352X576 Motion Compensation : Full field/frame adaptive motion compensation. Video Processing delay : < 0.75 seconds typical. Composite Video Input/Output : 75 Ohms, 1Vp-p Receiver outputs : a)Analog composite (PAL) b)S-Video 2. Audio Coding/Decoding: Coding Format : MPEG-1 layer 2 (Musicam) Input/Output format : Analog or Digital (AES/EBU) Audio channels : 3 stereo pairs. Auxiliary Data Channel : 9.6 kbps Async 3. Integrated Satellite Receive Decoder(IRD) : The IRD shall be remotely controllable for RF channel selection, programme ID selection, Audio/Video selection etc. RF input (F connector) : L-Band (950-2050 MHz) RF output level : -20 to -60 dBm LNB power (dc) : 13 - 18 V Video Input (BNC) : Analog composite Audio Output (RCA) : Analog & Digital(AES &EBU) Data output (D25) : RS232 (low speed) Eb/No threshold : 4.5 dB at 1/2 FEC rate & BER of 1E-06 4. 384 Kbps codec : The codec shall be capable of receiving at lower rates (nX64) as per ITU-T Rec H-320. Aggregate Transmission : 384 Kbps (As per H.320) (Video+Audio+Data) Input/output video formats : Analog composite PAL - 75 Ohms 1Vp-p ITU-T R.601 standard 4:2:2 digital component (serial D1) Audio input / output : Analog or AES/EBU digital Audio Channels : 1 stereo pair Auxiliary data channel : 9.6 kbps Async We would like to have a clear picture of the output interfaces which the cards will provide. Also we would like to know if standalone system, instead of PC Plug-In cards are available. As we want to buy the above equipment in the near future, an early reply is highly appreciated. With warm regards, R. S. Arkesh Kumar SAT COM DIVISION C-DOT 71/1, Miller Road, Bangalore - 560 052 India. Ph : 91-80-2261529 Fax : 91-80-2263256 _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From rem-conf Wed Apr 15 16:03:03 1998 From rem-conf-request@es.net Wed Apr 15 16:03:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPb8F-0000Ol-00; Wed, 15 Apr 1998 15:58:19 -0700 Received: from ece.rice.edu [128.42.4.34] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yPb8D-0000Oa-00; Wed, 15 Apr 1998 15:58:17 -0700 Received: from qos.ece.rice.edu (qos.ece.rice.edu [128.42.12.65]) by ece.rice.edu (8.8.5/8.7.1) with ESMTP id RAA03991 for ; Wed, 15 Apr 1998 17:58:15 -0500 (CDT) Received: (from knightly@localhost) by qos.ece.rice.edu (8.7.5/8.7.5) id RAA22754 for rem-conf@es.net; Wed, 15 Apr 1998 17:58:15 -0500 (CDT) From: "Edward W. Knightly" Message-Id: <980415175814.ZM22752@qos.ece.rice.edu> Date: Wed, 15 Apr 1998 17:58:14 -0500 X-Mailer: Z-Mail (4.0.1 13Jan97) To: rem-conf@es.net Subject: IWQoS Program: May 18-20, Napa, CA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Below is the preliminary program for IWQoS '98, May 18-20 in Napa, California. Full details are at the workshop's web page http://www-ece.rice.edu/conf/iwqos98 The deadline for hotel reservations (reduced rate) and workshop pre-registration is Friday, April 24. Best regards, -Ed Knightly (IWQoS '98 co-chair) --------------- Invited Program --------------- May 18, Keynote Address: Roch Guerin, IBM Research "Quality-of-Service: Too little or too much (How much optimization do we really need?)" May 19, Keynote Paper: Domenico Ferrari Universita Cattolica Piacenza "Charging for QoS" May 19, Panel: Hui Zhang, Carnegie Mellon University "The Future of Differential and Integrated Services in the Internet" May 20, Panel: Vaduvur Bharghavan, University of Illinois "QoS in Wireless Networks: the Transition from Myth to Reality" ----------------- Technical Program ----------------- Technical Session 1, Monday Morning, May 18th QoS, Scaling, and Large-Scale Networks Full papers: Measuring and Analyzing Service Levels: A Scalable Passive Approach Manjari Asawa (Hewlett-Packard Laboratories) On Flow Aggregation for Multicast Video Transport Kentarou Fukuda, Naoki Wakamiya, Masayuki Murata, Hideo Miyahara (Osaka University) Position papers: Reservations for Aggregate Traffic: Experiences from an RSVP Tunnels Implementation Andreas Terzis, Lixia Zhang (UCLA), Ellen Hahne (Bell Labs) Aggregation of Internet Service States Steven Berson and Subramaniam Vincent (University of Southern California) Aggregating Resource Reservations over Multiple Routing Domains Olov Schelen and Stephen Pink (Lulea University of Technology) A Case for Proportional Fair Sharing Zheng Wang (Bell Labs) Session Panel Discussion Technical Session 2, Monday Afternoon, May 18th Internet Resource Reservation Full papers: On-line Measurement of QoS for Call Admission Control Matthew Siler and Jean Walrand (University of California at Berkeley) A General Framework for Deterministic Service Guarantees in Telecommunication Networks with Variable Length Packets C.S. Chang and Y. Lin (National Tsing Hua University) Position papers: QoS Enhancement and its Implementation in the vBNS Laura Cunningham, Chuck Song, and Rick Wilder (MCI) QoS Control via Robust Envelope-Based MBAC Jingyu Qiu and Edward W. Knightly (Rice University) High Quality and High Utilization - Incompatible Objectives for the Internet? Kalevi Kilkki, Jussi Ruutu, and Ove Strandberg (Nokia Research Center) Conservative Gaussian Models Applied to Measurement-Based Admission Control Francois Brichet and Alain Simonian (France Telecom) Session Panel Discussion Technical Session 3, Monday Afternoon, May 18th Economics, Pricing, and QoS Full papers: Paying for QoS: An Optimal Distributed Algorithm for Pricing Network Resources Errin Fulp (NEC and North Carolina State University), Max Ott and Daniel Reininger (NEC), and Douglas Reeves (North Carolina State University) INDEX: A Platform for Determining how People Value the Quality of their Internet Access Bjorn Rupp, Richard Edell, and Pravin Varaiya (University of California at Berkeley) An Embedded Charging Approach for RSVP Martin Karsten, Jens Schmitt, Lars Wolf, and Ralf Steinmetz (Darmstadt University of Technology) Position paper: INDEX Project: User Support for Buying QoS with Regard to User's Preferences Jorn Altmann and Pravin Varaiya (University of California at Berkeley) Session Panel Discussion Technical Session 4, Tuesday Morning, May 19th QoS Architecture, Protocols, and Middleware Full papers: SRP: a Scalable Resource Reservation Protocol for the Internet Werner Almesberger (EPFL ICA), Tiziana Ferrari (University of Bologna), and Jean-Yves Le Boudec (EPFL ICA) SAAM: Integrated Network Architecture for Integrated Services Geoffrey Xie, Debra Hensgen, Taylor Kidd, and John Yarger (Naval Postgraduate School) Dynamic Authentication for High-Performance Networked Applications Phyllis Schneck and Karsten Schwan (Georgia Institute of Technology) Position papers: The Quality of Service (QoS) Binding Model Jan de Meer (GMD Fokus), Abdelhakim Hafid (University of Western Ontario), and Arno Puder (ICSI) Qualis: the QoS Component for the Globus Metacomputing System Craig Lee (The Aerospace Corporation), Carl Kesselman, Robert Lindell, Soonwook Hwang, Joseph Bannister (University of Southern California), Ian Foster, Alain Roy (Argonne National Laboratory) Session Panel Discussion Technical Session 5, Tuesday Afternoon, May 19th Adaptive QoS 1 Full papers: A Control Theoretical Model for Quality of Service Adaptations Baochun Li and Klara Nahrstedt (University of Illinois at Urbana-Champaign) Soft Real-Time Application Execution with Dynamic QoS Assurance Scott Brandt, Gary Nutt, Toby Berk, and Marty Humphrey (University of Colorado at Boulder) Position papers: A Study of Dynamic QoS Negotiation for Multimedia Applications in RSVP Antonio Loureiro, Vladimir de L. Santos, Carlos de C. Goulart and Jose Marcos S. Nogueira (Federal University of Minas Gerais) Robust and Secure Light-weight Resource Reservation for Unicast IP Traffic Anders Eriksson (Ericsson Telecom) and Christian Gehrmann (Ericsson Radio Systems) Satisfying QoS with a Learning Based Scheduling Algorithm Jason Hall and Philip Mars (University of Durham) Session Panel Discussion Technical Session 6, Tuesday Afternoon, May 19th Application QoS Full papers: User Services Assistant: An End-to-End Reactive QoS Architecture Bjorn Landfeldt, Aruna Seneviratne (UTS), and Christophe Diot (Inria) Network Support for Application-Oriented QoS Prashant Chandra, Allan Fisher, Corey Kosak, and Peter Steenkiste (Carnegie Mellon University) Development of Opinion-Based Audiovisual Quality Models for Desktop Video Teleconferencing Coleen Jones and D. Atkinson (U.S. Department of Commerce) Position paper: Content-based VBR Resource Allocation Model and its Application to Dynamic Network Resource Allocation Paul Bocheck and Shih-Fu Chang (Columbia University) Session Panel Discussion Technical Session 7, Wednesday Morning, May 20th QoS Scheduling and Switching Full papers: Achieving High Utilization in Guaranteed Services Networks using Early-Deadline-First Scheduling Fabio Chiussi and Vijay Sivaraman (Bell Laboratories) Exact Emulation of an Output Queueing Switch by a Combined Input Output Queueing Switch Ion Stoica and Hui Zhang (Carnegie Mellon University) On the Speedup Required for Work-Conserving Crossbar Switches P. Krishna (DEC), N. Patel (Sycamore), A. Charney (Cabletron and MIT), and R. Simcoe (Nexabit) Algorithms for Providing Bandwidth and Delay Guarantees in Input-Buffered Crossbars with Speed Up A. Charny (Cabletron and MIT), P. Krishna (DEC), N. Patel (Sycamore), and R. Simcoe (Nexabit) Session Panel Discussion Technical Session 8, Wednesday Afternoon, May 20th Adaptive QoS 2 Full papers: Decision Support in Cooperative QoS Management Stefan Fischer (University of Mannheim) and Hermann De Meer (University of Hamburg) Supporting Utility Fair Adaptive Services in Wireless Networks Giuseppe Bianchi, Andrew Campbell, and Raymond Liao (Columbia University) Position papers: UNITE: A Framework for Flexible QoS in Networks Gisli Hjalmtysson and K. K. Ramakrishnan (AT&T Labs) A Summary of QoS Support in SWAN T. Chen (Bell Labs), P. Krzyanowski (VenGen Inc.), C. Sreenan, (AT&T Labs Research), and J. Trotter, (Bell Labs) A General Model for QoS Adaptation D.G. Waddington and D. Hutchison (Lancaster University) Session Panel Discussion From rem-conf Wed Apr 15 23:12:43 1998 From rem-conf-request@es.net Wed Apr 15 23:12:41 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPhqC-0002dV-00; Wed, 15 Apr 1998 23:08:08 -0700 Received: from bettina.informatik.uni-bremen.de [134.102.200.16] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yPhqA-0002dL-00; Wed, 15 Apr 1998 23:08:06 -0700 Received: from klobs.cs.tu-berlin.de (host1.q11q12q13q14-unet.ocn.ne.jp [210.162.213.178]) by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id IAA18676; Thu, 16 Apr 1998 08:01:21 +0200 (MET DST) Message-Id: <3.0.5.32.19980416081008.008b5810@127.0.0.1> X-Sender: jo@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 16 Apr 1998 08:10:08 +0200 To: Linda Cline , Robert Webber From: Joerg Ott Subject: Re: status of RFC 2190 (old H.263 over IP) Cc: rem-conf@es.net, stewe@cs.tu-berlin.de, garys@pictel.com, cabo@informatik.uni-bremen.de In-Reply-To: <199804131701.KAA07388@ideal.jf.intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list All, > >> Just so we're clear on this, here is what I understand would be the main >> reasons to Obsolete RFC 2190: >> >> * The 1996 version of H.263 can be put into packets using the scheme >> provided in the new draft. Under some circumstances, using the new scheme >> will mean adding less overhead per packet than using the old scheme. > >Yes, and in some circumstances, using the old scheme will mean adding less >overhead per packet than using the new scheme. There are also cases where >you can get better packet level recovery using the old scheme. However, >I feel these differences are minimal. To me, the main reason to move to >the new payload is that it is simpler to implement and is flexible (hence >the two situations listed above). First of all, obsoleting/updating the RFC2190 payload spec is not going to change existing implementations, but new ones should converge to a single payload format. A vague statement that under certain circumstances (which are not clearly specified) RFC2190 will be more efficient / more resilient than the new payload spec may encourage people to always implement both -- which is clearly not desirable. We already have far too much legacy in the area of H.263 paylaods. Plus, I would like to repeat that NOT USING THE NEW FEATURES OF H.263+ DOES NOT IMPLY USING RFC2190. Rather, the new format will work fine as well. > >My main concern is backward compatibility. If RFC 2190 is obsoleted (or >labeled "updated" by the new payload, it is essentially no longer a valid >RTP payload. You then require existing implementations to implement a >new payload to stay conformant. This seems unreasonable to me. > >> * H.323 systems use RFC 2190 as one scheme for putting H.263 in packets and >> will continue to do so regardless of the fate of RFC 2190. > >It is not clear that they will be able to continue to do this if the >payload type has been obsoleted. There is some H.245 wording which >prohibits the use of obsoleted payload types. I have not verified >this, or examined any other H.323 ramifications. We did explicit take care of the zoo of H.263 payload specs flying around when doing the text for the decided Recommendations H.245 and H.225.0. There is no need to worry about this. > >> * Having two ways to do H.263 over IP with no expressed preference between >> them on the part of the people who advanced the documents will make it >> needlessly confusing for new implementors. > >If we use Steve's suggestion to include text in the new payload draft that >describes the relationship to RFC 2190, I don't see what the problem would >be. I think Steve's text proposal is fine. What I do not want to see is -- what he briefly mentioned -- advancing RFC 2190 beyond Proposed Standard. On their way to Internet Standards, as far as I understand, the process documents may be refined due to new technical insights. The new payload spec reflects new technical insights and covers the full range of functionality H.263+ which has (referring to the ITU-T documents in IETF language) OBSOLETED H.263 (1996) -- even though in a backward compatible fashion. But, in my opionion, we should rule out the possibility of advancing a document that does not adequately reflect the standard it has to refer to. Again, we do have language in place in the H.323 context that distinguishes between the various packetization formats for H.263 include the non-standard ones. As we have to build backward compatible standards, we (hopefully) cannot be forced to change this text in a future revision of H.225.0/H.245 -- regardless of the status of RFC 2190. Joerg From rem-conf Thu Apr 16 01:33:51 1998 From rem-conf-request@es.net Thu Apr 16 01:33:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPjzz-0003qY-00; Thu, 16 Apr 1998 01:26:23 -0700 Received: from dienstmann-lane.informatik.uni-bremen.de (dienstmann.informatik.uni-bremen.de) [134.102.214.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yPjzx-0003qO-00; Thu, 16 Apr 1998 01:26:22 -0700 Received: by dienstmann.informatik.uni-bremen.de (8.7.3/30.7.96cl) id KAA13199 Thu, 16 Apr 1998 10:26:12 +0200 (MET DST) Date: Thu, 16 Apr 1998 10:26:12 +0200 (MET DST) Message-Id: <199804160826.KAA13199@dienstmann.informatik.uni-bremen.de> From: Carsten Bormann To: Joerg Ott Cc: Linda Cline , Robert Webber , rem-conf@es.net, stewe@cs.tu-berlin.de, garys@pictel.com Subject: Re: status of RFC 2190 (old H.263 over IP) In-Reply-To: <3.0.5.32.19980416081008.008b5810@127.0.0.1> References: <199804131701.KAA07388@ideal.jf.intel.com> <3.0.5.32.19980416081008.008b5810@127.0.0.1> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Joerg Ott writes: > I think Steve's text proposal is fine. What I do not want to see is -- what > he briefly mentioned -- advancing RFC 2190 beyond Proposed Standard. So we should make it HISTORIC. This is exactly the right status: The spec is not obsolete in the sense of "you need not read this document because a newer version of the same protocol has been issued", but then we believe the protocol was not that good an idea and should not be used for new implementations. >From RFC 2200: Some protocols have been superseded by better ones or are otherwise unused. Such protocols are still documented in this memorandum with the designation "historic". To give an example: RIP version 1 is HISTORIC for good reasons (it is classful and thus not useful in a modern Internet), but you probably would still be well-advised to implement it for backwards compatibility reasons. 1058 Routing Information Protocol. C.L. Hedrick. Jun-01-1988. (Format: TXT=93285 bytes) (Updated by RFC1388, RFC1723) (Status: HISTORIC) Gruesse, Carsten From rem-conf Thu Apr 16 03:45:01 1998 From rem-conf-request@es.net Thu Apr 16 03:45:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPm3L-00051H-00; Thu, 16 Apr 1998 03:37:59 -0700 Received: from mimos.my [192.228.128.18] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yPm3K-00050z-00; Thu, 16 Apr 1998 03:37:58 -0700 Received: from mimos.my (mac02.mimos.my [192.228.133.18]) by mimos.my (8.8.8/8.8.8) with ESMTP id SAA19050; Thu, 16 Apr 1998 18:36:51 +0800 (MYT) Message-ID: <35365092.8ECD74FF@mimos.my> Date: Thu, 16 Apr 1998 18:40:21 +0000 From: JY Luke Organization: MIMOS X-Mailer: Mozilla 4.05 (Macintosh; I; PPC) MIME-Version: 1.0 To: rem-conf@es.net, chandran@ew.mimos.my, kjlim@ew.mimos.my, kjjohn@ew.mimos.my Subject: MBone broadcast Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, The opening ceremony of Malaysia's Infotech 98 will be multlicasted on 21st April 1998 from 8:00am to 12:00pm Malaysian time (00:00 to 08:00 GMT). The event includes special keynote address by Prime Minister of Malaysia, open plenary and dialogue session with Prime Minister of Malaysia. More information can be obtained from this site: http://www.jaring.my/nitc/Infotech/1998/main.html Regards, JY Luke MIMOS Berhad (http://www.jaring.my/mimos/) Malaysia From rem-conf Thu Apr 16 08:54:21 1998 From rem-conf-request@es.net Thu Apr 16 08:54:20 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPqq7-0000Hp-00; Thu, 16 Apr 1998 08:44:39 -0700 Received: from vsys1.informatik.uni-hamburg.de [134.100.11.181] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yPqq6-0000HT-00; Thu, 16 Apr 1998 08:44:38 -0700 Received: (from listproc@localhost) by vsys1.informatik.uni-hamburg.de (8.8.5/8.8.5) id RAA24640; Thu, 16 Apr 1998 17:40:19 +0200 (MET DST) Resent-Date: Thu, 16 Apr 1998 17:40:19 +0200 (MET DST) Date: Thu, 16 Apr 1998 14:59:09 +0200 (MET DST) From: Electronic Commerce X-Sender: ec98@vsys1.informatik.uni-hamburg.de To: trec98-announce@vsys.informatik.uni-hamburg.de Subject: TrEC98 early bird deadline prolongued Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"im4to.A.nDB.fCgN1"@vsys1> Resent-From: trec98-announce@vsys.informatik.uni-hamburg.de X-Mailing-List: archive/latest/15 X-Loop: trec98-announce@vsys.informatik.uni-hamburg.de Resent-Sender: trec98-announce-request@vsys.informatik.uni-hamburg.de Resent-Bcc: X-Loop: rem-conf@es.net Precedence: list +-------------------------------------------------------------+ | If you do not wish to recive any further mailings from us, | | please send a mail to: | | trec98-announce-request@vsys.informatik.uni-hamburg.de | | and in the *body* of the mail type: | | unsubscribe | +-------------------------------------------------------------+ Conference Announcement ------------------------------------------------------------------- ///////////////// /////// /////// // ///// ///// // // // // / / / / / // // // // / ///// ///// // ////// ///// // / / / // // // // / / / // // // // //// ///// // // //////// //////// ------------------------------------------------------------------- International IFIP Working Conference: June 3-5 1998 Hamburg, Germany Trends in Electronic Commerce ------------------------------------------------------------------- We would like to remind you to register for the TrEC'98 Conference on Electronic Commerce. Online registration is possible via the TrEC Web server: http://vsys-www.informatik.uni-hamburg.de/trec98 Due to a connectivity desaster this week (the main faculty gateway was stolen), the early bird registration deadline is prolongued to April 24th. With kind regards, the TrEC organization team From rem-conf Thu Apr 16 10:03:50 1998 From rem-conf-request@es.net Thu Apr 16 10:03:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPs0c-0001RB-00; Thu, 16 Apr 1998 09:59:34 -0700 Received: from fs3.ee.ubc.ca (ee.ubc.ca) [137.82.52.241] by mail1.es.net with smtp (Exim 1.81 #2) id 0yPs0b-0001R0-00; Thu, 16 Apr 1998 09:59:33 -0700 Received: from Tectra.ee.ubc.ca by ee.ubc.ca (0/0 = undefined) id JAA28771; Thu, 16 Apr 1998 09:55:08 -0700 From: "Stephan Wenger" To: "Carsten Bormann" , "Joerg Ott" Cc: "Linda Cline" , "Robert Webber" , , Subject: Re: status of RFC 2190 (old H.263 over IP) Date: Thu, 16 Apr 1998 09:58:33 -0700 Message-ID: <01bd6958$e3e02cc0$32df5289@Tectra.ee.ubc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I strongly support Carstens idea of making RFC2190 historic. However, I would recommend to delay this decision until the new payload specification has reached at least Proposed Standard status for procedural reasons. * First of all, RFC2190 it is intended for a ITU-recommendation, which would be called 'historic' if it would be an RFC: it was superseded by a more recent recommendation with the same name. * Other than H.263 (1995, old version), the new version provides much better support for packet networks. In contrast to some other statements made here, I do see a strong movement towards the use of those mechanisms. * As already pointed out by other people, ITU-T H.323 implementers have no problems with the status of RFC2190. Even if the IETF would make RFC2190 obsolete, a copy of the language of this RFC would be still a normative part of H.225, so that implementers of H.323-systems have any information they need. * I don't know of any non-H.323 system implementing RFC2190 by now. I would like to know whether I missed one. So there is no true reason to continue with RFC2190 for procedural reasons. * From a technical point of view, I see absolutely no advantages of RFC2190 over the new draft. * Using the type 1 packets of RFC2190 (with parts of the information of the picture header coded in the payload header) improves the compression ratio only in case of many packets per frame, which happens rarely (because we usually want to fill the packets up to the MTU size due to payload/overhead constraints, and this leads for all practical bit-rates to 1 packet per frame). In the latter case, the new draft gives better compression * Type 2 and type 3 packets do not work, at least not if not augmented by a really sophisticated error concealment technique, which is not defined in RFC2190. This is because of the way H.263 does its motion vector prediction: unlike H.261, it is not sufficient to have only the motion vector of the left neighboring macroblock to reconstruct the a vector; in addition you need the vectors of two macroblocks above the current one. Without these vectors, it is impossible to get acceptable results even for medium motion scenes like Paris. I just did a quick simulation on this and found that a single lost packet (with packet-size == line size) causes a picture degradation with as much as 3.7 dB for Paris (QCIF) and 6.5 for Coastguard (QCIF). More details on this simulation on request. Stephan -----Original Message----- From: Carsten Bormann To: Joerg Ott Cc: Linda Cline ; Robert Webber ; rem-conf@es.net ; stewe@cs.tu-berlin.de ; garys@pictel.com Date: Thursday, April 16, 1998 2:03 AM Subject: Re: status of RFC 2190 (old H.263 over IP) >Joerg Ott writes: >> I think Steve's text proposal is fine. What I do not want to see is -- what >> he briefly mentioned -- advancing RFC 2190 beyond Proposed Standard. > >So we should make it HISTORIC. This is exactly the right status: >The spec is not obsolete in the sense of "you need not read this >document because a newer version of the same protocol has been >issued", but then we believe the protocol was not that good an idea >and should not be used for new implementations. > >>From RFC 2200: > > Some protocols have been superseded by better ones or are otherwise > unused. Such protocols are still documented in this memorandum with > the designation "historic". > >To give an example: RIP version 1 is HISTORIC for good reasons (it is >classful and thus not useful in a modern Internet), but you probably >would still be well-advised to implement it for backwards >compatibility reasons. > >1058 Routing Information Protocol. C.L. Hedrick. Jun-01-1988. (Format: > TXT=93285 bytes) (Updated by RFC1388, RFC1723) (Status: HISTORIC) > >Gruesse, Carsten > > From rem-conf Thu Apr 16 10:03:51 1998 From rem-conf-request@es.net Thu Apr 16 10:03:51 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPs2j-0001SN-00; Thu, 16 Apr 1998 10:01:45 -0700 Received: from dienstmann-lane.informatik.uni-bremen.de (dienstmann.informatik.uni-bremen.de) [134.102.214.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yPs2i-0001SD-00; Thu, 16 Apr 1998 10:01:44 -0700 Received: by dienstmann.informatik.uni-bremen.de (8.7.3/30.7.96cl) id TAA15675 Thu, 16 Apr 1998 19:01:33 +0200 (MET DST) Date: Thu, 16 Apr 1998 19:01:33 +0200 (MET DST) Message-Id: <199804161701.TAA15675@dienstmann.informatik.uni-bremen.de> From: Carsten Bormann To: "Stephan Wenger" Cc: "Carsten Bormann" , "Joerg Ott" , "Linda Cline" , "Robert Webber" , , Subject: Re: status of RFC 2190 (old H.263 over IP) In-Reply-To: <01bd6958$e3e02cc0$32df5289@Tectra.ee.ubc.ca> References: <01bd6958$e3e02cc0$32df5289@Tectra.ee.ubc.ca> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephan Wenger writes: > I strongly support Carstens idea of making RFC2190 historic. > However, I would recommend to delay this decision until > the new payload specification has reached at least > Proposed Standard status for procedural reasons. Oh certainly -- I was expecting we were going to ask this decision to be taken at the same time, certainly not earlier than the new spec going Proposed Standard. Gruesse, Carsten From rem-conf Thu Apr 16 10:45:30 1998 From rem-conf-request@es.net Thu Apr 16 10:45:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPsh9-0002zl-00; Thu, 16 Apr 1998 10:43:31 -0700 Received: from dslab7.cs.uit.no [129.242.16.27] (frodef) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yPsh6-0002za-00; Thu, 16 Apr 1998 10:43:29 -0700 Received: (from frodef@localhost) by dslab7.cs.uit.no (8.8.7/8.8.7) id TAA02864; Thu, 16 Apr 1998 19:43:16 +0200 To: rem-conf@es.net Subject: vat@linux2.1 From: Frode Vatvedt Fjeld Date: 16 Apr 1998 19:43:16 +0200 Message-ID: <2hg1jdu0gb.fsf@dslab7.cs.uit.no> Lines: 11 X-Mailer: Gnus v5.5/XEmacs 20.3 - "Vatican City" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Has anyone been successful in getting vat to work on linux kernel series 2.1? I'm using 2.1.91. I'm not able to switch the output selector, it's stuck at "speaker" (even if I start with the -j switch), and there's no audio output. The packets seems to be received fine. The audio does work fine with other applications. I've tried with both prebuilt binaries and locally compiled ones. Thanks, -- Frode Vatvedt Fjeld From rem-conf Thu Apr 16 11:24:16 1998 From rem-conf-request@es.net Thu Apr 16 11:24:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPtGf-00047Y-00; Thu, 16 Apr 1998 11:20:13 -0700 Received: from relay8.uu.net [192.48.96.84] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yPtGe-00047O-00; Thu, 16 Apr 1998 11:20:12 -0700 Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQeljt04637; Thu, 16 Apr 1998 14:20:11 -0400 (EDT) Received: by neserve0.uu.net id QQeljt04242; Thu, 16 Apr 1998 14:20:02 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: vat@linux2.1 To: frodef@acm.org (Frode Vatvedt Fjeld) Date: Thu, 16 Apr 1998 14:20:02 -0400 (EDT) Cc: rem-conf@es.net In-Reply-To: <2hg1jdu0gb.fsf@dslab7.cs.uit.no> from "Frode Vatvedt Fjeld" at Apr 16, 98 07:43:16 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list yes, I have gotten vat to work with kernels up to 2.1.90. 2.1.90 had a serious defect that isn't resolved yet. I have successfully gotten both vat and rat to compile fine under Linux. _J Frode Vatvedt Fjeld said: > > > Has anyone been successful in getting vat to work on linux kernel > series 2.1? I'm using 2.1.91. I'm not able to switch the output > selector, it's stuck at "speaker" (even if I start with the -j > switch), and there's no audio output. The packets seems to be received > fine. The audio does work fine with other applications. I've tried > with both prebuilt binaries and locally compiled ones. > > Thanks, > -- > Frode Vatvedt Fjeld > From rem-conf Thu Apr 16 11:25:19 1998 From rem-conf-request@es.net Thu Apr 16 11:25:19 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPtLH-0004CY-00; Thu, 16 Apr 1998 11:24:59 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yPtLG-00049n-00; Thu, 16 Apr 1998 11:24:58 -0700 Received: from oak.precept.com (oak.precept.com [204.162.116.21]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id LAA28195; Thu, 16 Apr 1998 11:19:05 -0700 (PDT) Date: Thu, 16 Apr 1998 11:19:30 -0700 (Pacific Daylight Time) From: Stephen Casner To: Carsten Bormann cc: Stephan Wenger , Joerg Ott , Linda Cline , Robert Webber , rem-conf@es.net, garys@pictel.com Subject: Re: status of RFC 2190 (old H.263 over IP) In-Reply-To: <199804161701.TAA15675@dienstmann.informatik.uni-bremen.de> Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephan Wenger wrote: > I strongly support Carstens idea of making RFC2190 historic. > However, I would recommend to delay this decision until > the new payload specification has reached at least > Proposed Standard status for procedural reasons. Carsten Bormann wrote: > Oh certainly -- I was expecting we were going to ask this decision to > be taken at the same time, certainly not earlier than the new spec > going Proposed Standard. The new spec would be published as a Proposed Standard RFC as soon as it completes IESG Last Call and the IESG approves it. I would expect RFC2190 to remain at Proposed Standard status until such time as the new spec is ready to advance from Proposed Standard to Draft Standard (which involves the establishment of interoperability of independent implementations and the passing of a minimum time interval that I'd have to look up). At that time, it should be more clear whether the new spec is displacing the old one. If so, then at that time (most) everyone might be comfortable with changing the status of 2190 to Historic. In this discussion, everyone seems to agree that including a paragraph in the new spec explaining the relationship to 2190 is a good idea. There have also been several opinions stated pro & con regarding the designation of 2190 as "updated by" the new one. I think I've seen the folks who were concerned about that be persuaded that it would be OK to do so. If my interpretation is not correct, please send me email. -- Steve From rem-conf Thu Apr 16 11:34:33 1998 From rem-conf-request@es.net Thu Apr 16 11:34:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPtTX-0004zu-00; Thu, 16 Apr 1998 11:33:31 -0700 Received: from gauss.engga.uwo.ca [129.100.9.33] by mail1.es.net with smtp (Exim 1.81 #2) id 0yPtTV-0004vv-00; Thu, 16 Apr 1998 11:33:29 -0700 Message-Id: <010601bd6965$cdbfe2c0$a0096481@dive.engga.uwo.ca> From: "Farid Nait" To: Subject: IPv6 over ATM Date: Thu, 16 Apr 1998 14:30:59 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Can sombody give me with references toward IPv6 over ATM and specially how the QoS is mapped between the two techmologies. Thanks in advance. From rem-conf Thu Apr 16 12:54:12 1998 From rem-conf-request@es.net Thu Apr 16 12:54:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPueX-0006yS-00; Thu, 16 Apr 1998 12:48:57 -0700 Received: from mickey.ee.pdx.edu [131.252.209.58] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yPueW-0006yI-00; Thu, 16 Apr 1998 12:48:56 -0700 Received: from dale.ee.pdx.edu (videoc@dale.ee.pdx.edu [131.252.220.134]) by mickey.ee.pdx.edu (8.8.6/8.8.6) with ESMTP id MAA19612; Thu, 16 Apr 1998 12:38:33 -0700 (PDT) From: Video Compression Workshop Received: (from videoc@localhost) by dale.ee.pdx.edu (8.8.6/8.8.6) id MAA10432; Thu, 16 Apr 1998 12:35:39 -0700 (PDT) Date: Thu, 16 Apr 1998 12:35:39 -0700 (PDT) Message-Id: <199804161935.MAA10432@dale.ee.pdx.edu> To: fli@ee.pdx.edu Subject: Video Compression Shortcourse 7/13-17/98 Portland OR USA X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list WWW: http://www.ee.pdx.edu/short_courses/image_compression/ July 13 - 17, 1998, Portland, Oregon - A 4 and 1/2 Day Intensive Course on Image and Video Compression: Fundamentals, Standards and Applications Portland State University, EE, Portland, OR 97207-0751, USA Phone:(503) 725-3806 Fax:(503) 725-3807 E-mail: eed@ee.pdx.edu Presented by: Majid Rabbani M. Ibrahim Sezan Thomas Gardos Eastman Kodak Sharp Labs. of America Intel Corporation ************************ Course Outline ************************ Introduction - Need for compression (application and product examples) - Statistical redundancy and perceptual irrelevancy in images and video, examples. - Fundamental building blocks of compression algorithm. - Transformation/Decomposition: discrete cosine transform (DCT), wavelets. - Quantization: scalar uniform, nonuniform, and entropy constrained; Trellis-Coded Quantization (TCQ). - Symbol modeling and encoding: Markov models and entropy; Huffman, arithmetic, LZW, and Golomb-Rice coding. Emerging Technologies - Wavelet compression (filterbank design, zerotree coding, comparisons to JPEG) - Fractal image compression Image and video compression international standards The JPEG international Standard - Lossless JPEG and JPEG-LS - Baseline JPEG - JPEG extensions and enhancements - JPEG implementation issues - JPEG-2000 Fundamentals of Video Compression - Motion Estimation - Pre- and Post-Processing including motion-compensation noise filtering, coding artifact reduction, video format conversion (frame rate conversion and deinterlacing.) Video Compression Standards - The MPEG1 standard - The MPEG2 standard (including discussions on rate control, bit-stream syntax and utilization in Digital Video Disk and Advanced TV standardization). - The MPEG4 standard (object based coding and object based functionalities) - The Future: MPEG7 - The H.261, H.263, and H.263+ standards and an update on H.263L development. - Video compression for Internet applications - Examples of silicon and board-level implementations of standards. - P*roduct demonstrations ************************************************************************ WWW: http://www.ee.pdx.edu/short_courses/image_compression/ July 13 - 17, 1998, Portland, Oregon - A 4 and 1/2 Day Intensive Course on Image and Video Compression: Fundamentals, Standards and Applications From rem-conf Thu Apr 16 14:06:07 1998 From rem-conf-request@es.net Thu Apr 16 14:06:07 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yPvnE-0000QZ-00; Thu, 16 Apr 1998 14:02:00 -0700 Received: from colibri.cpqd.com.br [200.231.0.33] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yPvnA-0000PZ-00; Thu, 16 Apr 1998 14:01:57 -0700 Received: from dragon.cpqd.com.br (dragon.cpqd.com.br [10.202.48.9]) by colibri.cpqd.com.br (8.8.7/8.8.7) with SMTP id RAA06489; Thu, 16 Apr 1998 17:58:52 -0300 (EST) Received: from CPqD2.cpqd.com.br by dragon.cpqd.com.br (SMI-8.6/SMI-SVR4) id RAA26728; Thu, 16 Apr 1998 17:59:10 -0300 Received: by CPqD2.cpqd.com.br(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 032565E8.00735A85 ; Thu, 16 Apr 1998 17:59:58 -0300 X-Lotus-FromDomain: CPQD From: "Bruno Souza Vianna" To: osimcast@bbn.com, sc6wg4@ntd.comsat.com, xtp-relay@cs.concordia.ca, reres@laas.fr, prs@masi.ibp.fr, comswtc@gmu.ed, multicomm@cc.bellcore.com, giga@tele.pitt.edu, tccc@ieee.org, itc%ieee.org.isadsoc@fokus.gmd.de, ctc-members@redbank.tinac.com, ieee_rtc_list@cs.tamu.edu, enternet@bbn.com, gcomlist1@manjaro.ece.iit.edu, comsoc.bog@tab.ieee.org, sigmedia@bellcore.com, comsoc.tac@tab.ieee.org, comsoc-gicb@ieee.org, commsoft@cc.bellcore.com, BM-List1@cs.ucdavis.edu, modern-heuristics@uk.ac.mailbase.ucdavis.edu, cellular@dfv.rwth-aachen.edu, cost237-transport@comp.lancs.ac.uk, testnet@canarie.ca, itc@fokus.gmd.de, dbworld@cs.wisc.edu, end2end-interest@isi.edu, f-troup@codex.cis.upenn.edu, hipparch@sophia.inria.fr, rem-conf@es.net, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, epr@infotest.com, golshani@asu.edu, ni@cps.msu.edu, park@cstp.umkc.edu, tcp-over-satellite@achtung.sp.trw.com, udlr@sophia.inria.fr, knom@nile.postech.ac.kr, han-announce@news.postech.ac.kr, han-net-announce@news.postech.ac.kr, info@nmf.org, comsoc-tcii@ieee.org, ifip-nm@bbn.com, nmf-objects@nmf.org, ietf@venera.isi.edu, fli@ee.pdx.edu Message-ID: <032565E8.0045FA7B.00@CPqD2.cpqd.com.br> Date: Thu, 16 Apr 1998 17:59:50 -0300 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear ComSoc Colleague, Ballots for the upcoming IEEE Communications Society (ComSoc) election have already been mailed out. After many years of volunteer work for ComSoc, I am running now for Member-At-Large on the Board of Governors (BoG) and I would appreciate it if you would consider selecting me as one of the candidates you can vote for. Thanks and best regards, Bruno _____________________________________ Bruno S. Vianna TELEBRAS R&D Center P.O. Box 1579 13088-061 Campinas, SP - Brazil Tel: +55 19 705-6186 Fax +55 19 705-7269 e-mail: brunosv@cpqd.com.br _____________________________________ Biography BRUNO S. VIANNA received his B.Sc. and M.Sc. degrees in Electronic Engineering from the University of Sao Paulo in 1975/78 and completed his Ph.D.program at the University of Campinas in 1987. He joined TELEBRAS R&D Center in 1978,leading switching development projects; for the last 5 years he managed the SGR/TMN Project,providing consultancy to the Brazilian telcos to achieve a new Network Management environment and prepare for competition through Business Transformation. Now he is in charge of all Network Operations and Management solutions. He is a consultant and lecturer in Latin-America and has been Director and member of the Brazilian Telecommunications Society's Deliberative Body for 11 years. He chaired and organized sessions at ComSoc conferences, including NOMS, participated in several technical committees, and was vice-chair of CNOM (Committee on Network Operations and Management). He chaired the Latin-American Committee on ComSoc's International Activities Council (IAC) for several years and acted also as Geographic Director on the International Conferences Policy Board (ICPB). He is one of the organizers of Globecom'99 in Rio de Janeiro. Candidate's Statement ComSoc plays a key role in the telecommunications community by bringing people together to exchange knowledge, and we can create new ways to further develop this capability. ComSoc can be really client-focused, by directing our action plans according to the main expectations of the various market segments. Presence at all client levels in a two-way relationship can be enhanced using new technologies, making ComSoc a worldwide leader in client service through easier, faster and ubiquitous access to information. Other important steps towards ComSoc globalization are Sister Society agreements (I led the accomplishment of ComSoc's second signed agreement) and regional conferences (I contributed to institute ComSoc's first regional conference). ___________________________________________________________________________ __ From rem-conf Fri Apr 17 04:22:49 1998 From rem-conf-request@es.net Fri Apr 17 04:22:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yQ98x-0005nj-00; Fri, 17 Apr 1998 04:17:19 -0700 Received: from alpha.netvision.net.il [194.90.1.13] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yQ98v-0005nZ-00; Fri, 17 Apr 1998 04:17:18 -0700 Received: from netvision (ts002p8.pop8a.netvision.net.il [199.203.248.46]) by alpha.netvision.net.il (8.8.6/8.8.6) with ESMTP id OAA21747; Fri, 17 Apr 1998 14:13:57 +0300 (IDT) Message-Id: <199804171113.OAA21747@alpha.netvision.net.il> Reply-To: "gadi ittach" From: "Gadi Ittah" To: "Scott Bradner" , , "Robert Webber" Cc: Subject: REMOVE Date: Tue, 28 Apr 1998 15:06:46 +0300 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by alpha.netvision.net.il id OAA21747 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list REMOVE ---------- > From: Robert Webber > To: Scott Bradner ; casner@precept.com > Cc: rem-conf@es.net > Subject: Re: status of RFC 2190 (old H.263 over IP) > Date: =E9=E5=ED =F9=F0=E9, =E0=F4=F8=E9=EC 13, 1998 06:21 >=20 > At 08:00 PM 4/12/98 -0400, Scott Bradner wrote: > >-- > >If there were some other way to indicate a preference for the new sche= me > >over the old scheme ... > >-- > > > >there is another way, text can be put in the new document that says > >it updates 2190 and the "updates" tag can be put into the RFC index=20 > >next to the new RFC and "updated by" tag can be put next to 2190 >=20 > That would answer my concern fairly completely, because the "updated by= " > tag would be visible in the RFC index. Is "updated by" acceptable to > people who don't like "obsoleted by?" >=20 > Btw, some of the authors of the new H.263 over IP draft are at an ITU-T SG > 16 meeting in Yokosuka, Japan, this week and might have some trouble > participating in this discussion. Next week. the ITU-T SG 16 H.263 experts > will be meeting in Tampere, Finland and again might have some trouble > participating. I think all the main groups overlapping (so to speak) i= n > this area should be home and as fully connected as they get by about 27 > April, 1998, in case anybody wants to be sure that all the main interested > groups have had a chance to participate in this discussion. >=20 > Bob >=20 From rem-conf Fri Apr 17 04:22:49 1998 From rem-conf-request@es.net Fri Apr 17 04:22:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yQ98N-0005nN-00; Fri, 17 Apr 1998 04:16:43 -0700 Received: from alpha.netvision.net.il [194.90.1.13] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yQ98L-0005mw-00; Fri, 17 Apr 1998 04:16:41 -0700 Received: from netvision (ts002p8.pop8a.netvision.net.il [199.203.248.46]) by alpha.netvision.net.il (8.8.6/8.8.6) with ESMTP id OAA31436; Fri, 17 Apr 1998 14:14:11 +0300 (IDT) Message-Id: <199804171114.OAA31436@alpha.netvision.net.il> Reply-To: "gadi ittach" From: "Gadi Ittah" To: , "=?ISO-8859-1?Q?Angel_Luis_Mateo_Mart=EDnez?=" Subject: REMOVE Date: Tue, 28 Apr 1998 15:07:16 +0300 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by alpha.netvision.net.il id OAA31436 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list REMOVE ---------- > From: Angel Luis Mateo Mart=EDnez > To: rem-conf@es.net > Subject: vat and encryption > Date: =E9=E5=ED =F8=E1=E9=F2=E9, =E0=F4=F8=E9=EC 01, 1998 11:42 >=20 > Hello all: >=20 > I would like to know if there is a version of vat for Windows95/NT th= at > supports DES1 encryption. If there is, where I can found it? >=20 > Thanks, >=20 > Angel L. Mateo Mart=EDnez >=20 From rem-conf Fri Apr 17 06:15:38 1998 From rem-conf-request@es.net Fri Apr 17 06:15:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yQAvI-0007Tu-00; Fri, 17 Apr 1998 06:11:20 -0700 Received: from www45.inria.fr [138.96.10.9] (hoschka) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yQAvE-0007Tk-00; Fri, 17 Apr 1998 06:11:18 -0700 Received: by www45.inria.fr (8.8.8/8.8.5) id PAA12148; Fri, 17 Apr 1998 15:11:14 +0200 (MET DST) Message-Id: <199804171311.PAA12148@www45.inria.fr> To: rem-conf@es.net From: Philipp Hoschka Subject: W3C moves SMIL to proposed recommendation Date: Fri, 17 Apr 1998 15:11:13 +0200 Sender: Philipp.Hoschka@sophia.inria.fr X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list SMIL allows integrating a set of independent multimedia objects such as audio, video or textfiles into a synchronized multimedia presentation. Using SMIL, an author can 1.describe the temporal behavior of the presentation 2.describe the layout of the presentation on a screen 3.associate hyperlinks with media objects This allows doing things like "Bloomberg TV on the Internet" SMIL is based on XML, i.e. uses an html-like syntax. The document can be found at http://www.w3.org/TR/PR-smil/ More info (implementations etc.) is available at http://www.w3.org/AudioVideo/ W3C has moved the Synchronized Multimedia Integration Language (SMIL, pronounced "smile") to proposed recommendation status. This is the final review period, before it is decided whether SMIL should become a W3C recommendation, be sent back to the WG for further work, or be dropped as a W3C work item (a more theoretical possibility). The review period lasts for another four weeks. If you have comments, send them to www-smil@w3.org - Philipp Hoschka, W3C ---------------------------------------------------------------------- Philipp Hoschka | http://www.w3.org/people/hoschka | | World Wide Web Consortium | MIT-LCS hoschka@w3.org | 545, Technology Square Tel:(+1) 617.258.5714 | Cambridge, MA 02139 Fax:(+1) 617.258.5999 | USA ---------------------------------------------------------------------- --PAA12139.892818622/www45.inria.fr-- From rem-conf Fri Apr 17 08:33:39 1998 From rem-conf-request@es.net Fri Apr 17 08:33:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yQCpt-00013H-00; Fri, 17 Apr 1998 08:13:53 -0700 Received: from listbox2.cern.ch [137.138.24.200] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yQCpr-00010I-00; Fri, 17 Apr 1998 08:13:51 -0700 Received: from cern.ch (pcitcs04.cern.ch [137.138.33.126]) by listbox2.cern.ch (8.8.8/8.8.8) with ESMTP id RAA19520; Fri, 17 Apr 1998 17:12:26 +0200 (MET DST) X-Authentication-Warning: listbox2.cern.ch: Host pcitcs04.cern.ch [137.138.33.126] claimed to be cern.ch Message-ID: <3537715E.9A707E69@cern.ch> Date: Fri, 17 Apr 1998 17:12:30 +0200 From: Miguel CHAMOCHIN GOMEZ Organization: CERN X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "rem-conf@es.net" , "mbone@ISI.EDU" CC: Miguel.Chamochin@cern.ch Subject: wrtpVoD-v0.1 & wrtp-v0.2 Announcement Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am pleased to announce the availability of the binaries for the wrtp Video on Demand System and the binaries & source of the new version of the wrtp application. These developments are part of my work at CERN. wrtpVoD system -------------- WrtpVoD system offers a solution for interactive playback and recording on demand. It has a API that interfaces with the RTSP gateway, so it is possible to embed it in others applications. The example included in the wrtpVoD bundle, is intended for playing conferences from a web browser, so users can control a videoconference from a web browser in a "VCR-style" due to the RTSP use (specified by the Multiparty Multimedia Session Control WG). System architecture is distributed and balanceable so as not to congest the network. More information: http://csvod1.cern.ch/wrtp_project#system wrtp application ---------------- It is intended for recording and playing RTPv2 conferences. It is based on the public domain rtptools toolkit developed by Henning Schulzrinne. Wrtp allows you to record and play, audio and video from other IP addresses (unicast or multicast). It encapsulates audio and video streams in RTP packets. Sessions are transparently managed. More information: http://csvod1.cern.ch/wrtp_project#application ---- -- More information about wrtp project: http://csvod1.cern.ch/wrtp_project wrtpVoD system binaries: http://csvod1.cern.ch/wrtp_project#installation wrtp application source code and binaries: http://csvod1.cern.ch/cgi-bin/nph-MBone-VCR Miguel. -- Miguel Angel Chamochin Gomez Information Technology Division CERN CH-1211 Geneve 23 SWITZERLAND Phone: +41-22-767-9703 Fax: +41-22-767-7155 e-mail:Miguel.Chamochin@cern.ch From rem-conf Fri Apr 17 09:43:01 1998 From rem-conf-request@es.net Fri Apr 17 09:43:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yQE8S-0002Rt-00; Fri, 17 Apr 1998 09:37:08 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yQE8Q-0002Rj-00; Fri, 17 Apr 1998 09:37:06 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id JAA03966; Fri, 17 Apr 1998 09:36:37 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804171636.JAA03966@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Miguel CHAMOCHIN GOMEZ cc: "rem-conf@es.net" , "mbone@ISI.EDU" Subject: Re: wrtpVoD-v0.1 & wrtp-v0.2 Announcement In-reply-to: Your message of "Fri, 17 Apr 1998 17:12:30 +0200." <3537715E.9A707E69@cern.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Apr 1998 09:36:37 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Are there any FreeBSD binaries available or are the sources available for wrtpVod? Tnks, Amancio From rem-conf Sat Apr 18 08:14:30 1998 From rem-conf-request@es.net Sat Apr 18 08:14:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yQZ89-0002Ms-00; Sat, 18 Apr 1998 08:02:13 -0700 Received: from mail.pccs.ca (apollo.pc-comp-sol.ca) [209.195.72.193] by mail1.es.net with smtp (Exim 1.81 #2) id 0yQZ88-0002Mh-00; Sat, 18 Apr 1998 08:02:12 -0700 Received: from TARIK by apollo.pc-comp-sol.ca (NTMail 3.01.03) id na035373; Sat, 18 Apr 1998 10:51:59 -0400 Message-ID: <3538EB20.149@pc-comp-sol.ca> Date: Sat, 18 Apr 1998 11:04:16 -0700 From: tsyed X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: RTP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Info: P&C Computer Solutions Inc. http://www.pccs.ca/ X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi I am a Master student of University of Ottawa. My thesis topic is RTP. I am looking RTP on Window95 or on Window NT platform. I appreciate if someone can let me know the site from where I can get the RTP. Thanks Tariq Syed From rem-conf Sun Apr 19 01:29:30 1998 From rem-conf-request@es.net Sun Apr 19 01:29:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yQpQI-0006Yx-00; Sun, 19 Apr 1998 01:26:02 -0700 Received: from smtp.tele.fi [192.89.123.25] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yQpQH-0006Ym-00; Sun, 19 Apr 1998 01:26:01 -0700 Received: from 118.middletown-10.va.dial-access.att.net ([12.68.22.118] HELO worldlynx.com ident: NO-IDENT-SERVICE [port 2264]) by smtp.tele.fi with SMTP id <19103-23519>; Sun, 19 Apr 1998 11:25:50 +0300 To: koleuku62@msn.com From: koleuku62@msn.com ( ) Comments: Authenticated sender is Reply-to: j-phillip@usa.net Subject: Bulk Mail Tools, And Services, Web Hosting in Mexico, Bulk friendly! Message-Id: <19980419822ZAA20220@post.tele.fi> Date: Sun, 19 Apr 1998 11:25:49 +0300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

Express Mail Server

The Next Genereration in Mass Emailers Completely bypass your ISP's email server and send out your email originating from your personal computer directly into your recipients mail system! Send email directly from you computer without using any of your ISP's server resources! Mail is delivered instantaneously: This incredible mail engine actually hand delivers the message from your computer into the recipients mail system. No delay; message literally travels right to its destination. Guaranteed delivery: Every single last one of your messages gets delivered! Message goes directly from your computer to your recipients mail system. Personalize messages: Automatically inserts recipients name in the body or your letter for a dramatic increase in responses. Verifies every single addresses before sending: Puts all bad addresses in a bad address file (practically eliminates undeliverables!). Unbelievably FAST: This new technology uses a multithreaded process to connect directly with your recipients mail system! Express Mail will send up to 80,000 messages per hour with a 28.8 modem (even faster with ISDN and T-1) and every single message will be individually placed in your recipients mail system instantaneously! Randomizing option allows you to break through any filters: This is a necessity to get mail through to AOL members. Create your messages in the built-in word processor: It has everything you need including spell check and color! Customization feature allows you to personally create your program: This will single-handedly generate additional sales for you and your clients. You'll love this feature! REQUIREMENTS: Windows 95 or higher 8 MB RAM 486 or faster processor 10 MB free space on your hard drive

**SPECIAL** ONLY $150.00! Call 24 Hrs 1-888-398-9866 To Order Your Demo Today!! And recieve 250,000 email addresses free, along with Stealth Mass Mailer for free!! Express Mail Server Is The Only Mass Emailer With 100% Delivery!!

We also have Gold Rush for only $300.00

Email Adressee Extractor for $100.00

Caller ID for $100.00

Bulk Mate List Manager for $129.00

Desk Top Server 98 for $339.00

Bulk Friendly Web Hosting On Mexican Backbone only $99.00 a month

MUCH MORE!!!

Also, call about a great rate of 8.9 cents long distance, even with 800/888 numbers!!

Please leave information on the item that you are calling about. Thank you.

WARNING:ONLY THOSE INTERESTED IN OUR PRODUCTS ARE AUTHORIZED TO USE THIS TOLL FREE NUMBER!! WE CAN ALSO OFFER YOU AN 800 VOICE MAIL NUMBER FOR $40.00, "UNLIMITED CALLS" From rem-conf Sun Apr 19 16:40:17 1998 From rem-conf-request@es.net Sun Apr 19 16:40:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yR3aO-0002ar-00; Sun, 19 Apr 1998 16:33:24 -0700 Received: from mimos.my [192.228.128.18] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yR3aC-0002aZ-00; Sun, 19 Apr 1998 16:33:23 -0700 Received: from ew.mimos.my (ew.mimos.my [192.228.129.34]) by mimos.my (8.8.8/8.8.8) with SMTP id HAA14792; Mon, 20 Apr 1998 07:32:10 +0800 (MYT) Received: from mimos.my by ew.mimos.my (SMI-8.6/SMI-SVR4) id HAA27613; Mon, 20 Apr 1998 07:26:48 +0800 Message-ID: <353A897B.262A824C@mimos.my> Date: Mon, 20 Apr 1998 07:32:11 +0800 From: "Dr. KJ John" Organization: MIMOS BERHAD X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: JY Luke CC: rem-conf@es.net, chandran@ew.mimos.my, kjlim@ew.mimos.my, kjjohn@ew.mimos.my Subject: Re: MBone broadcast References: <35365092.8ECD74FF@mimos.my> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thanks, how do we announce it so all Jaring and other ISP users know? Also, we better reflect that DPM is now launching it and not YAB PM. JY Luke wrote: > Hi, > > The opening ceremony of Malaysia's Infotech 98 will be multlicasted on 21st > April 1998 from 8:00am to 12:00pm Malaysian time (00:00 to 08:00 GMT). > > The event includes special keynote address by Prime Minister of Malaysia, open > plenary and dialogue session with Prime Minister of Malaysia. More information > can be obtained from this site: http://www.jaring.my/nitc/Infotech/1998/main.html > > Regards, > JY Luke > MIMOS Berhad (http://www.jaring.my/mimos/) > Malaysia From rem-conf Sun Apr 19 19:54:03 1998 From rem-conf-request@es.net Sun Apr 19 19:54:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yR6dl-00041M-00; Sun, 19 Apr 1998 19:49:05 -0700 Received: from isb.worldwerx.com.pk [194.133.48.216] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yR6dh-00041C-00; Sun, 19 Apr 1998 19:49:02 -0700 Received: from riqbal (pc34.isb.worldwerx.com.pk [192.168.5.34]) by isb.worldwerx.com.pk (8.8.8/8.8.5) with SMTP id HAA06098; Mon, 20 Apr 1998 07:48:43 +0500 Message-Id: <199804200248.HAA06098@isb.worldwerx.com.pk> Comments: Authenticated sender is From: "Rashed Iqbal" Organization: Worldwerx, Islamabad To: tsyed Date: Mon, 20 Apr 1998 07:52:16 PKT MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: RTP CC: rem-conf@es.net X-Confirm-Reading-To: "Rashed Iqbal" Priority: normal In-reply-to: <3538EB20.149@pc-comp-sol.ca> X-mailer: Pegasus Mail for Win32 (v2.54) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Tariq, If by RTP you mean the document RTP: A Transport Protocol for Real-Time Applications then this is available at the following site/homepage of Audio Video Transport (AVT) Group of IETF http://www.ietf.org/html.charters/avt-charter.html This site contains other documents and pointers as well you may find useful for your project. Rashed > Date: Sat, 18 Apr 1998 11:04:16 -0700 > From: tsyed > To: rem-conf@es.net > Subject: RTP > Hi > > I am a Master student of University of Ottawa. My thesis topic is RTP. I > am looking RTP on Window95 or on Window NT platform. I appreciate if > someone can let me know the site from where I can get the RTP. > > Thanks > > > Tariq Syed > > From rem-conf Mon Apr 20 00:45:04 1998 From rem-conf-request@es.net Mon Apr 20 00:45:03 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRB8s-0005za-00; Mon, 20 Apr 1998 00:37:30 -0700 Received: from mailex.rz.fh-ulm.de [141.59.42.15] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRB8r-0005zQ-00; Mon, 20 Apr 1998 00:37:29 -0700 Received: from hugo.rz.fh-ulm.de (Hugo.rz.fh-ulm.de [141.59.43.36]) by mailex.rz.fh-ulm.de (8.8.8/8.8.8) with ESMTP id JAA13398 for ; Mon, 20 Apr 1998 09:37:28 +0200 Received: from HUGO/SpoolDir by hugo.rz.fh-ulm.de (Mercury 1.31); 20 Apr 98 09:37:32 +0100 Received: from SpoolDir by HUGO (Mercury 1.31); 20 Apr 98 09:36:49 +0100 From: "RZ Dietmar Rahlfs" Organization: Fachhochschule Ulm To: rem-conf@es.net Date: Mon, 20 Apr 1998 09:35:49 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Re: vat@linux2.1 X-Confirm-Reading-To: "RZ Dietmar Rahlfs" Priority: normal X-mailer: Pegasus Mail v3.31 Message-ID: <1F9ED1041@hugo.rz.fh-ulm.de> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > yes, I have gotten vat to work with kernels up to 2.1.90. > > 2.1.90 had a serious defect that isn't resolved yet. I have successfully > gotten both vat and rat to compile fine under Linux. > 2.0.11 to 2.0.33 are not appropriate ? > _J > Have you experience in tunneling multicast IP packets? I always had he problem that I could not establish and release the sessions (or connections to sessions) dynamically when I chose them. The administrator of a remote Cisco Router that received sessions data had to explicitely configure that my Linux PC should receive a special MBone session per tunneling (through our Cisco Router). Then I got the data, but no other session. But the effect was also that the data did flow all the time. Dietmar Rahlfs From rem-conf Mon Apr 20 01:01:12 1998 From rem-conf-request@es.net Mon Apr 20 01:01:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRBPP-0006Lb-00; Mon, 20 Apr 1998 00:54:35 -0700 Received: from basil.cdt.luth.se [130.240.64.67] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRBPO-0006LR-00; Mon, 20 Apr 1998 00:54:34 -0700 Received: from salt (peppar@salt.cdt.luth.se [130.240.194.242]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id JAA23499; Mon, 20 Apr 1998 09:54:20 +0200 (MET DST) Message-Id: <199804200754.JAA23499@basil.cdt.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 To: "RZ Dietmar Rahlfs" cc: rem-conf@es.net Subject: Re: vat@linux2.1 In-reply-to: Your message of "Mon, 20 Apr 1998 09:35:49 BST." <1F9ED1041@hugo.rz.fh-ulm.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 20 Apr 1998 09:54:20 +0200 From: Peter Parnes X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RAHLFS@hugo.rz.fh-ulm.de said: > Have you experience in tunneling multicast IP packets? I always had he > problem that I could not establish and release the sessions (or > connections to sessions) dynamically when I chose them. Have you seen mTunnel? This is a tunneling application that allows you to choose exactly the sessions you want to tunnel via a Web-interface. It does not base it's tunneling decisions on IGMP. http://www.cdt.luth.se/~peppar/progs/mTunnel/ /P From rem-conf Mon Apr 20 02:21:48 1998 From rem-conf-request@es.net Mon Apr 20 02:21:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRCha-0007a8-00; Mon, 20 Apr 1998 02:17:26 -0700 Received: from relay9.uu.net [192.48.96.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRChZ-0007Zy-00; Mon, 20 Apr 1998 02:17:25 -0700 Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQelxd13437; Mon, 20 Apr 1998 05:17:24 -0400 (EDT) Received: by neserve0.uu.net id QQelxd04520; Mon, 20 Apr 1998 05:17:17 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Re: vat@linux2.1 To: RAHLFS@hugo.rz.fh-ulm.de (RZ Dietmar Rahlfs) Date: Mon, 20 Apr 1998 05:17:17 -0400 (EDT) Cc: rem-conf@es.net In-Reply-To: <1F9ED1041@hugo.rz.fh-ulm.de> from "RZ Dietmar Rahlfs" at Apr 20, 98 09:35:49 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi there, I would assume you are running mrouted, and you have configured the cisco at the other end to have a ``dvmrp'' tunnel. In adition, you must make sure: O ip tunneling is supported (insert the tunnel module) O insert the IPIP module O enable kernel forwarding in 2.1 with echo 1 >/proc/sys/net/ipv4/ip_forwarding If this machine is acting as a firewall, consult your system administrator before doing this, as kernel level forwarding is enabled by the cat command shown above. Finally, you must ensure ip mrouting is configured. If you're playing with the alpha pim thing, good luck. It is on my list of things to try. _J RZ Dietmar Rahlfs said: > > > yes, I have gotten vat to work with kernels up to 2.1.90. > > > > 2.1.90 had a serious defect that isn't resolved yet. I have successfully > > gotten both vat and rat to compile fine under Linux. > > > 2.0.11 to 2.0.33 are not appropriate ? > > > _J > > > > Have you experience in tunneling multicast IP packets? > I always had he problem that I could not establish > and release the sessions (or connections to sessions) > dynamically when I chose them. > > The administrator of a remote Cisco Router that > received sessions data had to explicitely configure that my > Linux PC should receive a special MBone session per > tunneling (through our Cisco Router). Then I got the > data, but no other session. But the effect was also that the > data did flow all the time. > > Dietmar Rahlfs > From rem-conf Mon Apr 20 03:00:06 1998 From rem-conf-request@es.net Mon Apr 20 03:00:05 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRDGI-00014V-00; Mon, 20 Apr 1998 02:53:18 -0700 Received: from aries.dif.um.es (aries.dif.um.es.) [155.54.12.152] by mail1.es.net with smtp (Exim 1.81 #2) id 0yRDGE-00013a-00; Mon, 20 Apr 1998 02:53:17 -0700 Received: from Labredes5.dif.um.es by aries.dif.um.es. (SMI-8.6/SMI-SVR4) id LAA03443; Mon, 20 Apr 1998 11:48:42 +0100 Message-Id: <199804201048.LAA03443@aries.dif.um.es.> X-Sender: amateo@aries.dif.um.es X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Demo Date: Mon, 20 Apr 1998 11:52:01 +0200 To: rem-conf@es.net From: Angel Luis Mateo =?iso-8859-1?Q?Mart=EDnez?= Subject: imj Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have seen that there is a program call imj to playout conferences over the mbone. Where I can found it? Thanks, ------------------------------------------------------------------------ Angel L. Mateo Mart=EDnez Facultad de Inform=E1tica Universidad de Murcia Espa=F1a (Spain) From rem-conf Mon Apr 20 04:19:47 1998 From rem-conf-request@es.net Mon Apr 20 04:19:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRERn-0002KS-00; Mon, 20 Apr 1998 04:09:15 -0700 Received: from aohakobe.ipc.chiba-u.ac.jp [133.82.241.137] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRERm-0002KF-00; Mon, 20 Apr 1998 04:09:14 -0700 Received: from aohakobe.ipc.chiba-u.ac.jp (localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.8.8/3.4Wbeta3 (-: 95041617) with ESMTP id UAA05983 for ; Mon, 20 Apr 1998 20:09:06 +0900 (JST) Message-Id: <199804201109.UAA05983@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: Re: imj In-reply-to: Your message of "Mon, 20 Apr 1998 11:52:01 +0200." <199804201048.LAA03443@aries.dif.um.es.> Date: Mon, 20 Apr 1998 20:09:04 +0900 From: Yozo Toda X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I have seen that there is a program call imj to playout confere nces over > the mbone. > > Where I can found it? see . -- yozo. From rem-conf Mon Apr 20 04:53:22 1998 From rem-conf-request@es.net Mon Apr 20 04:53:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRF4p-000370-00; Mon, 20 Apr 1998 04:49:35 -0700 Received: from cepheid.physics.gla.ac.uk [130.209.45.251] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRF4n-00036q-00; Mon, 20 Apr 1998 04:49:33 -0700 Received: from a5.ph.gla.ac.uk (a5.ph.gla.ac.uk [194.36.1.167]) by cepheid.physics.gla.ac.uk (8.8.5/8.8.5) with ESMTP id MAA17008; Mon, 20 Apr 1998 12:43:25 +0100 (BST) Received: from localhost (flavell@localhost) by a5.ph.gla.ac.uk (8.8.8/8.8.8) with SMTP id MAA27136; Mon, 20 Apr 1998 12:49:17 +0100 (BST) Date: Mon, 20 Apr 1998 12:49:17 +0100 (BST) From: "Alan J. Flavell" Reply-To: A.Flavell@physics.gla.ac.uk To: Peter Parnes cc: rem-conf@es.net Subject: mTunnel, was Re: vat@linux2.1 In-Reply-To: <199804200754.JAA23499@basil.cdt.luth.se> Message-ID: X-antiSpam: Do not send me unsolicited commercial email MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Mon, 20 Apr 1998, Peter Parnes wrote: > http://www.cdt.luth.se/~peppar/progs/mTunnel/ This looks very interesting for its intended purpose. However, a problem with which we have struggled as users of the MBone (but having no direct influence on the international MBone's infrastructure) is achieving reliable access to a remote mbone session when the intervening mbone paths are congested. E.g via supplying our own unicast or ISDN path. You're giving a very clear statement that your software doesn't address this problem: *** Warning!! Warning!! Warning!! Warning!! Warning!! Warning!! .. Do NOT start tunneling with both end-points on two hosts that already have MBone connectivity with each other. As far as I've been able to understand, the only solution to the problem I describe is to establish a _different_ multicast session at the other end of the unicast or ISDN path. Merely feeding copies of the same multicast packets back into the general MBone at a different place is bad news, right? If there's something we've overlooked that could address this problem situation we'd be msot interested to hear about it. From rem-conf Mon Apr 20 07:51:21 1998 From rem-conf-request@es.net Mon Apr 20 07:51:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRHqu-00053D-00; Mon, 20 Apr 1998 07:47:24 -0700 Received: from calliope1.fm.intel.com [132.233.247.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRHqt-00052o-00; Mon, 20 Apr 1998 07:47:23 -0700 Received: from fmsmsx27.fm.intel.com (fmsmsx27.fm.intel.com [132.233.42.27]) by calliope1.fm.intel.com (8.8.6/8.8.5) with ESMTP id OAA11804; Mon, 20 Apr 1998 14:46:00 GMT Received: by FMSMSX27 with Internet Mail Service (5.5.1960.3) id ; Mon, 20 Apr 1998 07:45:59 -0700 Message-ID: From: "Putzolu, David" To: "'tsyed'" , rem-conf@es.net Subject: RE: RTP Date: Mon, 20 Apr 1998 07:45:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I am a Master student of University of Ottawa. My thesis > topic is RTP. I > am looking RTP on Window95 or on Window NT platform. I appreciate if > someone can let me know the site from where I can get the RTP. Windows NT 5.0 beta has support for RTP in the form of a bunch of DirectShow filters (Microsoft's architecture for handling multimedia data - part of the DirectX suite). Look for RTP in the help files (or it might appear under TAPI 3). More information about these filters is available in the paper, "An Extensible Framework for RTP Based Multimedia Applications," which appeared in NOSSDAV'97. Cheers, David Putzolu David M. Putzolu, Intel Architecture Labs David.Putzolu@intel.com (503) 264-4510, FAX (503) 264-3483 From rem-conf Mon Apr 20 08:29:15 1998 From rem-conf-request@es.net Mon Apr 20 08:29:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRISm-0005r9-00; Mon, 20 Apr 1998 08:26:32 -0700 Received: from hofmann.cs.berkeley.edu [128.32.35.123] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRISm-0005qy-00; Mon, 20 Apr 1998 08:26:32 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by hofmann.CS.Berkeley.EDU (8.9.0.Beta5/8.6.6.Beta11) with SMTP id IAA25885 for ; Mon, 20 Apr 1998 08:26:31 -0700 (PDT) Message-Id: <3.0.3.32.19980420082630.00b41ca0@postgres.berkeley.edu> X-Sender: ireney@postgres.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 20 Apr 1998 08:26:30 -0700 To: rem-conf@es.net From: Irene Yam Subject: Reminder UCB MM Seminar 4/22 /98 "Emerging Standards In Streaming Multimedia" Rob Lanphier, Real Networks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Emerging Standards In Streaming Multimedia (Wednesday April 22, 1998 12:30-2:00 PDT 405 Soda Hall) Rob Lanphier Real Networks The W3C and the IETF have been hard at work defining standards for streaming multimedia, and a number of these are becoming ready for prime-time. These standards include: RTSP-Real Time Streaming Protocol. RTSP is an IETF Proposed Standard used for the control of on-demand streams in a networked environment. RTP-Real Time Transport Protocol. RTP is another IETF Proposed standard which provides a packet format for multimedia data, and provides a means of interoperation between conferencing solutions and streaming media applications. SDP-Session Description Protocol. SDP is an IETF Proposed Standard used for providing initialization information for multimedia sessions. SMIL-Synchronized Multimedia Integration Language. SMIL (pronounced "smile") is a W3C Working Draft with which one can compose complex multimedia presentations from discrete media clips and images. I'll discuss the latest work with RTSP, RTP, SDP and SMIL, and give examples of real world uses for these standards. -------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40PST (GMT - 8 hrs). See sd or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. ____________________________________________ Irene Yam Berkeley Multimedia Research Center (BMRC) 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: ireney@bmrc.berkeley.edu Url: http://bmrc.berkeley.edu/people/irene/ ____________________________________________ Irene Yam Berkeley Multimedia Research Center (BMRC) 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: ireney@bmrc.berkeley.edu Url: http://bmrc.berkeley.edu/people/irene/ From rem-conf Mon Apr 20 08:45:14 1998 From rem-conf-request@es.net Mon Apr 20 08:45:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRIjP-0006RG-00; Mon, 20 Apr 1998 08:43:43 -0700 Received: from hermes.rz.uni-sb.de [134.96.7.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRIjO-0006R6-00; Mon, 20 Apr 1998 08:43:42 -0700 Received: from sbustd.stud.uni-sb.de (HmHrc89f26xFn1bIeaVy/K0aAbgXVd//@eris.rz.uni-sb.de [134.96.7.8]) by hermes.rz.uni-sb.de (8.8.8/8.8.7/8.7.7) with ESMTP id RAA20276 for ; Mon, 20 Apr 1998 17:42:29 +0200 (CST) Received: from stud.uni-sb.de (nts-202.dfki.uni-sb.de [134.96.189.207]) by sbustd.stud.uni-sb.de (8.8.8/8.8.5) with ESMTP id RAA02375 for ; Mon, 20 Apr 1998 17:43:39 +0200 (CST) Message-ID: <353B7B89.91049987@stud.uni-sb.de> Date: Mon, 20 Apr 1998 17:44:57 +0100 From: Alexei Gromov X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: VAT problems with MS IE? Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, All. Has anyone from you got some problems with running vat 4.0 beta 2 on PC with MS Internet Explorer? I'm getting some errors, but I'm not pretty sure it's cause of MS IE. Thanks, Alexej Gromov From rem-conf Mon Apr 20 08:54:32 1998 From rem-conf-request@es.net Mon Apr 20 08:54:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRIsR-0006vs-00; Mon, 20 Apr 1998 08:53:03 -0700 Received: from hermes.rz.uni-sb.de [134.96.7.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRIsQ-0006vh-00; Mon, 20 Apr 1998 08:53:02 -0700 Received: from sbustd.stud.uni-sb.de (efQS4dZ8rwvq4nH7ZYwbxN9opMSww/90@eris.rz.uni-sb.de [134.96.7.8]) by hermes.rz.uni-sb.de (8.8.8/8.8.7/8.7.7) with ESMTP id RAA20838; Mon, 20 Apr 1998 17:51:49 +0200 (CST) Received: from stud.uni-sb.de (nts-202.dfki.uni-sb.de [134.96.189.207]) by sbustd.stud.uni-sb.de (8.8.8/8.8.5) with ESMTP id RAA03397; Mon, 20 Apr 1998 17:52:59 +0200 (CST) Message-ID: <353B7DB7.13C8E073@stud.uni-sb.de> Date: Mon, 20 Apr 1998 17:54:15 +0100 From: Alexei Gromov X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: tsyed , rem-conf@es.net Subject: Re: RTP References: <3538EB20.149@pc-comp-sol.ca> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list tsyed wrote: > Hi > > I am a Master student of University of Ottawa. My thesis topic is RTP. I > am looking RTP on Window95 or on Window NT platform. I appreciate if > someone can let me know the site from where I can get the RTP. > What do you mean by RTP? Do you need some broadcasting tool that uses RTP or what?If this is the case, try this link: www-nrg.ee.lbl.gov/vat/. To learn about it try www.tascmad.mcg.gla.ac.uk/ . Hope it will help you. Bye. Alexej Gromov From rem-conf Mon Apr 20 13:53:27 1998 From rem-conf-request@es.net Mon Apr 20 13:53:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRNVU-00027i-00; Mon, 20 Apr 1998 13:49:40 -0700 Received: from n1.radiant.net [207.194.200.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRNVT-00027W-00; Mon, 20 Apr 1998 13:49:39 -0700 Received: from maintest (maintest.radiant.net [207.194.200.11]) by n1.radiant.net (8.8.8/8.8.8) with SMTP id NAA22241 for ; Mon, 20 Apr 1998 13:43:50 -0800 (PST) Message-Id: <3.0.32.19980420134933.0092b350@mail.radiant.net> X-Sender: dana@mail.radiant.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 20 Apr 1998 13:49:34 -0700 To: rem-conf@es.net From: dana@radiant.net Subject: Netshow and the MBONE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Greetings ! I have been unicasting audio using Netshow, and want to multicast as we are running out of pipe ! We are using a Cisco 4000 between our LAN and the rest of the world. I am looking for details on utilizing multicast and would be very thankful for information helping me towards this end. If someone would be kind enough to point me in the right direction I would be very appreciative. From rem-conf Mon Apr 20 14:31:12 1998 From rem-conf-request@es.net Mon Apr 20 14:31:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRO8B-000334-00; Mon, 20 Apr 1998 14:29:39 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRO89-00032o-00; Mon, 20 Apr 1998 14:29:37 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id OAA08733; Mon, 20 Apr 1998 14:29:11 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804202129.OAA08733@rah.star-gate.com> To: dana@radiant.net cc: rem-conf@es.net, hasty@rah.star-gate.com Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Mon, 20 Apr 1998 13:49:34 PDT." <3.0.32.19980420134933.0092b350@mail.radiant.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8730.893107751.1@rah.star-gate.com> Date: Mon, 20 Apr 1998 14:29:11 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi ! What is NetShow and can it interoperate with typical Mbone tools such as vic, vat, sdr.. ? Tnks! Amancio From rem-conf Mon Apr 20 15:31:27 1998 From rem-conf-request@es.net Mon Apr 20 15:31:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRP16-00040d-00; Mon, 20 Apr 1998 15:26:24 -0700 Received: from n1.radiant.net [207.194.200.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRP14-00040T-00; Mon, 20 Apr 1998 15:26:22 -0700 Received: from maintest (maintest.radiant.net [207.194.200.11]) by n1.radiant.net (8.8.8/8.8.8) with SMTP id PAA25042 for ; Mon, 20 Apr 1998 15:20:39 -0800 (PST) Message-Id: <3.0.32.19980420152622.00b40100@mail.radiant.net> X-Sender: dana@mail.radiant.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 20 Apr 1998 15:26:22 -0700 To: rem-conf@es.net From: dana@radiant.net Subject: Re: Netshow and the MBONE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Amancio Netshow is a client and server product available for free from Microsoft. I've been running it on NT4 with good results unicasting to about 100 clients worldwide. The problem I am running into is bandwidth (of course), so multicasting is necessary. I simply do not know what it is that I need to know in order to get it going. Regarding interoperability with MBONE tool I can't answer that one. Cheers At 02:29 PM 4/20/98 -0700, you wrote: >Hi ! > >What is NetShow and can it interoperate with typical Mbone tools >such as vic, vat, sdr.. ? > > Tnks! > Amancio > > From rem-conf Mon Apr 20 15:51:42 1998 From rem-conf-request@es.net Mon Apr 20 15:51:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRPN3-0004hn-00; Mon, 20 Apr 1998 15:49:05 -0700 Received: from n1.radiant.net [207.194.200.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRPN1-0004hc-00; Mon, 20 Apr 1998 15:49:04 -0700 Received: from maintest (maintest.radiant.net [207.194.200.11]) by n1.radiant.net (8.8.8/8.8.8) with SMTP id PAA25704 for ; Mon, 20 Apr 1998 15:43:21 -0800 (PST) Message-Id: <3.0.32.19980420154904.00905610@mail.radiant.net> X-Sender: dana@mail.radiant.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 20 Apr 1998 15:49:04 -0700 To: rem-conf@es.net From: dana@radiant.net Subject: Thank you for the response ! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Mon Apr 20 23:31:49 1998 From rem-conf-request@es.net Mon Apr 20 23:31:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRWSU-00000g-00; Mon, 20 Apr 1998 23:23:10 -0700 Received: from artemis.rus.uni-stuttgart.de [129.69.18.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRWSS-00000W-00; Mon, 20 Apr 1998 23:23:08 -0700 Received: from kssun9.rus.uni-stuttgart.de (kssun9.rus.uni-stuttgart.de [129.69.13.19]) by artemis.rus.uni-stuttgart.de (8.8.7/8.8.7) with ESMTP id IAA15921; Tue, 21 Apr 1998 08:23:05 +0200 (MET DST) env-from (wesner@rus.uni-stuttgart.de) Received: from ksat22 (ksat22.rus.uni-stuttgart.de [129.69.13.26]) by kssun9.rus.uni-stuttgart.de (8.8.5/8.8.5) with SMTP id IAA08907; Tue, 21 Apr 1998 08:22:33 +0200 (MET DST) Received: by localhost with Microsoft MAPI; Tue, 21 Apr 1998 08:23:21 +0200 Message-ID: <01BD6CFE.BEFA2740.wesner@rus.uni-stuttgart.de> From: Stefan Wesner To: "'Alexei Gromov'" , "rem-conf@es.net" Subject: RE: VAT problems with MS IE? Date: Tue, 21 Apr 1998 08:23:20 +0200 Organization: RUS Stuttgart X-Mailer: Microsoft Internet E-Mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hallo, I have no problems with IE 3.0, 3.1 or 4.01 installed. -- Stefan Wesner Kommunikationssysteme & BelWue Entwicklung Allmandring 3a mailto:wesner@rus.uni-stuttgart.de 70550 Stuttgart Tel.: +49 711 685 4275 Fax.: +49 711 678 8363 -----Original Message----- From: Alexei Gromov [SMTP:algr0010@stud.uni-sb.de] Sent: Monday, April 20, 1998 6:45 PM To: rem-conf@es.net Subject: VAT problems with MS IE? << File: ATT00004.txt; charset = koi8-r >> From rem-conf Tue Apr 21 02:00:51 1998 From rem-conf-request@es.net Tue Apr 21 02:00:05 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRYrJ-0001YA-00; Tue, 21 Apr 1998 01:56:57 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0yRYrI-0001Vt-00; Tue, 21 Apr 1998 01:56:56 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 21 Apr 1998 09:55:06 +0100 To: dana@radiant.net cc: rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Mon, 20 Apr 1998 15:26:22 PDT." <3.0.32.19980420152622.00b40100@mail.radiant.net> Date: Tue, 21 Apr 1998 09:55:04 +0100 Message-ID: <2487.893148904@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <3.0.32.19980420152622.00b40100@mail.radiant.net>, dana@radiant.net typed: >>Netshow is a client and server product available for free from Microsoft. >>I've been running it on NT4 with good results unicasting to about 100 >>clients worldwide. The problem I am running into is bandwidth (of course), >>so multicasting is necessary. I simply do not know what it is that I need >>to know in order to get it going. >>Regarding interoperability with MBONE tool I can't answer that one. sad, and i guess its what people get for bowing to externalities and going for microsoft products....:-) i guess we'll start to hear all kinds of interesting scaling complaints from h323 wide area users soon too basically, CLIENT SERVER DOESNT scale for multiparty applications, ok - this lesson (from the early 80s) has not yet been learned by a lot of folks..... >> >>Cheers >> >> >>At 02:29 PM 4/20/98 -0700, you wrote: >>>Hi ! >>> >>>What is NetShow and can it interoperate with typical Mbone tools >>>such as vic, vat, sdr.. ? >>> >>> Tnks! >>> Amancio >>> >>> >> cheers jon From rem-conf Tue Apr 21 02:28:16 1998 From rem-conf-request@es.net Tue Apr 21 02:28:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRZIo-0002Kf-00; Tue, 21 Apr 1998 02:25:22 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRZIm-0002KV-00; Tue, 21 Apr 1998 02:25:20 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id CAA13344; Tue, 21 Apr 1998 02:21:07 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804210921.CAA13344@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jon Crowcroft cc: dana@radiant.net, rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Tue, 21 Apr 1998 09:55:04 BST." <2487.893148904@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 02:21:07 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hmm... Whats the difference between a single instance of vic acting just as a server, several vic instances acting as clients vs. Netshow type scenario -- provided of course that the clients are not interactive? Not that I want to defend something like Netshow . 8) Cheers, Amancio > > In message <3.0.32.19980420152622.00b40100@mail.radiant.net>, dana@radiant.net > typed: > > >>Netshow is a client and server product available for free from Microsoft. > >>I've been running it on NT4 with good results unicasting to about 100 > >>clients worldwide. The problem I am running into is bandwidth (of course), > >>so multicasting is necessary. I simply do not know what it is that I need > >>to know in order to get it going. > >>Regarding interoperability with MBONE tool I can't answer that one. > > > sad, and i guess its what people get for bowing to externalities and > going for microsoft products....:-) > > i guess we'll start to hear all kinds of interesting scaling > complaints from h323 wide area users soon too > > basically, CLIENT SERVER DOESNT scale for multiparty applications, ok > - this lesson (from the early 80s) has not yet been learned by a lot > of folks..... > > >> > >>Cheers > >> > >> > >>At 02:29 PM 4/20/98 -0700, you wrote: > >>>Hi ! > >>> > >>>What is NetShow and can it interoperate with typical Mbone tools > >>>such as vic, vat, sdr.. ? > >>> > >>> Tnks! > >>> Amancio > >>> > >>> > >> > > cheers > > jon > > From rem-conf Tue Apr 21 02:35:20 1998 From rem-conf-request@es.net Tue Apr 21 02:35:19 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRZRx-0002ej-00; Tue, 21 Apr 1998 02:34:49 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0yRZRv-0002dn-00; Tue, 21 Apr 1998 02:34:47 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 21 Apr 1998 10:27:05 +0100 To: Amancio Hasty cc: dana@radiant.net, rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Tue, 21 Apr 1998 02:21:07 PDT." <199804210921.CAA13344@rah.star-gate.com> Date: Tue, 21 Apr 1998 10:27:03 +0100 Message-ID: <3408.893150823@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <199804210921.CAA13344@rah.star-gate.com>, Amancio Hasty typed: >>Hmm... >>Whats the difference between a single instance of vic acting just as a server, >>several vic instances acting as clients vs. Netshow type >>scenario -- provided of course that the clients are not >>interactive? for data distribution, not so much.... the main difference is in the control protocol designs... >>Not that I want to defend something like Netshow . 8) oh, there are some nice aspects to netmeeting and netshow... j. From rem-conf Tue Apr 21 02:36:07 1998 From rem-conf-request@es.net Tue Apr 21 02:36:07 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRZSu-0002kM-00; Tue, 21 Apr 1998 02:35:48 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRZSt-0002k6-00; Tue, 21 Apr 1998 02:35:47 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id CAA13457 for ; Tue, 21 Apr 1998 02:35:43 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804210935.CAA13457@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 to: rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Tue, 21 Apr 1998 09:55:04 BST." <2487.893148904@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 02:35:43 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hmm... Whats the difference between a single instance of vic acting just as a server, several vic instances acting as clients vs. Netshow type scenario -- provided of course that the clients are not interactive? Not that I want to defend something like Netshow . 8) Cheers, Amancio From rem-conf Tue Apr 21 02:37:24 1998 From rem-conf-request@es.net Tue Apr 21 02:37:24 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRZTn-0002re-00; Tue, 21 Apr 1998 02:36:43 -0700 Received: from mail.zrz.tu-berlin.de [130.149.4.15] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRZTl-0002jy-00; Tue, 21 Apr 1998 02:36:41 -0700 Received: from ft.ee.TU-Berlin.DE (actually ftsu07.ee.TU-Berlin.DE) by mail.zrz.TU-Berlin.DE with SMTP (IC-PP); Tue, 21 Apr 1998 11:35:14 +0200 Received: from ftsu31 by ft.ee.TU-Berlin.DE (8.8.6/ZRZ-Gen-8) with SMTP id LAA04124 for ; Tue, 21 Apr 1998 11:35:11 +0200 (MET DST) Sender: momuc98@ft.ee.TU-Berlin.DE Message-ID: <353C684E.2F5A@ft.ee.tu-berlin.de> Date: Tue, 21 Apr 1998 11:35:10 +0200 From: momuc98 Organization: Technical University of Berlin X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5 sun4m) MIME-Version: 1.0 To: miint@ft.ee.TU-Berlin.DE Subject: MoMuC'98: 2nd Call for Papers Content-Type: multipart/mixed; boundary="------------33A611597388" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------33A611597388 Content-type: text/plain; charset="us-ascii" Dear Colleague, Enclosed is the 2nd-CFP for MoMuC'98. Please feel free to distribute it to interested colleagues and post it as appropriate. Also, please accept our sincere apologies if you receive multiple copies of this CFP. Best regards Adam Wolisz -- MoMuC'98 --------------33A611597388 Content-type: text/plain; charset="us-ascii"; name="cfp2.txt" Content-transfer-encoding: quoted-printable Content-Disposition: inline; filename="cfp2.txt" X-MIME-Autoconverted: from 8bit to quoted-printable by ft.ee.TU-Berlin.DE id LAA04125 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ MoMuC '98 _/ _/ FIFTH INTERNATIONAL WORKSHOP ON _/ _/ MOBILE MULTIMEDIA COMMUNICATION _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ SECOND CALL FOR PAPERS Berlin, Germany October 12-14, 1998 (immediately after ICUPC`98, Florence, Italy) =20 WWW: http://momuc98.ee.tu-berlin.de=20 email: momuc98@ee.tu-berlin.de Technical Co-Sponsored by IEEE Communication Society Technical Co-Sponsored by ITG (German Information Technologies Society) With support from the European's Commission ACTS Programme WORKSHOP OBJECTIVE:=20 This is the fifth in a series of international work- shops - Tokyo in 1994, Bristol in 1995, Princeton in=20 1996 and Seoul in 1997 - aimed at stimulating tech- nical exchanges in the emerging and strategically=20 important field of Mobile Multimedia Communica- tions. MoMuC'98 is intended to provide a timely=20 forum for exploratory research contributions, and to=20 promote cross-disciplinary technical interactions in=20 an informal setting. The scope of the workshop=20 includes broadband wireless networking for data=20 and multimedia, mobile multimedia system & appli- cations together with associated mobile computing=20 terminals, video processing and software.=20 The workshop goal is to bring together researchers,=20 practitioners and potential users of this emerging=20 technology. The workshop targets at experts in mul- timedia systems, mobility issues in network proto- cols and communication systems. The impact of the=20 workshop is to provide an effective forum for origi- nal and fundamental advances in Mobile Multime- dia Systems and to foster communication among=20 researchers and practitioners working in a wide vari- ety of scientific areas with a common interest in=20 mobile multimedia communication.=20 After the MoMuC'98 Workshop, the First Workshop on Wireless=20 Broadband Testbeds (http://comet.columbia.edu/demo98/),=20 which is co-located with MoMuC'98,=20 will be held on October 15, 1998. TECHNICAL PROGRAM: The 3-day technical program will primarily consist=20 of contributed research papers. In addition, there=20 will be a few distinguished invited speakers and=20 expert panel sessions providing a broad perspective=20 in each technical area. The conference language is=20 english. TECHNICAL TOPICS COVERED INCLUDE=20 (but are not limited to):=20 WIRELESS NETWORKS FOR MULTIMEDIA COMMUNICATION - broadband wireless networks - wireless ATM - voice/data in CDMA & TDMA systems=20 - high-speed wireless modems & radio techniques - medium access/data link control and handoff protocols - quality-of-service (QoS) management in wireless networks - wireless network signaling, control & mobility management - mobile internet protocol=20 - wireless network management & services control MOBILE MULTIMEDIA TERMINAL HARDWARE AND SOFTWARE - multimedia terminal hardware - signal processing techniques - low power VLSI for mobile computing - video compression, including MPEG-4 - network API and transport protocols - software technologies for personal multimedia MOBILE MULTIMEDIA SYSTEMS - mobile computing=20 - optimization of bandwidth use - powers saving - mobility support in ATM and INTERNET - QoS and mobility - adaptive applications - system architectures for mobile multimedia=20 - innovative prototypes, systems & products=20 - multimedia satellite systems=20 - personal multimedia applications=20 We especially invite submissions pertaining to sys- tem approach rather than investigation of individual=20 mechanisms. If individual mechanisms are consid- ered, their relevance to the multimedia communica- tion system should be clearly stated. Papers on all=20 aspects of multimedia mobile communication are=20 welcome. Of particular interest are papers which=20 address the system aspects: design, real-life experi- ences, but relevant papers concerned with individual=20 important mechanisms are also welcome. Authors=20 are invited to submit extended abstracts, clearly stat- ing the problem statement, the approach to its solu- tion, the approach used as well as the main results.=20 In case of system description the new features/ mechanisms should be exposed, in case of contribu- tions concerned with individual mechanisms their=20 relevance for multimedia mobile communication=20 should be stressed.=20 SUBMISSION INFORMATION: Contributions in english are invited in the form of=20 extended abstracts (about 1500 words) which should=20 be submitted electronically before May 14, 1998. All submitted papers will be refereed for quality,=20 correctness, originality and relevance. The program=20 committee reserves the right to accept a submission=20 as full paper or poster presentation. All accepted=20 papers will be published in the conference proceed- ings. Authors will be interested to know that issuing=20 a book containing outstanding papers from the=20 Workshop is being planned.=20 To submit a paper send an email to momuc98@ee.tu-berlin.de=20 including: - a cover sheet, which contains:=20 * title,=20 * author(s), * author's affiliation,=20 * email address(es),=20 * fax number and=20 * postal address. * In case of multiple authors, the author's name=20 which is responsible for correspondence and preparing the camera ready paper for the proceedings. - the submitted paper (single spaced, 10 point Times font,=20 A4 paper, Postscript or PDF format) as attachment. =20 All printed material (text, illustrations) must be kept=20 within a print area of 6-7/8 inches (17.5 cm) wide=20 by 8-7/8 inches (22.54 cm) high.=20 On all pages, the bottom margin should be=20 approximately 1-5/8 inches (4.13 cm) from the=20 bottom edge of the page (A4 paper).=20 If it is not possible to submit via email, send five copies of=20 the manuscript to the following address, including a cover sheet with the above mentioned informations.=20 Submission address for hardcopies: Prof. Dr.-Ing. Adam Wolisz TU Berlin, Sekr.FT-5-2, Einsteinufer 25 10587 Berlin, Germany We also try to arrange financial support for authors=20 of accepted papers coming from Middle- or Eastern European countries.=20 Please, if you would like to be considered for support=20 send an email to momuc98@ee.tu-berlin.de asking for more details,=20 or check the workshop's web-page. WORKSHOP CHAIR: Adam Wolisz (Technical University of Berlin) STEERING COMMITTEE: =20 D. Goodman (Rutgers University) D. Raychaudhuri (NEC, Princeton) =20 H. Tominaga (Waseda University Tokyo)=20 TECHNICAL PROGRAMM COMMITTEE: Y. Akaiwa, Kyushuu University V. Bahl, Microsoft Research E. Bonek, TU Wien A. Campbell, Columbia University K. David, T-Mobil N. Davies, Lancaster University G. Fettweis, TU Dresden Z. Haas, Cornell University T. Hattori, Sophia University Tokyo R. Jain, UC Los Angeles M. Karol, Lucent Technologies R. Kr=E4mer, Phillips Research P. K=FChn, Universit=E4t Stuttgart K. S. Kwak, Inha University Seoul G. Maguire, KTH Stockholm H. Mitts, Nokia P. Noll, TU Berlin S. Pink, Lulea University G. Polyzos, UC San Diego K. Sabnani, Bell Labs O. Spaniol, RWTH Aachen S. Thome, ENST C.-K. Toh, Hughes Research Labs B. Walke, RWTH Aachen A. Wolisz, TU Berlin R. Popescu-Zeletin, GMD Fokus IMPORTANT DATES: Submission Deadline: May 14, 1998=20 Notification of Acceptance: June 12, 1998=20 Camera Ready Full Paper: August 14, 1998=20 Venue: October 12-14, 1998 VENUE:=20 MoMuC `98 will be held in Berlin, the city which=20 after 40 years of splitting is now the live symbol of=20 the German reunification, and on its way to the grow=20 into the role of the German capital. It is currently=20 one of the largest construction sites worldwide. On=20 the other hand it is also a city of industry, the place=20 where the first tram worldwide was operating, where glo- bal companies like Siemens started off and still have=20 a strong position. Nowadays Berlin is changing its=20 economic role away from mainly industrial to=20 become a service-oriented gateway to the new=20 democracies in Eastern Europe. Located between=20 numerous lakes it has more bridges than Venice,=20 Italy within its city limits. It is a vibrant cultural=20 metropolis, with 3 Opera Houses, several Musicals=20 Houses and hundreds of theaters. It offers a very=20 exiting and surprising nightlife scene with countless=20 restaurants, bars, clubs and galleries.=20 FOR MORE INFORMATIONS: visit our WWW site at: http://momuc98.ee.tu-berlin.de/ or mail your questions, comments and suggestions to momuc98@ee.tu-berlin.de ------------------------------------------- Telecommunication Networks Group (TKN) at the Department of Electrical Engineering=20 of Technical University of Berlin: http://www-tkn.ee.tu-berlin.de --------------33A611597388-- From rem-conf Tue Apr 21 03:06:18 1998 From rem-conf-request@es.net Tue Apr 21 03:06:17 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRZs5-0004ak-00; Tue, 21 Apr 1998 03:01:49 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRZs3-0004aa-00; Tue, 21 Apr 1998 03:01:47 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id CAA13559; Tue, 21 Apr 1998 02:55:31 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804210955.CAA13559@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jon Crowcroft cc: dana@radiant.net, rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Tue, 21 Apr 1998 10:27:03 BST." <3408.893150823@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 02:55:31 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thats interesting so Netshow's control protocol is not scalable ? About netmeeting and netshow having good features besides their H.323 stacks which costs upwards of $100, 000 to license whats good about them? And yes, I heard that if I run win95 I can get a free h.323 stack provided that I install netmeeting or the Intel video phone thingie. Sorry me being a FreeBSD hacker the only good thing I see with Netmeeting or Netshow is their h.323 stack 8) Cheers, Amancio From rem-conf Tue Apr 21 10:15:43 1998 From rem-conf-request@es.net Tue Apr 21 10:15:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRgYL-0002KS-00; Tue, 21 Apr 1998 10:09:53 -0700 Received: from n1.radiant.net [207.194.200.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRgYJ-0002KH-00; Tue, 21 Apr 1998 10:09:52 -0700 Received: from maintest (maintest.radiant.net [207.194.200.11]) by n1.radiant.net (8.8.8/8.8.8) with SMTP id KAA25298; Tue, 21 Apr 1998 10:03:42 -0800 (PST) Message-Id: <3.0.32.19980421100927.009e05a0@mail.radiant.net> X-Sender: dana@mail.radiant.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 21 Apr 1998 10:09:33 -0700 To: Jon Crowcroft From: dana@radiant.net Subject: Re: Netshow and the MBONE Cc: rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list With respect to you Jon, Obviously your knowledge of the topic is deeper than mine. It is clear that you know this. Do you have anthing to offer which addresses my original question directly ? The last thing this group needs is any sort of huge flames, Jon, so I'm not going there with this. I asked a simple question which I think is on topic. If you can assist then thank you very much, otherwise what is the point of using my question to support your "sadness over bowing to externalities...:-)" ? Here to learn, not to burn. At 09:55 AM 4/21/98 +0100, Jon Crowcroft wrote: > >In message <3.0.32.19980420152622.00b40100@mail.radiant.net>, dana@radiant.net >typed: > > >>Netshow is a client and server product available for free from Microsoft. > >>I've been running it on NT4 with good results unicasting to about 100 > >>clients worldwide. The problem I am running into is bandwidth (of course), > >>so multicasting is necessary. I simply do not know what it is that I need > >>to know in order to get it going. > >>Regarding interoperability with MBONE tool I can't answer that one. > > >sad, and i guess its what people get for bowing to externalities and >going for microsoft products....:-) > >i guess we'll start to hear all kinds of interesting scaling >complaints from h323 wide area users soon too > >basically, CLIENT SERVER DOESNT scale for multiparty applications, ok >- this lesson (from the early 80s) has not yet been learned by a lot >of folks..... > > >> > >>Cheers > >> > >> > >>At 02:29 PM 4/20/98 -0700, you wrote: > >>>Hi ! > >>> > >>>What is NetShow and can it interoperate with typical Mbone tools > >>>such as vic, vat, sdr.. ? > >>> > >>> Tnks! > >>> Amancio > >>> > >>> > >> > > cheers > > jon > > > From rem-conf Tue Apr 21 10:36:55 1998 From rem-conf-request@es.net Tue Apr 21 10:36:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRgwc-00035e-00; Tue, 21 Apr 1998 10:34:58 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRgwb-00035U-00; Tue, 21 Apr 1998 10:34:57 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id KAA15007; Tue, 21 Apr 1998 10:34:21 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804211734.KAA15007@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: dana@radiant.net cc: Jon Crowcroft , rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Tue, 21 Apr 1998 10:09:33 PDT." <3.0.32.19980421100927.009e05a0@mail.radiant.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 10:34:21 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sorry about that and you are not the target . There is a lot politics being played in the background concerning audio/video and to make matters worse someone once posted that it was nearly impossible to come up with a new codec for either video or audio without first infringing on a existing patent. You do have a valid question however most of us here are used to easily accessible audio/video/text mbone tools and of which NetShow or NetMeeting appears not to be part of . Over the last few years we have conducted extensive network tests with tools such as vic , vat and sdr . One of the things that comes to mind is that in the case of vic or vat they can report transmission or reception stats and I am not sure that you can do that with NetXXX ; additionally, it is probably well not understood how NetXXX will behave in large scale deployment in the Mbone given its strict Microsoft nature it is kind of hard to help out. Why am I saying this ? Just in case you don't get a lot of cooperation from the list. Good Luck, Amancio From rem-conf Tue Apr 21 10:49:03 1998 From rem-conf-request@es.net Tue Apr 21 10:49:03 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRh9E-0003a4-00; Tue, 21 Apr 1998 10:48:00 -0700 Received: from n1.radiant.net [207.194.200.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRh9D-0003Zt-00; Tue, 21 Apr 1998 10:47:59 -0700 Received: from maintest (maintest.radiant.net [207.194.200.11]) by n1.radiant.net (8.8.8/8.8.8) with SMTP id KAA26741 for ; Tue, 21 Apr 1998 10:42:14 -0800 (PST) Message-Id: <3.0.32.19980421104758.0092c2d0@mail.radiant.net> X-Sender: dana@mail.radiant.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 21 Apr 1998 10:47:59 -0700 To: rem-conf@es.net From: dana@radiant.net Subject: MBONE tools and Netsow Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To all, Thanks for the considerate responses. I will continue to read & learn from your experiences, and hopefully be able to add something for someone else in the future. Good luck ! From rem-conf Tue Apr 21 12:50:26 1998 From rem-conf-request@es.net Tue Apr 21 12:50:25 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRizG-0006G6-00; Tue, 21 Apr 1998 12:45:50 -0700 Received: from ns10.nokia.com [131.228.6.229] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRizE-0006FG-00; Tue, 21 Apr 1998 12:45:49 -0700 Received: from pepper.research.nokia.com (pepper.research.nokia.com [131.228.12.3]) by ns10.nokia.com (8.8.8/8.6.9) with SMTP id WAA20586 for ; Tue, 21 Apr 1998 22:44:44 +0300 (EET DST) Received: (from smap@localhost) by pepper.research.nokia.com (8.6.13/8.6.13) id WAA15514; Tue, 21 Apr 1998 22:44:36 +0300 Received: from nrchub01he.research.nokia.com(131.228.10.247) by pepper.research.nokia.com via smap (V1.3) id sma015501; Tue Apr 21 22:43:51 1998 Received: from Microsoft Mail (PU Serial #1751) by nrchub01he.research.nokia.com (PostalUnion/SMTP(tm) v2.1.9h for Windows NT(tm)) id AA-1998Apr21.223300.1751.1787636; Tue, 21 Apr 1998 22:44:39 +0200 From: roberta.eklund@research.nokia.com (Eklund Roberta NRC/Tre) To: dana@radiant.net (dana), hasty@rah.star-gate.com (EXT Amancio Hasty) Cc: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft), rem-conf@es.net (rem-conf) Message-ID: <1998Apr21.223300.1751.1787636@nrchub01he.research.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 21 Apr 1998 22:44:39 +0200 Subject: RE: Netshow and the MBONE X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Amancio, You mention in your mail extensive network test with tools such as vic, vat and sdr. Can I obtain a document reference or URL quoting the statistics? Best Regards, Roberta Eklund Research Engineer Nokia Research Center ---------- From: EXT Amancio Hasty Sent: Tuesday, April 21, 1998 10:34 AM To: dana Cc: Jon Crowcroft; rem-conf Subject: Re: Netshow and the MBONE Precedence: list Sorry about that and you are not the target . There is a lot politics being played in the background concerning audio/video and to make matters worse someone once posted that it was nearly impossible to come up with a new codec for either video or audio without first infringing on a existing patent. You do have a valid question however most of us here are used to easily accessible audio/video/text mbone tools and of which NetShow or NetMeeting appears not to be part of . Over the last few years we have conducted extensive network tests with tools such as vic , vat and sdr . One of the things that comes to mind is that in the case of vic or vat they can report transmission or reception stats and I am not sure that you can do that with NetXXX ; additionally, it is probably well not understood how NetXXX will behave in large scale deployment in the Mbone given its strict Microsoft nature it is kind of hard to help out. Why am I saying this ? Just in case you don't get a lot of cooperation from the list. Good Luck, Amancio From rem-conf Tue Apr 21 15:21:29 1998 From rem-conf-request@es.net Tue Apr 21 15:21:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRlMs-0000oB-00; Tue, 21 Apr 1998 15:18:22 -0700 Received: from mailgate2.boeing.com [199.238.248.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRlMr-0000nz-00; Tue, 21 Apr 1998 15:18:21 -0700 Received: from xch-pssbh-01.ca.boeing.com ([192.42.211.28]) by mailgate2.boeing.com (8.8.5/8.8.5) with ESMTP id PAA00639 for ; Tue, 21 Apr 1998 15:18:18 -0700 (PDT) Received: by xch-pssbh-01.ca.boeing.com with Internet Mail Service (5.0.1458.49) id <2RMDG20R>; Tue, 21 Apr 1998 15:18:31 -0700 Message-ID: From: "Fleischman, Eric W" To: rem-conf@es.net, "'dana@radiant.net'" Subject: RE: Netshow and the MBONE Date: Tue, 21 Apr 1998 15:18:24 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list NetShow supports both Unicast and Multicast transmissions. The online help files which come with the NetShow Server application explain how to do either. For more direct help, I recommend that you consider contacting Microsoft directly via the established support channels (e.g., http://www.microsoft.com/netshow/support.htm). > ---------- > From: dana@radiant.net[SMTP:dana@radiant.net] > Sent: Monday, April 20, 1998 1:49 PM > To: rem-conf@es.net > Subject: Netshow and the MBONE > > Greetings ! > > I have been unicasting audio using Netshow, and want to multicast as > we are > running out of pipe ! > We are using a Cisco 4000 between our LAN and the rest of the world. I > am > looking for details on utilizing multicast and would be very thankful > for > information helping me towards this end. If someone would be kind > enough to > point me in the right direction I would be very appreciative. > > > From rem-conf Tue Apr 21 20:14:22 1998 From rem-conf-request@es.net Tue Apr 21 20:14:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRpuJ-0003f1-00; Tue, 21 Apr 1998 20:09:11 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRpuH-0003el-00; Tue, 21 Apr 1998 20:09:10 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id UAA17024; Tue, 21 Apr 1998 20:09:01 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804220309.UAA17024@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Fleischman, Eric W" cc: rem-conf@es.net, "'dana@radiant.net'" Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Tue, 21 Apr 1998 15:18:24 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 20:09:01 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >NetShow supports both Unicast and Multicast transmissions. The online Thats interesting so do WinXX support mrouted or do the clients still have to rely on the LAN to provide ip multicasting? I would say that for now unless is limited to intra-net which support ip multicast it makes no sense for a provider to start broadcasting ip multicast contents given that for 99.999 percent of the WinXXX clients can not be connected to the MBONE. The other issue is can the MBONE support thousands of Netshow servers 8) Amancio From rem-conf Tue Apr 21 21:10:55 1998 From rem-conf-request@es.net Tue Apr 21 21:10:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRqqF-0004RV-00; Tue, 21 Apr 1998 21:09:03 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRqqE-0004RK-00; Tue, 21 Apr 1998 21:09:02 -0700 Received: from cflat.precept.com (cflat.precept.com [204.162.117.199]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id VAA22183; Tue, 21 Apr 1998 21:07:25 -0700 (PDT) Date: Tue, 21 Apr 1998 21:07:35 -0700 (PDT) From: Karl Auerbach Reply-To: Karl Auerbach To: Amancio Hasty cc: rem-conf@es.net Subject: Re: Netshow and the MBONE In-Reply-To: <199804220309.UAA17024@rah.star-gate.com> Message-ID: X-X-Sender: karl@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It's not often I defend Microsoft... ;-) Windows 95 (and 98) and NT (4 and 5) *do* support IP multicast. They use IGMP v1 (or, in newer versions, IGMP v2). As an existance proof that it is possible to build MBone compatable applications on those platforms: The Precept (oops, we are now Cisco) IP/TV uses the native Microsoft provided multicast facilities for both our servers and our viewers. I figure that if we can do it, so can Microsoft (but I'll claim we do it better ;-) We mainly use native multicast on the net, but we do bring our MBONE feed in the normal way, via a tunnel into a router or into a mrouted (we do both.) (At Interop I'll be showing a version of IP/TV that uses Microsoft's "generic QoS" API to establish RSVP reservations for the multicast RTP/RTCP streams sent and received by IP/TV.) As for the question whether the MBone can support thousands of PC-based audio/video servers: It is better that it is done using IP Multicast than by using redundant unicast streams. --karl-- From rem-conf Tue Apr 21 21:52:10 1998 From rem-conf-request@es.net Tue Apr 21 21:52:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRrTr-00057e-00; Tue, 21 Apr 1998 21:49:59 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRrTp-00057U-00; Tue, 21 Apr 1998 21:49:58 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id VAA17280; Tue, 21 Apr 1998 21:49:50 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804220449.VAA17280@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Karl Auerbach cc: rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Tue, 21 Apr 1998 21:07:35 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 21:49:49 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Me too, I don't defend Microsoft however in their case as I pointed out since most of ISP (I think ) are targetting their streams to home users it makes no sense for ISPs with just a Microsoft solution to broadcast ip multicast streams. Not if people get a Cisco router or a PC running FreeBSD in their home is a different story -- shameless plug 8) As to Netshow and the MBONE we will see , my prediction unless we controll access to the MBONE we ain't going to have an MBONE. Cheers, Amancio From rem-conf Tue Apr 21 22:33:31 1998 From rem-conf-request@es.net Tue Apr 21 22:33:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRs7p-0005sX-00; Tue, 21 Apr 1998 22:31:17 -0700 Received: from proxy4.ba.best.com [206.184.139.15] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRs7o-0005sN-00; Tue, 21 Apr 1998 22:31:16 -0700 Received: from mg130-146.ricochet.net (mg130-146.ricochet.net [204.179.130.146]) by proxy4.ba.best.com (8.8.8/8.8.BEST) with SMTP id WAA04919 for ; Tue, 21 Apr 1998 22:30:27 -0700 (PDT) Message-Id: <3.0.5.16.19980421212145.268f5fa2@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Tue, 21 Apr 1998 21:21:45 To: rem-conf@es.net From: Ross Finlayson Subject: Re: Netshow and the MBONE In-Reply-To: <199804220449.VAA17280@rah.star-gate.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 09:49 PM 4/21/98 -0700, Amancio Hasty wrote: >...since most of ISP (I think ) are targetting their streams to >home users it makes no sense for ISPs with just a Microsoft solution >to broadcast ip multicast streams. However, a media server (NetShow or other) can (I presume) send n unicast streams *as well as* a single multicast stream. So, those clients that support multicast (& this includes increasingly many home users, BTW) can tune into the (single) multicast stream; other clients would get their own unicast stream. Ross. From rem-conf Tue Apr 21 23:00:36 1998 From rem-conf-request@es.net Tue Apr 21 22:59:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRsVs-0006ZP-00; Tue, 21 Apr 1998 22:56:08 -0700 Received: from necom830.hpcl.titech.ac.jp [131.112.32.132] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRsVq-0006Z6-00; Tue, 21 Apr 1998 22:56:07 -0700 From: Masataka Ohta Message-Id: <199804220542.OAA08499@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA08499; Wed, 22 Apr 1998 14:41:47 +0859 Subject: Re: Netshow and the MBONE To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Wed, 22 Apr 98 14:41:46 JST Cc: dana@radiant.net, rem-conf@es.net, confctrl@isi.edu In-Reply-To: <2487.893148904@cs.ucl.ac.uk>; from "Jon Crowcroft" at Apr 21, 98 9:55 am X-Mailer: ELM [version 2.3 PL11] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jon; This message is sent also to confctrl. > In message <3.0.32.19980420152622.00b40100@mail.radiant.net>, dana@radiant.net > typed: > > >>Netshow is a client and server product available for free from Microsoft. > >>I've been running it on NT4 with good results unicasting to about 100 > >>clients worldwide. The problem I am running into is bandwidth (of course), > >>so multicasting is necessary. I simply do not know what it is that I need > >>to know in order to get it going. > >>Regarding interoperability with MBONE tool I can't answer that one. > > > sad, and i guess its what people get for bowing to externalities and > going for microsoft products....:-) > > i guess we'll start to hear all kinds of interesting scaling > complaints from h323 wide area users soon too > > basically, CLIENT SERVER DOESNT scale for multiparty applications, ok > - this lesson (from the early 80s) has not yet been learned by a lot > of folks..... Right. But, it is better to tell it in MMUSIC as a criticism on SIP. SIP is unnecessary for unicast. SIP doesn't scale for multiparty applications. Masataka Ohta From rem-conf Tue Apr 21 23:13:10 1998 From rem-conf-request@es.net Tue Apr 21 23:13:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRskY-00079Y-00; Tue, 21 Apr 1998 23:11:18 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRskW-00079L-00; Tue, 21 Apr 1998 23:11:17 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id XAA17592; Tue, 21 Apr 1998 23:11:09 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804220611.XAA17592@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Ross Finlayson cc: rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Tue, 21 Apr 1998 21:21:45." <3.0.5.16.19980421212145.268f5fa2@shell7.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 23:11:08 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list True however the original posters plead was to start streaming to I presumed the mbone because of bandwith limitations and I sincerely doubt that their site consists of only one unique stream. Let me put it another way. http://www.thinker.org is a 3 teryabyte image database consisting of a small farm of FreeBSD boxes (about 20 systems). How would you like if such FreeBSD farms start pumping out audio/video streams into the network? ftp.freebsd.org is pumping out a few terabytes per month on some days we hit 120 Gigs /day and ftp.freebsd.org a (a single cpu) right now is mostly limited by the Net. The above freebsd sites are nothing compared to thousands of netshow servers pumping out audio/video streams be it unicast or multi-cast and don't forget unless you run winxx you can't par take 8) Perhaps is time to start charging commercial sites for MBONE use and use the funds to support and expand the MBONE. Regards, Amancio > However, a media server (NetShow or other) can (I presume) send n unicast > streams *as well as* a single multicast stream. So, those clients that > support multicast (& this includes increasingly many home users, BTW) can > tune into the (single) multicast stream; other clients would get their own > unicast stream. > Ross. From rem-conf Wed Apr 22 03:06:37 1998 From rem-conf-request@es.net Wed Apr 22 03:06:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRwFv-00028C-00; Wed, 22 Apr 1998 02:55:55 -0700 Received: from listbox2.cern.ch [137.138.24.200] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRwFu-00027m-00; Wed, 22 Apr 1998 02:55:54 -0700 Received: from cern.ch (pcitcs04.cern.ch [137.138.33.126]) by listbox2.cern.ch (8.8.8/8.8.8) with ESMTP id LAA16771; Wed, 22 Apr 1998 11:53:47 +0200 (MET DST) X-Authentication-Warning: listbox2.cern.ch: Host pcitcs04.cern.ch [137.138.33.126] claimed to be cern.ch Message-ID: <353DBE2A.BB427C1@cern.ch> Date: Wed, 22 Apr 1998 11:53:46 +0200 From: Miguel CHAMOCHIN GOMEZ Organization: CERN X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Amancio Hasty CC: "rem-conf@es.net" , "mbone@ISI.EDU" Subject: Re: wrtpVoD-v0.1 & wrtp-v0.2 Announcement References: <199804171636.JAA03966@rah.star-gate.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have no freeBSD machine accessible. Miguel. Amancio Hasty wrote: > > Are there any FreeBSD binaries available or are the sources available > for wrtpVod? > > Tnks, > Amancio -- Miguel Angel Chamochin Gomez Information Technology Division CERN CH-1211 Geneve 23 SWITZERLAND Phone: +41-22-767-9703 Fax: +41-22-767-7155 e-mail: mangel@mail.cern.ch Miguel.Chamochin@cern.ch --- "Would you tell me, please, which way I ought to go from here?" "That depends a good deal on where you want to get to." - Lewis Carrol, Alice in Wonderland ----- From rem-conf Wed Apr 22 05:55:07 1998 From rem-conf-request@es.net Wed Apr 22 05:55:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRyx7-0004Mb-00; Wed, 22 Apr 1998 05:48:41 -0700 Received: from cepheid.physics.gla.ac.uk [130.209.45.251] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yRyx5-0004KT-00; Wed, 22 Apr 1998 05:48:40 -0700 Received: from a5.ph.gla.ac.uk (a5.ph.gla.ac.uk [194.36.1.167]) by cepheid.physics.gla.ac.uk (8.8.5/8.8.5) with ESMTP id NAA13793; Wed, 22 Apr 1998 13:41:35 +0100 (BST) Received: from localhost (flavell@localhost) by a5.ph.gla.ac.uk (8.8.8/8.8.8) with SMTP id NAA08683; Wed, 22 Apr 1998 13:47:28 +0100 (BST) Date: Wed, 22 Apr 1998 13:47:27 +0100 (BST) From: "Alan J. Flavell" Reply-To: A.Flavell@physics.gla.ac.uk To: Karl Auerbach cc: Amancio Hasty , rem-conf@es.net Subject: Re: Netshow and the MBONE In-Reply-To: Message-ID: X-antiSpam: Do not send me unsolicited commercial email MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Tue, 21 Apr 1998, Karl Auerbach wrote: > Windows 95 (and 98) and NT (4 and 5) *do* support IP multicast. I don't think that comes as any surprise to those of us who have been using the MBone apps in multicast mode on those platforms for some time. Surely the question was not whether one can run multicast apps (it's well known that one can), but how an arbitrary PC somewhere out on the Internet is supposed to get multicast connectivity to elsewhere. Hence the question about "mrouted". From rem-conf Wed Apr 22 06:35:17 1998 From rem-conf-request@es.net Wed Apr 22 06:35:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yRzdN-0005mI-00; Wed, 22 Apr 1998 06:32:21 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0yRzdM-0005m8-00; Wed, 22 Apr 1998 06:32:20 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id JAA11089; Wed, 22 Apr 1998 09:31:57 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Amancio Hasty cc: Karl Auerbach , rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Tue, 21 Apr 1998 21:49:49 PDT." <199804220449.VAA17280@rah.star-gate.com> Date: Wed, 22 Apr 1998 09:31:57 -0400 Message-ID: <11087.893251917@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >As to Netshow and the MBONE we will see , my prediction unless >we controll access to the MBONE we ain't going to have an >MBONE. I disagree with you here - if anything kills the Mbone it will be apathy. ISPs will provide multicast when their customers demand it, when they think they can do so without damaging service for unicast traffic, and when they think it won't damage their business model. So, for multicast to become ubiquitous, we need several things: - content. high volume and high quality. - many many users that want it. - solutions that improve quality (audio repair techniques, diffserv, ECN, possibly RSVP (though I don't really believe in RSVP for end-to-end call setup), multicast congestion control. - technical solutions that help multicast routing scale. Personally I believe in BGMP as a key part of this. - stable router implementations. Without all these the Mbone will not become ubiquitous. The last three, we (the Internet engineering community) are working on. The first two are something of a problem. Without compelling content, users get bored and go away. Without many users, no-one provides good quality content. Vendors (like Vxtreme) have been know to pay very large amounts of money to content providers to use their software for exactly this reason. Controlling access to the Mbone is probably the surest way to ensure that it eventually fades away. When Microsoft implement open standards, we should applaud them, not attempt to put up barriers! When a rapidly increasing user-base causes technical issues to arise, we fix those issues. That's the way of the Internet. If we're lucky, we're ahead of the growth curve. If we're not, things get bad for a while until we get back on the curve. But not having a growth curve to be ahead of is the worst fate... Cheers, Mark From rem-conf Wed Apr 22 07:03:08 1998 From rem-conf-request@es.net Wed Apr 22 07:03:07 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS02y-0006Vb-00; Wed, 22 Apr 1998 06:58:48 -0700 Received: from plains.nodak.edu [134.129.111.64] (hoag) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS02u-0006VI-00; Wed, 22 Apr 1998 06:58:47 -0700 Received: from localhost (hoag@localhost) by plains.NoDak.edu (8.8.8/8.8.8) with SMTP id IAA32619 for ; Wed, 22 Apr 1998 08:58:11 -0500 (CDT) Date: Wed, 22 Apr 1998 08:58:11 -0500 (CDT) From: Marty Hoag To: rem-conf@es.net Subject: Re: Netshow and the MBONE In-Reply-To: <199804220449.VAA17280@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Tue, 21 Apr 1998, Amancio Hasty wrote: > As to Netshow and the MBONE we will see , my prediction unless > we controll access to the MBONE we ain't going to have an > MBONE. Isn't elimination of MBone our goal? My understanding is that the MBone is an experimental network which should lead to ubiquitous "native" IP multicast availability throughout the Internet once the protocols are developed? Mass numbers of users of IP multicast may be daunting but the alternative of the same number of users using unicast is not so attractive either. I realize the ISPs like unicast because the billing model is easier to understand but I think that is sort of short-sighted. Marty From rem-conf Wed Apr 22 07:39:07 1998 From rem-conf-request@es.net Wed Apr 22 07:39:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS0dz-0007TK-00; Wed, 22 Apr 1998 07:37:03 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS0dx-0007TA-00; Wed, 22 Apr 1998 07:37:02 -0700 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA25972; Wed, 22 Apr 1998 10:36:59 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA05140; Wed, 22 Apr 1998 10:36:54 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <353E0085.47D145B7@cs.columbia.edu> Date: Wed, 22 Apr 1998 10:36:53 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Mark Handley CC: Amancio Hasty , Karl Auerbach , rem-conf@es.net Subject: Re: Netshow and the MBONE References: <11087.893251917@north.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark Handley wrote: > > >As to Netshow and the MBONE we will see , my prediction unless > >we controll access to the MBONE we ain't going to have an > >MBONE. > > I disagree with you here - if anything kills the Mbone it will be > apathy. ISPs will provide multicast when their customers demand it, > when they think they can do so without damaging service for unicast > traffic, and when they think it won't damage their business model. > > So, for multicast to become ubiquitous, we need several things: > > - content. high volume and high quality. > > - many many users that want it. Playing devil's advocate here :-) It seems instructive to look at recent audience statistics. The type of events and the audience numbers seem to have decreased, if anything, >from numbers in 1994 (say). When I peeked at the vat window at IETF, there were maybe a dozen names. The operator confirmed that this was not atypical. For the Infocom transmission, we had maybe ten listeners, max, with 3 or 4 more typical. Windows on the world has about 20; MAGIC 94 about 4 (including myself, for testing). This is during a time (10 am) when Europe is still around... I know that a number of people are behind firewalls and don't send RTCP reports, but I doubt that this would more than double the audience. Even most research labs haven't enabled (or have shut down again) multicast ingress, from what I can tell. All of NYC (courtesy of Sprintnet) get Mbone at an average loss rate of 50-80%, so if this is at all typical, this is not surprising. This argument has been made elsewhere and earlier, but most people I talked to about Infocom distribution care very little about hearing whole sessions live. (They'd be at Infocom if they had the time.) They want selected talks (and often want to fast-forward through the introduction), at their convenience, i.e., unicast. Any sufficiently compelling mass-audience content is - likely available on broadcast TV, radio, cable, pay-TV or on tape, at far better quality and with less hassle - or is not suited for minors - not particularly enjoyable at 28 kb/s or even 280 kb/s. Multicast makes sense (as IP/TV demonstrates) for *local* redistribution of content such as CNN. For now, having a bunch of local feeds of this type of fare seems far more efficient, as I can significantly ramp up the bandwidth. Henning From rem-conf Wed Apr 22 07:39:08 1998 From rem-conf-request@es.net Wed Apr 22 07:39:08 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS0ec-0007Ti-00; Wed, 22 Apr 1998 07:37:42 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0yS0eb-0007TY-00; Wed, 22 Apr 1998 07:37:41 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id KAA11329; Wed, 22 Apr 1998 10:37:38 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Marty Hoag cc: rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Wed, 22 Apr 1998 08:58:11 CDT." Date: Wed, 22 Apr 1998 10:37:37 -0400 Message-ID: <11327.893255857@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Isn't elimination of MBone our goal? My understanding is that the >MBone is an experimental network which should lead to ubiquitous "native" >IP multicast availability throughout the Internet once the protocols are >developed? I agree with the sentiment. I'm not sure about the terminology though. I know people use the term "Mbone" to mean two different things: 1. The network of _tunnels_ between mrouted's. 2. That part of the Internet that supposts multicast (native or not). Personally I tend to use the latter definition. According the Piete Brookes' mbone stats page (http://www.cl.cam.ac.uk:80/cgi-bin/mr-vers?league=1) 67% of the 3500 multicast routers that mcollect can get a response from are Cisco routers. I can't tell what proportion of links are running native multicast from the stats, but we can at least conclude that mrouted isn't the predominant multicast router these days. Cheers, Mark From rem-conf Wed Apr 22 07:39:12 1998 From rem-conf-request@es.net Wed Apr 22 07:39:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS0fP-0007U2-00; Wed, 22 Apr 1998 07:38:31 -0700 Received: from nettrix.mediatrix.com [205.237.248.99] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS0fO-0007Ts-00; Wed, 22 Apr 1998 07:38:30 -0700 Received: by nettrix.mediatrix.com with Internet Mail Service (5.5.1960.3) id ; Wed, 22 Apr 1998 10:29:56 -0400 Message-ID: From: Francois Menard To: 'Masataka Ohta' , J.Crowcroft@cs.ucl.ac.uk Cc: dana@radiant.net, rem-conf@es.net, confctrl@isi.edu Subject: RE: Netshow and the MBONE Date: Wed, 22 Apr 1998 10:29:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > SIP is unnecessary for unicast. Could you substantialize a little bit ... -=Francois=- From rem-conf Wed Apr 22 08:07:16 1998 From rem-conf-request@es.net Wed Apr 22 08:07:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS10G-0001Y8-00; Wed, 22 Apr 1998 08:00:04 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS10E-0001Wt-00; Wed, 22 Apr 1998 08:00:02 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id HAA20154; Wed, 22 Apr 1998 07:58:35 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804221458.HAA20154@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Henning Schulzrinne cc: Mark Handley , Karl Auerbach , rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Wed, 22 Apr 1998 10:36:53 EDT." <353E0085.47D145B7@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Apr 1998 07:58:35 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Any sufficiently compelling mass-audience content is > - likely available on broadcast TV, radio, cable, pay-TV or on tape, at > far better quality and with less hassle > - or is not suited for minors > - not particularly enjoyable at 28 kb/s or even 280 kb/s. A couple of years ago I wathched the Mean Fiddler Concert out of Ireland -- had a great time listening to the broadcast however I doubt that bigger enterprises were interested in carrying the content . For scenarios that the media moguls decide that they don't want to carry , ip multicast is an attractive alternative. Local redistribution or local distribution is a great idea and a easy way for ISPs to differentiate themselves. Amancio From rem-conf Wed Apr 22 08:12:12 1998 From rem-conf-request@es.net Wed Apr 22 08:12:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS1B6-0001v6-00; Wed, 22 Apr 1998 08:11:16 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS1B5-0001ut-00; Wed, 22 Apr 1998 08:11:15 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.7/8.8.7) with SMTP id LAA00904; Wed, 22 Apr 1998 11:04:04 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id LAA14407; Wed, 22 Apr 1998 11:00:12 -0400 Date: Wed, 22 Apr 1998 11:00:12 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199804221500.LAA14407@billings.csb> To: rem-conf@es.net Subject: Declining audiences? (Was: Netshow and the MBONE) Cc: mjh@east.isi.edu, schulzrinne@cs.columbia.edu, hasty@rah.star-gate.com, karl@precept.com X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From rem-conf-request@es.net Wed Apr 22 10:42:18 1998 > From: Henning Schulzrinne > Organization: Columbia University, Dept. of Computer Science > To: Mark Handley > Mark Handley wrote: [deletions...] > > > > So, for multicast to become ubiquitous, we need several things: > > > > - content. high volume and high quality. > > > > - many many users that want it. > > Playing devil's advocate here :-) > > It seems instructive to look at recent audience statistics. The type of > events and the audience numbers seem to have decreased, if anything, > from numbers in 1994 (say). Dear Colleauges, As an enthusiast for multicasting and the MBONE, it give me no pleasure at all to observe that this has been our experience with multicasting >from the International Web conference series as well 8^( We peaked with our first serious effort, the WWW2 meeting in Chicago in 1994, with something on the order of 400 hosts and 1000 (at least part-time) viewers (we did a detailed survey after the conf.). It has declined steadily, to almost absurdly low numbers at WWW6 in Santa Clara in April 1997. Of course, general interest in the Web has been spead over a much larger number of meeting since Chicago, and we were head-to-head with the IETF at Santa Clara, but still, it has been somewhat disheartening... Best Regards, Rick Rodgers From rem-conf Wed Apr 22 08:12:45 1998 From rem-conf-request@es.net Wed Apr 22 08:12:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS1C3-0001yT-00; Wed, 22 Apr 1998 08:12:15 -0700 Received: from doggate.exchange.microsoft.com [131.107.88.55] by mail1.es.net with smtp (Exim 1.81 #2) id 0yS1C2-0001uq-00; Wed, 22 Apr 1998 08:12:14 -0700 Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2204.2) id ; Wed, 22 Apr 1998 08:10:57 -0700 Message-ID: <69D8143E230DD111B1D40000F848584002B3E4E0@ED> From: "Mike Beckerman (Exchange)" To: 'Amancio Hasty' , Ross Finlayson Cc: rem-conf@es.net Subject: RE: Netshow and the MBONE Date: Wed, 22 Apr 1998 08:10:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2204.2) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Just a point of clarification on Amancio=92s comment: The above freebsd sites are nothing compared to thousands of netshow=20 servers pumping out audio/video streams be it unicast or multi-cast and don't forget unless you run winxx you can't par take 8) I assume Amancio was referring to the availability of clients for = NetShow servers. NetShow clients are available not only for Win9x, Win3.1, and WinNT, but also for MacOS, x86 Linux ELF, SGI Irix 6.x, Sun Sparc SunOS = 4.x, Sun Sparc SunOS 5.5+, and Sun Sparc Solaris 2.5+, with more to come. = You can find them at http://www.microsoft.com/netshow/download/player.htm , if you=92re interested. Regards. -Mike -----Original Message----- From: Amancio Hasty [mailto:hasty@rah.star-gate.com] Sent: Tuesday, April 21, 1998 11:11 PM To: Ross Finlayson Cc: rem-conf@es.net Subject: Re: Netshow and the MBONE=20 True however the original posters plead was to start streaming to=20 I presumed the mbone because of bandwith limitations and I sincerely doubt that their site consists of only one unique stream.=20 Let me put it another way. http://www.thinker.org is a 3 teryabyte image database consisting of a small farm of FreeBSD boxes (about 20 systems). How would you like if such FreeBSD farms start pumping out audio/video streams into the network? ftp.freebsd.org is pumping out a few terabytes per month on some days we hit 120 Gigs /day and ftp.freebsd.org a (a single cpu) right now is mostly limited by the Net.=20 The above freebsd sites are nothing compared to thousands of netshow=20 servers pumping out audio/video streams be it unicast or multi-cast and don't forget unless you run winxx you can't par take 8) Perhaps is time to start charging commercial sites for MBONE use and use the funds to support and expand the MBONE.=20 Regards, Amancio > However, a media server (NetShow or other) can (I presume) send n unicast > streams *as well as* a single multicast stream. So, those clients that > support multicast (& this includes increasingly many home users, BTW) can > tune into the (single) multicast stream; other clients would get their own > unicast stream. > Ross. =09 From rem-conf Wed Apr 22 08:33:22 1998 From rem-conf-request@es.net Wed Apr 22 08:33:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS1Sq-0003cO-00; Wed, 22 Apr 1998 08:29:36 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0yS1Sp-0003cA-00; Wed, 22 Apr 1998 08:29:35 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id LAA11415; Wed, 22 Apr 1998 11:29:33 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Henning Schulzrinne cc: rem-conf@es.net Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Wed, 22 Apr 1998 10:36:53 EDT." <353E0085.47D145B7@cs.columbia.edu> Date: Wed, 22 Apr 1998 11:29:33 -0400 Message-ID: <11413.893258973@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Playing devil's advocate here :-) ... >All of NYC (courtesy of Sprintnet) get Mbone at an average loss rate of >50-80%, so if this is at all typical, this is not surprising. 50-80% loss also renders TCP pretty much useless for anything other than email which can tolerate long delays. Here's a random unscientific sampling - reception at MIT (via ISI) of Places all over the World. Loss stats are 10 minute (or so) averages. This is peak time for EU, not yet peak time for US. UW-Milwaukee, US: 5% loss (caused between SF and LA in MCI's backbone) SURFnet, NL: 26% loss (cause: sprintlink->MCI and SE-US link) Switch, CH: 27% loss (cause: sprintlink->MCI and SE-US link) Ericsson, SE: 35% loss (cause: SUnet->ebone, sprintlink->MCI and SE-US link) TeleEd, CA: 1% loss Peter Lothberg, SE: 60% loss (cause: SUnet->ebone, SE-US link, plus a possible route flap near to the source) FAU, Erlangen, DE: 5% loss (cause: Nuernberg->Stuttgart) Informatik, Erlangen, DE: 5% loss in short bursts Essex, UK: 0% loss, but 50% duplicates (cause unknown - traffic stopped) NYU, USA: 7% loss (caused between SF and LA in MCI's backbone) Basically the sites behind the SE-US link are seeing high loss rates. The other sites are doing fairly well. Although the audiences may be small, there are a lot more simultaneous sessions than there used to be a few years ago, so the traffic levels are considerably higher. So what can we do about it? Receiver-based audio repair techniques can easily hide loss rates of up to 10%, perhaps higher. We just need to get code deployed that does this. Adding redundancy can provide good quality for those sites in the 20-30% loss range, but we may decide that it's not sufficiently network-friendly to do so. Blindly applying Sally Floyd and Matt Mathis's TCP equation indicates that up to around 48Kb/s might be acceptable, so redundancy might be feasible. However, the equation doesn't really hold well above 10% loss, so this number is really an upper bound. These sites really need something like diffserv, and have the receivers pay some proportion of the cost of upgrading the links. Obviously they're not going to pay though unless the content is worthwhile. Using layered codings would help significantly - it wouldn't be a binary decision whether the loss rate was too high. We're still seeing route flags cause significant loss - this is what I mean by needing stable router implementations. Plus there are still sites out there running code that doesn't prune! Cheers, Mark From rem-conf Wed Apr 22 08:33:23 1998 From rem-conf-request@es.net Wed Apr 22 08:33:22 1998 Received: from list by mail2.es.net with local (Exim 1.81 #2) id 0yS1Ur-0007e8-00; Wed, 22 Apr 1998 08:31:41 -0700 Received: from relay9.uu.net [192.48.96.85] by mail2.es.net with esmtp (Exim 1.81 #2) id 0yS1Up-0007dx-00; Wed, 22 Apr 1998 08:31:40 -0700 Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQemfm08737; Wed, 22 Apr 1998 11:31:19 -0400 (EDT) Received: by neserve0.uu.net id QQemfm19303; Wed, 22 Apr 1998 11:31:11 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Netshow and the MBONE To: schulzrinne@cs.columbia.edu (Henning Schulzrinne) Date: Wed, 22 Apr 1998 11:31:10 -0400 (EDT) Cc: mjh@east.isi.edu, hasty@rah.star-gate.com, karl@precept.com, rem-conf@es.net In-Reply-To: <353E0085.47D145B7@cs.columbia.edu> from "Henning Schulzrinne" at Apr 22, 98 10:36:53 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by relay9.uu.net id QQemfm08737 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, Henning Schulzrinne said: >=20 > Mark Handley wrote: > > - many many users that want it. >=20 > Playing devil's advocate here :-) >=20 > It seems instructive to look at recent audience statistics. The type of > events and the audience numbers seem to have decreased, if anything, > from numbers in 1994 (say). When I peeked at the vat window at IETF, > there were maybe a dozen names. The operator confirmed that this was no= t > atypical. For the Infocom transmission, we had maybe ten listeners, max= , > with 3 or 4 more typical. Windows on the world has about 20; MAGIC 94 > about 4 (including myself, for testing). This is during a time (10 am) > when Europe is still around... >=20 At the moment, folk are watching shuttle. There are currently only 48, but I counted well over a hundred thirty on launch day. David Sheryn [138.40.22.202/357175523] (muted) Bill Fenner (Xerox PARC) [13.2.116.11/357150303] Brad Cain (Bay Networks) [192.32.242.7/357354811] Steve VanDevender (University of Oregon) [128.223.32.56/3675140343] Pekka Kyt=F6laakso [193.166.1.7/1268491354] Trent MacDougall (Dalhousie University) [134.190.11.86/356729858] 128.223.32.206 [128.223.32.206/3798072303] Eric Fronberg [171.71.41.32/356507375] Steven Jack [130.209.10.15/927825384] CRC - BADLAB - sgi [199.71.88.21/356855236] mark [128.2.211.1/357054425] John Ferguson (Synopsys, Inc.) [146.225.66.46/356955851] Greg Smith (NASA Ames) [129.99.34.103/356923862] harper [142.150.160.90/2392236122] Digital Video Lab [128.102.84.134/357438632] Jose' Vilela (RCCN) [193.136.7.198/357025555] John Guchardi [142.150.160.86/357139421] H=E5kan Lennest=E5l CDT & Ericsson Erisoft, Lule=E5, Sweden [130.240.64.41/356930409] xyz (Yago Systems, Inc) [207.135.122.14/3674596102] rolly ( glasgow Uni ) [130.209.38.13/1442439721] Dana Allen (CEWES) [134.164.35.57/357323175] Hugh LaMaster (NASA ARC) [128.102.132.36/356871427] Gizella M. Kapus [131.243.2.27/3674685200] Michael Langdon [12.0.1.7/356836225] Hermann Kuhn (GKSS Research Center) [141.4.7.104/357476873] JY Luke (Multicast Staff, MIMOS) [192.228.133.185/356831084] Eric Fronberg [171.71.41.32/357146257] Marc Hasson (Mentat) [192.88.122.155/357072134] Academic User Services (CC - University of Oregon) [128.223.32.241/790895075] Bill Burris (Physics) [129.128.162.60/3670691144] Syun Tutiya [133.82.241.65/2020901737] Robert Jansen (Brussels University) [134.184.64.12/356053678] Victor Reijs (SURFnet bv) [192.87.109.61/38] Heinz Herker (Rechenzentrum, Uni Essen) [132.252.164.135/3880674045] Kevin Blackwell-LLNL [134.9.11.37/3675193340] Ralf Lehmann [141.76.41.21/3675608779] Frank Lepera [130.199.130.79/1772376687] David Moore [192.172.226.102/3674574707] QuickTime Steaming Client [204.162.117.32/16494] sharad ( U of Alberta) [129.128.9.91/536696878] Jordi Adell (Universitat Jaume I) [150.128.39.41/357254691] Jim Lowe (UW-Milwaukee) [129.89.142.49/3675239213] Christine Clark (University of Essex) [155.245.211.167/357490305] Robert Holmes (OneNet) [164.58.253.25/1207917465] Victor Reijs (SURFnet bv) [192.87.109.61/3675224027] Yasuhiko Higaki(Chiba Univ.) [133.82.181.181/356529114] Chuck Kennedy (ARL) [128.63.155.97/357085069] Jeremy Hall (UUNET Technologies) [153.39.253.133/3674844532] Now most of these people are from labs and universities, but isn't that where we became interested in mbone? at university? In adition, transcoders and other methods can prevent us from seeing all the viewers. Sparce networks connected via dense mode can also cause partitions. It would be interesting to determine who is listening/watching the mbone feed that is unable or unwilling to send rtc= p packets. We could send a ping to the group, but that might not be reliable. > I know that a number of people are behind firewalls and don't send RTCP > reports, but I doubt that this would more than double the audience. Eve= n > most research labs haven't enabled (or have shut down again) multicast > ingress, from what I can tell. >=20 > All of NYC (courtesy of Sprintnet) get Mbone at an average loss rate of > 50-80%, so if this is at all typical, this is not surprising. >=20 If people are willing to put up with packet loss, that's fine for them. Sprint isn't the only mbone provider. There are other providers providin= g less packet loss than Sprint. > This argument has been made elsewhere and earlier, but most people I > talked to about Infocom distribution care very little about hearing > whole sessions live. (They'd be at Infocom if they had the time.) They > want selected talks (and often want to fast-forward through the > introduction), at their convenience, i.e., unicast. >=20 If that's the case, a mechanism should be devised to record the data in a compressed format. Then, they can tape the sessions and play them back a= t their convenience. Just like those remote classes from GMU or whatever. > Any sufficiently compelling mass-audience content is > - likely available on broadcast TV, radio, cable, pay-TV or on tape, at > far better quality and with less hassle If that is the case, then we've already lost. If we build encoding schemes which are more attractable, content will arrive. > - or is not suited for minors We have joked around before about providing porn on a 24 hour basis, but what we are really trying to do is find compelling content. Besides...If somebody were providing porn content, do you really think you would want the whole world to know you were watching it? > - not particularly enjoyable at 28 kb/s or even 280 kb/s. >=20 yes, but even real* have made stereo at 28.8K. It really does make a difference. > Multicast makes sense (as IP/TV demonstrates) for *local* redistributio= n > of content such as CNN. For now, having a bunch of local feeds of this > type of fare seems far more efficient, as I can significantly ramp up > the bandwidth. >=20 Oh sure. replicate your multicast. Build reliable links, and you won't have to have little CNN islands. Assuming Turner allows you to do this, you could multicast CNN on the mbone. Two things would happen: 1: pruning bugs would get fixed in router implementations. 2: people would have a reason to fix IP multicast rather than it being a pastime. > Henning >=20 _J From rem-conf Wed Apr 22 08:33:40 1998 From rem-conf-request@es.net Wed Apr 22 08:33:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS1VF-0003i8-00; Wed, 22 Apr 1998 08:32:05 -0700 Received: from uucp1.nwnexus.com [206.63.63.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS1VE-0003fa-00; Wed, 22 Apr 1998 08:32:04 -0700 Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id IAA06147; Wed, 22 Apr 1998 08:31:14 -0700 (PDT) Received: from [204.57.137.9] by internaut.com (NX5.67c/NeXT-3.0) id AA01287; Wed, 22 Apr 98 07:36:20 -0800 Reply-To: "Bernard Aboba" From: "Bernard Aboba" To: "Henning Schulzrinne" , "Mark Handley" Cc: Subject: Re: Netshow and the MBONE Date: Wed, 22 Apr 1998 08:41:49 -0700 Message-Id: <01bd6e05$2a45c7f0$098939cc@multi> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >This argument has been made elsewhere and earlier, but most people I >talked to about Infocom distribution care very little about hearing >whole sessions live. (They'd be at Infocom if they had the time.) They >want selected talks (and often want to fast-forward through the >introduction), at their convenience, i.e., unicast. I have to agree with Henning here. It appears that MBONE network count is rising less steeply than that of the Internet as a whole. While there is a good deal of corporate deployment occurring behind firewalls, this does say something about the progress in deployment of multicast as an internet-wide service. Some rather large multicast deployments have failed to garner audience interest because they solely offered live events, and users were primarily interested in on-demand viewing. This is why it is desirable to integrate record/playback and caching into such deployments. However, on the positive side, enterprise deployments are starting to take off, particularly in the financial service industry. This involves a mixture of audio/video content feeds (i.e. CNN), and reliable multicasting of various flavors. I would also note that there has been a considerable increase in interest in satellite distribution. This may offer considerable promise in lowering the cost and improving the quality of MBONE feeds, particularly for trans-oceanic carriage. As Henning noted, there is often horrendous packet loss on trans-oceanic links. However, this does require somewhat of a shift in thinking, since satellite applications often are uni-directional. Thus RTCP feedback, or reliable multicast techniques requiring feedback (i.e. NAKing) are frequently infeasible. From rem-conf Wed Apr 22 08:37:36 1998 From rem-conf-request@es.net Wed Apr 22 08:37:35 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS1Yr-00043F-00; Wed, 22 Apr 1998 08:35:49 -0700 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS1Yq-00042i-00; Wed, 22 Apr 1998 08:35:48 -0700 Received: from [140.249.10.1] by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA12766 for ; Wed, 22 Apr 1998 11:35:18 -0400 X-Sender: bill@140.249.38.180 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Apr 1998 11:38:11 +0100 To: rem-conf@es.net From: bryan@wpine.com (Bill Ryan) Subject: Re: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The decline in viewers of various multicast events begs the following questions: 1. Is it due to lack of content (or content which interests the masses)? 2. Is it due to the lack of user friendly apps. which allow an enduser to view a multicast event easily? 3. Is it due to the lack of user friendly apps. which allow content providers to host multicast events? 4. Is it due to the lack of PR for multicast events? Most likely a combination of all of the above? Bill > >Dear Colleauges, > >As an enthusiast for multicasting and the MBONE, it give me no pleasure >at all to observe that this has been our experience with multicasting >from the International Web conference series as well 8^( >We peaked with our first serious effort, the WWW2 meeting in Chicago >in 1994, with something on the order of 400 hosts and 1000 (at least >part-time) viewers (we did a detailed survey after the conf.). >It has declined steadily, to almost absurdly low numbers at WWW6 >in Santa Clara in April 1997. Of course, general interest in the Web >has been spead over a much larger number of meeting since Chicago, >and we were head-to-head with the IETF at Santa Clara, but still, >it has been somewhat disheartening... > >Best Regards, Rick Rodgers __________________________________________________________ Bill Ryan (bill@wpine.com) http://www.wpine.com White Pine Software, Inc. http://www.cuseeme.com 542 Amherst Street PH: 603-886-9050 x351 Tu/Fri Nashua, NH 03063 603-529-5070 Mon/Wed/Thur __________________________________________________________ From rem-conf Wed Apr 22 08:47:04 1998 From rem-conf-request@es.net Wed Apr 22 08:47:03 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS1gq-00057c-00; Wed, 22 Apr 1998 08:44:04 -0700 Received: from proxy3.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS1gp-00057Q-00; Wed, 22 Apr 1998 08:44:03 -0700 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12] (may be forged)) by proxy3.ba.best.com (8.8.8/8.8.BEST) with SMTP id IAA13586; Wed, 22 Apr 1998 08:42:28 -0700 (PDT) Message-Id: <3.0.5.16.19980422073409.26e76e3a@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (16) Date: Wed, 22 Apr 1998 07:34:09 To: Marty Hoag From: Ross Finlayson Subject: Re: Netshow and the MBONE Cc: rem-conf@es.net In-Reply-To: References: <199804220449.VAA17280@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Isn't elimination of MBone our goal? My understanding is that the >MBone is an experimental network which should lead to ubiquitous "native" >IP multicast availability throughout the Internet once the protocols are >developed? No, this is a common misuse/misunderstanding of the term "MBone". The MBone is simply the subset of the Internet that supports IP multicast routing. It's currently the case, however, that: 1/ This subset is itself a disjoint set. E.g., some corporate/campus 'intranets' may support multicast routing internally, but not externally. Also, some content aggregators have recently been using separate, private multicast backbones to carry A/V traffic - e.g., for QOS reasons. Over time, these disjoint subsets should merge together, in some form or another... 2/ Some parts of this subset are still routed using higher-level routing agents (notably "mrouted"), rather than native multicast routing. This is how the MBone started, but it's no longer particularly useful to think of the term "MBone" as meaning only this set of "mrouted" nodes, because there's now lots of native multicast routing going on, even within the well-known 'public' portion of the MBone. >I realize the ISPs like unicast because the billing model is >easier to understand but I think that is sort of short-sighted. Yes, I agree. For illustration, it wasn't so long ago that there were only a handful of companies (e.g., Netcom and Portal) that provided Internet access to the home. At the time, many people thought that this wasn't going to be economically viable. Ross. From rem-conf Wed Apr 22 08:52:40 1998 From rem-conf-request@es.net Wed Apr 22 08:52:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS1nD-00062I-00; Wed, 22 Apr 1998 08:50:39 -0700 Received: from rah.star-gate.com [209.133.7.234] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS1nB-000626-00; Wed, 22 Apr 1998 08:50:38 -0700 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id IAA20521; Wed, 22 Apr 1998 08:50:24 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804221550.IAA20521@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: bryan@wpine.com (Bill Ryan) cc: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) In-reply-to: Your message of "Wed, 22 Apr 1998 11:38:11 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Apr 1998 08:50:24 -0700 From: Amancio Hasty X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > 1. Is it due to lack of content (or content which interests the masses)? My vote is for number 1 also typical mbone transmissions exceed home users bandwith which is 28.8k. Granted , it is expected that this limitation will soon be over for instance I am shopping around for ADSL to replace my ISDN line 8) It is kind of hard to target corporate users given that they are supposed to be working and not watching "TV". Cheers, Amancio From rem-conf Wed Apr 22 09:02:02 1998 From rem-conf-request@es.net Wed Apr 22 09:02:02 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS1wY-0006uv-00; Wed, 22 Apr 1998 09:00:18 -0700 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS1wV-0006ti-00; Wed, 22 Apr 1998 09:00:15 -0700 Received: from [140.249.10.1] by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA13252 for ; Wed, 22 Apr 1998 11:59:48 -0400 X-Sender: bill@140.249.38.180 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Apr 1998 12:02:41 +0100 To: rem-conf@es.net From: bryan@wpine.com (Bill Ryan) Subject: Re: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I forgot one: 5. Is the technology just not there yet to make multicast events feasible for the masses (deployment of RSVP routers, availability of low bandwidth codecs, pipes wide enough to carry the load)? Bill >The decline in viewers of various multicast events begs the following >questions: > >1. Is it due to lack of content (or content which interests the masses)? > >2. Is it due to the lack of user friendly apps. which allow an enduser to >view a multicast event easily? > >3. Is it due to the lack of user friendly apps. which allow content >providers to host multicast events? > >4. Is it due to the lack of PR for multicast events? > >Most likely a combination of all of the above? > >Bill > > > >> >>Dear Colleauges, >> >>As an enthusiast for multicasting and the MBONE, it give me no pleasure >>at all to observe that this has been our experience with multicasting >>from the International Web conference series as well 8^( >>We peaked with our first serious effort, the WWW2 meeting in Chicago >>in 1994, with something on the order of 400 hosts and 1000 (at least >>part-time) viewers (we did a detailed survey after the conf.). >>It has declined steadily, to almost absurdly low numbers at WWW6 >>in Santa Clara in April 1997. Of course, general interest in the Web >>has been spead over a much larger number of meeting since Chicago, >>and we were head-to-head with the IETF at Santa Clara, but still, >>it has been somewhat disheartening... >> >>Best Regards, Rick Rodgers > >__________________________________________________________ >Bill Ryan (bill@wpine.com) http://www.wpine.com >White Pine Software, Inc. http://www.cuseeme.com >542 Amherst Street PH: 603-886-9050 x351 Tu/Fri >Nashua, NH 03063 603-529-5070 Mon/Wed/Thur >__________________________________________________________ __________________________________________________________ Bill Ryan (bill@wpine.com) http://www.wpine.com White Pine Software, Inc. http://www.cuseeme.com 542 Amherst Street PH: 603-886-9050 x351 Tu/Fri Nashua, NH 03063 603-529-5070 Mon/Wed/Thur __________________________________________________________ From rem-conf Wed Apr 22 09:04:28 1998 From rem-conf-request@es.net Wed Apr 22 09:04:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS1zs-00079M-00; Wed, 22 Apr 1998 09:03:44 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0yS1zp-000773-00; Wed, 22 Apr 1998 09:03:42 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 22 Apr 1998 17:01:14 +0100 To: Henning Schulzrinne cc: Mark Handley , Amancio Hasty , Karl Auerbach , rem-conf@es.net, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Netshow and the MBONE In-reply-to: Your message of "Wed, 22 Apr 1998 10:36:53 EDT." <353E0085.47D145B7@cs.columbia.edu> Date: Wed, 22 Apr 1998 17:01:11 +0100 Message-ID: <16948.893260871@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <353E0085.47D145B7@cs.columbia.edu>, Henning Schulzrinne typed: >>Multicast makes sense (as IP/TV demonstrates) for *local* redistribution >>of content such as CNN. For now, having a bunch of local feeds of this >>type of fare seems far more efficient, as I can significantly ramp up >>the bandwidth. Henning there's at least 3 different problems 1/ arranging/organising the topology of a set of branch points (whether at physical, link, IP, transport or application) to efficiently distribute data over bandwidth constrained mesh network from a small number of current sources to a large number of concurrent receivers 2/ allowing IP to make non stupid use of physical broadcast media 3/ controlling the delivery of non congestion avoiding sources. The ISPs are so afraid of 3/ disrupting their busniess and web dimensioning that they are prepared to suffer the cost of _manual_ configuration of 1/ at application level, or local use of 1/ at IP level, and occasionally 3/ (e.g. smart ones that use satellite nets) I assert that organising ANY multipeer system (whether its replicated nameservers, diasaster recovery failover webservers, distributed replicated file and web cache servers, multipath routing systems, multicast conferencing, remote teaching) will have exactly the same scaling problems, but a common IP level solution has several major _management_ benefits....in the long run but because of the aforementioned traffic control problem , we may see a 3 level system, viz local multicast at a site backbone multicast and server level distribution between and betwixt these (were these servers to co-incide with firewalls, bandwidth brokers and transcoder/filter, repair servers for relibility, i would not be too surprised were a certain company to fix NT so it made a good lo-cost router, we might find the whole multicast thing to happen in a VERY big way again... note also, a LOT of private, admin scoped multicast is now going on that simply doesnt show up in your global sessions - we discover quite large groups of peopel that we gave mbone training seminars to a while ago just _got on with it_, but not in public... cheers jon From rem-conf Wed Apr 22 09:06:14 1998 From rem-conf-request@es.net Wed Apr 22 09:06:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS21d-0007Q7-00; Wed, 22 Apr 1998 09:05:33 -0700 Received: from plains.nodak.edu [134.129.111.64] (hoag) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS21a-0007Dt-00; Wed, 22 Apr 1998 09:05:31 -0700 Received: from localhost (hoag@localhost) by plains.NoDak.edu (8.8.8/8.8.8) with SMTP id LAA20829; Wed, 22 Apr 1998 11:04:03 -0500 (CDT) Date: Wed, 22 Apr 1998 11:04:03 -0500 (CDT) From: Marty Hoag To: Ross Finlayson cc: rem-conf@es.net Subject: Re: Netshow and the MBONE In-Reply-To: <3.0.5.16.19980422073409.26e76e3a@shell7.ba.best.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 22 Apr 1998, Ross Finlayson wrote: > No, this is a common misuse/misunderstanding of the term "MBone". The > MBone is simply the subset of the Internet that supports IP multicast > routing. ... I stand corrected. I was using terminology from the apparently obsolete MBONE FAQ (from that site with the black backgrounds and green letters - uff da) which called it a "testbed" and a virtual network which was to be used until IP multicast was supported across the Internet "production routers". I can't even seem to get to that old site any longer (www.mbone.com). I suspect this has hindered progress compared to other applications and protocols which work across the real Internet. By the way, where is the real current MBone home page on the WWW these days? Sorry about adding confusion to the discussion. Marty From rem-conf Wed Apr 22 09:15:13 1998 From rem-conf-request@es.net Wed Apr 22 09:15:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS28j-0000ov-00; Wed, 22 Apr 1998 09:12:53 -0700 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS28i-0000fM-00; Wed, 22 Apr 1998 09:12:52 -0700 Received: from [140.249.10.1] by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA13492 for ; Wed, 22 Apr 1998 12:11:36 -0400 X-Sender: bill@140.249.38.180 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Apr 1998 12:14:28 +0100 To: rem-conf@es.net From: bryan@wpine.com (Bill Ryan) Subject: Re: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I forgot one: 5. Is the technology just not there yet to make multicast events feasible for the masses (deployment of RSVP routers, availability of low bandwidth codecs, pipes wide enough to carry the load)? Bill __________________________________________________________ Bill Ryan (bill@wpine.com) http://www.wpine.com White Pine Software, Inc. http://www.cuseeme.com 542 Amherst Street PH: 603-886-9050 x351 Tu/Fri Nashua, NH 03063 603-529-5070 Mon/Wed/Thur __________________________________________________________ From rem-conf Wed Apr 22 09:17:56 1998 From rem-conf-request@es.net Wed Apr 22 09:17:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS2D6-0001Px-00; Wed, 22 Apr 1998 09:17:24 -0700 Received: from basil.cdt.luth.se [130.240.64.67] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS2D4-0001PZ-00; Wed, 22 Apr 1998 09:17:22 -0700 Received: from ganymede (ganymede.cdt.luth.se [130.240.64.41]) by basil.cdt.luth.se (8.8.8/8.7.3) with ESMTP id SAA28243 for ; Wed, 22 Apr 1998 18:17:17 +0200 (MET DST) Message-Id: <199804221617.SAA28243@basil.cdt.luth.se> X-Mailer: exmh version 2.0.2 2/24/98 To: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) In-reply-to: Your message of "Wed, 22 Apr 1998 08:50:24 PDT." <199804221550.IAA20521@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 22 Apr 1998 18:19:08 +0200 From: Hakan Lennestal Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by basil.cdt.luth.se id SAA28243 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <199804221550.IAA20521@rah.star-gate.com>, Amancio Hasty write= s: > > 1. Is it due to lack of content (or content which interests the mass= es)? >=20 > My vote is for number 1 also typical mbone transmissions exceed home > users bandwith which is 28.8k. Granted , it is expected that this limit= ation > will soon be over for instance I am shopping around for ADSL to replace > my ISDN line 8) >=20 > It is kind of hard to target corporate users given that they are suppos= ed > to be working and not watching "TV".=20 My vote is on this item: 5. Is it to high packet loss ? Whatching many of the global mbone events, at least over here in europe, often falls on the high packet loss (not seldom around 50%). =20 Regards. /H=E5kan From rem-conf Wed Apr 22 09:27:40 1998 From rem-conf-request@es.net Wed Apr 22 09:27:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS2Lx-0002IL-00; Wed, 22 Apr 1998 09:26:33 -0700 Received: from sirocco.cc.mcgill.ca [132.206.27.12] by mail1.es.net with smtp (Exim 1.81 #2) id 0yS2Lv-0002I4-00; Wed, 22 Apr 1998 09:26:31 -0700 Received: from staffpop_1.cc.mcgill.ca (staff.McGill.CA [132.206.27.100]) by sirocco.CC.McGill.CA (8.6.12/8.6.6) with ESMTP id MAA19508 for ; Wed, 22 Apr 1998 12:26:30 -0400 X-SMTP-Posting-Origin: staffpop_1.cc.mcgill.ca (staff.McGill.CA [132.206.27.100]) Received: by staff.McGill.CA with Internet Mail Service (5.0.1458.49) id ; Wed, 22 Apr 1998 12:17:03 -0400 Message-ID: From: Yves Lepage To: "'bryan@wpine.com'" , rem-conf@es.net Subject: RE: Declining audiences? (Was: Netshow and the MBONE) Date: Wed, 22 Apr 1998 12:17:02 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'd like to modify one (#2): 2. Is it due to the lack of user friendly freeware apps that support OS'es the masses use? Reason for modification: When I was using a UNIX system as my desktop, finding apps (even user friendly ones) was never a problem. Since then, my desktop is NT. This makes it much more problematic. I am not going to purchase IP/TV or Icast. My only option from that point is to use the freeware apps, which are not really mature on MS OS'es. The only SDR I could find that works on NT 4.0 SP3 is that of the mash project. Still, it will crash from time to time. VIC for NT has been spectacularly unstable. If I ever get to see a picture, it will usually last no more than 5 minutes before the application completely freezes. Since the masses use MS OS'es, that UNIX as a desktop is fading away, maybe more emphasis could be put on actually allowing the audience to attend MBone events. I've not had access to the MBone ever since I moved from UNIX to NT. In this case, mcast connectivity wasn't a problem. Regards, Yves Lepage > -----Original Message----- > From: bryan@wpine.com [mailto:bryan@wpine.com] > Sent: Wednesday, April 22, 1998 7:03 AM > To: rem-conf@es.net > Subject: Re: Declining audiences? (Was: Netshow and the MBONE) > > > I forgot one: > > 5. Is the technology just not there yet to make multicast > events feasible > for the masses (deployment of RSVP routers, availability of > low bandwidth > codecs, pipes wide enough to carry the load)? > > Bill > > > >The decline in viewers of various multicast events begs the following > >questions: > > > >1. Is it due to lack of content (or content which interests > the masses)? > > > >2. Is it due to the lack of user friendly apps. which allow > an enduser to > >view a multicast event easily? > > > >3. Is it due to the lack of user friendly apps. which allow content > >providers to host multicast events? > > > >4. Is it due to the lack of PR for multicast events? > > > >Most likely a combination of all of the above? > > > >Bill > > > > > > > >> > >>Dear Colleauges, > >> > >>As an enthusiast for multicasting and the MBONE, it give me > no pleasure > >>at all to observe that this has been our experience with > multicasting > >>from the International Web conference series as well 8^( > >>We peaked with our first serious effort, the WWW2 meeting in Chicago > >>in 1994, with something on the order of 400 hosts and 1000 (at least > >>part-time) viewers (we did a detailed survey after the conf.). > >>It has declined steadily, to almost absurdly low numbers at WWW6 > >>in Santa Clara in April 1997. Of course, general interest > in the Web > >>has been spead over a much larger number of meeting since Chicago, > >>and we were head-to-head with the IETF at Santa Clara, but still, > >>it has been somewhat disheartening... > >> > >>Best Regards, Rick Rodgers > > > >__________________________________________________________ > >Bill Ryan (bill@wpine.com) http://www.wpine.com > >White Pine Software, Inc. http://www.cuseeme.com > >542 Amherst Street PH: 603-886-9050 x351 Tu/Fri > >Nashua, NH 03063 603-529-5070 > Mon/Wed/Thur > >__________________________________________________________ > > __________________________________________________________ > Bill Ryan (bill@wpine.com) http://www.wpine.com > White Pine Software, Inc. http://www.cuseeme.com > 542 Amherst Street PH: 603-886-9050 x351 Tu/Fri > Nashua, NH 03063 603-529-5070 > Mon/Wed/Thur > __________________________________________________________ > > > From rem-conf Wed Apr 22 09:32:16 1998 From rem-conf-request@es.net Wed Apr 22 09:32:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS2Qv-0002rv-00; Wed, 22 Apr 1998 09:31:41 -0700 Received: from listbox2.cern.ch [137.138.24.200] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS2Qt-0002mE-00; Wed, 22 Apr 1998 09:31:40 -0700 Received: from cern.ch (pcitcs04.cern.ch [137.138.33.126]) by listbox2.cern.ch (8.8.8/8.8.8) with ESMTP id SAA28092; Wed, 22 Apr 1998 18:30:28 +0200 (MET DST) X-Authentication-Warning: listbox2.cern.ch: Host pcitcs04.cern.ch [137.138.33.126] claimed to be cern.ch Message-ID: <353E1B27.808A7F74@cern.ch> Date: Wed, 22 Apr 1998 18:30:31 +0200 From: Miguel CHAMOCHIN GOMEZ Organization: CERN X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Bill Ryan , "rem-conf@es.net" Subject: Re: Declining audiences? (Was: Netshow and the MBONE) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It is a question of time... it is not a question of technology. ;-D People time is worth a lot... you can not expect people to be there when you want them to be, they will be there when they can. !!! They want to access to the information when it is convenient for them, as fast as the tech allows it (metadata, video file with index approach) by topic, as the "search engine" allows with some keys. They want the answer to their question as soon as possible and better with as media as possible (a clue: conference time indexed by topics => editing facilities, search engine across conferences). Regards, Miguel. Bill Ryan wrote: > > The decline in viewers of various multicast events begs the following questions: > > 1. Is it due to lack of content (or content which interests the masses)? > > 2. Is it due to the lack of user friendly apps. which allow an enduser to > view a multicast event easily? > > 3. Is it due to the lack of user friendly apps. which allow content > providers to host multicast events? > > 4. Is it due to the lack of PR for multicast events? > > Most likely a combination of all of the above? > > Bill -- Miguel Angel Chamochin Gomez Information Technology Division CERN CH-1211 Geneve 23 SWITZERLAND Phone: +41-22-767-9703 Fax: +41-22-767-7155 e-mail: Miguel.Chamochin@cern.ch From rem-conf Wed Apr 22 09:41:22 1998 From rem-conf-request@es.net Wed Apr 22 09:41:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS2Yv-0003d4-00; Wed, 22 Apr 1998 09:39:57 -0700 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS2Yt-0003ci-00; Wed, 22 Apr 1998 09:39:55 -0700 Received: from [140.249.10.1] by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA13962 for ; Wed, 22 Apr 1998 12:39:26 -0400 X-Sender: bill@140.249.38.180 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Apr 1998 12:42:18 +0100 To: rem-conf@es.net From: bryan@wpine.com (Bill Ryan) Subject: Re: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is the old "live vs. prerecorded" arguement........aka "multicast vs unicast". I myself like to see some events "live" (superbowl, first moonwalk, shuttle launches, etc...). Others I can wait to watch as prerecorded events (or as reruns :) ). Bill >It is a question of time... it is not a question of technology. ;-D > > People time is worth a lot... you can not expect people to be >there when you want them to be, they will be there when they can. !!! > > They want to access to the information when it is convenient for >them, as fast as the tech allows it (metadata, video file with index >approach) by topic, as the "search engine" allows with some keys. They >want the answer to their question as soon as possible and better with as >media as possible (a clue: conference time indexed by topics => editing >facilities, search engine across conferences). > > Regards, > > Miguel. __________________________________________________________ Bill Ryan (bill@wpine.com) http://www.wpine.com White Pine Software, Inc. http://www.cuseeme.com 542 Amherst Street PH: 603-886-9050 x351 Tu/Fri Nashua, NH 03063 603-529-5070 Mon/Wed/Thur __________________________________________________________ From rem-conf Wed Apr 22 09:42:54 1998 From rem-conf-request@es.net Wed Apr 22 09:42:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS2bL-0003tZ-00; Wed, 22 Apr 1998 09:42:27 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS2bJ-0003sy-00; Wed, 22 Apr 1998 09:42:25 -0700 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA03178; Wed, 22 Apr 1998 12:42:23 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA05705; Wed, 22 Apr 1998 12:42:23 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <353E1DEF.CAFB1C9E@cs.columbia.edu> Date: Wed, 22 Apr 1998 12:42:23 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Mark Handley CC: rem-conf@es.net Subject: Re: Netshow and the MBONE References: <11413.893258973@north.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark Handley wrote: > > >Playing devil's advocate here :-) > ... > >All of NYC (courtesy of Sprintnet) get Mbone at an average loss rate of > >50-80%, so if this is at all typical, this is not surprising. > > 50-80% loss also renders TCP pretty much useless for anything other > than email which can tolerate long delays. To clarify: Our packet loss on anything else (except morning to Germany and that reasons beyond Sprintlink) is just fine, in terms of delay, loss and throughput. It's only the Mbone connection that has problems. > > Here's a random unscientific sampling - reception at MIT (via ISI) of > Places all over the World. Loss stats are 10 minute (or so) averages. > This is peak time for EU, not yet peak time for US. > > UW-Milwaukee, US: 5% loss (caused between SF and LA in MCI's backbone) > SURFnet, NL: 26% loss (cause: sprintlink->MCI and SE-US link) > Switch, CH: 27% loss (cause: sprintlink->MCI and SE-US link) > Ericsson, SE: 35% loss (cause: SUnet->ebone, sprintlink->MCI and SE-US link) > TeleEd, CA: 1% loss > Peter Lothberg, SE: 60% loss (cause: SUnet->ebone, SE-US link, plus > a possible route flap near to the source) > FAU, Erlangen, DE: 5% loss (cause: Nuernberg->Stuttgart) > Informatik, Erlangen, DE: 5% loss in short bursts > Essex, UK: 0% loss, but 50% duplicates (cause unknown - traffic stopped) > NYU, USA: 7% loss (caused between SF and LA in MCI's backbone) As you can see, sprintlink makes more than a few appearances in this list :-) > > Basically the sites behind the SE-US link are seeing high loss rates. > The other sites are doing fairly well. Loss rates of around 30% are not exactly a stable design point. You have to do heavy-duty FEC to hide that (with lots of extra packets), plus these losses tend to be bursty, so that user experience is still dismal. From rem-conf Wed Apr 22 09:50:59 1998 From rem-conf-request@es.net Wed Apr 22 09:50:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS2iU-0004gq-00; Wed, 22 Apr 1998 09:49:50 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0yS2iS-0004cv-00; Wed, 22 Apr 1998 09:49:48 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 22 Apr 1998 17:48:56 +0100 To: Yves Lepage cc: "'bryan@wpine.com'" , rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) In-reply-to: Your message of "Wed, 22 Apr 1998 12:17:02 EDT." Date: Wed, 22 Apr 1998 17:48:54 +0100 Message-ID: <2266.893263734@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Yves Lepage writes: >I'd like to modify one (#2): > >2. Is it due to the lack of user friendly freeware apps that support >OS'es the masses use? > >Reason for modification: > >When I was using a UNIX system as my desktop, finding apps (even user >friendly ones) was never a problem. > >Since then, my desktop is NT. This makes it much more problematic. I am >not going to purchase IP/TV or Icast. My only option from that point is >to use the freeware apps, which are not really mature on MS OS'es. > >The only SDR I could find that works on NT 4.0 SP3 is that of the mash >project. Still, it will crash from time to time. VIC for NT has been >spectacularly unstable. If I ever get to see a picture, it will usually >last no more than 5 minutes before the application completely freezes. > >Since the masses use MS OS'es, that UNIX as a desktop is fading away, >maybe more emphasis could be put on actually allowing the audience to >attend MBone events. We've recently had a number of people working on RAT to try to make it more stable on Windows, see ftp://cs.ucl.ac.uk/mice/rat/3.0.24/rat-win32.zip for our latest attempt (doesn't solve all the problems, but it's better than it used to be...). Also, we have modified versions of vic, sdr and nte which work better on Windows. See http://www.cs.ucl.ac.uk/staff/k.hasler/shrimp/bin/ for beta-test binaries of a "shrink-wrapped" set of tools. Colin ps: Credit where it's due: most of this work has been done by Kris Hasler and Orion Hodson here at UCL. I'm just reporting it's existance... From rem-conf Wed Apr 22 09:52:21 1998 From rem-conf-request@es.net Wed Apr 22 09:52:21 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS2jx-0004pX-00; Wed, 22 Apr 1998 09:51:21 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS2jv-0004p6-00; Wed, 22 Apr 1998 09:51:19 -0700 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA03596; Wed, 22 Apr 1998 12:51:17 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id MAA05718; Wed, 22 Apr 1998 12:51:16 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <353E2004.1DA5BD6E@cs.columbia.edu> Date: Wed, 22 Apr 1998 12:51:16 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Jeremy Hall CC: rem-conf@es.net Subject: Re: Netshow and the MBONE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jeremy Hall wrote: > > > Now most of these people are from labs and universities, but isn't that > where we became interested in mbone? at university? > > In adition, transcoders and other methods can prevent us from seeing all > the viewers. Sparce networks connected via dense mode can also cause > partitions. It would be interesting to determine who is > listening/watching the mbone feed that is unable or unwilling to send rtcp > packets. We could send a ping to the group, but that might not be > reliable. Compare that to the number of people retrieving content through RealAudio :-) > > All of NYC (courtesy of Sprintnet) get Mbone at an average loss rate of > > 50-80%, so if this is at all typical, this is not surprising. > > > If people are willing to put up with packet loss, that's fine for them. > Sprint isn't the only mbone provider. There are other providers providing > less packet loss than Sprint. If you can convince the University to switch network providers because Mbone doesn't work, you earn the "UUNet best salesman of the year award". :-) > If that's the case, a mechanism should be devised to record the data in a > compressed format. Then, they can tape the sessions and play them back at > their convenience. Just like those remote classes from GMU or whatever. Useless at the loss rates that we see and Mark reported. Much easier for the user to use RealAudio. > > > - or is not suited for minors > > We have joked around before about providing porn on a 24 hour basis, but > what we are really trying to do is find compelling content. Besides...If > somebody were providing porn content, do you really think you would want > the whole world to know you were watching it? I suppose that's when people will demand viewers that can turn off RTCP :-) From rem-conf Wed Apr 22 10:17:33 1998 From rem-conf-request@es.net Wed Apr 22 10:17:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS34o-0006UL-00; Wed, 22 Apr 1998 10:12:54 -0700 Received: from dxcoms.cern.ch [137.138.28.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS34m-0006TD-00; Wed, 22 Apr 1998 10:12:52 -0700 Received: from localhost (isnard@localhost) by dxcoms.cern.ch (8.8.8/8.8.8) with SMTP id TAA08523 for ; Wed, 22 Apr 1998 19:11:43 +0200 (MET DST) Date: Wed, 22 Apr 1998 19:11:43 +0200 (MET DST) From: Christian Isnard - CERN IT/CS To: rem-conf MBONE List Subject: Running vic with SunVideoPlus card ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, I've got a Sun UltraStation 30 model 300 running Solaris 2.5.1 and equipped with the new SunVideoPlus video card (PCI card). I would like to run vic to transmit video from this platform. Unfortunately vic will not transmit and outputs the message: /dev/rtvcctl0: No such file or directory vic.xil (XIL version of vic) does not produce any error message, but the transmitted video freezes after displaying the first frame. Any hints? Cheers, -- Christian. From rem-conf Wed Apr 22 10:19:39 1998 From rem-conf-request@es.net Wed Apr 22 10:19:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS3Au-0006sS-00; Wed, 22 Apr 1998 10:19:12 -0700 Received: from fw-es06.hac.com [128.152.1.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS3At-0006kj-00; Wed, 22 Apr 1998 10:19:11 -0700 Received: from pmdf1.es.hac.com ([147.17.103.50]) by fw-es06.hac.com (8.8.4/8.8.4) with ESMTP id KAA06772 for ; Wed, 22 Apr 1998 10:28:33 -0700 (PDT) From: vbarajas@mail.hac.com Received: from mime.mail.hac.com by mail.hac.com (PMDF V5.1-10 #26245) id <0ERT00401RS024@mail.hac.com> for rem-conf@es.net; Wed, 22 Apr 1998 10:12:09 -0700 (PDT) Date: Wed, 22 Apr 1998 10:03 -0700 (PDT) Subject: Re[2]: Declining audiences? (Was: Netshow and the MBONE) To: rem-conf@es.net Message-id: <0ERT0041IRS924@mail.hac.com> MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_JgIyQ9CMRa+AEgycejFROA)" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --Boundary_(ID_JgIyQ9CMRa+AEgycejFROA) Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1 What about a lack of an appropriate technology. I recently was able to participate in a the reception of an MBONE broadcast and , as a member of the "masses", I was really underwhelmed. With the choices available for the delivery of media, the technology as executed today is woefully lacking. I am very interested in the content but have a hard time justifiying the time wasted trying to decipher garbled audio and sttuudering video movement. ....victor _______________________________________________________________________________ Subject: Re: Declining audiences? (Was: Netshow and the MBONE) From: bryan@wpine.com (Bill Ryan) at CCGATE Date: 4/22/98 8:39 AM The decline in viewers of various multicast events begs the following questions: 1. Is it due to lack of content (or content which interests the masses)? 2. Is it due to the lack of user friendly apps. which allow an enduser to view a multicast event easily? 3. Is it due to the lack of user friendly apps. which allow content providers to host multicast events? 4. Is it due to the lack of PR for multicast events? Most likely a combination of all of the above? Bill --Boundary_(ID_JgIyQ9CMRa+AEgycejFROA) Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1; NAME=rfc822.txt Content-description: rfc822.txt Content-disposition: ATTACHMENT; FILENAME=rfc822.txt Content-transfer-encoding: 8BIT Received: by ccmail from fw-es05.hac.com >From rem-conf-request@es.net X-Envelope-From: rem-conf-request@es.net Received: from mail1.es.net ([198.128.3.181]) by fw-es05.hac.com (8.8.4/8.8.4) with SMTP id IAA06044; Wed, 22 Apr 1998 08:35:05 -0700 (PDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS1Yr-00043F-00; Wed, 22 Apr 1998 08:35:49 -0700 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS1Yq-00042i-00; Wed, 22 Apr 1998 08:35:48 -0700 Received: from [140.249.10.1] by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA12766 for ; Wed, 22 Apr 1998 11:35:18 -0400 X-Sender: bill@140.249.38.180 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Apr 1998 11:38:11 +0100 To: rem-conf@es.net From: bryan@wpine.com (Bill Ryan) Subject: Re: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --Boundary_(ID_JgIyQ9CMRa+AEgycejFROA)-- From rem-conf Wed Apr 22 10:31:36 1998 From rem-conf-request@es.net Wed Apr 22 10:31:35 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS3LR-0000Fo-00; Wed, 22 Apr 1998 10:30:05 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS3LQ-0000Fc-00; Wed, 22 Apr 1998 10:30:04 -0700 Received: from scv1.apple.com (A17-128-100-139.apple.com [17.128.100.139]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id KAA23578 for ; Wed, 22 Apr 1998 10:23:43 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv1.apple.com (8.8.5/8.8.5) with ESMTP id KAA06498 for ; Wed, 22 Apr 1998 10:23:39 -0700 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <11413.893258973@north.lcs.mit.edu> References: "Your message of Wed, 22 Apr 1998 10:36:53 EDT." <353E0085.47D145B7@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Apr 1998 10:22:10 -0700 To: rem-conf@es.net From: Dave Singer Subject: Re: MBone usage and loss X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 11:29 AM -0400 4/22/98, Mark Handley wrote: ... >Basically the sites behind the SE-US link are seeing high loss rates. >The other sites are doing fairly well. > It seems that a good option for dealing with the case where there us a single link which causes problems, is to have a version of mrouted which can a) buffer some small quantity of packets b) request a re-transmission of 'recently lost' packets. Then you can get one re-transmission request/response to improve service for the whole cloud downstream of that link. Clearly there are two issues here which make it a little trickier: a) if the predominant cause of loss is congestion, re-transmission is making the larger problem worse, not better. However, it would at leats put RTP/IP-multicast on a par with TCP for competign for the bandwidth. b) the interval over which re-transmission is worth asking for depends (i) critically on the amount of buffering at the final clients, and (ii) that they are willing to manage 'severe' packet re-ordering in that interval. If the interval is 'short' (shorter than the re-transmission time over a long link), or re-ordering is not tolerated, re-transmission doesn't help. Given the jitter one sees on the public net, I don't believe that b(i) should be an issue (the de-jitter buffer should already be large for a one-way event). I don't know about b(ii), but we've certainly seen some pretty weird packet orders from apparently 'local' events (e.g. NASA Mountain View, which is only a few miles away). Per-link packet recovery is more efficient and more likely to work than per-client, I believe. As for why people don't watch the MBone, try the telling combination of a) 'specialist' content (i.e. relevant to only a fraction of the population) b) low multicast connectivity, especially to the 'masses' c) poor viewing conditions (low frame rate, audio drop-outs) d) often mediocre sourcing (camera and sound techniques) e) very basic tools (not that I'm criticizing, mind you) at both ends f) mis-match between data rates and access rates (few events at even 56K and below) David Singer Apple Computer/IMG 408-974-3162 From rem-conf Wed Apr 22 10:43:51 1998 From rem-conf-request@es.net Wed Apr 22 10:43:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS3Wo-0000xz-00; Wed, 22 Apr 1998 10:41:50 -0700 Received: from zephyr.isi.edu [128.9.160.160] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS3Wn-0000xk-00; Wed, 22 Apr 1998 10:41:49 -0700 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id KAA24495; Wed, 22 Apr 1998 10:41:34 -0700 (PDT) Date: Wed, 22 Apr 1998 10:41:34 -0700 From: braden@ISI.EDU Posted-Date: Wed, 22 Apr 1998 10:41:34 -0700 Message-Id: <199804221741.AA09077@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Wed, 22 Apr 1998 10:41:34 -0700 To: rem-conf@es.net, bryan@wpine.com Subject: Re: Declining audiences? (Was: Netshow and the MBONE) Cc: braden@ISI.EDU X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list *> From list-mgr@ISI.EDU Wed Apr 22 08:47:28 1998 *> X-Sender: bill@140.249.38.180 *> Mime-Version: 1.0 *> Content-Type *> : *> text/plain *> ; *> charset="us-ascii" *> *> Date: Wed, 22 Apr 1998 11:38:11 +0100 *> To: rem-conf@es.net *> From: bryan@wpine.com (Bill Ryan) *> Subject: Re: Declining audiences? (Was: Netshow and the MBONE) *> X-Mailing-List: *> X-Loop: rem-conf@es.net *> Precedence: list *> Content-Length: 1633 *> X-Lines: 44 *> *> The decline in viewers of various multicast events begs the following questions: *> *> 1. Is it due to lack of content (or content which interests the masses)? *> *> 2. Is it due to the lack of user friendly apps. which allow an enduser to *> view a multicast event easily? *> *> 3. Is it due to the lack of user friendly apps. which allow content *> providers to host multicast events? *> *> 4. Is it due to the lack of PR for multicast events? *> *> Most likely a combination of all of the above? *> *> Bill *> How about "none of the above"? I have personally observed two problems with watching interesting technical events like conferences and seminars, as well as with using the MBONE for teleconferences. (1) Audio often does not work very well, presumably due to congested paths. This is a technical problem in our beloved Internet, and it has proved the most serious barrier to my using the MBONE for collaborations with others. There are people with whom I would very much like to hold MBONE teleconferences on a weekly basis, just as if there were in my office, but congested Internet paths make it impossible. (It was partly to solve this problem that we developed RSVP/Integrated Services. Mark does not like RSVP, but currently it is the only solution that I believe will reliably provide useful MBONE service.) (2) The quality of the camera work, miking, and lighting often make it difficult to follow the content of a meeting or seminar without my paying very close and continuing attention. Sometimes the content is very important to me, so that it is worth turning off all other distractions and sitting down in the virtual meeting room. More often, I have some casual interest and would like to divert part of my attention to other tasks. I imagine that if the broadcast were of higher quality, I would be able to more easily and effectively do so. This is not a network problem, although it is a technical problem. Bob Braden From rem-conf Wed Apr 22 11:53:55 1998 From rem-conf-request@es.net Wed Apr 22 11:53:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS4Yl-0002TT-00; Wed, 22 Apr 1998 11:47:55 -0700 Received: from calvin.dgbt.crc.ca (calvin.dgbt.doc.ca) [142.92.36.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS4Yk-0002Sv-00; Wed, 22 Apr 1998 11:47:54 -0700 Received: from dilbert.dgbt.doc.ca (dilbert.dgbt.crc.ca [142.92.36.11]) by calvin.dgbt.doc.ca (8.8.8/8.8.8) with SMTP id OAA16909 for ; Wed, 22 Apr 1998 14:46:52 -0400 (EDT) Message-ID: <012c01bd6e1f$6bf1eb60$0b245c8e@dilbert.dgbt.doc.ca> Reply-To: "Andrew Patrick" From: "Andrew Patrick" To: Subject: Human Factors of MBone Videoconferences (a new research paper) Date: Wed, 22 Apr 1998 14:49:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The recent discussion on the problems with and audiences for MBone sessions makes a great opportunity to plug my latest work :-) I have recently completed a research paper The Human Factors of MBone Videoconferences: Recommendations for Improving Sessions and Software which you can find at http://debra.dgbt.doc.ca/mbone/human-factors/ The paper presents a review of the current MBone conferencing tools and current practices and attempts to draw lessons from human-factors research on videoconferencing and broadcasting. I try to make specific recommendations for improving the MBone videoconference software and the sessions we are organizing. I have submitted the manuscript for publication in a peer-reviewed scientific journal. Here is the Abstract: The "MBone" is the portion of the Internet that has implemented a new computer network technology called "multicasting". Multicasting supports efficient distribution of network traffic to multiple users simultaneously. Videoconferencing is the most common MBone application in use today and this paper reviews the human factors issues related to MBone videoconferencing. Three parameters of human factors concerns are defined: the task of the session (meeting, education, entertainment), the media used during the session (video, audio, shared workspace), and the communication modes involved (interactive vs. non-interactive and formal vs. informal). Videoconference sessions and software can be placed in this parameter space and this can provide valuable information about the technical and human requirements. The human factors research literature relevant to each of these parameters is reviewed and the current MBone tools are analyzed. Specific recommendations are made for MBone session organizers and software developers. These recommendations are not all specific to multicasting and will be of interest to people developing or using any videoconference system. Early on, I identify some of the problems that are leading to slow adoption of MBone videoconferencing: There are a number of factors that are contributing to the rate that the MBone is being deployed. First, implementing the MBone is a difficult technical task that requires advanced knowledge of Internet protocols and routers. Second, support for the MBone protocols must be provided in the network itself and cannot be installed by end users. Third, the MBone technologies have developed gradually and have been relatively unstable and unpredictable in the past, making many potential users hesitant. Fourth, the end user applications developed for the MBone are still immature and difficult to use especially in comparison to more highly developed multimedia applications. Fifth, the Internet is often congested and this leads to unacceptable audio and video quality. Sixth, there is little compelling content available on the MBone and too few people to support personal communications and too little high quality production material to support a mass audience. Seventh, the content that is available on the MBone is usually badly produced, often created by pointing a camera at the front of a classroom, making the service pale in comparison to television or films. Some of you may find this paper interesting and valuable, and I welcome your comments. From rem-conf Wed Apr 22 13:34:03 1998 From rem-conf-request@es.net Wed Apr 22 13:34:02 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS69O-0004BC-00; Wed, 22 Apr 1998 13:29:50 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS69N-0004Ag-00; Wed, 22 Apr 1998 13:29:49 -0700 Received: from cflat.precept.com (cflat.precept.com [204.162.117.199]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id NAA03130; Wed, 22 Apr 1998 13:28:16 -0700 (PDT) Date: Wed, 22 Apr 1998 13:28:10 -0700 (PDT) From: Karl Auerbach Reply-To: Karl Auerbach To: Henning Schulzrinne cc: rem-conf@es.net Subject: Re: Netshow and the MBONE In-Reply-To: <353E0085.47D145B7@cs.columbia.edu> Message-ID: X-X-Sender: karl@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > This argument has been made elsewhere and earlier, but most people I > talked to about Infocom distribution care very little about hearing > whole sessions live. (They'd be at Infocom if they had the time.) They > want selected talks (and often want to fast-forward through the > introduction), at their convenience, i.e., unicast. Kevin Almeroth's IMJ is a pretty good way to watch the recorded sessions. And it multicasts 'em out so that if anybody else happens to come by at about the same time there the bandwidth costs can be shared. Otherwise the flow is no worse than unicast. The more we allow yuppie networking -- i.e. "I want to see it and I want to see it now!" -- the less efficient it is going to be. The trick seems to be to allow true on-demand but also offer a "if you wait a little while, we can show it to you at a lower cost" alternative that can hopefully garner multiple, simultaneous clients. --karl-- From rem-conf Wed Apr 22 14:18:37 1998 From rem-conf-request@es.net Wed Apr 22 14:18:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS6sq-0005I5-00; Wed, 22 Apr 1998 14:16:48 -0700 Received: from eagle.rvs.uni-hannover.de [130.75.5.48] by mail1.es.net with smtp (Exim 1.81 #2) id 0yS6sp-0005Hf-00; Wed, 22 Apr 1998 14:16:47 -0700 Received: from kauai(really [130.75.5.162]) by eagle.rvs.uni-hannover.de via sendmail with smtp id for ; Wed, 22 Apr 1998 23:15:58 +0200 (METDST) (Smail-3.2.0.92 1997-Feb-9 #3 built 1997-Apr-4) Date: Wed, 22 Apr 1998 23:15:58 +0200 (MET DST) From: "Lutz Grueneberg, RVS" X-Sender: gruen@kauai To: Christian Isnard - CERN IT/CS cc: rem-conf MBONE List Subject: Re: Running vic with SunVideoPlus card ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, some people in Erlangen/Germany have enhanced VIC to run with the new Osprey chipset in the SunVidoPlus card. Toerless Eckert gave me a hint to the right FTP location. ftp://ftp.informatik.uni-erlangen.de/pub/vic.FAU We run the vic versions found there on our Sparc10 with SunVideoPlus without problems. Regards, Lutz -- // Lutz Gr=FCneberg Lehrgebiet Rechnernetze und Verteilte Sy= steme // Universit=E4t Hannover // Schlo=DFwender Str. 5 // gruen@rvs.uni-hannover.de D-30159 Hannover, Germany // Public PGP-Key available: http://www.rvs.uni-hannover.de/people/gruen.ht= ml // http://bs.mit.edu:8001/pks-toplev.html From rem-conf Wed Apr 22 14:19:29 1998 From rem-conf-request@es.net Wed Apr 22 14:19:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS6vC-0005Le-00; Wed, 22 Apr 1998 14:19:14 -0700 Received: from sparc.isl.net [199.3.25.3] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS6vA-0005LF-00; Wed, 22 Apr 1998 14:19:13 -0700 Received: from sparc.isl.net (206-18-112-85.la.inreach.net [206.18.112.85]) by sparc.isl.net (8.8.5/8.8.5) with SMTP id QAA25352; Wed, 22 Apr 1998 16:04:14 -0500 (CDT) From: Success@mauimail.com Posted-Date: Wed, 22 Apr 1998 16:04:14 -0500 (CDT) Message-Id: <199804222104.QAA25352@sparc.isl.net> Date: Wed, 22 Apr 98 14:01:44 EST To: associates@success1.com Subject: Express mail X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You just stumbled upon something big ! Pt or FT !No competition !No selling ! Not MLM ! $1,000 - $5,000 per week from home, within 30 days ! Daily conference calls ! Complete training and support ! Leads available ! Dear Friend, If your tired of the hype , then read on : Everyone wants more and we have the system that can get it...... Over 20,000 doctors, lawyers, CPA's and business people, last year alone, started using our system to create wealth in their spare time. Many are making in excess of $50,000 per month. Speak to them yourself ! " I'm a chiropractor in Hawaii and use this system in my spare time to consistently make over $4,000 per week !" Michael F. Makawao, HI " I'm a single nurse and mom with 5 kids, have been using the system for 18 months,and last year alone, earned $400,000 ! " Melissa F., Parkersburg, IA " I was a practicing priest for many years, retired and started using this system. Last week I earned $33,000 and bought my wife a new van - CASH " Jim P., Port Angeles, WA These people were taught how to turn a one time investment into big money ! Is the timing right for you ?Find out on our discovery call. Risk free and pressure free ! 1 800 452 4981 Outside the U.S. 1 619 678 4227 ext. 0630 To have your name removed form our list, send an email with remove in subject to asedrick@usa.net. We filter against all universal remove lists. From rem-conf Wed Apr 22 14:25:13 1998 From rem-conf-request@es.net Wed Apr 22 14:25:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS70d-00061M-00; Wed, 22 Apr 1998 14:24:51 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS70c-00060i-00; Wed, 22 Apr 1998 14:24:50 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.7/8.8.7) with SMTP id RAA21982; Wed, 22 Apr 1998 17:24:16 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id RAA16578; Wed, 22 Apr 1998 17:20:24 -0400 Date: Wed, 22 Apr 1998 17:20:24 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199804222120.RAA16578@billings.csb> To: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) Cc: vbarajas@mail.hac.com X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list There is a critically important issue of user perception underlying this remark. The "masses" 8^) often confuse *streaming* technology such as RealVideo with *real-time* MBONE technology. When you can buffer several seconds of content coming over the wire, you can play all sorts of clever tricks to present smooth and intact audio and video. When you have to present things in near-real-time to allow for interaction between dispersed participants, it can be hellishly difficult for the technology and the listener. Viewers raised on TV, and now streaming systems, tend to hold real-time multicast to the same standards. We certainly must work on improving multicast technology, but perhaps we also need to work on 1) appropriate use in areas where it has strengths, and 2) working on improving the appreciation of the difference between streaming and real-time systems. Cheerio, Rick Rodgers > From rem-conf-request@es.net Wed Apr 22 13:20:24 1998 > From: vbarajas@mail.hac.com > > What about a lack of an appropriate technology. I recently was able to > participate in a the reception of an MBONE broadcast and , as a member of the > "masses", I was really underwhelmed. With the choices available for the > delivery of media, the technology as executed today is woefully lacking. I am > very interested in the content but have a hard time justifiying the time wasted > trying to decipher garbled audio and sttuudering video movement. > > ....victor From rem-conf Wed Apr 22 14:26:59 1998 From rem-conf-request@es.net Wed Apr 22 14:26:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS72V-0006Ie-00; Wed, 22 Apr 1998 14:26:47 -0700 Received: from burdell.cc.gatech.edu [130.207.3.207] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS72U-0006Hi-00; Wed, 22 Apr 1998 14:26:46 -0700 Received: from ibis.cc.gatech.edu (ammar@ibis.cc.gatech.edu [130.207.8.101]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id RAA18526; Wed, 22 Apr 1998 17:26:39 -0400 (EDT) Received: (from ammar@localhost) by ibis.cc.gatech.edu (8.8.4/8.6.9) id RAA07697; Wed, 22 Apr 1998 17:26:33 -0400 (EDT) From: ammar@cc.gatech.edu (Mostafa Ammar) Message-Id: <199804222126.RAA07697@ibis.cc.gatech.edu> Subject: Re: Netshow and the MBONE To: karl@precept.com Date: Wed, 22 Apr 1998 17:26:33 -0400 (EDT) Cc: rem-conf@es.net In-Reply-To: from "Karl Auerbach" at Apr 22, 98 01:28:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > >> This argument has been made elsewhere and earlier, but most people I >> talked to about Infocom distribution care very little about hearing >> whole sessions live. (They'd be at Infocom if they had the time.) They >> want selected talks (and often want to fast-forward through the >> introduction), at their convenience, i.e., unicast. > >Kevin Almeroth's IMJ is a pretty good way to watch the recorded sessions. >And it multicasts 'em out so that if anybody else happens to come by at >about the same time there the bandwidth costs can be shared. Otherwise >the flow is no worse than unicast. > > --karl-- > I agree with Karl's comments (of course:). The earlier message, however, implies that interaction with content automatically means that it would have to be unicast. This is not necessarily true. I would encourage people to look at our PicPat system that allows you to pause multicast streams as they are being received. See http://www.cc.gatech.edu/fac/Mostafa.Ammar/picpat/ The ideas can also be extended to other VCR-style functions (FF and REW) as described in our 1996 JSAC paper -- See link in above Web Page. Mostafa ================================================================= Mostafa Ammar Phone:(404)894-3292 Professor Fax: (404)894-0272 College of Computing E-mail: ammar@cc.gatech.edu Georgia Institute of Technology Atlanta, GA 30332 WWW:http://www.cc.gatech.edu/fac/Mostafa.Ammar ================================================================= From rem-conf Wed Apr 22 14:38:58 1998 From rem-conf-request@es.net Wed Apr 22 14:38:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS7BH-0007Xq-00; Wed, 22 Apr 1998 14:35:51 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS7BG-0007Xe-00; Wed, 22 Apr 1998 14:35:51 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.7/8.8.7) with SMTP id RAA22435; Wed, 22 Apr 1998 17:35:46 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id RAA16633; Wed, 22 Apr 1998 17:31:54 -0400 Date: Wed, 22 Apr 1998 17:31:54 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199804222131.RAA16633@billings.csb> To: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) Cc: braden@isi.edu X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From rem-conf-request@es.net Wed Apr 22 13:45:20 1998 > > How about "none of the above"? > > I have personally observed two problems with watching interesting > technical events like conferences and seminars, as well as with > using the MBONE for teleconferences. > > (1) Audio often does not work very well, presumably due to congested > paths. > (2) The quality of the camera work, miking, and lighting often make > it difficult to follow the content of a meeting or seminar > without my paying very close and continuing attention. > Bob Braden Two important point, Bob!!! If it's one thing we've learned from the WWW series, it is that audio is paramount, text is important, video of the speaker is interesting but of comparatively low information value. There are certainly network issues in the audio quality problem, but there are also much neglected issues of *production values* in many MBONE presentations, starting with inadequate planning and advance setup of audio and video equipment, lack of any enforcement of good presentation principles for speakers (and here I refer to issues we've known about for >100 years, and which pre-Web conferences have had guidelines for, including requirements that speakers speak slowly and clearly, that slides be made up well in advance, use large fonts and clearly contrasting colors, that slides only have on the order of 5 lines of text on them, etc.). Although the era of IETF-like presentations in which the speaker taps on his hand-held mike while wiggling the hand-scrawled overhead he dashed off on the plane trip last night did have its charms for techies, we should work hard on drawing a line under it -- we need to move on to an era with much higher technical production values. We struggled toward that goal at the Web conferences -- it's hard and underappreciated work, but we have to start getting it right... Cheerio, Rick Rodgers From rem-conf Wed Apr 22 15:02:48 1998 From rem-conf-request@es.net Wed Apr 22 15:02:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS7Y1-0000ng-00; Wed, 22 Apr 1998 14:59:21 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS7Y1-0000nW-00; Wed, 22 Apr 1998 14:59:21 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.7/8.8.7) with SMTP id RAA23511 for ; Wed, 22 Apr 1998 17:59:20 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id RAA16723; Wed, 22 Apr 1998 17:55:27 -0400 Date: Wed, 22 Apr 1998 17:55:27 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199804222155.RAA16723@billings.csb> To: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > we need to move on to an era with much > higher technical production values. Rats, forgot an important point: we've all struggled trying to read tiny type that is being captured by a video camera aimed at a projection screen. This is a dismally inadequate way of conveying information, and the reason I've tried to foster the integration of multicast and Web technologies, a problem which has been attacked first by Ed Burns at NCSA, then Peter Parnes at CDT (Sweden) and Tie Liao at INRIA. What we need is good audio coupled to clear locally displayed documents (over which the viewer has control of things like font sizes, etc.) on occasion with low-bandwith video of the speaker. It's not hard to imagine interesting directions for this work to take... Of course, we have to pour exciting content into this framework, but we ignore good production values at our peril... Cheerio, Rick Rodgers From rem-conf Wed Apr 22 15:23:33 1998 From rem-conf-request@es.net Wed Apr 22 15:23:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS7sV-0001f3-00; Wed, 22 Apr 1998 15:20:31 -0700 Received: from hnc.hnc.com [206.79.10.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yS7sT-0001dy-00; Wed, 22 Apr 1998 15:20:29 -0700 Received: (from adm@localhost) by hnc.hnc.com (8.8.8/8.8.8) id PAA10398; Wed, 22 Apr 1998 15:16:12 -0700 (PDT) Received: from hnc2.hnc.com(206.79.10.10) by hnc.hnc.com via smap (V2.1) id xma010391; Wed, 22 Apr 98 15:15:42 -0700 Received: from pchnc.hnc.com (pchnc [191.9.204.105]) by spike.hnc.com (8.8.8/8.8.8) with ESMTP id PAA23962; Wed, 22 Apr 1998 15:16:42 -0700 (PDT) Received: by pchnc.hnc.com with Internet Mail Service (5.0.1460.8) id ; Wed, 22 Apr 1998 15:18:23 -0700 Message-ID: From: "Lovett, Dean" To: scwpf@sdsc.edu, talks@ucsd.edu, talks-ece@ece.ucsd.edu, talks-cse@cs.UCSD.EDU, e-club@ucsd.edu, web-watchers--KClaffy, rem-conf@es.net, webteam@qualcomm.com, webheads@sio.ucsd.edu, java-ucsd@mib.org, flesner@nosc.mil, GregJohnson Subject: Thursday night - Web Programmers Forum - Live MBone Broadcast Date: Wed, 22 Apr 1998 15:18:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Thursday, April 23, 1998, 7pm San Diego Supercomputer Center (SDSC) Auditorium Scheduled speakers: Gary Gwin Cafesoft Gary will discuss and demonstrate how Cafesoft has used Java on the server and in client applications to implement business solutions. Alex Shah, Product Manager Tony Darugar, Technical Director Binary Evolution, Inc. "Creating high performance web sites using display templates and database content" For directions and parking information, see the Southern California Web Programmers Forum home page at http://www.sdsc.edu/scwpf From rem-conf Wed Apr 22 16:23:33 1998 From rem-conf-request@es.net Wed Apr 22 16:23:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yS8nY-0003CC-00; Wed, 22 Apr 1998 16:19:28 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0yS8nW-0003Bm-00; Wed, 22 Apr 1998 16:19:26 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Apr 1998 00:18:19 +0100 To: Dave Singer cc: rem-conf@es.net, J.Crowcroft@cs.ucl.ac.uk Subject: Re: MBone usage and loss In-reply-to: Your message of "Wed, 22 Apr 1998 10:22:10 PDT." Date: Thu, 23 Apr 1998 00:18:18 +0100 Message-ID: <28829.893287098@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message , Dave Singer typed: yes, but realaudio stream off the web is alo ZILCH out of our 155 Mbps backbone traffic in the uk, so the problem is not "mbone v. streamed web" it is (as rick rodgers says) authored , relevent, engaging, content >>At 11:29 AM -0400 4/22/98, Mark Handley wrote: >>... >>>Basically the sites behind the SE-US link are seeing high loss rates. >>>The other sites are doing fairly well. >>> >> >>It seems that a good option for dealing with the case where there us a >>single link which causes problems, is to have a version of mrouted which >>can >> >>a) buffer some small quantity of packets >>b) request a re-transmission of 'recently lost' packets. >> >>Then you can get one re-transmission request/response to improve service >>for the whole cloud downstream of that link. >> >>Clearly there are two issues here which make it a little trickier: >>a) if the predominant cause of loss is congestion, re-transmission is >>making the larger problem worse, not better. However, it would at leats put >>RTP/IP-multicast on a par with TCP for competign for the bandwidth. >>b) the interval over which re-transmission is worth asking for depends (i) >>critically on the amount of buffering at the final clients, and (ii) that >>they are willing to manage 'severe' packet re-ordering in that interval. If >>the interval is 'short' (shorter than the re-transmission time over a long >>link), or re-ordering is not tolerated, re-transmission doesn't help. >> >>Given the jitter one sees on the public net, I don't believe that b(i) >>should be an issue (the de-jitter buffer should already be large for a >>one-way event). I don't know about b(ii), but we've certainly seen some >>pretty weird packet orders from apparently 'local' events (e.g. NASA >>Mountain View, which is only a few miles away). >> >>Per-link packet recovery is more efficient and more likely to work than >>per-client, I believe. >> >> >>As for why people don't watch the MBone, try the telling combination of >> >>a) 'specialist' content (i.e. relevant to only a fraction of the population) >>b) low multicast connectivity, especially to the 'masses' >>c) poor viewing conditions (low frame rate, audio drop-outs) >>d) often mediocre sourcing (camera and sound techniques) >>e) very basic tools (not that I'm criticizing, mind you) at both ends >>f) mis-match between data rates and access rates (few events at even 56K >>and below) >> >>David Singer >>Apple Computer/IMG 408-974-3162 >> >> >> cheers jon From rem-conf Wed Apr 22 18:24:28 1998 From rem-conf-request@es.net Wed Apr 22 18:24:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySAha-0004y7-00; Wed, 22 Apr 1998 18:21:26 -0700 Received: from post-30.mail.demon.net (post.mail.demon.net) [194.217.242.40] by mail1.es.net with smtp (Exim 1.81 #2) id 0ySAhZ-0004vo-00; Wed, 22 Apr 1998 18:21:25 -0700 Received: from ([194.222.59.15]) [194.222.59.15] by post.mail.demon.net with esmtp (Exim 1.82 #2) id 0ySAgQ-0004Lr-00; Thu, 23 Apr 1998 02:20:15 +0100 X-Sender: (Unverified) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Apr 1998 02:24:02 +0000 To: Yves Lepage , rem-conf@es.net From: Julian Highfield Subject: RE: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Yves Lepage wrote: > >Since then, my desktop is NT. This makes it much more problematic. I am >not going to purchase IP/TV or Icast. My only option from that point is >to use the freeware apps, which are not really mature on MS OS'es. If you noticed the lack of a "wb" whiteboard I can perhaps help: http://www.stile.lboro.ac.uk/~cojch/winwbd/winwbd.html Of course, I've only tested it under Windows 95 because I've never met anyone who will admit to using NT... Regards, Julian. From rem-conf Wed Apr 22 19:44:34 1998 From rem-conf-request@es.net Wed Apr 22 19:44:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySBxa-000694-00; Wed, 22 Apr 1998 19:42:02 -0700 Received: from necom830.hpcl.titech.ac.jp [131.112.32.132] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySBxW-00068t-00; Wed, 22 Apr 1998 19:42:00 -0700 From: Masataka Ohta Message-Id: <199804230233.LAA10928@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA10928; Thu, 23 Apr 1998 11:32:53 +0859 Subject: Re: Netshow and the MBONE To: mjh@east.isi.edu (Mark Handley) Date: Thu, 23 Apr 98 11:32:52 JST Cc: schulzrinne@cs.columbia.edu, rem-conf@es.net In-Reply-To: <11413.893258973@north.lcs.mit.edu>; from "Mark Handley" at Apr 22, 98 11:29 am X-Mailer: ELM [version 2.3 PL11] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark; > >Playing devil's advocate here :-) > ... > >All of NYC (courtesy of Sprintnet) get Mbone at an average loss rate of > >50-80%, so if this is at all typical, this is not surprising. > > 50-80% loss also renders TCP pretty much useless for anything other > than email which can tolerate long delays. By just sending 10 duplicated packets, you can effectively reduce 80% loss 10% without incurring delay. While it make the Internet more congested, it's fine for those who are using the duplicated packets, which makes people deploy the strategy, which melts down the Internet. > Adding redundancy can provide good quality for those sites in the > 20-30% loss range, but we may decide that it's not sufficiently > network-friendly to do so. Certainly. Masataka OHta From rem-conf Wed Apr 22 20:30:50 1998 From rem-conf-request@es.net Wed Apr 22 20:30:49 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySCg8-0007Ew-00; Wed, 22 Apr 1998 20:28:04 -0700 Received: from cu.nih.gov [128.231.160.112] by mail1.es.net with smtp (Exim 1.81 #2) id 0ySCg7-0007Em-00; Wed, 22 Apr 1998 20:28:03 -0700 To: rem-conf@es.net From: "Roger Fajman" Date: Wed, 22 Apr 1998 23:25:47 EDT Subject: Re: Netshow and the MBONE Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > It appears that MBONE network count is rising less > steeply than that of the Internet as a whole. While there is > a good deal of corporate deployment occurring behind > firewalls, this does say something about the progress in deployment > of multicast as an internet-wide service. We are multicasting a number of scientific (biomedical) seminars on our own network and have put a few on the MBONE. We'll be doing more of that in the future. The multicasts on our network have been well-received by our users. The quality on our internal network is good, which is important. Our scientists are interested in the material being discussed, not in the technology being used to distribute it. Roger Fajman Telephone: +1 301 402 4265 National Institutes of Health Internet: raf@cu.nih.gov Bethesda, Maryland, USA From rem-conf Thu Apr 23 01:18:20 1998 From rem-conf-request@es.net Thu Apr 23 01:18:18 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySH5y-0001y5-00; Thu, 23 Apr 1998 01:11:02 -0700 Received: from concorde.inria.fr [192.93.2.39] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySH5u-0001xt-00; Thu, 23 Apr 1998 01:10:59 -0700 Received: from maillol.inria.fr (maillol.inria.fr [128.93.25.14]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id KAA13455; Thu, 23 Apr 1998 10:10:55 +0200 (MET DST) Received: (from liao@localhost) by maillol.inria.fr (8.7.6/8.7.3) id JAA05282; Thu, 23 Apr 1998 09:51:24 +0200 (MET DST) Date: Thu, 23 Apr 1998 09:51:24 +0200 (MET DST) Message-Id: <199804230751.JAA05282@maillol.inria.fr> From: Tie Liao To: schulzrinne@cs.columbia.edu CC: rem-conf@es.net In-reply-to: <353E0085.47D145B7@cs.columbia.edu> (message from Henning Schulzrinne on Wed, 22 Apr 1998 10:36:53 -0400) Subject: Re: Netshow and the MBONE Reply-to: Tie.Liao@inria.fr X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I make the same observations. At beginning, users are rather curious to use mbone tools. But as time passed, the quality and maybe the content as well discouraged users. One of the main reasons should be the lack of bandwidth. Use of unicast makes the things even worse. While mbone conferences lose audience in global scope, small conferences or seminars in a limited scope have gained audience. We have experimented a number of conference broadcasts in France with clean HTML slides (http://webcanal.inria.fr/doc/man/webconf.html) and get rather positive feedback. Slides are important for local audience and particularly important for remote listeners. Tie Liao > Playing devil's advocate here :-) > > It seems instructive to look at recent audience statistics. The type of > events and the audience numbers seem to have decreased, if anything, > from numbers in 1994 (say). When I peeked at the vat window at IETF, > there were maybe a dozen names. The operator confirmed that this was not > atypical. For the Infocom transmission, we had maybe ten listeners, max, > with 3 or 4 more typical. Windows on the world has about 20; MAGIC 94 > about 4 (including myself, for testing). This is during a time (10 am) > when Europe is still around... > > I know that a number of people are behind firewalls and don't send RTCP > reports, but I doubt that this would more than double the audience. Even > most research labs haven't enabled (or have shut down again) multicast > ingress, from what I can tell. > > All of NYC (courtesy of Sprintnet) get Mbone at an average loss rate of > 50-80%, so if this is at all typical, this is not surprising. > > This argument has been made elsewhere and earlier, but most people I > talked to about Infocom distribution care very little about hearing > whole sessions live. (They'd be at Infocom if they had the time.) They > want selected talks (and often want to fast-forward through the > introduction), at their convenience, i.e., unicast. > > Any sufficiently compelling mass-audience content is > - likely available on broadcast TV, radio, cable, pay-TV or on tape, at > far better quality and with less hassle > - or is not suited for minors > - not particularly enjoyable at 28 kb/s or even 280 kb/s. > > Multicast makes sense (as IP/TV demonstrates) for *local* redistribution > of content such as CNN. For now, having a bunch of local feeds of this > type of fare seems far more efficient, as I can significantly ramp up > the bandwidth. From rem-conf Thu Apr 23 01:25:53 1998 From rem-conf-request@es.net Thu Apr 23 01:25:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySHFq-00025I-00; Thu, 23 Apr 1998 01:21:14 -0700 Received: from relay8.uu.net [192.48.96.84] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySHFp-000255-00; Thu, 23 Apr 1998 01:21:13 -0700 Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQemib06808; Thu, 23 Apr 1998 04:21:07 -0400 (EDT) Received: by neserve0.uu.net id QQemib04888; Thu, 23 Apr 1998 04:21:05 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Declining audiences? (Was: Netshow and the MBONE) To: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Date: Thu, 23 Apr 1998 04:21:05 -0400 (EDT) Cc: rem-conf@es.net, braden@isi.edu In-Reply-To: <199804222131.RAA16633@billings.csb> from "R. P. Channing Rodgers, M.D." at Apr 22, 98 05:31:54 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Making things interactive helps spark the multicast spirit. That is the difference in the mbone apps and the microsoft apps. If the mbone apps could be refined, those little rtcp packets could actually be of use. _J R. P. Channing Rodgers, M.D. said: > > > > From rem-conf-request@es.net Wed Apr 22 13:45:20 1998 > > > > How about "none of the above"? > > > > I have personally observed two problems with watching interesting > > technical events like conferences and seminars, as well as with > > using the MBONE for teleconferences. > > > > (1) Audio often does not work very well, presumably due to congested > > paths. > > (2) The quality of the camera work, miking, and lighting often make > > it difficult to follow the content of a meeting or seminar > > without my paying very close and continuing attention. > > Bob Braden > > Two important point, Bob!!! If it's one thing we've learned from the > WWW series, it is that audio is paramount, text is important, video > of the speaker is interesting but of comparatively low information > value. There are certainly network issues in the audio quality problem, > but there are also much neglected issues of *production values* in > many MBONE presentations, starting with inadequate planning and advance > setup of audio and video equipment, lack of any enforcement of good > presentation principles for speakers (and here I refer to issues we've > known about for >100 years, and which pre-Web conferences have had > guidelines for, including requirements that speakers speak slowly and > clearly, that slides be made up well in advance, use large fonts and > clearly contrasting colors, that slides only have on the order of > 5 lines of text on them, etc.). Although the era of IETF-like > presentations in which the speaker taps on his hand-held mike while > wiggling the hand-scrawled overhead he dashed off on the plane trip > last night did have its charms for techies, we should work hard > on drawing a line under it -- we need to move on to an era with much > higher technical production values. We struggled toward that goal at > the Web conferences -- it's hard and underappreciated work, but we have > to start getting it right... > > Cheerio, Rick Rodgers > From rem-conf Thu Apr 23 02:39:53 1998 From rem-conf-request@es.net Thu Apr 23 02:39:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySIR5-0003Zo-00; Thu, 23 Apr 1998 02:36:55 -0700 Received: from dienstmann-atm.informatik.uni-bremen.de (dienstmann.informatik.uni-bremen.de) [134.102.213.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySIR1-0003Zc-00; Thu, 23 Apr 1998 02:36:52 -0700 Received: by dienstmann.informatik.uni-bremen.de (8.7.3/30.7.96cl) id LAA11992 Thu, 23 Apr 1998 11:36:45 +0200 (MET DST) Date: Thu, 23 Apr 1998 11:36:45 +0200 (MET DST) Message-Id: <199804230936.LAA11992@dienstmann.informatik.uni-bremen.de> From: Carsten Bormann To: rem-conf@es.net CC: gaertner@Informatik.Uni-Bremen.DE, jo@tzi.org Subject: Distributed thesis defense, anyone? X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We would like to conduct a thesis defense with one of the reviewers being 6000 miles away, using RTP/Mbone technology. Now, this is not a big problem from a technical point of view, but our legal people would like to have some precedent before saying yes. So: Does anyone of you know about a thesis defense or some other high-key legal event where the people who had to be there legally were distributed and connected using videoconferencing technology? BTW, I have heard about the story of the marriage via H.320, and I would welcome some more details on that. A thesis defense or similar event (where a reviewer actually has to judge the performance of a candidate) would be much more convincing, though. Gruesse, Carsten From rem-conf Thu Apr 23 03:11:44 1998 From rem-conf-request@es.net Thu Apr 23 03:11:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySIln-00049m-00; Thu, 23 Apr 1998 02:58:19 -0700 Received: from brain.sedal.usyd.edu.au [129.78.24.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySIlh-00049H-00; Thu, 23 Apr 1998 02:58:13 -0700 Received: from brain.sedal.usyd.edu.au (brain.sedal.usyd.edu.au [129.78.24.68]) by brain.sedal.usyd.edu.au (8.8.8/8.8.8) with SMTP id TAA14027; Thu, 23 Apr 1998 19:57:46 +1000 (EST) Date: Thu, 23 Apr 1998 19:57:46 +1000 (EST) From: Marwan Jabri X-Sender: marwan@brain.sedal.usyd.edu.au To: Carsten Bormann cc: rem-conf@es.net, gaertner@Informatik.Uni-Bremen.DE, jo@tzi.org Subject: Re: Distributed thesis defense, anyone? In-Reply-To: <199804230936.LAA11992@dienstmann.informatik.uni-bremen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I am aware of a thesis defence involving a staff from AT&T (Holmdel, NJ, USA) and a University in France, using H.320. The presentation and the committee was France. This was in 1993. Hope this helps. Marwan Jabri ------------ Marwan Jabri Professor in Adaptive Systems Dept of Electrical Engineering, The University of Sydney NSW 2006, Australia Tel: (+61-2) 9351-2240, Fax:(+61-2) 9351-7209, Mobile: (+61) 414-512240 Email: marwan@sedal.usyd.edu.au, http://www.sedal.usyd.edu.au/~marwan/ On Thu, 23 Apr 1998, Carsten Bormann wrote: > We would like to conduct a thesis defense with one of the reviewers > being 6000 miles away, using RTP/Mbone technology. Now, this is not a > big problem from a technical point of view, but our legal people would > like to have some precedent before saying yes. > > So: > > Does anyone of you know about a thesis defense or some other high-key > legal event where the people who had to be there legally were > distributed and connected using videoconferencing technology? > > BTW, I have heard about the story of the marriage via H.320, and I > would welcome some more details on that. A thesis defense or similar > event (where a reviewer actually has to judge the performance of a > candidate) would be much more convincing, though. > > Gruesse, Carsten > > From rem-conf Thu Apr 23 05:28:13 1998 From rem-conf-request@es.net Thu Apr 23 05:28:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySL0L-00065U-00; Thu, 23 Apr 1998 05:21:29 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySL0K-00065K-00; Thu, 23 Apr 1998 05:21:28 -0700 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA02832; Thu, 23 Apr 1998 08:20:57 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id IAA08912; Thu, 23 Apr 1998 08:20:52 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <353F3224.F88178D2@cs.columbia.edu> Date: Thu, 23 Apr 1998 08:20:52 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Carsten Bormann CC: rem-conf@es.net, gaertner@Informatik.Uni-Bremen.DE, jo@tzi.org Subject: Re: Distributed thesis defense, anyone? References: <199804230936.LAA11992@dienstmann.informatik.uni-bremen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Carsten Bormann wrote: > > We would like to conduct a thesis defense with one of the reviewers > being 6000 miles away, using RTP/Mbone technology. Now, this is not a > big problem from a technical point of view, but our legal people would > like to have some precedent before saying yes. > > So: > > Does anyone of you know about a thesis defense or some other high-key > legal event where the people who had to be there legally were > distributed and connected using videoconferencing technology? > > BTW, I have heard about the story of the marriage via H.320, and I > would welcome some more details on that. A thesis defense or similar > event (where a reviewer actually has to judge the performance of a > candidate) would be much more convincing, though. You might want to take a look at the March 1998 "DFN Mitteilungen", where I have a brief article detailing my experiences conducting a number of Master's theses defenses at the TU Berlin while sitting in my office in NYC. It's in German, but I presume that's not an issue in this case. > > Gruesse, Carsten -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 (@Bell Labs: 732 949 8344) Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf Thu Apr 23 06:21:40 1998 From rem-conf-request@es.net Thu Apr 23 06:21:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySLtK-00070u-00; Thu, 23 Apr 1998 06:18:18 -0700 Received: from mars.dgrc.crc.ca [142.92.95.100] by mail1.es.net with smtp (Exim 1.81 #2) id 0ySLtI-00070b-00; Thu, 23 Apr 1998 06:18:16 -0700 Received: from casper.dgrc.doc.ca (casper.dgrc.crc.ca) by mars.dgrc.crc.ca (4.1/SMI-4.1) id AA29249; Thu, 23 Apr 98 09:17:13 EDT Received: by casper.dgrc.doc.ca (SMI-8.6/SMI-SVR4) id JAA06708; Thu, 23 Apr 1998 09:17:14 -0400 Date: Thu, 23 Apr 1998 09:17:14 -0400 From: luigi@mars.dgrc.crc.ca (John A. Stewart) Message-Id: <199804231317.JAA06708@casper.dgrc.doc.ca> To: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: HJX+6/eUBrge0pA5WYbZAw== X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 1) Interactive sessions. I have found that overheads are impossible to read, and thus, the video of most presentations is bad. Multicasting a netscape window would be a good idea (all I need is the time), but even putting the URL for the slides would be better. 2) playback of pre-recorded sessions. Kevin Almeroths' IMJ is a great idea, as are the more recent tools for record/playback. I quite often watch the IMJ channels, just to see what comes along. The idea of recording and re-playing sessions is great - we need more of this. For instance, I'd like to see some of the Severe Tire Damage "presentations", they were always at times when I could not be at work to see them. Thanks; John Stewart john.stewart@crc.ca From rem-conf Thu Apr 23 06:29:12 1998 From rem-conf-request@es.net Thu Apr 23 06:29:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySLzi-00079z-00; Thu, 23 Apr 1998 06:24:54 -0700 Received: from cagw2.att.com (att.com) [192.128.52.90] by mail1.es.net with smtp (Exim 1.81 #2) id 0ySLzh-00079p-00; Thu, 23 Apr 1998 06:24:53 -0700 Received: by cagw2.att.com; Thu Apr 23 09:16 EDT 1998 Received: from njb140r1.ems.att.com (njb140r1.ems.att.com [135.65.202.58]) by caig2.att.att.com (AT&T/GW-1.0) with SMTP id JAA19370 for ; Thu, 23 Apr 1998 09:20:43 -0400 (EDT) Received: from njb140bh3.EMS.ATT.COM by njb140r1.ems.att.com (SMI-8.6/EMS-1.2 sol2) id JAA07937; Thu, 23 Apr 1998 09:19:12 -0400 Received: by njb140bh3.EMS.ATT.COM with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD6E99.15C8E160@njb140bh3.EMS.ATT.COM>; Thu, 23 Apr 1998 09:20:41 -0400 Message-ID: From: "Hussain, Arshad, NPG NNAD" To: "'info@inexchange.net'" , "'rem-conf@es.net'" Subject: RE: Advertisement: Website Hosting Date: Thu, 23 Apr 1998 09:20:37 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please remove me from your list >-----Original Message----- >From: info@inexchange.net [SMTP:info@inexchange.net] >Sent: Wednesday, March 25, 1998 6:12 PM >To: rem-conf@es.net >Subject: Advertisement: Website Hosting > >http://www.inexchange.net >info@inexchange.net > >InExchange would like to introduce our complete Hosting and Promotional >service. > > FOR ONLY $19.95 PER MONTH ! > >* 20 MB (megabytes) of disk space >* 750 MB of data transfer per month >* 5 E-mail accounts >* INTERNATIONAL Hosting >* Access to your account anytime via the Web Control Panel >* Full MS Front Page support >* Unlimited FTP updates >* Personal CGI directory for your own scripts (or use ours) >* The best statistics analyzer in the industry >* E-mail forwarding, auto responders and vacation reply >* Domain name registration (www.yourname.com) >* FREE registration of your domain with over 250 search engines >* Real Audio/Video support > >* Inquire about our $16.95 plan > >* Other plans also include: > Shopping cart application and database access/utilities > Cold Fusion Hosting > CyberCash, iBill and VersaNet ready > Instant on-line credit card processing > >For additional details, please refer to our website: >http://inexchange.net >info@inexchange.net > > > > > > From rem-conf Thu Apr 23 06:41:22 1998 From rem-conf-request@es.net Thu Apr 23 06:41:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySMCZ-00007j-00; Thu, 23 Apr 1998 06:38:11 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySMCY-00007T-00; Thu, 23 Apr 1998 06:38:10 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.7/8.8.7) with SMTP id JAA25348; Thu, 23 Apr 1998 09:38:04 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id JAA17677; Thu, 23 Apr 1998 09:34:11 -0400 Date: Thu, 23 Apr 1998 09:34:11 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199804231334.JAA17677@billings.csb> To: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) Cc: luigi@mars.dgrc.crc.ca X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From: luigi@mars.dgrc.crc.ca (John A. Stewart) > To: rem-conf@es.net > Subject: Re: Declining audiences? (Was: Netshow and the MBONE) > > 1) Interactive sessions. > > I have found that overheads are impossible to read, and thus, the > video of most presentations is bad. > Multicasting a netscape window would be a good idea (all I need is > the time), This is a critically important issue for presentations, and multicasting HTML is exactly what we have tried to do at various Web conferences, using the tools of Ed Burns, then Peter Parnes and Tie Liao. Getting this right is a harder problem than is generally appreciated, so it might take more of your time than you imagine 8^) > but even putting the URL for the slides would be better. This approach won't scale for large numbers of remote participants, unless you create a mechanism in advance for having multiple distributed copies of documents... > > 2) playback of pre-recorded sessions. > > Kevin Almeroths' IMJ is a great idea, as are the more recent tools > for record/playback. Thought I applaud Kevin's interesting experiments, it's not clear to me that you really need multicast for this. In any event, on-demand playback is certainly not a situation that showcases the unique properties of multicasting... Cheerio, Rick Rodgers From rem-conf Thu Apr 23 07:07:17 1998 From rem-conf-request@es.net Thu Apr 23 07:07:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySMd9-0001CP-00; Thu, 23 Apr 1998 07:05:39 -0700 Received: from burdell.cc.gatech.edu [130.207.3.207] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySMd8-0001C5-00; Thu, 23 Apr 1998 07:05:38 -0700 Received: from ibis.cc.gatech.edu (ammar@ibis.cc.gatech.edu [130.207.8.101]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id KAA00588; Thu, 23 Apr 1998 10:05:24 -0400 (EDT) Received: (from ammar@localhost) by ibis.cc.gatech.edu (8.8.4/8.6.9) id KAA09283; Thu, 23 Apr 1998 10:05:23 -0400 (EDT) From: ammar@cc.gatech.edu (Mostafa Ammar) Message-Id: <199804231405.KAA09283@ibis.cc.gatech.edu> Subject: Re: Declining audiences? (Was: Netshow and the MBONE) To: rodgers@nlm.nih.gov (R. P. Channing Rodgers M.D.) Date: Thu, 23 Apr 1998 10:05:23 -0400 (EDT) Cc: rem-conf@es.net, luigi@mars.dgrc.crc.ca In-Reply-To: <199804231334.JAA17677@billings.csb> from "R. P. Channing Rodgers, M.D." at Apr 23, 98 09:34:11 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >> >> 2) playback of pre-recorded sessions. >> >> Kevin Almeroths' IMJ is a great idea, as are the more recent tools >> for record/playback. > >Thought I applaud Kevin's interesting experiments, it's not clear to >me that you really need multicast for this. In any event, on-demand >playback is certainly not a situation that showcases the unique >properties of multicasting... The motivation for the IMJ (and the use of multicast in this instant) is spelled out in a paper that was presented at the WWW7 conference last week. You can find the paper at http://www.cs.ucsb.edu/~almeroth/publish/333.html Mostafa ================================================================= Mostafa Ammar Phone:(404)894-3292 Associate Professor Fax: (404)894-0272 College of Computing E-mail: ammar@cc.gatech.edu Georgia Institute of Technology Atlanta, GA 30332 WWW:http://www.cc.gatech.edu/fac/Mostafa.Ammar ================================================================= From rem-conf Thu Apr 23 07:07:19 1998 From rem-conf-request@es.net Thu Apr 23 07:07:18 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySMdk-0001Dq-00; Thu, 23 Apr 1998 07:06:16 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0ySMdj-0001Dc-00; Thu, 23 Apr 1998 07:06:16 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Apr 1998 15:05:40 +0100 To: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) cc: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) In-reply-to: Your message of "Thu, 23 Apr 1998 09:34:11 EDT." <199804231334.JAA17677@billings.csb> Date: Thu, 23 Apr 1998 15:05:38 +0100 Message-ID: <12703.893340338@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <199804231334.JAA17677@billings.csb>, R. P. Channing Rodgers, M.D. t yped: >>> but even putting the URL for the slides would be better. >>This approach won't scale for large numbers of remote participants, >>unless you create a mechanism in advance for having multiple distributed >>copies of documents... it would be relatively easy to take our reliable multicast file transfer/protocol and implement it as a netscape/ie plugin, then people could click on a URL, the browser would fetch it, get a redirect which would cause the protocol to join the relavent group, and the source site could multicast it out to (unchanged) browsers, even with timing - in fact, this could be recurvsively applied so it worked to send data to a powerpoint viewer plugin in the browser too, so you could use it for any slideshow.....for 1-n, it would be more general than netshow, platform and viewer independent, and nearly free...see ftp://cs.ucl.ac.uk/darpa/infocom98.ps for the protocol (jim gemmel and eve schooler have a neat paper about using somethign very simialr for s/w distribution....) alternatively, you could rely (hah! :-) on client site caches .... cheers j From rem-conf Thu Apr 23 07:42:23 1998 From rem-conf-request@es.net Thu Apr 23 07:42:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySN97-0002g5-00; Thu, 23 Apr 1998 07:38:41 -0700 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySN96-0002fv-00; Thu, 23 Apr 1998 07:38:40 -0700 Received: from [140.249.10.1] by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA25964 for ; Thu, 23 Apr 1998 10:38:15 -0400 X-Sender: bill@140.249.38.180 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Apr 1998 10:41:07 +0100 To: rem-conf@es.net From: bryan@wpine.com (Bill Ryan) Subject: Re: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >> 1) Interactive sessions. >> >> I have found that overheads are impossible to read, and thus, the >> video of most presentations is bad. >> Multicasting a netscape window would be a good idea (all I need is >> the time), >From the FWIW dept. :) We've implemented something similiar in our ClassPoint Distance Learning product. The teacher/presenter is able to "walk" the students/attendees through Web pages. Normally, the presenter outlines the presentation on a Web page with links to other pages. ClassPoint makes use of whatever Web Browser is installed on the attendee's system to display the current Web page. Presenter controls web page flow. Audio/Video/Chat is done through ClassPoint (with presenter controlling the presentation...who talks next, who sees who, who hears who, etc...). We've also done hot URL links from within our chat window in CU-SeeMe...people seem to like this feature.. Both the CU-SeeMe and ClassPoint clients require the use of our Meeting Point Conference Server in order to support multicasting and/or multi-client unicast...... Bill __________________________________________________________ Bill Ryan (bill@wpine.com) http://www.wpine.com White Pine Software, Inc. http://www.cuseeme.com 542 Amherst Street PH: 603-886-9050 x351 Tu/Fri Nashua, NH 03063 603-529-5070 Mon/Wed/Thur __________________________________________________________ From rem-conf Thu Apr 23 07:58:27 1998 From rem-conf-request@es.net Thu Apr 23 07:58:27 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySNPe-0003Ag-00; Thu, 23 Apr 1998 07:55:46 -0700 Received: from rumor.research.att.com [192.20.225.9] by mail1.es.net with smtp (Exim 1.81 #2) id 0ySNPd-0003AV-00; Thu, 23 Apr 1998 07:55:45 -0700 Received: from research.att.com ([135.207.30.100]) by rumor; Thu Apr 23 10:51:47 EDT 1998 Received: from surfcity.research.att.com ([135.207.128.5]) by research-clone; Thu Apr 23 10:54:13 EDT 1998 Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id KAA25952; Thu, 23 Apr 1998 10:54:11 -0400 (EDT) Message-ID: <043101bd6ec7$2ea0f690$4683cf87@pcmrcfast.research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: , "R. P. Channing Rodgers, M.D." Subject: Re: Declining audiences? (Was: Netshow and the MBONE) Date: Thu, 23 Apr 1998 10:50:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >> 2) playback of pre-recorded sessions. >> >> Kevin Almeroths' IMJ is a great idea, as are the more recent tools >> for record/playback. > >Thought I applaud Kevin's interesting experiments, it's not clear to >me that you really need multicast for this. In any event, on-demand >playback is certainly not a situation that showcases the unique >properties of multicasting... > When someone puts a coin into a jukebox to get a selection played, the expectation is more than a simple music-on-demand because, other people in the room listen for the selection also. Similarly, a multicast jukebox may provide more functionality than a simple VoD with (almost) no additional cost using the "unique properties of multicasting." Additionally, MJ's using different admission control policies (e.g., play a selection only when more than certain number of requests are received in a given time period) provide an excellent compromise between mass broadcast and individual VoD. By the way, this idea was around during the ITV days as a mechanism for using shared cable TV connections also. There may even be some patents on it. ----------------------------------------------------------------------- M. Reha Civanlar From rem-conf Thu Apr 23 08:02:39 1998 From rem-conf-request@es.net Thu Apr 23 08:02:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySNVU-0003Tw-00; Thu, 23 Apr 1998 08:01:48 -0700 Received: from concorde.inria.fr [192.93.2.39] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySNVS-0003Q2-00; Thu, 23 Apr 1998 08:01:46 -0700 Received: from maillol.inria.fr (maillol.inria.fr [128.93.25.14]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id RAA22649; Thu, 23 Apr 1998 17:01:22 +0200 (MET DST) Received: (from liao@localhost) by maillol.inria.fr (8.7.6/8.7.3) id QAA06502; Thu, 23 Apr 1998 16:41:56 +0200 (MET DST) Date: Thu, 23 Apr 1998 16:41:56 +0200 (MET DST) Message-Id: <199804231441.QAA06502@maillol.inria.fr> From: Tie Liao To: J.Crowcroft@cs.ucl.ac.uk CC: rodgers@nlm.nih.gov, rem-conf@es.net In-reply-to: <12703.893340338@cs.ucl.ac.uk> (message from Jon Crowcroft on Thu, 23 Apr 1998 15:05:38 +0100) Subject: Re: Declining audiences? (Was: Netshow and the MBONE) Reply-to: Tie.Liao@inria.fr X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > >>This approach won't scale for large numbers of remote participants, > >>unless you create a mechanism in advance for having multiple distributed > >>copies of documents... > > it would be relatively easy to take our reliable multicast file > transfer/protocol and implement it as a netscape/ie plugin, then > people could click on a URL, the browser would fetch it, get a > redirect which would cause the protocol to join the relavent group, > and the source site could multicast it out to (unchanged) browsers, > even with timing - in fact, this could be recurvsively applied so it > worked to send data to a powerpoint viewer plugin in the browser too, > so you could use it for any slideshow.....for 1-n, it would be more > general than netshow, platform and viewer independent, and nearly > free...see ftp://cs.ucl.ac.uk/darpa/infocom98.ps > for the protocol (jim gemmel and eve schooler have a neat paper about > using somethign very simialr for s/w distribution....) > > alternatively, you could rely (hah! :-) on client site caches .... There are two points missing: o what's the interactivity for the speaker. Generally a speaker wants to multicast a page on a simple click in a browser, no matter which browser is used. o using a netscape plugin would depend on netscape navigator. So it cann't be viewer independent. Some people also tried to mutlicast URLs so that the user's browser will fetch corresponding pages. In addition to unnecessary network traffic, that can easily cause the server overloaded and thus does not scale to large audiences. We've implemented a web conference application in webcanal which runs on a number of platforms: IRIX, Sun OS, Linux, Win 95/NT, etc. This application functions like a proxy server so which browser used does not matter. At reception a java applet is run in a java-enabled browser for automatic display of received web pages. This scheme works pretty well in our experiements (three monthly conferences or seminars are using it regularly). Record and playback will come soon... The feedback we got is that helps a lot to understand a presentation. Many people even don't like video stream until better quality can be achieved. For those interested, look at http://webcanal.inria.fr/doc/man/webconf.html Tie Liao From rem-conf Thu Apr 23 08:07:01 1998 From rem-conf-request@es.net Thu Apr 23 08:07:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySNZg-0003oy-00; Thu, 23 Apr 1998 08:06:08 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0ySNZf-0003mr-00; Thu, 23 Apr 1998 08:06:07 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Apr 1998 16:05:23 +0100 To: Tie.Liao@inria.fr cc: rodgers@nlm.nih.gov, rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) In-reply-to: Your message of "Thu, 23 Apr 1998 16:41:56 +0200." <199804231441.QAA06502@maillol.inria.fr> Date: Thu, 23 Apr 1998 16:05:18 +0100 Message-ID: <18062.893343918@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <199804231441.QAA06502@maillol.inria.fr>, Tie Liao typed: >> o what's the interactivity for the speaker. Generally a speaker >> wants to multicast a page on a simple click in a browser, no >> matter which browser is used. yes, but freedom for receivers to use different tools, choose a subset of media, and join asynchronously and browser material ahead of behind the speaker are all usefulll..... >> o using a netscape plugin would depend on netscape navigator. >> So it cann't be viewer independent. um, its _viewer_ independent - but the plugi n(not the source or viewer) might be browser dependent. >>Some people also tried to mutlicast URLs so that the user's browser >>will fetch corresponding pages. In addition to unnecessary network >>traffic, that can easily cause the server overloaded and thus does not >>scale to large audiences. sure.....except if you have a decent cache hierarchyt (possible with prefetch) then its possibly fine... >>We've implemented a web conference application in webcanal which >>runs on a number of platforms: IRIX, Sun OS, Linux, Win 95/NT, etc. >>This application functions like a proxy server so which browser >>used does not matter. At reception a java applet is run in a >>java-enabled browser for automatic display of received web pages. >>This scheme works pretty well in our experiements (three monthly >>conferences or seminars are using it regularly). Record and >>playback will come soon... >>The feedback we got is that helps a lot to understand a presentation. >>Many people even don't like video stream until better quality can >>be achieved. >>For those interested, look at >> http://webcanal.inria.fr/doc/man/webconf.html yes, webcanal is a good prototype of the right way to go... cheers jon From rem-conf Thu Apr 23 08:12:54 1998 From rem-conf-request@es.net Thu Apr 23 08:12:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySNeb-0004C4-00; Thu, 23 Apr 1998 08:11:13 -0700 Received: from sirocco.cc.mcgill.ca [132.206.27.12] by mail1.es.net with smtp (Exim 1.81 #2) id 0ySNea-0004Bu-00; Thu, 23 Apr 1998 08:11:12 -0700 Received: from staffpop_1.cc.mcgill.ca (staff.McGill.CA [132.206.27.100]) by sirocco.CC.McGill.CA (8.6.12/8.6.6) with ESMTP id LAA23467 for ; Thu, 23 Apr 1998 11:11:10 -0400 X-SMTP-Posting-Origin: staffpop_1.cc.mcgill.ca (staff.McGill.CA [132.206.27.100]) Received: by staff.McGill.CA with Internet Mail Service (5.0.1458.49) id ; Thu, 23 Apr 1998 11:10:36 -0400 Message-ID: From: Yves Lepage To: "'bryan@wpine.com'" , rem-conf@es.net Subject: RE: Declining audiences? (Was: Netshow and the MBONE) Date: Thu, 23 Apr 1998 11:10:34 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, Implementing new functionality for presenting documents would be very nice but some social engineering is also needed. >From the experience I got from the various confs I attended and/or multicasted, most presenters will have simple plastic slides in black and white. The camera is almost always at an angle to the screen and the presenter often points at things on the slide directly on the projected screen placing him/herself directly between the camera and the screen. All of these make slides hard to read. The social engineering part would consist primarily, in convincing these presenters to produce better presentation material and secondarily in convincing those who organize the conferences to provide facilities to use this better quality material. Since such material is harder and takes longer to produce, there has to be some form of benefit to the presenter, besides just allowing MBone viewers to be able to read it. WB was a good step in that direction but it unability to handle anything else than postscript limits its usefulness. I don't pretend to have a solution but I forecast that it will be hard to completely implement any solution. As far as better quality presentation material goes, powerpoint seems to have become the tool of choice for this. Some conferences I attended provide a video projector to display PPT files. For those non-M$ users, maybe developping a file format converter from some-format to powerpoint would be enough. One sure thing, plastic slides, even if very easy and cheap to produce are starting to be an outdated technology and presenters should consider moving on. Regards, Yves Lepage > -----Original Message----- > From: bryan@wpine.com [mailto:bryan@wpine.com] > Sent: Thursday, April 23, 1998 5:41 AM > To: rem-conf@es.net > Subject: Re: Declining audiences? (Was: Netshow and the MBONE) > > > >> 1) Interactive sessions. > >> > >> I have found that overheads are impossible to read, and thus, the > >> video of most presentations is bad. > >> Multicasting a netscape window would be a good idea (all I need is > >> the time), > > From the FWIW dept. :) > > We've implemented something similiar in our ClassPoint > Distance Learning > product. > > The teacher/presenter is able to "walk" the > students/attendees through Web > pages. > > Normally, the presenter outlines the presentation on a Web > page with links > to other pages. ClassPoint makes use of whatever Web Browser > is installed > on the attendee's system to display the current Web page. > > Presenter controls web page flow. Audio/Video/Chat is done through > ClassPoint (with presenter controlling the presentation...who > talks next, > who sees who, who hears who, etc...). > > We've also done hot URL links from within our chat window in > CU-SeeMe...people seem to like this feature.. > > Both the CU-SeeMe and ClassPoint clients require the use of > our Meeting > Point Conference Server in order to support multicasting and/or > multi-client unicast...... > > Bill > > __________________________________________________________ > Bill Ryan (bill@wpine.com) http://www.wpine.com > White Pine Software, Inc. http://www.cuseeme.com > 542 Amherst Street PH: 603-886-9050 x351 Tu/Fri > Nashua, NH 03063 603-529-5070 > Mon/Wed/Thur > __________________________________________________________ > > > From rem-conf Thu Apr 23 08:23:30 1998 From rem-conf-request@es.net Thu Apr 23 08:23:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySNmL-00050I-00; Thu, 23 Apr 1998 08:19:13 -0700 Received: from azure.stl.nps.navy.mil [131.120.64.4] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySNmK-0004zs-00; Thu, 23 Apr 1998 08:19:12 -0700 Received: from nps.navy.mil (thinkpad.stl.nps.navy.mil [131.120.63.206]) by azure.stl.nps.navy.mil (8.7.3/8.7.3) with ESMTP id IAA09020; Thu, 23 Apr 1998 08:18:40 -0700 (PDT) Message-ID: <353F5B12.BF3F84D@nps.navy.mil> Date: Thu, 23 Apr 1998 08:15:30 -0700 From: Don Brutzman Organization: Naval Postgraduate School X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Carsten Bormann CC: rem-conf@es.net, gaertner@Informatik.Uni-Bremen.DE, jo@tzi.org, Ted Lewis Subject: Re: Distributed thesis defense, anyone? References: <199804230936.LAA11992@dienstmann.informatik.uni-bremen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We helped Ted Lewis attend a thesis defense at University of Oregon (i think) about two years ago. To be prudent, we asked for a set of slides in advance and also had a speakerphone arranged as audio backup. I believe the student passed. Carsten Bormann wrote: > > We would like to conduct a thesis defense with one of the reviewers > being 6000 miles away, using RTP/Mbone technology. Now, this is not a > big problem from a technical point of view, but our legal people would > like to have some precedent before saying yes. > > So: > > Does anyone of you know about a thesis defense or some other high-key > legal event where the people who had to be there legally were > distributed and connected using videoconferencing technology? > > BTW, I have heard about the story of the marriage via H.320, and I > would welcome some more details on that. A thesis defense or similar > event (where a reviewer actually has to judge the performance of a > candidate) would be much more convincing, though. > > Gruesse, Carsten all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman From rem-conf Thu Apr 23 08:33:07 1998 From rem-conf-request@es.net Thu Apr 23 08:33:07 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySNxh-00068g-00; Thu, 23 Apr 1998 08:30:57 -0700 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySNxg-00068N-00; Thu, 23 Apr 1998 08:30:56 -0700 Received: from [140.249.10.1] by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA26883 for ; Thu, 23 Apr 1998 11:30:30 -0400 X-Sender: bill@140.249.38.180 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Apr 1998 11:33:23 +0100 To: rem-conf@es.net From: bryan@wpine.com (Bill Ryan) Subject: RE: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Seems these days more and more information is becoming web based. Allows for easy access by all, it's searchable, standards are in place, tools to view are there, tools to create content are mature. Many presenters who present material want it to be available to archive it easily (so that the masses can view it) and thus use html as their format of choice (or use a word processor which generates basic html as well). Some even intially create the presentation this way and then use a video projector (as was mentioned for PowerPoint presentations). I remember basic black and white slides and overheads....I recall one Biochem prof who could turn the mylar roll with one hand while drawing large molecules and text with the other....he didn't provide handouts and thus taking notes was a joy :) I would imagine PowerPoint has a way to convert it's output to html? I think either PowerPoint or html based presentations are a major improvement over black/white hand drawn plastic slides (not to mention they are more "professional looking"). Bill >Hi all, > >Implementing new functionality for presenting documents would be very >nice but some social engineering is also needed. > >From the experience I got from the various confs I attended and/or >multicasted, most presenters will have simple plastic slides in black >and white. The camera is almost always at an angle to the screen and the >presenter often points at things on the slide directly on the projected >screen placing him/herself directly between the camera and the screen. >All of these make slides hard to read. > >The social engineering part would consist primarily, in convincing these >presenters to produce better presentation material and secondarily in >convincing those who organize the conferences to provide facilities to >use this better quality material. > >Since such material is harder and takes longer to produce, there has to >be some form of benefit to the presenter, besides just allowing MBone >viewers to be able to read it. > >WB was a good step in that direction but it unability to handle anything >else than postscript limits its usefulness. I don't pretend to have a >solution but I forecast that it will be hard to completely implement any >solution. As far as better quality presentation material goes, >powerpoint seems to have become the tool of choice for this. Some >conferences I attended provide a video projector to display PPT files. > >For those non-M$ users, maybe developping a file format converter from >some-format to powerpoint would be enough. > >One sure thing, plastic slides, even if very easy and cheap to produce >are starting to be an outdated technology and presenters should consider >moving on. > >Regards, >Yves Lepage __________________________________________________________ Bill Ryan (bill@wpine.com) http://www.wpine.com White Pine Software, Inc. http://www.cuseeme.com 542 Amherst Street PH: 603-886-9050 x351 Tu/Fri Nashua, NH 03063 603-529-5070 Mon/Wed/Thur __________________________________________________________ From rem-conf Thu Apr 23 08:45:27 1998 From rem-conf-request@es.net Thu Apr 23 08:45:27 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySO9h-0006nZ-00; Thu, 23 Apr 1998 08:43:21 -0700 Received: from concorde.inria.fr [192.93.2.39] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySO9g-0006nF-00; Thu, 23 Apr 1998 08:43:20 -0700 Received: from maillol.inria.fr (maillol.inria.fr [128.93.25.14]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id RAA23760; Thu, 23 Apr 1998 17:43:09 +0200 (MET DST) Received: (from liao@localhost) by maillol.inria.fr (8.7.6/8.7.3) id RAA06775; Thu, 23 Apr 1998 17:23:42 +0200 (MET DST) Date: Thu, 23 Apr 1998 17:23:42 +0200 (MET DST) Message-Id: <199804231523.RAA06775@maillol.inria.fr> From: Tie Liao To: bryan@wpine.com CC: rem-conf@es.net In-reply-to: (bryan@wpine.com) Subject: RE: Declining audiences? (Was: Netshow and the MBONE) Reply-to: Tie.Liao@inria.fr X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > I would imagine PowerPoint has a way to convert it's output to html? Yes... as gif images embedded in html files. Tie From rem-conf Thu Apr 23 08:45:27 1998 From rem-conf-request@es.net Thu Apr 23 08:45:27 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySO9F-0006ky-00; Thu, 23 Apr 1998 08:42:53 -0700 Received: from vod.arc.nasa.gov [128.102.32.200] by mail1.es.net with smtp (Exim 1.81 #2) id 0ySO9E-0006j8-00; Thu, 23 Apr 1998 08:42:52 -0700 Received: by vod.arc.nasa.gov (950413.SGI.8.6.12/1.35) id IAA16371; Thu, 23 Apr 1998 08:34:34 -0700 Date: Thu, 23 Apr 1998 08:34:34 -0700 From: dmeyers@vod.arc.nasa.gov (David Meyers) Message-Id: <199804231534.IAA16371@vod.arc.nasa.gov> To: rem-conf@es.net Subject: Tactical Improvements for Multicast X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A number of tactical improvements are needed for accelerating deployment of multicast technology and improving the quality of the services using multicast. As the person who pioneered the Shuttle multicasts here at Ames, I want to share some of the work we and some of our associates are doing to improve multicast quality and availability: 1) Training classes on deployment of multicast routing protocols. 2) Better online documentation on deployment of multicast routing protocols. 3) Multicast route fault detection and isolation tools suitable for use by network operations people. 4) A differentiated service class of service byte for signaling as proposed at the LA IETF. 5) Differentiated services support for class of service management in routers (in the next year ?) 6) Multicast Border Gateway Protocol support from NASA managed exchange points with the cooperation of other networks and ISPs. There is a great amount of work ahead. The journey is just beginning. David Meyers NASA Ames/Sterling Software "The views expressed are solely my own and do not represent the position of NASA" From rem-conf Thu Apr 23 08:45:29 1998 From rem-conf-request@es.net Thu Apr 23 08:45:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySOAQ-0006s4-00; Thu, 23 Apr 1998 08:44:06 -0700 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySOAP-0006rr-00; Thu, 23 Apr 1998 08:44:05 -0700 Received: from [140.249.10.1] by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA27113 for ; Thu, 23 Apr 1998 11:43:40 -0400 X-Sender: bill@140.249.38.180 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Apr 1998 11:46:33 +0100 To: rem-conf@es.net From: bryan@wpine.com (Bill Ryan) Subject: Re: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Tie Liao wrote: >Some people also tried to mutlicast URLs so that the user's browser >will fetch corresponding pages. In addition to unnecessary network >traffic, that can easily cause the server overloaded and thus does not >scale to large audiences. I guess this depends on the web server platform and what you define as a large audience. We've not found that broadcasting the actual URLs as opposed to the page itself to be fine for classroom size groups (30 or less). >We've implemented a web conference application in webcanal which >runs on a number of platforms: IRIX, Sun OS, Linux, Win 95/NT, etc. >This application functions like a proxy server so which browser >used does not matter. At reception a java applet is run in a >java-enabled browser for automatic display of received web pages. I'm not a Web browser/server weenie, but are there any complications when using one browser to attain a web page and then sending this page to a potentially different browser? HTML is standardized, but I've found browsers interpret things differently..... Bill __________________________________________________________ Bill Ryan (bill@wpine.com) http://www.wpine.com White Pine Software, Inc. http://www.cuseeme.com 542 Amherst Street PH: 603-886-9050 x351 Tu/Fri Nashua, NH 03063 603-529-5070 Mon/Wed/Thur __________________________________________________________ From rem-conf Thu Apr 23 09:05:05 1998 From rem-conf-request@es.net Thu Apr 23 09:05:05 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySORE-0000s3-00; Thu, 23 Apr 1998 09:01:28 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySORD-0000rq-00; Thu, 23 Apr 1998 09:01:27 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.7/8.8.7) with SMTP id MAA02200; Thu, 23 Apr 1998 12:01:23 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id LAA18472; Thu, 23 Apr 1998 11:57:29 -0400 Date: Thu, 23 Apr 1998 11:57:29 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199804231557.LAA18472@billings.csb> To: rem-conf@es.net Subject: RE: Declining audiences? (Was: Netshow and the MBONE) Cc: yves@cc.mcgill.ca, bryan@wpine.com X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Yves, Nice points... > From: Yves Lepage > Date: Thu, 23 Apr 1998 11:10:34 -0400 > > Hi all, > > Implementing new functionality for presenting documents would be very > nice but some social engineering is also needed. > > From the experience I got from the various confs I attended and/or > multicasted, most presenters will have simple plastic slides in black > and white. The camera is almost always at an angle to the screen and the > presenter often points at things on the slide directly on the projected > screen placing him/herself directly between the camera and the screen. > All of these make slides hard to read. Add to that that there is generally way too much text to begin with, that (when overheads are used, as is often the case in the scientific and computing communities) the material is often written in a poorly legible handwritten scrawl, that the (generally nervous) presenter is often wiggling the overhead while she/he speaks, and leaves the slide up for too short a time... > The social engineering part would consist primarily, in convincing these > presenters to produce better presentation material and secondarily in > convincing those who organize the conferences to provide facilities to > use this better quality material. > > Since such material is harder and takes longer to produce, there has to > be some form of benefit to the presenter, besides just allowing MBone > viewers to be able to read it. These problems are not new, nor unique, and well-run conferences have had written instructions for presenters telling them how to do it right. Motivating speakers and enforcing these policies has always been the problem. What we are talking about here are aspects of a *good presentation*, and apply as much to attendees in the room as attendees out on the MBONE. > WB was a good step in that direction but it unability to handle anything > else than postscript limits its usefulness. I don't pretend to have a > solution but I forecast that it will be hard to completely implement any > solution. As far as better quality presentation material goes, > powerpoint seems to have become the tool of choice for this. Some > conferences I attended provide a video projector to display PPT files. There are still those of us, go ahead and call us dinosaurs, who will resist to the end the imposition of "de facto" standards based on proprietary products and protocols. In addition, I've found the abuse of visual gimmickry in ppt to be a distraction in many cases, much as "font abuse" was in the early days of readily accessible computer typography. Use of the Web and webcastings seems a much more attractive avenue to me... > One sure thing, plastic slides, even if very easy and cheap to produce > are starting to be an outdated technology and presenters should consider > moving on. Amen to that... Cheerio, Rick Rodgers From rem-conf Thu Apr 23 09:31:47 1998 From rem-conf-request@es.net Thu Apr 23 09:31:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySOqO-0001o5-00; Thu, 23 Apr 1998 09:27:28 -0700 Received: from concorde.inria.fr [192.93.2.39] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySOqN-0001nr-00; Thu, 23 Apr 1998 09:27:27 -0700 Received: from maillol.inria.fr (maillol.inria.fr [128.93.25.14]) by concorde.inria.fr (8.8.7/8.8.5) with ESMTP id SAA25133 for ; Thu, 23 Apr 1998 18:27:21 +0200 (MET DST) Received: (from liao@localhost) by maillol.inria.fr (8.7.6/8.7.3) id SAA07109; Thu, 23 Apr 1998 18:07:54 +0200 (MET DST) Date: Thu, 23 Apr 1998 18:07:54 +0200 (MET DST) Message-Id: <199804231607.SAA07109@maillol.inria.fr> From: Tie Liao To: rem-conf@es.net In-reply-to: (bryan@wpine.com) Subject: Re: Declining audiences? (Was: Netshow and the MBONE) Reply-to: Tie.Liao@inria.fr X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > >Some people also tried to mutlicast URLs so that the user's browser > >will fetch corresponding pages. In addition to unnecessary network > >traffic, that can easily cause the server overloaded and thus does not > >scale to large audiences. > > I guess this depends on the web server platform and what you define as a > large audience. > We've not found that broadcasting the actual URLs as opposed to the page > itself to be fine for classroom size groups (30 or less). What a "large audience" means may depend on network environment. In a campus network, it's fine to send URLs to classroom size groups. But in a national or international scope, it may not be fine. Note that unicast HTTP load contributes a lot to current internet congestion problems, so better organizing HTTP traffic (through multicasting) also makes sense. > >We've implemented a web conference application in webcanal which > >runs on a number of platforms: IRIX, Sun OS, Linux, Win 95/NT, etc. > >This application functions like a proxy server so which browser > >used does not matter. At reception a java applet is run in a > >java-enabled browser for automatic display of received web pages. > > I'm not a Web browser/server weenie, but are there any complications when > using one browser to attain a web page and then sending this page to a > potentially different browser? HTML is standardized, but I've found > browsers interpret things differently..... That's another story, hope the differences will not be significant if cares are taken. From our experience, the slides prepared by speakers (generally using basic features) are displayed correctly on most popular web browsers. That's already a big progress compared with black/white sildes. Tie Liao From rem-conf Thu Apr 23 09:32:41 1998 From rem-conf-request@es.net Thu Apr 23 09:32:41 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySOv2-0001ur-00; Thu, 23 Apr 1998 09:32:16 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySOv1-0001uf-00; Thu, 23 Apr 1998 09:32:15 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.7/8.8.7) with SMTP id MAA03303; Thu, 23 Apr 1998 12:32:11 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id MAA00696; Thu, 23 Apr 1998 12:28:18 -0400 Date: Thu, 23 Apr 1998 12:28:18 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199804231628.MAA00696@billings.csb> To: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) Cc: bryan@wpine.com X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From: bryan@wpine.com (Bill Ryan) > Subject: Re: Declining audiences? (Was: Netshow and the MBONE) > > I guess this depends on the web server platform and what you define as a > large audience. > We've not found that broadcasting the actual URLs as opposed to the page > itself to be fine for classroom size groups (30 or less). Yes, it will generally scale to groups of this size -- but try 100, or 1000 , ... or a 10,000,000. It won't scale to larger groups, and multicast audiences are potentially *huge* > I'm not a Web browser/server weenie, but are there any complications when > using one browser to attain a web page and then sending this page to a > potentially different browser? HTML is standardized, but I've found > browsers interpret things differently..... Open *standards* are a fundamental undepinning of the Web and its rapid success. While one certainly can particularize a document to a specific browser, for example by use of proprietary extensions to HTML, this is bad practice. Not to say it does not happen, but it should be discouaraged, Certainly in the context of conferences, materials should be prepared in advance and validated against a DTD, for example by using the validator that W3C provide (http://validator.w3.org/). If you do this, the minor differences in how documents are painted within a browser are negligible... Cheerio, Rick From rem-conf Thu Apr 23 09:46:42 1998 From rem-conf-request@es.net Thu Apr 23 09:46:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySP64-0002ko-00; Thu, 23 Apr 1998 09:43:40 -0700 Received: from (matilda.wpine.com) [140.249.38.180] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySP63-0002hq-00; Thu, 23 Apr 1998 09:43:40 -0700 Received: from [140.249.10.1] by matilda.wpine.com (Post.Office MTA v3.1 release PO203a ID# 0-34401U600L100S0) with SMTP id AAA28232 for ; Thu, 23 Apr 1998 12:42:24 -0400 X-Sender: bill@140.249.38.180 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Apr 1998 12:45:16 +0100 To: rem-conf@es.net From: bryan@wpine.com (Bill Ryan) Subject: Re: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >> From: bryan@wpine.com (Bill Ryan) >> We've not found that broadcasting the actual URLs as opposed to the page >> itself to be fine for classroom size groups (30 or less). > >R. P. Channing Rodgers, M.D. replied: >Yes, it will generally scale to groups of this size -- but try 100, >or 1000 , ... or a 10,000,000. It won't scale to larger groups, and >multicast audiences are potentially *huge* Very true for large numbers. I've experienced this firsthand after a software company announces a bug fix or update to a product along with the URL of where to obtain it :) Definitely brings a web server to it's knees...not to mention the net traffic burst it produces. Side note: One should be so lucky as to have > 100 people attend their presentation :) Cheers, Bill __________________________________________________________ Bill Ryan (bill@wpine.com) http://www.wpine.com White Pine Software, Inc. http://www.cuseeme.com 542 Amherst Street PH: 603-886-9050 x351 Tu/Fri Nashua, NH 03063 603-529-5070 Mon/Wed/Thur __________________________________________________________ From rem-conf Thu Apr 23 10:16:05 1998 From rem-conf-request@es.net Thu Apr 23 10:16:05 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySPYs-0004Lm-00; Thu, 23 Apr 1998 10:13:26 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySPYr-0004Lc-00; Thu, 23 Apr 1998 10:13:25 -0700 Received: from scv3.apple.com (A17-128-100-121.apple.com [17.128.100.121]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id KAA20014 for ; Thu, 23 Apr 1998 10:05:57 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv3.apple.com (8.8.5/8.8.5) with ESMTP id KAA12680 for ; Thu, 23 Apr 1998 10:05:47 -0700 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <199804231628.MAA00696@billings.csb> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Apr 1998 10:04:06 -0700 To: rem-conf@es.net From: Dave Singer Subject: Re: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 12:28 PM -0400 4/23/98, R. P. Channing Rodgers, M.D. wrote: >> We've [not] found that broadcasting the actual URLs as opposed to the page >> itself to be fine for classroom size groups (30 or less). > >Yes, it will generally scale to groups of this size -- but try 100, >or 1000 , ... or a 10,000,000. It won't scale to larger groups, and >multicast audiences are potentially *huge* > I feel obliged to remark on the incongruity between the subject, which bewails audiences of the size of dozens, and the expressed fear, of audiences of the size of millions. Powerpoint is a little slicker than html for presentations, but those fades/wipes/sliding text etc. can all be frilly distractions. HTML is easily handled by lots of tools and is a well-defined open standard. I believe that the replication of html pages to very large audiences is amenable to solution. If the client-side browsers could be persuaded to pre-load their caches by alerting them with a packet of URLs ahead of time, then medium-sized audiences could be covered. Anyone know any browser that can be told 'I'm going to watch this URL soon, please start trying to cache it now'? Note that multicasting a URL does *not* mean it has to be an HTTP url. It could be some new scheme -- e.g. multicast pages *before time* in the style of SDP, and have a URL format which accesses the local sdp-style cache. Another technique might be to use XTP reliable multicast and have a URL format which pulls 'the next page' off that. I much prefer allowing the URL scheme to handle this, over insisting on sending the HTML directly; using a URL gives a convenient indirection point, and allows different techniques to be used & experimented with, depending on cirumstances. Putting HTML into RTP bulks up the RTP transmission itself, and raises more questions of reliable delivery -- and still leaves the question of URLs embedded in the HTML open (e.g. for images). For small audiences, sending the URLs out and letting the client-side browsers do a fetch, is a solution which is effective, open, and easy. Problems of large audiences are amenable to solution. Let's get a standard in place for transmitting a URL stream over RTP. With a few options, and permitted multiple transmission, this could be a simple boost to utility. Any takers? David Singer Apple Computer/IMG 408-974-3162 From rem-conf Thu Apr 23 10:54:11 1998 From rem-conf-request@es.net Thu Apr 23 10:54:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySQ9D-0005Lp-00; Thu, 23 Apr 1998 10:50:59 -0700 Received: from sirius.ctr.columbia.edu [128.59.64.60] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySQ9C-0005Le-00; Thu, 23 Apr 1998 10:50:58 -0700 Received: from akari.ocs.columbia.edu (akari.ocs.columbia.edu [128.59.240.239]) by sirius.ctr.columbia.edu (8.8.7/8.6.4.287) with SMTP id NAA07985; Thu, 23 Apr 1998 13:50:49 -0400 (EDT) From: "Alexandros Eleftheriadis" To: , Cc: Subject: RE: Declining audiences? (Was: Netshow and the MBONE) Date: Thu, 23 Apr 1998 13:52:05 -0400 Message-ID: <003601bd6ee0$86f86f80$eff03b80@akari.ocs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199804231523.RAA06775@maillol.inria.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From: Tie Liao [mailto:Tie.Liao@inria.fr] > Sent: Thursday, April 23, 1998 11:24 AM > To: bryan@wpine.com > Cc: rem-conf@es.net > Subject: RE: Declining audiences? (Was: Netshow and the MBONE) > > > > I would imagine PowerPoint has a way to convert it's output to html? > > Yes... as gif images embedded in html files. > > Tie Powerpoint 97 also has a nice 'Presentation Conference' feature, that allows you to distribute PP content to one or more recipients and control it in real-time (including mark up etc.). If you are concerned about quality, just use a telephone for voice and have the speaker control the slides both locally and remotely using this feature. From rem-conf Thu Apr 23 10:54:11 1998 From rem-conf-request@es.net Thu Apr 23 10:54:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySQAv-0005MA-00; Thu, 23 Apr 1998 10:52:45 -0700 Received: from beta.mcit.com [199.249.19.143] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySQAu-0005Lt-00; Thu, 23 Apr 1998 10:52:44 -0700 Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49]) by beta.mcit.com (8.8.8/) with ESMTP id MAA12568; Thu, 23 Apr 1998 12:51:08 -0500 (CDT) Received: from omss5.mcit.com.mci.com (omss5.mcit.com [166.37.204.27]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id NAA09837; Thu, 23 Apr 1998 13:51:04 -0400 (EDT) Received: from sinnreich2 ([166.41.36.85]) by omss5.mcit.com.mci.com (Intermail v3.1 117 241) with SMTP id <19980423175103.ENKY22404@[166.41.36.85]>; Thu, 23 Apr 1998 12:51:03 -0500 From: "Henry Sinnreich" To: "R. P. Channing Rodgers, M.D." , Cc: , Subject: RE: Declining audiences? (Was: Netshow and the MBONE) Date: Thu, 23 Apr 1998 12:50:04 +0200 Message-ID: <000d01bd6ea5$92a6b520$552429a6@sinnreich2.678.mciw> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199804231557.LAA18472@billings.csb> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3007.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > There are still those of us, go ahead and call us dinosaurs, who will > resist to the end the imposition of "de facto" standards based on > proprietary products and protocols. As the risk of being flamed from several sides; it would be just the best of both worlds, if we could somehow have NetMeeting or its scalable (to Mbone audience size) equivalents on various platforms running on standard IETF protocols. Most of the application issues raised here would then become a non-issue. It is also fair for the application developer to get paid for the product, though in an affordable manner ;-) Henry > -----Original Message----- > From: R. P. Channing Rodgers, M.D. [mailto:rodgers@nlm.nih.gov] > Sent: Thursday, April 23, 1998 5:57 PM > To: rem-conf@es.net > Cc: yves@cc.mcgill.ca; bryan@wpine.com > Subject: RE: Declining audiences? (Was: Netshow and the MBONE) > > > Yves, > > Nice points... > > > From: Yves Lepage > > Date: Thu, 23 Apr 1998 11:10:34 -0400 > > > > Hi all, > > > > Implementing new functionality for presenting documents would be very > > nice but some social engineering is also needed. > > > > From the experience I got from the various confs I attended and/or > > multicasted, most presenters will have simple plastic slides in black > > and white. The camera is almost always at an angle to the screen and the > > presenter often points at things on the slide directly on the projected > > screen placing him/herself directly between the camera and the screen. > > All of these make slides hard to read. > > Add to that that there is generally way too much text to begin with, > that (when overheads are used, as is often the case in the scientific > and computing communities) the material is often written in a poorly > legible handwritten scrawl, that the (generally nervous) presenter > is often wiggling the overhead while she/he speaks, and leaves the > slide up for too short a time... > > > The social engineering part would consist primarily, in convincing these > > presenters to produce better presentation material and secondarily in > > convincing those who organize the conferences to provide facilities to > > use this better quality material. > > > > Since such material is harder and takes longer to produce, there has to > > be some form of benefit to the presenter, besides just allowing MBone > > viewers to be able to read it. > > These problems are not new, nor unique, and well-run conferences have > had written instructions for presenters telling them how to do it > right. Motivating speakers and enforcing these policies has always > been the problem. What we are talking about here are aspects of a > *good presentation*, and apply as much to attendees in the room as > attendees out on the MBONE. > > > WB was a good step in that direction but it unability to handle anything > > else than postscript limits its usefulness. I don't pretend to have a > > solution but I forecast that it will be hard to completely implement any > > solution. As far as better quality presentation material goes, > > powerpoint seems to have become the tool of choice for this. Some > > conferences I attended provide a video projector to display PPT files. > > There are still those of us, go ahead and call us dinosaurs, who will > resist to the end the imposition of "de facto" standards based on > proprietary products and protocols. In addition, I've found the abuse > of visual gimmickry in ppt to be a distraction in many cases, > much as "font abuse" was in the early days of readily accessible > computer typography. Use of the Web and webcastings seems a much > more attractive avenue to me... > > > One sure thing, plastic slides, even if very easy and cheap to produce > > are starting to be an outdated technology and presenters should consider > > moving on. > > Amen to that... > > Cheerio, Rick Rodgers > From rem-conf Thu Apr 23 11:05:40 1998 From rem-conf-request@es.net Thu Apr 23 11:05:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySQLK-00063D-00; Thu, 23 Apr 1998 11:03:30 -0700 Received: from alpha.mcit.com [199.249.18.143] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySQLB-0005yV-00; Thu, 23 Apr 1998 11:03:21 -0700 Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49]) by alpha.mcit.com (8.8.8/) with ESMTP id OAA04090; Thu, 23 Apr 1998 14:01:19 -0400 (EDT) Received: from omss5.mcit.com.mci.com (omss5.mcit.com [166.37.204.27]) by omzrelay.mcit.com (8.8.7/) with ESMTP id NAA12227; Thu, 23 Apr 1998 13:01:18 -0500 (CDT) Received: from sinnreich2 ([166.41.36.85]) by omss5.mcit.com.mci.com (Intermail v3.1 117 241) with SMTP id <19980423180117.EOVE22404@[166.41.36.85]>; Thu, 23 Apr 1998 13:01:17 -0500 From: "Henry Sinnreich" To: "R. P. Channing Rodgers, M.D." , Cc: , Subject: RE: Declining audiences? (Was: Netshow and the MBONE) Date: Thu, 23 Apr 1998 13:00:19 +0200 Message-ID: <001101bd6ea7$013842a0$552429a6@sinnreich2.678.mciw> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <199804231557.LAA18472@billings.csb> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3007.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > There are still those of us, go ahead and call us dinosaurs, who will > resist to the end the imposition of "de facto" standards based on > proprietary products and protocols. As the risk of being flamed from several sides; it would be just the best of both worlds, if we could somehow have NetMeeting or its scalable (to Mbone audience size) equivalents on various platforms running on standard IETF protocols. Most of the application issues raised here would then become a non-issue. It is also fair for the application developer to get paid for the product, though in an affordable manner ;-) Henry From rem-conf Thu Apr 23 12:26:36 1998 From rem-conf-request@es.net Thu Apr 23 12:26:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySRWq-0000Ok-00; Thu, 23 Apr 1998 12:19:28 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySRWo-0000Oa-00; Thu, 23 Apr 1998 12:19:27 -0700 Received: from jackson.cs.ucsb.edu (almeroth@jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with SMTP id MAA29871 for ; Thu, 23 Apr 1998 12:19:21 -0700 (PDT) Received: by jackson.cs.ucsb.edu (SMI-8.6/SMI-SVR4) id MAA18653 for rem-conf@es.net; Thu, 23 Apr 1998 12:18:53 -0700 Date: Thu, 23 Apr 1998 12:18:53 -0700 From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199804231918.MAA18653@jackson.cs.ucsb.edu> To: rem-conf@es.net Subject: RE: Declining audiences? (Was: Netshow and the MBONE) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've been out of town at the WWW7 conference so I haven't had much of a chance to read everything but let me write a few comments: 1. I've done a fair amount of analysis of MBone growth and I've talked to a lot of people about the availability of RTCP. My opinion is that the MBone is indeed growing rapidly but the number of global conferences with RTCP-responding receivers is declining. The power of multicast is really being realized in Intranets. I presented some results at the Washington DC IETF and am hoping that I can put together some thoughts in a paper this summer. We continue to see new IP addresses sending RTCP to global sessions but many don't stick around... why? First, best, easiest guess is quality. 2. Three reasons why the MBone is not growing more: quality, utility and usability. Losses are just too high especially if you go through an exchange point or trans-oceanic link. Trying to get an MBone connection up and stable is a royal pain. For example, trying to get REAL support for multicast in the UC System has proven difficult. I don't think I'm stepping on any toes here because it just isn't a "supported service". As of right now, our connection is down. Applications have just not been innovative enough. Where are the new-and-improved conferencing tools? Why isn't there real-time indexing, real-time stream storage for playback, etc.? PicPat is a start and so is the MBone VCR and wrtp and rtpplay/rtpdump and ... but these are not supported at the level of Precept/Microsoft/Real Network/etc. vic/vat/wb/sdr were the de facto standard but look how much time is spent in upgrading and maintaining the tools (especially compared to companies that sell these tools for-profit). Does anyone really think the MBone is going to grow along these lines? 3. I may be a bit biased here but the IETF probably has the best act going in terms of delivering quality presentations. One of the key limitations though is that presentations tend to be more informal and slides for a 1pm talk are sometimes hand written at lunch. That limits the ability of the MBone staff to use wb for slides. The key is likely that there is some consistency in having the same people in charge plus there is always a near-unlimited supply of expertise available when problems do occur. But, bottom line... it still does not seem to be enough. People just aren't watching as much as they once where. -Kevin Almeroth From rem-conf Thu Apr 23 12:27:30 1998 From rem-conf-request@es.net Thu Apr 23 12:27:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySRd4-0000e0-00; Thu, 23 Apr 1998 12:25:54 -0700 Received: from lhc.nlm.nih.gov [130.14.35.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySRd2-0000dq-00; Thu, 23 Apr 1998 12:25:52 -0700 Received: from billings.csb (billings [130.14.35.141]) by lhc.nlm.nih.gov (8.8.7/8.8.7) with SMTP id PAA10175; Thu, 23 Apr 1998 15:25:49 -0400 (EDT) Received: by billings.csb (SMI-8.6/SMI-SVR4) id PAA01427; Thu, 23 Apr 1998 15:21:56 -0400 Date: Thu, 23 Apr 1998 15:21:56 -0400 From: rodgers@nlm.nih.gov (R. P. Channing Rodgers, M.D.) Message-Id: <199804231921.PAA01427@billings.csb> To: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) Cc: singer@apple.com X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > To: rem-conf@es.net > From: Dave Singer > Subject: Re: Declining audiences? (Was: Netshow and the MBONE) > > At 12:28 PM -0400 4/23/98, R. P. Channing Rodgers, M.D. wrote: > >> We've [not] found that broadcasting the actual URLs as opposed to the page > >> itself to be fine for classroom size groups (30 or less). > > > >Yes, it will generally scale to groups of this size -- but try 100, > >or 1000 , ... or a 10,000,000. It won't scale to larger groups, and > >multicast audiences are potentially *huge* > > > > I feel obliged to remark on the incongruity between the subject, which > bewails audiences of the size of dozens, and the expressed fear, of > audiences of the size of millions. No fear there, just a comment on potential... 8^) From rem-conf Thu Apr 23 12:35:50 1998 From rem-conf-request@es.net Thu Apr 23 12:35:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySRl5-0001BO-00; Thu, 23 Apr 1998 12:34:11 -0700 Received: from cepheid.physics.gla.ac.uk [130.209.45.251] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySRl4-0001B0-00; Thu, 23 Apr 1998 12:34:10 -0700 Received: from a5.ph.gla.ac.uk (a5.ph.gla.ac.uk [194.36.1.167]) by cepheid.physics.gla.ac.uk (8.8.5/8.8.5) with ESMTP id UAA06466; Thu, 23 Apr 1998 20:28:10 +0100 (BST) Received: from localhost (flavell@localhost) by a5.ph.gla.ac.uk (8.8.8/8.8.8) with SMTP id UAA31886; Thu, 23 Apr 1998 20:34:02 +0100 (BST) Date: Thu, 23 Apr 1998 20:34:02 +0100 (BST) From: "Alan J. Flavell" Reply-To: A.Flavell@physics.gla.ac.uk To: "R. P. Channing Rodgers, M.D." cc: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) In-Reply-To: <199804231628.MAA00696@billings.csb> Message-ID: X-antiSpam: Do not send me unsolicited commercial email MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Thu, 23 Apr 1998, R. P. Channing Rodgers, M.D. wrote: > Open *standards* are a fundamental undepinning of the Web and its rapid > success. While one certainly can particularize a document to a specific > browser, for example by use of proprietary extensions to HTML, this > is bad practice. Well said. > Certainly in the context of conferences, materials > should be prepared in advance and validated against a DTD, for example > by using the validator that W3C provide (http://validator.w3.org/). > If you do this, the minor differences in how documents are painted > within a browser are negligible... Excuse me if this gets too far off topic, but I feel I have to speak up here. HTML is designed to mark up the logical content of text (and of course to link to other media). Each brower is supposed to do the best it can, in each particular viewing situation, to render that logical content. There may indeed be MAJOR differences in the appearance of the material between one browser/situation and another (indeed, it might even be fed to a Brailler, to a speaking engine). The point is that they are all valid renderings of the original HTML. And if the reader is sight-impaired then these major differences are the true glory of HTML, as compared to a format that would successfully impose a specific rendering, in format and size. Best regards. From rem-conf Thu Apr 23 17:01:41 1998 From rem-conf-request@es.net Thu Apr 23 17:01:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySVrk-0004U7-00; Thu, 23 Apr 1998 16:57:20 -0700 Received: from oldredshift.com (165.227.94.16) [165.227.94.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySVri-0004Tx-00; Thu, 23 Apr 1998 16:57:18 -0700 Received: from [207.204.198.163] (pm4-163.sal.redshift.com [207.204.198.163]) by 165.227.94.16 (8.8.8/8.8.8) with ESMTP id QAA05701; Thu, 23 Apr 1998 16:57:00 -0700 X-Sender: learning@friction-free-economy.com Message-Id: In-Reply-To: <353F5B12.BF3F84D@nps.navy.mil> References: <199804230936.LAA11992@dienstmann.informatik.uni-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Apr 1998 17:04:27 -0700 To: Don Brutzman , Carsten Bormann From: Ted Lewis Subject: Re: Distributed thesis defense, anyone? Cc: rem-conf@es.net, gaertner@Informatik.Uni-Bremen.DE, jo@tzi.org X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Don, I think it was over 3 yrs ago, wasn't it? Like 1994? And, yes the student passed. --ted Ted Lewis, Ph.D. Technology Assessment Group 13260 Corte Lindo Salinas, CA. 93908 (408)-484-1240 v, -0730 fax (408)-596-0620 cellular www.friction-free-economy.com (Articles and book preface) tedglewis@friction-free-economy.com (Most-likely place to find me) From rem-conf Thu Apr 23 17:51:58 1998 From rem-conf-request@es.net Thu Apr 23 17:51:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySWgO-0005L1-00; Thu, 23 Apr 1998 17:49:40 -0700 Received: from alpha.xerox.com [13.1.64.93] (firewall-user) by mail1.es.net with smtp (Exim 1.81 #2) id 0ySWgN-0005Kr-00; Thu, 23 Apr 1998 17:49:39 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <53934(5)>; Thu, 23 Apr 1998 16:06:28 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177520>; Thu, 23 Apr 1998 15:53:30 -0700 To: dmeyers@vod.arc.nasa.gov (David Meyers) cc: rem-conf@es.net Subject: Re: Tactical Improvements for Multicast In-reply-to: Your message of "Thu, 23 Apr 98 08:34:34 PDT." <199804231534.IAA16371@vod.arc.nasa.gov> Date: Thu, 23 Apr 1998 15:53:20 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <98Apr23.155330pdt.177520@crevenia.parc.xerox.com> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list dmeyers@vod.arc.nasa.gov (David Meyers) wrote: >3) Multicast route fault detection and isolation tools suitable > for use by network operations people. Tools which require learning don't get used. mtrace has been available for 3 years now, and does an incredible job of fault detection and isolation, if you know how to use it. There are probably a handful of people who have learned how to use it. We need tools which present an analysis (like "There's 20% loss between router A and router B"), not just measurement tools like mtrace. This is one of the things we're working on. Bill From rem-conf Fri Apr 24 01:34:02 1998 From rem-conf-request@es.net Fri Apr 24 01:33:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySdq8-0000CV-00; Fri, 24 Apr 1998 01:28:12 -0700 Received: from weeble.lut.ac.uk [158.125.96.47] (exim) by mail1.es.net with smtp (Exim 1.81 #2) id 0ySdq6-0000CJ-00; Fri, 24 Apr 1998 01:28:10 -0700 Received: from jon by weeble.lut.ac.uk with smtp (Exim 1.81 #1) id 0ySdps-0000cC-00; Fri, 24 Apr 1998 09:27:56 +0100 Date: Fri, 24 Apr 1998 09:27:56 +0100 (BST) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Dave Singer cc: rem-conf@es.net Subject: Re: Declining audiences? (Was: Netshow and the MBONE) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Thu, 23 Apr 1998, Dave Singer wrote: > If the client-side browsers could be persuaded to pre-load their caches by > alerting them with a packet of URLs ahead of time, then medium-sized > audiences could be covered. Anyone know any browser that can be told 'I'm > going to watch this URL soon, please start trying to cache it now'? Any browser sitting behind a proxy cache where you've told the proxy cache to preload (pre-cache) the required resources. We've done that here from time to time but the problems are: a) getting the lecturing staff/conference organiser/whoever is running the session to either pull the stuff through the cache before hand, b) resources that come from cache busting sites (some big corporate players in the Internet field are guilty of this - what they don't realise is that cache busting can make their documents unusable for people on the other site of the planet from them. More fools them). Now if the proxy caches were listening to a multicast group that said which URLs are likely to be wanted in the near future (maybe along with some session information so that you know if anyone at your site has prejoined the conference) you'd be on to a winner. The local site caches should already be ready to handle peaks from their local communities so there shouldn't be too much of a problem with a few tens of people at each site pulling the resources from the caches at the same time. Tatty bye, Jim'll #!/usr/bin/perl -- -Whois++-client-in-6-lines-of-Perl -Beat-that-Z39.50! use IO::Socket;sub w{$f=shift;$a{$f}=1;($h,$p,$q)=split("/",$f);$s= IO::Socket::INET->new(PeerAddr=>"$h:$p")||return;print $s "$q\r\n";while(<$s>) {next if(/^%/);if(/^# SERVER-TO-ASK/){while(<$s>){$x=$1 if/Name: (.*)\r\n$/;$y =$1 if/Port: (.*)\r\n$/;$f="$x/$y/$q";@j=(@j,$f)if(/^# END/&&!$a{$f});}}else{ print;}}close($s);}@j=shift;while(@j){w(pop(@j));}# whois++.pl host/port/query From rem-conf Fri Apr 24 08:41:46 1998 From rem-conf-request@es.net Fri Apr 24 08:41:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySkQH-0002ei-00; Fri, 24 Apr 1998 08:29:57 -0700 Received: from p-voyageur.issy.cnet.fr [139.100.0.39] by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySkQG-0002eW-00; Fri, 24 Apr 1998 08:29:56 -0700 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.0.1460.8) id <2QPVTZCJ>; Fri, 24 Apr 1998 17:31:18 +0200 Message-ID: <425A62747E7CD111B4570060974B1C6344F7FC@r-mhs.ccett.fr> From: GOULEAU Emmanuel CNET/DSM/REN To: rem-conf@es.net Subject: Payload format for "MPEG1 System" Date: Fri, 24 Apr 1998 17:35:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear AVT participants, I would like to know if a Payload Format has been defined for "MPEG1 System". Thank you in advance for your response. Regards, Emmanuel GOULEAU ********************************************************************** /_/_/_/_/ Emmanuel GOULEAU /_/_/_/_/ France Telecom CNET /_/_/_/_/ "Broadcast and On-Line Services Networks" Tel : +33 2 99 12 43 94 - Fax : +33 2 99 12 40 98 mailto:emmanuel.gouleau@cnet.francetelecom.fr ********************************************************************** From rem-conf Fri Apr 24 10:37:55 1998 From rem-conf-request@es.net Fri Apr 24 10:37:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0ySmLl-0004Yx-00; Fri, 24 Apr 1998 10:33:25 -0700 Received: from hofmann.cs.berkeley.edu [128.32.35.123] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0ySmLk-0004Yn-00; Fri, 24 Apr 1998 10:33:24 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by hofmann.CS.Berkeley.EDU (8.9.0.Beta5/8.6.6.Beta11) with SMTP id KAA22321; Fri, 24 Apr 1998 10:33:19 -0700 (PDT) Message-Id: <3.0.3.32.19980424103318.00c36a20@postgres.berkeley.edu> X-Sender: ireney@postgres.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 24 Apr 1998 10:33:18 -0700 To: rem-conf@es.net, 298-list@bmrc.berkeley.edu From: Irene Yam Subject: Reminder: UCB MIG Seminar 4/29/98 " Promoting the Use of End-to-End Congestion Control in the Internet* " Kevin Fall, Network Research Group, Lawrence Berkeley Laboratories Cc: ireney@cs.Berkeley.EDU Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Promoting the Use of End-to-End Congestion Control in the Internet* (Wednesday April 29, 1998 12:30-2:00 PDT 405 Soda Hall) Kevin Fall Network Research Group Lawrence Berkeley Laboratories The Internet operates in a stable fashion due in large part to end systems obeying the congestion control algorithms of TCP. Although most of today's wide-area best-effort traffic is TCP-based, concern about future stability is raised by a possible increase in the use of UDP-based applications, which generally do not take steps to avoid congestion. In this talk, we describe the problems of congestion collapse and unfairness caused by unrestricted high-bandwidth flows. Further, we outline a number of tests and regulation strategies used by routers to detect and penalize ill-behaved flows. We argue that by penalizing such flows, an incentive is created to deploy congestion control techniques in all best-effort applications. * Joint work with Sally Floyd -------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40PST (GMT - 8 hrs). See sd or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. ____________________________________________ Irene Yam Berkeley Multimedia Research Center (BMRC) 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: ireney@bmrc.berkeley.edu Url: http://bmrc.berkeley.edu/people/irene/ From rem-conf Mon Apr 27 10:49:00 1998 From rem-conf-request@es.net Mon Apr 27 10:48:59 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yTrlC-0006kR-00; Mon, 27 Apr 1998 10:32:10 -0700 Received: from zephyr.isi.edu [128.9.160.160] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yTrlB-0006kH-00; Mon, 27 Apr 1998 10:32:09 -0700 Received: from roo.isi.edu (roo.isi.edu [128.9.160.127]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id KAA04788; Mon, 27 Apr 1998 10:32:04 -0700 (PDT) Posted-Date: Mon, 27 Apr 1998 10:30:16 -0700 (PDT) Received: from localhost by roo.isi.edu (5.65c/4.0.3-6) id ; Mon, 27 Apr 1998 10:30:16 -0700 Date: Mon, 27 Apr 1998 10:30:16 -0700 (PDT) From: Steven Berson To: Cadia Chan Cc: rsvp-test@ISI.EDU, rem-conf@es.net Subject: Re: How to use device "still" in vic? In-Reply-To: <199804271545.PAA08092@bacchus.mos.ics.keio.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Mon, 27 Apr 1998, Cadia Chan wrote: > I'm running vic-2.8 with rsvp support. I noticed that device "still" can work without any grabber hardware, but when I start to use it to transfer jpeg picture, the display in the window is not correct. and the receiver can't receive this image. > Can anyone who had used still device before tell me how to use it correctly! > Thanks! > > Chen > > ----------------------------------------------------- > Xiaojian Chen | TEL: +81 45 563-1141 ext.3568 > Keio University | FAX: +81 45-563-0322 > Visiting Scholar | Email: xjchen@mos.ics.keio.ac.jp I am not sure exactly what you are doing, but it sounds like a vic issue, rather than an rsvp issue, so I am forwarding it to the rem-conf list. Cheers, Steve From rem-conf Mon Apr 27 15:56:39 1998 From rem-conf-request@es.net Mon Apr 27 15:56:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yTwi0-0002N7-00; Mon, 27 Apr 1998 15:49:12 -0700 Received: from gateway-gw.pictel.com [140.242.1.1] by mail1.es.net with smtp (Exim 1.81 #2) id 0yTwhz-0002Mo-00; Mon, 27 Apr 1998 15:49:11 -0700 Received: from pictel.com (roadrunner.pictel.com) by gateway-gw.pictel.com (4.1/cf.gw.970707.rdw) id AA05702; Mon, 27 Apr 98 18:47:30 EDT Received: from by pictel.com (4.1/SMI-4.1) id AB06862; Mon, 27 Apr 98 18:47:28 EDT Message-Id: <9804272247.AB06862@pictel.com> X-Sender: webber@cactus.pictel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 27 Apr 1998 18:36:53 -0700 To: Carsten Bormann , rem-conf@es.net From: Robert Webber Subject: Re: Distributed thesis defense, anyone? Cc: jo@tzi.org In-Reply-To: <199804230936.LAA11992@dienstmann.informatik.uni-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list IIRC, the initial arraignment hearing for Ted Kozynski (sp? the man known as "the Unabomber") was held with the prisoner someplace in the West (Colorado?) and the judge in New Jersey. This was done using an H.320 call. Details might be obtained from a US newspaper's archives. Bob At 11:36 AM 4/23/98 +0200, Carsten Bormann wrote: >We would like to conduct a thesis defense with one of the reviewers >being 6000 miles away, using RTP/Mbone technology. Now, this is not a >big problem from a technical point of view, but our legal people would >like to have some precedent before saying yes. > >So: > >Does anyone of you know about a thesis defense or some other high-key >legal event where the people who had to be there legally were >distributed and connected using videoconferencing technology? > >BTW, I have heard about the story of the marriage via H.320, and I >would welcome some more details on that. A thesis defense or similar >event (where a reviewer actually has to judge the performance of a >candidate) would be much more convincing, though. > >Gruesse, Carsten > From rem-conf Tue Apr 28 04:32:20 1998 From rem-conf-request@es.net Tue Apr 28 04:32:19 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yU8XM-0006Dk-00; Tue, 28 Apr 1998 04:27:00 -0700 Received: from nis-tradewind.paisley.ac.uk (wpmail.paisley.ac.uk) [146.191.32.5] by mail1.es.net with smtp (Exim 1.81 #2) id 0yU8XK-0006DS-00; Tue, 28 Apr 1998 04:26:59 -0700 Received: from Gate-Message_Server by wpmail.paisley.ac.uk with Novell_GroupWise; Tue, 28 Apr 1998 11:57:23 +0000 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 28 Apr 1998 11:56:37 +0000 From: Delia Atherton To: rem-conf@es.net Subject: Europia'98 - Reminder Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list All, Final call for papers. Papers due by 12 June 1998. Thanks to those who used our online Registration of Interest. Please use it if you are participating: http://www-cis.paisley.ac.uk/Europia98 Delia From rem-conf Tue Apr 28 09:49:02 1998 From rem-conf-request@es.net Tue Apr 28 09:49:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yUDUM-00016w-00; Tue, 28 Apr 1998 09:44:14 -0700 Received: from sonne.darmstadt.gmd.de [141.12.62.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yUDUL-000169-00; Tue, 28 Apr 1998 09:44:13 -0700 Received: from darmstadt.gmd.de (pc-taler [141.12.60.25]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id SAA06842; Tue, 28 Apr 1998 18:41:53 +0200 (MET DST) Message-ID: <354606AD.3DBB7A90@darmstadt.gmd.de> Date: Tue, 28 Apr 1998 18:41:30 +0200 From: Peter Hoermann X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: MBONE@isi.edu, rem-conf@es.net, video@clci.com Subject: RTP over ATM ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, is anybody out there working on 'RTP over ATM' (NOT: 'RTP over UDP over ATM'), i.e. directly packing the AV data in ATM cells ? I came across this because RTP/RTCP is not linked to a certain protocol stack and I'm working on Audio/Video over ATM, trying to avoid the overhead of e.g. the TCP/IP stack. Many thanx in advance Peter From rem-conf Tue Apr 28 10:16:39 1998 From rem-conf-request@es.net Tue Apr 28 10:16:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yUDxT-00023X-00; Tue, 28 Apr 1998 10:14:19 -0700 Received: from liberator.cit.cornell.edu [132.236.200.24] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yUDxR-00023L-00; Tue, 28 Apr 1998 10:14:18 -0700 Received: from liberator.cit.cornell.edu (LOCALHOST [127.0.0.1]) by liberator.cit.cornell.edu (8.8.8/8.8.8) with ESMTP id NAA12823; Tue, 28 Apr 1998 13:13:59 -0400 (EDT) (envelope-from shore@liberator.cit.cornell.edu) Message-Id: <199804281713.NAA12823@liberator.cit.cornell.edu> To: Peter Hoermann cc: MBONE@isi.edu, rem-conf@es.net, video@clci.com Subject: Re: RTP over ATM ? In-reply-to: Your message of "Tue, 28 Apr 1998 18:41:30 +0200." <354606AD.3DBB7A90@darmstadt.gmd.de> Date: Tue, 28 Apr 1998 13:13:59 -0400 From: Melinda Shore X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > is anybody out there working on 'RTP over ATM' (NOT: 'RTP over UDP over > ATM'), i.e. directly packing the AV data in ATM cells ? I came across > this because RTP/RTCP is not linked to a certain protocol stack and I'm > working on Audio/Video over ATM, trying to avoid the overhead of e.g. > the TCP/IP stack. H.323 Annex C describes a mechanism for carrying RTP in AAL5 frames, but it's got some problems with header overhead, even without IP. Francois Audet at Nortel has done some analysis and made some packetization recommendations to much improve the situation, but not really fix it. K.K. Ramakrishnan sent several contributions to the ATM Forum RMOA WG describing a mechanism for sending compressed RTP over AAL5, using the U-U byte for indicating header info. It's rather nice. Melinda Shore Only briefly at Cornell University shore@nr-atp.cit.cornell.edu From rem-conf Tue Apr 28 11:35:32 1998 From rem-conf-request@es.net Tue Apr 28 11:35:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yUF6g-0003D9-00; Tue, 28 Apr 1998 11:27:54 -0700 Received: from dienstmann-atm.informatik.uni-bremen.de (dienstmann.informatik.uni-bremen.de) [134.102.213.88] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yUF6f-0003Cz-00; Tue, 28 Apr 1998 11:27:53 -0700 Received: by dienstmann.informatik.uni-bremen.de (8.7.3/30.7.96cl) id UAA05374 Tue, 28 Apr 1998 20:24:28 +0200 (MET DST) Date: Tue, 28 Apr 1998 20:24:28 +0200 (MET DST) Message-Id: <199804281824.UAA05374@dienstmann.informatik.uni-bremen.de> From: Carsten Bormann To: Peter Hoermann Cc: MBONE@ISI.EDU, rem-conf@es.net, video@clci.com Subject: Re: RTP over ATM ? In-Reply-To: <354606AD.3DBB7A90@darmstadt.gmd.de> References: <354606AD.3DBB7A90@darmstadt.gmd.de> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Peter Hoermann writes: > is anybody out there working on 'RTP over ATM' (NOT: 'RTP over UDP over > ATM'), i.e. directly packing the AV data in ATM cells ? I came across > this because RTP/RTCP is not linked to a certain protocol stack and I'm > working on Audio/Video over ATM, trying to avoid the overhead of e.g. > the TCP/IP stack. There is no TCP in RTP, so there is no TCP overhead to avoid. Avoiding the header overhead of IP, UDP, and RTP is best done using IP header compression and compressed RTP. Avoiding the (now really significant) overhead of AAL5 is best done using AAL2 (the new one). The remaining work is defining a mapping of IP/IP header compression/CRTP on AAL2 VCs. There have been some hallway discussions about this at the Spring IETF. Let's do it (says he who didn't even finish the existing homework from that IETF). Any people from industry who would be interested? Direct RTP over ATM (AAL5) sounds like a remnant of very, very old thinking. Gruesse, Carsten From rem-conf Tue Apr 28 12:15:15 1998 From rem-conf-request@es.net Tue Apr 28 12:15:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yUFob-0004El-00; Tue, 28 Apr 1998 12:13:17 -0700 Received: from liberator.cit.cornell.edu [132.236.200.24] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yUFoa-0004Ea-00; Tue, 28 Apr 1998 12:13:16 -0700 Received: from liberator.cit.cornell.edu (LOCALHOST [127.0.0.1]) by liberator.cit.cornell.edu (8.8.8/8.8.8) with ESMTP id PAA15027; Tue, 28 Apr 1998 15:13:00 -0400 (EDT) (envelope-from shore@liberator.cit.cornell.edu) Message-Id: <199804281913.PAA15027@liberator.cit.cornell.edu> To: Carsten Bormann cc: Peter Hoermann , MBONE@ISI.EDU, rem-conf@es.net Subject: Re: RTP over ATM ? In-reply-to: Your message of "Tue, 28 Apr 1998 20:24:28 +0200." <199804281824.UAA05374@dienstmann.informatik.uni-bremen.de> Date: Tue, 28 Apr 1998 15:13:00 -0400 From: Melinda Shore X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > There is no TCP in RTP, so there is no TCP overhead to avoid. > Avoiding the header overhead of IP, UDP, and RTP is best done using IP > header compression and compressed RTP. > Avoiding the (now really significant) overhead of AAL5 is best done > using AAL2 (the new one). That really depends, and it's highly situational. It's certainly possible to argue that if you're using, say, a 5ms packet encoded using G.711, you've no overhead since you'd have 8 unused bytes in the cell payload, anyway. A more immediate concern is that AAL2 is being perceived as most suitable for trunking, and I expect that it will be quite some time before we see AAL2 support in NIC SARs. Melinda Shore Temporarily at Cornell University shore@nr-atp.cit.cornell.edu From rem-conf Tue Apr 28 18:23:01 1998 From rem-conf-request@es.net Tue Apr 28 18:22:59 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yULVn-0006sT-00; Tue, 28 Apr 1998 18:18:15 -0700 Received: from acacia.ucop.edu [128.48.100.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yULVl-0006sJ-00; Tue, 28 Apr 1998 18:18:13 -0700 Received: from localhost (delaroca@localhost) by acacia.ucop.edu (8.8.8/8.8.8) with SMTP id SAA07125; Tue, 28 Apr 1998 18:17:42 -0700 (PDT) Date: Tue, 28 Apr 1998 18:17:42 -0700 (PDT) From: Denis DeLaRoca To: Yiorgos Adamopoulos cc: mbone@ISI.EDU, rem-conf@es.net Subject: Re: Is www.mbone.net down ? In-Reply-To: <199804250905.MAA20457@dblab.ece.ntua.gr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Sat, 25 Apr 1998, Yiorgos Adamopoulos wrote: > > I keep getting ``connection refused'' from any *.gr site that I have tried Same with www.mbone.com. The DNS entries are gone so I presume that site is history... can anyone clarify that is the case and wether someone else will maintain the mbone archives and resource directory that used to reside at www.mbone.com? -- Denis From rem-conf Wed Apr 29 02:57:15 1998 From rem-conf-request@es.net Wed Apr 29 02:57:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yUTXF-0001gB-00; Wed, 29 Apr 1998 02:52:17 -0700 Received: from relay9.uu.net [192.48.96.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yUTXD-0001g0-00; Wed, 29 Apr 1998 02:52:16 -0700 Received: from neserve0.uu.net by relay9.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQenel13774; Wed, 29 Apr 1998 05:52:13 -0400 (EDT) Received: by neserve0.uu.net id QQenel05399; Wed, 29 Apr 1998 05:52:02 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: Is www.mbone.net down ? To: delaroca@acacia.ucop.edu (Denis DeLaRoca) Date: Wed, 29 Apr 1998 05:52:01 -0400 (EDT) Cc: adamo@dblab.ece.ntua.gr, mbone@ISI.EDU, rem-conf@es.net In-Reply-To: from "Denis DeLaRoca" at Apr 28, 98 06:17:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list www.mbone.com didn't pay their domain thingie to the internic. _J Denis DeLaRoca said: > > > On Sat, 25 Apr 1998, Yiorgos Adamopoulos wrote: > > > > > I keep getting ``connection refused'' from any *.gr site that I have tried > > Same with www.mbone.com. The DNS entries are gone so I presume that site > is history... can anyone clarify that is the case and wether someone else > will maintain the mbone archives and resource directory that used to > reside at www.mbone.com? > > -- Denis > From rem-conf Wed Apr 29 04:10:58 1998 From rem-conf-request@es.net Wed Apr 29 04:10:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yUUcV-0002gt-00; Wed, 29 Apr 1998 04:01:47 -0700 Received: from rumor.research.att.com [192.20.225.9] by mail1.es.net with smtp (Exim 1.81 #2) id 0yUUcU-0002gj-00; Wed, 29 Apr 1998 04:01:46 -0700 Received: from research.att.com ([135.207.30.100]) by rumor; Wed Apr 29 06:57:26 EDT 1998 Received: from alliance.research.att.com ([135.207.26.26]) by research-clone; Wed Apr 29 06:59:35 EDT 1998 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id GAA26946; Wed, 29 Apr 1998 06:59:23 -0400 (EDT) Received: (from kkrama@localhost) by windsor.research.att.com (8.8.7/8.8.5) id GAA01142; Wed, 29 Apr 1998 06:59:24 -0400 (EDT) From: "K. K. Ramakrishnan" Message-Id: <980429065924.ZM1140@windsor.research.att.com> Date: Wed, 29 Apr 1998 06:59:23 -0400 In-Reply-To: Melinda Shore "Re: RTP over ATM ?" (Apr 28, 3:13pm) References: <199804281913.PAA15027@liberator.cit.cornell.edu> X-Mailer: Z-Mail (4.0.1 13Jan97) To: kkrama@research.att.com, Carsten Bormann , Melinda Shore Subject: Re: RTP over ATM ? Cc: MBONE@ISI.EDU, Peter Hoermann , rem-conf@es.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We have recently proposed that the ideas of header compression for RTP/UDP/IP be used when carrying RTP payloads over ATM using AAL5. If you "model" and ATM VC as a point to point virtual link, then you can carry the compressed header in the AAL5 trailer (a sequence number is needed, which we propose should be in the U-U field; everything else is already there, with the VC providing the function of the context ID). The rest of the trailer (length, CRC) provides useful and necessary functionality. This way, you get reasonable efficiency when carrying real-time data over ATM using AAL5. In particular, with 5 msec G.711 voice, a cell carries all the needed information, including the AAL5 trailer. We use a "header extension" bit in the U-U field to allow us to communicate uncompressed (partial or full) headers. K. K. Ramakrishnan -- K. K. Ramakrishnan Email:kkrama@research.att.com AT&T Labs-Research, Rm. A155 Tel: (973)360-8766 180 Park Ave, Florham Park, N.J. 07932 Fax: (973) 360-8050 URL: http://www.research.att.com/info/kkrama From rem-conf Wed Apr 29 14:50:23 1998 From rem-conf-request@es.net Wed Apr 29 14:50:22 1998 Received: from list by mail2.es.net with local (Exim 1.81 #2) id 0yUeUR-0003wb-00; Wed, 29 Apr 1998 14:34:07 -0700 Received: from (server) [198.252.169.226] by mail2.es.net with smtp (Exim 1.81 #2) id 0yUeUE-0003wA-00; Wed, 29 Apr 1998 14:33:55 -0700 Date: Wed, 29 Apr 1998 13:57:18 From: To: Subject: Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please take 2 minutes of your time to read this letter and consider what it says. Like the instructions say, read it, print it, then read it again! thank you $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ This is a LEGAL, MONEY-MAKING PHENOMENON. PRINT this letter, read the directions, THEN READ IT AGAIN !!! You are about to embark on the most profitable and unique program you may ever see. Many times over, it has demonstrated and proven its ability to generate large amounts of cash. This program is showing fantastic appeal with a huge and ever-growing on-line population desirous of additional income. This is a legitimate, LEGAL, money-making opportunity. It does not require you to come in contact with people, do any hard work, and best of all, you never have to leave the house, except to get the mail and go to the bank! "This truly is that lucky break you've been waiting for! Simply follow the easy instructions in this letter, and your financial dreams can come true! When followed correctly, this electronic, multi-level marketing program works perfectly...100% EVERY TIME!" Thousands of people have used this program to: - Raise capital to start their own business - Pay off debts - Buy homes, cars, etc., - Even retire! "This is your chance, so don't pass it up!" ---------------------------------------------------------------------------------- OVERVIEW OF THIS EXTRAORDINARY ELECTRONIC MULTI-LEVEL MARKETING PROGRAM ---------------------------------------------------------------------------------- Basically, this is what we do: We send thousands of people a product for $5.00 that costs next to nothing to produce and e-mail. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the U.S. allows you to recruit new multi- level business online (via your computer). The products in this program are a series of four business and financial reports costing $5.00 each. Each order you receive via "snail mail" will include: * $5.00 cash * The name and number of the report they are ordering * The e-mail address where you will e-mail them the report they ordered. To fill each order, you simply e-mail the product to the buyer. THAT'S IT! The $5.00 is yours! This is the EASIEST electronic multi-level marketing business anywhere! FOLLOW THE INSTRUCTIONS TO THE LETTER AND BE PREPARED TO REAP THE STAGGERING BENEFITS! ******* I N S T R U C T I O N S ******* This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if you don't order them). * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR RETURN POSTAL ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. * When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "d" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, replace the name and address under REPORT #1 with your name and address, moving the one that was there down to REPORT #2. c. Move the name and address that was under REPORT #2 down to REPORT #3. d. Move the name and address that was under REPORT #3 down to REPORT #4. e. The name and address that was under REPORT #4 is removed from the list and has NO DOUBT collected a very large sum of money. Please make sure you copy everyone's name and address ACCURATELY!!! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. 4. Now you're ready to start an advertising campaign on the WORLDWIDE WEB! Advertising on the WEB is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Another avenue which you could use for advertising is e-mail lists. You can buy these lists for under $20/2,000 addresses or you can pay someone a minimal charge to take care of it for you. BE SURE TO START YOUR AD CAMPAIGN IMMEDIATELY! 5. For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out, with YOUR name and address on it, will be prompt because they can't advertise until they receive the report! ------------------------------------------ AVAILABLE REPORTS ------------------------------------------ ***Order Each REPORT by NUMBER and NAME*** Notes: - ALWAYS SEND $5 CASH FOR EACH REPORT - ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL - Make sure the cash is concealed by wrapping it in at least two sheets of paper - On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your postal address. _________________________________________________________________ REPORT #1 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES" Q4224 P.O. Box 5085 Hickory, NC 28603 ORDER REPORT #1 FROM: _________________________________________________________________ REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES" BTL P.O. Box 1104 Ft. Gibson, OK 74434 ORDER REPORT #2 FROM: _________________________________________________________________ REPORT #3 "SOURCES FOR THE BEST MAILING LISTS" Pulse Web Ventures P.O. Box 2577 Muskogee, OK 74402 ORDER REPORT #3 FROM: _________________________________________________________________ REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS" KBL P.O. Box 624-4960 Irvine, CA 92616-4960 ORDER REPORT #4 FROM: ____________________________________________________________ ---------------------------------------------------------------- HERE'S AN EXAMPLE OF HOW THIS AMAZING PLAN CAN MAKE YOU $MONEY$ ---------------------------------------------------------------- Let's say you decide to start small just to see how well it works. Assume your goal is to get 10 people to participate on your first level. (Placing a lot of FREE ads on the internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below. 1st level--your 10 members with $5............................$50 2nd level--10 members from those 10 ($5 x 100)...............$500 3rd level--10 members from those 100 ($5 x 1,000)..........$5,000 4th level--10 members from those 1,000 ($5 x 10,000)......$50,000 THIS TOTALS --------------------------------------------->$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! THINK ABOUT IT! Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an internet connection and e-mail is FREE!!! REPORT#3 shows you the most productive methods for bulk e-mailing and purchasing e-mail lists. Some list & bulk e-mail vendors even work on trade! About 250,000 new people get online every month, just on one service alone! *******TIPS FOR SUCCESS******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report to comply with the U.S. Postal & Lottery Laws, Title 18,Sections 1302 and 1341 or Title 18, Section 3005 in the U.S. Code, also Code of Federal Regs. vol. 16, Sections 255 and 436, which state that "a product or service must be exchanged for money received." * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, the results WILL undoubtedly be SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! *******YOUR SUCCESS GUIDELINE******* Here are some guidelines to follow that can better guarantee your success: If you don't receive 10 to 20 orders for REPORT #1 within two weeks, continue advertising until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don't, continue advertising until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails (500,000 or more) and start the whole process again! There is no limit to the income you will generate >from this business! You can also ask a qualified bulk e-mailer for tips on what is working the best. Find out if he or she is participating in the program. NOTE: If you need help with starting a business, registering a business name, how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal agency) for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business taxes. *******T E S T I M O N I A L S******* This program does work, but you must follow it EXACTLY! Especially the rule of not trying to place your name in a different position, it won't work and you'll lose a lot of potential income. I'm living proof that it works. It really is a great opportunity to make relatively easy money, with little cost to you. If you do choose to participate, follow the program exactly, and you'll be on your way to financial security. Sean McLaughlin, Jackson, MS My name is Frank. My wife, Doris, and I live in Bel-Air, MD. I am a cost accountant with a major U.S. Corporation and I make pretty good money. When I received the program I grumbled to Doris about receiving "junk mail." I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work. Doris totally ignored my supposed intelligence and jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work... well, the laugh was on me! Within two weeks she had received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it all figured and that it wouldn't work. I AM a believer now. I have joined Doris in her "hobby." I did have seven more years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM. Frank T., Bel-Air, MD I just want to pass along my best wishes and encouragement to you. Any doubts you have will vanish when your first orders come in. I even checked with the U.S. Post Office to verify that the plan was legal. It definitely is! IT WORKS!!! Paul Johnson, Raleigh, NC The main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still coming in. Sincerely yours, Phillip A. Brown, Esq. Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size post office box crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where in the U.S. the people live. There simply isn't a better investment with a faster return. Mary Rockland, Lansing, MI I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program... 11 months passed then it came...I didn't delete this one!...I made more than $41,000 on the first try!! D. Wilburn, Muncie, IN This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! Charles Fairchild, Spokane, WA ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM!!! From rem-conf Thu Apr 30 00:57:15 1998 From rem-conf-request@es.net Thu Apr 30 00:57:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yUo4y-0002oM-00; Thu, 30 Apr 1998 00:48:28 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yUo4r-0002np-00; Thu, 30 Apr 1998 00:48:21 -0700 Received: from big-bear (big-bear.precept.com [204.162.119.41]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id AAA24050; Thu, 30 Apr 1998 00:47:19 -0700 (PDT) Date: Thu, 30 Apr 1998 00:47:19 -0700 (PDT) From: Stephen Casner X-Sender: casner@big-bear To: rem-conf@es.net Subject: Minutes of AVT meeting at IETF41 - LA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Minutes of the Audio/Video Transport Working Group Reported by Steve Casner 1. Introduction and status The AVT working group met for two very full sessions at the 41st IETF meeting in Los Angeles. The biggest topic was a continuation of the discussion that began at the previous IETF regarding a "generic payload format" to handle the hundreds of existing codecs without requiring a payload format specification to be written for each. There were also two presentations on RTP for MPEG-4 which are related because the mechanisms in MPEG-4 are similar to a generic payload format. AVT's primary outputs, the Real-time Transport Protocol and the companion RTP profile for audio/video conferencing, remain at Proposed Standard status. Internet-Draft revisions of both have been posted in the working toward advancement to Draft Standard status. That step was not achieved before this meeting, but it is hoped that revisions will be completed before the next IETF. Several issues raised on the mailing list were presented and discussed in the second session. Since the last IETF meeting, a revision of the payload format for MPEG-1 and -2 video originally published in RFC2038 was published as RFC2250, still at Proposed Standard status. The IP/UDP/RTP header compression Internet-Draft remained on hold in IESG Last Call on a chain of document dependencies ending at IPSec, but it was reported that decisions allowing IPSec to proceed were completed at this meeting. Before the meeting, IESG Last Call was requested for two additional drafts: a revision of the JPEG video payload format, and a new payload format for BT.656 video. At this meeting, there were discussions of the next round of drafts as described in the following sections. 2. New drafts ready for WG last call Colin Perkins gave a brief presentation the revised draft "Options for Repair of Streaming Media", draft-ietf-avt-info-repair-03.txt. This draft covers loss mitigation schemes and recommendations for when they may be used appropriately. This revision includes discussion of a "reasonable operating point" for these schemes as suggested by the TCP throughput equivalence formula. There were no objections to issuing last call for comments from the working group on this draft before requesting publication as an Informational RFC. A second informational draft, written by Mark Handley during the last meeting, is draft-ietf-avt-rtp-format-guidelines-00.txt,.ps. This draft is a first attempt to capture the group's experience in designing payload formats, and is not considered ready for publication yet. However, the working group is requested to read the draft and contribute additional ideas. The third draft up for consideration is the H.263+ payload format which was presented in detail at the last meeting. Joerg Ott described the revised draft-ietf-avt-rtp-h263-video-01.txt which includes a number of changes that were announced at the last meeting to reorganize the payload header for improved efficiency without changing the overall functionality. This revision also removes the controversial feedback backchannel which will be revisited in a future separate draft that might be applied to other payloads in addition to H.263+. The authors consider the current draft ready for working group last call, and there were no objections to proceeding. However, Michael Speer suggested that an appendix be added to show how to map >from the current H.263 payload format in RFC2190 to the new one. Carsten Bormann countered that this should be a separate document and agreed to write it. There was some discussion of whether the new draft should obsolete RFC2190: some are concerned about having two Proposed Standard RFCs for H.263 payload formats, while others are concerned about obsoleting a spec that is referenced by the ITU and implemented in products. In a discussion on the mailing list since the meeting, it was agreed that the new RFC would be marked as "updating" the old one and would include a paragraph describing the relationship (the new one should be used for new implementations). Both RFCs will be Proposed Standards, but RFC2190 may be moved to Historic if that seems appropriate when the new RFC is ready to move to Draft Standard. The static payload type 34 will continue to be assigned to RFC2190, while the new payload format will use a dynamic payload type. 3. Format parameters in SDP Some encodings, such as H.263, may have optional modes or other parameters that need to be communicated out-of-band with respect to the RTP session. The "a=fmtp" attribute of the Session Description Protocol is one method. The recent draft-koskelainen-sdp263-01.txt defines a format parameter syntax for H.263. This draft is based on the 1996 version of H.263 (to which RFC2190 corresponds), but it includes some features of the 1998 version (H.263+). Given the imminent publication of H.263+, it does not make sense to move this draft forward before extending it to cover all of what's needed for H.263+. However, the authors of the H.263+ payload format assert that the converse is not true because H.263+ will be used with a variety of out-of-band mechanisms. When used with SDP, an H.263+ codec can operate "pretty well" with default parameters until the sdp263 draft is revised and published. The encoding of format parameters in SDP is also a component of the next topic, generic payload formats, in order to describe what encoding is being carried. One question to consider is whether there should be any standardization of parameter syntax within fmtp, or whether each payload format may define its own. 4. Generic payload formats The biggest topic of this meeting was a continuation of the discussion that began at the previous IETF regarding a generic payload format for the hundreds of existing codecs. It is deemed impractical to create an RFC to define an optimized payload format for each of them, especially since the details that would allow optimization may be unavailable for some. If one or more generic payload formats can be defined, then the problem is reduced to defining and managing the encoding namespace plus conveying the encoding name and parameters out of band. However, one may be concerned that the introduction of a generic payload format would stifle development of optimized payload formats as new encodings are created. 4.1 draft-periyannan-generic-rtp-00.txt The first of two proposals was presented by Alagu Periyannan. It defines a set of three packetization schemes A, B and C that can be applied as appropriate for different encodings, plus a mechanism within SDP to convey the encoding and packetization information out of band to receivers. The first two schemes are very simple and introduce no additional packetization overhead. Scheme A follows the model of packetization for many of the audio encodings in the RFC1890 profile where the number of samples or frames may be determined from the length of the packet, and all all samples or frames are smaller than the MTU so that no fragmentation is required. Since scheme A may be used for media other than audio, it was suggested that the marker bit be defined to indicate the first packet after "a gap in the timeline" rather than the start of a talkspurt. When the size of a sample (frame) may exceed the MTU, then scheme B may be used. Following the model of most existing video payload formats, fragmentation is indicated by the RTP timestamp being the same on all fragments of the sample, and the marker bit is set on the last fragment. Since the internal structure of the data is not known to the generic payload format, fragmentation is done without respect to any internal structure of the data. Loss of a fragment implies loss of the whole sample. Scheme C is much more complicated; it should be used only when the assumptions of schemes A and B don't apply. To accommodate samples sizes that may vary from a fraction of the MTU to several times the MTU, as may occur with some video encodings, scheme C allows each packet to carry either multiple samples or a fragment of a sample. Each sample or fragment is preceded by a scheme C header that gives the length of a whole sample or the offset of a fragment. The header size is 4, 8 or 12 bytes and may include a relative timestamp (offset >from the RTP timestamp) when multiple samples are aggregated and the spacing of samples cannot be assumed. The header may also include the sample duration and a key-sample flag when the encoding depends on external framing for this information. To indicate the selection of scheme A/B/C, it is proposed that the syntax of the encoding name in the SDP "a=rtpmap" attribute be extended to optionally include a namespace and a packetization scheme. Additional encoding parameters would be carried in the fmtp attribute as mentioned earlier. 4.2 draft-klemets-generic-rtp-00.txt The second proposal was presented by Anders Klemets (the draft is available from http://microsoft.com/asf/resources/). This proposal defines a single packetization scheme similar to scheme C in that multiple samples or fragments may be carried in one packet and each is prefixed with a header. To minimize overhead, 32-bit alignment is sacrificed so the size of the header can vary from 1 to 8 bytes (or more if "extension data" is included). As in scheme C, the header may include fragment offset, sample length, and timestamp delta fields. In addition, there is a fragment sequence number field that allows distinguishing between two kinds of fragmentation: codec-unaware, where the samples are fragmented at arbitrary boundaries during packetization; codec-aware, where the fragment boundaries are chosen by the application layer, perhaps at authoring time; or a nesting of the two. It is possible to include fragments from multiple frames in one packet, which the rules of scheme C do not allow. The extension data mechanism may be used to include arbitrary additional information into the header for each sample, such as a send time timestamp, duration, or a key frame flag. Some extensions may be hints that could be safely ignored, while others are mandatory. It is proposed that the set of extensions in use be specified in SDP. This would provide a means of "specializing" the generic payload format for a particular encoding. On the other hand, Alagu Periyannan observed that defining the details of the extension mechanism might be as much work as specifying a real payload format for the codec. This scheme has low overhead and is very flexible. The tradeoff is that decoding the set of fields included in the header requires a fairly complicated sequence of decisions based on bits in the header, the RTP marker bit, and the position in the sequence of header and data objects. 4.3 Discussion There was an extended discussion of the issues surrounding generic payload formats. There are two primary parts of the problem: - the packetization format and the set of features provided; one question is whether to have a single format or multiple formats, and a second question is the design of the format(s). - encoding namespaces, registration procedures, and how to carry the encoding and/or format names and parameters out of band, for example in SDP. The packetization formats themselves received less of the discussion this time. It was noted that there are similarities between the Klemets proposal and Scheme C in the Periyannan proposal. Eric Fleischman suggested that the four authors of the two drafts work together to produces one merged proposal also incorporating the ideas >from the discussion. The authors present all agreed. Mark Handley liked the idea of having a set of packetization formats, but suggested that they be used as a shortcut method of specifying an RTP payload format draft. In "three lines" one could specify that for a particular encoding, a particular one of the packetization schemes would be used, and if necessary, what parameters would be carried in the fmtp attribute. Colin Perkins observed that these formats might also serve as templates to facilitate the definition of encoding-specific payload formats without having to define the whole payload format from scratch. There were several issues related to naming. One goal is to have a single name registered in the IANA namespace to refer to any particular encoding. However, it will most likely be necessary to allow incorporation by reference of other encoding name registries sponsored by vendors, and there are already instances of multiple registrations of the same encoding in those registries. IANA can't be expected to determine which registrations are equivalent. Eric Fleischman expressed the hope that the encoding vendors, as participants in the AVT community, could go back and examine the registrations to determine which are equivalent to the preferred names in the IANA (MIME) namespace. Mark Handley summarized the process to say that the encoding names would be entered into the common namespace. There would be a flag associated with each entry to indicate whether or not it is appropriate for transport via RTP. For those that are easily mapped to one of the generic packetization schemes, the name of the selected scheme would be included in the registration, and that's all that would be required to use the encoding over RTP. One would want that table of encodings to be actively maintained by IANA and to be available in machine readable form. Rob Lanphier remarked that keeping the selection of packetization scheme implicit in the table avoids the problem of a server choosing an inappropriate scheme and the client having to be prepared to handle all the packetization choices for all data types even when some don't make sense. However, others were concerned about having to install the table on servers and clients and keep it up-to-date. This issue requires further discussion. To indicate the encoding in SDP, the MIME major types goes on the "m=" media selection line, and the minor type goes into the "a=rtpmap" attribute. Given that names from the vendor subspace of the MIME namespace specify the codec as a parameter of the type (see draft-fleischman-codec-subtree-02.txt), the syntax of those parameters might need to be modified for inclusion in the rtpmap. It might also be necessary to extract some of the parameters into the fmtp attribute. The details of this design are part of the work to be done in the merged draft. 5. MPEG-4 Two presentations were given on an RTP payload format and RTCP usage for MPEG-4. This work is at an early stage so there are a number of open issues to be resolved. There are some problems in fitting MPEG-4 and RTP together because of overlap in their functionality; in particular, at what level multiplexing of streams should be done. MPEG-4 is in a sense a generic payload format because the MPEG-4 Systems layer can carry data from many different codecs. Therefore, we might expect some synthesis between these two efforts. 5.1 MPEG-4 payload format: draft-ietf-avt-rtp-mpeg4-00.txt Michael Speer presented the proposed RTP payload format for MPEG-4. This format supports packetization of both single Elementary Streams and multiple Elementary Streams bundled into a FlexMux stream. For single streams, the Access Unit Layer in the MPEG-4 architecture fragments data into AL-PDUs according to the MTU. The AL-PDU can contain separate timestamps for composition time, decode time, and wallclock time, and these are of adjustable size and resolution. The composition timestamp is to be extracted from the AL-PDU and carried as the RTP timestamp unless it is longer than 32 bits, in which case the FlexMux encapsulation should be used. FlexMux encapsulation is also called for if the Access Unit Layer cannot fragment according to the MTU, and when there are many Elementary Streams sending many small data units such that sending each stream in a separate RTP session would incur too much overhead or require too many addresses and ports. In the FlexMux encapsulation, the RTP timestamp carries the wallclock time when the packet is sent. The data-related timestamps are carried in the original AL-PDUs as fragmented into FlexMux PDUs. Dave Oran asked why not send the FlexMux packets directly over UDP since that mode is not really using the features of RTP. The response >from Vahe Balabanian and Reha Civanlar was that operation over UDP was the original design, but that it is desired to take advantage of RTCP feedback and to allow multiplexing with non-MPEG-4 streams that are carried in RTP. Henning Schulzrinne observed that we should carefully consider whether FlexMux fits into RTP or whether it is a specific instance of a more generic problem of multiplexing streams into RTP that should be solved more generically. A related issue is whether elementary streams encoded in MPEG-1 or H.263 or other encodings for which there are specific RTP payload formats defined should use those formats instead of a generic MPEG-4 payload format. These issues are to be discussed further on the mailing list. 5.2 DMIF and RTP/MPEG-4: draft-ietf-avt-rtp-mpeg4-dmif-00.txt Vahe Balabanian described the role of DMIF (Delivery Multimedia Integration Framework) when using MPEG-4 with RTP and RTCP. DMIF defines the interface the MPEG--4 system will use RTP including the signalling and QoS negotiation which is outside the bounds of RTP. Using feedback obtained via RTCP, when the loss rate is to high to meet the requested QoS, DMIF might signal a reduction in the number of layers from a layered encoding to be received. Unfortunately, the QoS measures provided by RTCP don't match what's defined in DMIF exactly. In the FlexMux case, the number of AL-PDUs carried in an RTP packet will generally not be one, so the AL-PDU loss probability will not match the RTP packet loss probability that RTCP provides. DMIF also wants to provide a "gap loss" measure, but RTCP would require an extension to carry this. The methods for calculating jitter and delay are different between RTCP and DMIF as well. One question is what should be done when the underlying network layers cannot meet the interface specified by DMIF? There was some discussion of which AL-PDU timestamp should be carried in the RTP timestamp, considering the effect on jitter calculation. The jitter will be inaccurate if the timestamp represents the composition time but the data is sometimes sent early for rate smoothing, or if the timestamp is non-monotonic for interpolated video frames. Steve Casner pointed out that the jitter value in RTCP is intended as a comparative measure between streams or at different times rather than as an absolute measure. The selection of timestamps is another issue to be discussed on the mailing list. 6. Revision of RTP Spec and A/V Profile The discussion of changes to the RTP spec and A/V profile was abbreviated because of time limitations. The current drafts are available as draft-ietf-avt-rtp-new-00.txt, .ps for the main spec and draft-ietf-avt-profile-new-02.txt, .ps for the profile. The plan is to revise these drafts to incorporate changes discussed at the last meeting and then put the drafts forward for publication as revised RFCs. Steve Casner pointed out that as the specifications advance to Draft Standard, any features that have not been demonstrated to be interoperable must be dropped. This must be considered as we make changes. Most of the changes have been in algorithms such as the RTCP interval calculation rather than in the protocol on the wire, and are not expected to be problematic. Three topics from the mailing list were discussed: - A request was made for a means to add application-specific extensions to the RTCP RR packet. Mark Handley and Van Jacobson expressed concern about the negative impact this would have on interoperability. The general sentiment of the group was that a new RTCP packet type should be allocated instead to carry the additional information. - There have been a number of suggestions for redefining the interval over which the RTCP RR "loss fraction" is calculated. The problem is that when the RTCP interval is long, this value does not carry much information. However, there are enough potential problems with trying to define how the loss fraction should be calculated over a shorter interval that there was no consensus for changing it. - A request was received for a static payload type to be assigned to the Qclp audio encoding. As had been discussed in Munich, it was agreed that the RTP Profile draft should be revised to say no more static payload types would be assigned. Those that are already assigned should be considered "default" values in the dynamic payload type table, and may be overwritten once all the unassigned values have been used for dynamic types within a session. However, since the new policy has not yet been published, the request for Qclp should be allowed. 7. Payload format for generic FEC Jonathan Rosenberg presented an update on draft-ietf-avt-fec-02.txt which specifies a "meta payload format" to add forward error correction. The primary change was that the added FEC packets are sent on a separate stream rather than appearing within the sequence number space of the media stream. The means of separation may vary depending upon the application, for example using a different multicast address or port, or as a redundant coding in the same stream per RFC2198. This allows the sequence numbers and timestamps of the media stream to behave nicely so FEC-incapable receivers are not confused and so FEC-capable receivers can tell which packets are lost. On the FEC packets, it was agreed that the RTP timestamp on the FEC packets should represent the time when the FEC packets are sent rather than using the minimum timestamp from the covered media packets. However, the FEC timestamps must be in the past with respect to the media packets in order to use RFC2198. To make the change to separate streams, an explicit timestamp recovery field is added to the FEC header. This field was proposed to be 8 bits, but Steve Casner pointed out that the timestamp increment between video frames is a minimum of 3003. Two possible changes were discussed: make the TS recovery field 16 bits and reduce the packet pattern mask to be 8 bits, or increase the FEC header from 64 to 96 bits to allow a 32-bit TS recovery field. There were not strong opinions either way, but this "will be worked out". The draft now specifies a simple recovery algorithm as an example. Applications may implement more complex algorithms to give improved performance. 8. Elevating RTP to protocol Jonathan Rosenberg gave (part of) a second presentation on draft-rosenberg-rtpproto-00.txt which proposes that RTP be elevated to an IP protocol type of its own, parallel to UDP and TCP. The motivation is to make RTP packets easier to identify for purposes of classification in differentiated services, header compression, firewalls, etc. Response to this proposal was primarily negative due to concerns about interoperability problems it would impose without really solving the problems it was intended to address. Van Jacobson said that differentiated services would be driven off the TOS byte in the IP header and established according to the full "transport signature" and not just the protocol type. And for RTP header compression, the UDP traffic can also be compressed even when the following header is not RTP, so one would want to apply compression to both protocol types even if RTP did have a different one. Ross Finlayson felt that breaking away from the already supported UDP protocol would make RTP too hard to deploy in hosts, while Dave Oran expressed concern about needing to get access lists changed in routers all over the place to allow a new protocol type through. The consensus was not to proceed. 9. Wrapup Because the session ran over time, there were two agenda topics not discussed. Henning Schulzrinne has asked that the working group consider reactivating the idea of aggregation of multiple, parallel RTP streams. Jonathan Rosenberg presented this in December, 1996, but it was not ready for full consideration at that point. Since then the ideas have been refined and a draft will be posted after IETF. The second item was to note that several drafts have been recently posted regarding how RTP may be recorded and/or played back from different file formats. Should the working group take any action on these documents other than to provide feedback so they can be refined and published as informational RFCs? That is, should there be any standardization of an "RTP file format"? Please send comments on this to the mailing list. 10. Slides The presentation slides are available as follows: Agenda, status, H.263-SDP, RTP changes: ftp://ftp.isi.edu/mbone/avt/ietf41/casner.ppt ftp://ftp.isi.edu/mbone/avt/ietf41/casner-6up.ps.gz Options for Repair: http://www.cs.ucl.ac.uk/staff/c.perkins/slides/IETF-LA.ps.gz H.263+ payload format: ftp://ftp.isi.edu/mbone/avt/ietf41/ott.ppt ftp://ftp.isi.edu/mbone/avt/ietf41/ott-6up.ps.gz Generic payload format: ftp://ftp.isi.edu/mbone/avt/ietf41/periyannan.ps.gz ftp://ftp.isi.edu/mbone/avt/ietf41/klemets.ppt ftp://ftp.isi.edu/mbone/avt/ietf41/klemets-6up.ps.gz MPEG-4: ftp://playground.sun.com/pub/avt/mpeg4-rtp.ps http://drogo.cselt.it/mpeg/documents/dmif-avt.zip or ftp://ftp.isi.edu/mbone/avt/ietf41/balabanian.ppt.gz ftp://ftp.isi.edu/mbone/avt/ietf41/balabanian-6up.ps.gz FEC: http://www.cs.columbia.edu/~jdrosen/papers/ietf_fec_mar98.ppt http://www.cs.columbia.edu/~jdrosen/papers/ietf_fec_mar98.pdf RTP as protocol: http://www.cs.columbia.edu/~jdrosen/papers/ietf_rtpasproto_mar98.ppt http://www.cs.columbia.edu/~jdrosen/papers/ietf_rtpasproto_mar98.pdf From rem-conf Thu Apr 30 10:40:32 1998 From rem-conf-request@es.net Thu Apr 30 10:40:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yUx2N-0006i7-00; Thu, 30 Apr 1998 10:22:23 -0700 Received: from udecc.engr.udayton.edu [131.238.32.17] by mail1.es.net with smtp (Exim 1.81 #2) id 0yUx2M-0006hY-00; Thu, 30 Apr 1998 10:22:22 -0700 Received: from ensun101.UD.Engr by udecc.engr.udayton.edu (5.0/SMI-SVR4) id AA00657; Thu, 30 Apr 1998 13:22:18 -0400 X-Organization: University of Dayton, School of Engineering, Dayton OH Received: by ensun101.UD.Engr (SMI-8.6/SMI-SVR4) id SAA06158; Fri, 17 Apr 1998 18:13:21 -0400 Message-Id: <199804172213.SAA06158@ensun101.UD.Engr> Subject: CFP: Arch. Prot. & QoS for Future Internet To: rem-conf@es.net Date: Fri, 17 Apr 1998 18:13:19 -0400 (EDT) Reply-To: atiq@engr.udayton.edu (Mohammed Atiquzzaman) From: atiq@engr.udayton.edu (Mohammed Atiquzzaman) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit content-length: 3013 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CALL FOR PAPERS European Transactions on Telecommunications (ETT) Special Issue on ARCHITECTURES, PROTOCOLS AND QUALITY OF SERVICE FOR THE INTERNET OF THE FUTURE Guest Editors: Matteo D'Ambrosio and Mohammed Atiquzzaman Recent advances in switching and transmission technologies allow the implementation of very high speed networks that are changing the face of the Internet. In the next Telecommunication Age it will be possible to support new multimedia applications in a global environment and design new services on flexible platforms without upgrading the physical infrastrucure. In order to reach these goals many researchers are working on defining the new Network Architecture, which will be capable of offering transport and computation services to communication applications with stringent Quality of Service (QoS) requirements. New protocols and node implementations have to be envisioned with this objective in mind. The ETT Journal announces a forthcoming issue on "Architectures, Protocols and Quality of Service For The Internet Of The Future", that will be focused on (but not limited to) the following topics: - New node architectures for Switching and Routing at Gigabit Speeds - Multi-Protocol Label Switching (MPLS): design principles, network architecture and performance - Internetworking with ATM and High Speed Networks to offer QoS guarantees - Multimedia Services running on Heterogeneous Networks - Network and Transport Protocols in the Integrated Services Internet - QoS provision, multicast support and policy capabilities in Routing and Signalling Protocols - Differentiated Services Architectures - Open Control Architectures and Active Networks Prospective authors should email their manuscripts (PostScript format) or send five (5) hard copies to one of the Guest Editors listed below. The following deadlines will apply: - Submission of manuscripts June 30, 1998 - Notification of acceptance November 15, 1998 - Submission of final manuscript December 15, 1998 - Publication Date March-April, 1999 Guest Editors Matteo D'Ambrosio Mohammed Atiquzzaman Networking Department Department of Electrical & CSELT Computer Engineering v. Reiss Romoli 274 University of Dayton 10148 Torino Dayton, Ohio 45469-0226 Italy USA phone: +39 11 2285006 phone: +1 937 229-3183 fax: +39 11 2285069 fax: +1 937 229-4529 e-mail: matteo.dambrosio@cselt.it e-mail: atiq@engr.udayton.edu More information about the special issue can be obtained from http://www.engr.udayton.edu/faculty/matiquzz/ett-cfp.html Note: If a paper is not accepted for the special issue, it will be considered for publication in one of the regular issues of ETT. From rem-conf Thu Apr 30 11:59:06 1998 From rem-conf-request@es.net Thu Apr 30 11:59:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yUyI7-0000Kc-00; Thu, 30 Apr 1998 11:42:43 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yUyI6-0000J0-00; Thu, 30 Apr 1998 11:42:42 -0700 Received: from procy.gi.com by GI.COM (PMDF V5.1-8 #7516) with SMTP id <01IWH9BW4GPW8YDPWY@GI.COM> for rem-conf@es.net; Thu, 30 Apr 1998 11:41:36 PDT Received: from cream.gi.com by procy.gi.com (4.1/GIVC1.0) id AA15239; Thu, 30 Apr 1998 11:41:33 -0700 (PDT) Received: by cream.gi.com (SMI-8.6/SMI-SVR4) id LAA21185; Thu, 30 Apr 1998 11:41:33 -0700 Date: Thu, 30 Apr 1998 11:41:33 -0700 From: lalwaney@procy.gi.com (poornima lalwaney) Subject: Transport signatures To: rem-conf@es.net Message-id: <199804301841.LAA21185@cream.gi.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-MD5: TO9yK0MYZ/5ho1fAzM+IfA== X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Van Jacobson mentioned authenticated transport signatures for identification and classification of traffic ( real-time or otherwise) at the last IETF in the context of identification of RTP packets. I would like to understand this issue better. What are the current transport signature mechanisms that have been implemented or are being considered in the avt, diffserv or ipsec WG's? Thanks.. Poornima ------------------------------------------ Poornima Lalwaney General Instrument Corporation plalwaney@gi.com 619-404-3494 (Phone) ------------------------------------------- From rem-conf Thu Apr 30 13:01:37 1998 From rem-conf-request@es.net Thu Apr 30 13:01:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0yUzRP-0001Wb-00; Thu, 30 Apr 1998 12:56:23 -0700 Received: from cs.gmu.edu [129.174.87.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0yUzRO-0001WL-00; Thu, 30 Apr 1998 12:56:22 -0700 Received: from markov (markov [129.174.87.29]) by cs.gmu.edu (8.8.5/8.8.5) with SMTP id PAA04204; Thu, 30 Apr 1998 15:55:10 -0400 (EDT) From: Sanjeev Setia Received: by markov (SMI-8.6) id PAA11408; Thu, 30 Apr 1998 15:57:40 -0400 Date: Thu, 30 Apr 1998 15:57:40 -0400 Message-Id: <199804301957.PAA11408@markov> To: alg@comm.toronto.edu, apc@ee.nthu.edu.tw, apc_members@hornbill.ee.nus.sg, cabernet-general@newcastle.ac.uk, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comsoc.tac@tab.ieee.org, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, dbworld@cs.wisc.edu, end2end-interest@isi.edu, enternet@bbn.com, f-troup@codex.cis.upenn.edu, fokus-user@fokus.gmd.de, g-troup@ccrc.wustl.edu, giga@tele.pitt.edu, hipparch@sophia.inria.fr, ieee_rtc_list@cs.tamu.edu, ieeetcpc@ccvm.sunysb.edu, isadsoc@fokus.gmd.de, itc@fokus.gmd.de, modern-heuristics@uk.ac.mailbase, multicomm@cc.bellcore.com, osimcast@bbn.com, rem-conf@es.net, reres@laas.fr, sb.all@ieee.org, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@ieee.org, xtp-relay@cs.concordia.ca Subject: ACM Sigmetrics '98/ Performance '98 Call for Participation X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleague, The SIGMETRICS '98/PERFORMANCE '98 Joint International Conference on Measurement and Modeling of Computer Systems will be held in Madison, Wisconsin, June 24-26, 1998. (Tutorials June 22-23). The First Workshop on Internet Server Performance (WISP) will be held in conjunction with the conference on June 23. The Advance Program, Hotel and Conference Registration forms, and other information about the conference can be found on the following web page: http://www.cs.gmu.edu/conf/sigmetrics98 Deadline for early registration: May 22, 1998 Program Co-Chairs: Garth Gibson (garth@cs.cmu.edu) & Guy Latouche (Guy.Latouche@ulb.ac.be) Tutorials Chair: Daniel Menasce (menasce@cne.gmu.edu) A limited amount of travel support for students is available from TeleGIF, a non profit corporation. For further information, check out the conference web page. Sanjeev Setia, Publicity Co-Chair